Является ли clocksource tsc неустойчивым, когда единственным источником синхронизации является jiffies?

Question

После отладки неустойчивой проблемы с tsc для BIOS продуктов моей компании, я подозреваю, что tsc может быть всегда нестабильным, когда единственным источником синхронизации является jiffies.

У меня ошибка: Clocksource tsc unstable (delta = -531266231 ns). Тогда ядро ​​выбрало jiffies, отличное от tsc. Единственными двумя источниками времени являются tsc и jiffies. Я пробовал Linux 2.6 и 3.2 с i386 и x64. Ядро сказало, что CPU фактически поддерживает постоянную tsc и инвариантную tsc.

После проверки исходного кода Linux я обнаружил, что tsc имеет флаг CLOCKSOURCE_MUST_VERIFY, а jiffies - нет. Я предполагаю, что если есть только два источника времени, jiffies и tsc, то jiffies будут сторожевым таймером. Однако, по сравнению с tsc, jiffies - очень плохой источник синхронизации, и поэтому я подозреваю, что tsc в этой ситуации всегда будет «неустойчивой», потому что для проверки это плохой сторожевой таймер.

Я также проверяю некоторые другие системы с хорошо работающими tsc и обнаруживаю, что у них есть другие источники времени, такие как Hpet или acpi_pm.

Поэтому, как я могу определить, возникает ли неустойчивость tsc от jiffies или некоторой ошибки в другом месте?

Answer 1

В Linux - в пользовательских приложениях - прочитайте time(7) и не использовать непосредственно ТСК, но использовать clock_gettime(2) (вероятно, с CLOCK_REALTIME).

Если компьютер подключен к Интернету, установите некоторый демон клиента NTPD.

Answer 2

Сегодня я протестировал изображение CentOS 6.6 i386 с минимальной установкой. По умолчанию у ядра были три временных источника: tsc acpi_pm jiffies. Одним из используемых был Clocksource tsc.

Затем я попробовал вариант acpi=off и обнаружил, что существует только два источника времени, tsc jiffies. Однако tsc не был неустойчивым и все еще использовался в качестве основного источника синхронизации. Поэтому тактика сторожевого пса не всегда будет отрицать tsc.

Я сделал вышеупомянутый эксперимент на рабочем столе Dell. Однако, с тем же жестким диском на другом компьютере, но с использованием BIOS моей компании, tsc все еще был нестабилен (также были использованы только два источника: tsc и jiffies, но были использованы jiffies). Я подозреваю, что была проблема с BIOS. Я знаю, что мой BIOS еще не поддерживал acpi, но я не уверен, что это причина.

Следовательно, он перескакивает на другой вопрос: есть ли какая-то конфигурация в BIOS может привести к неустойчивому tsc? Мой BIOS поддерживает процессор Intel и уже отключает управление питанием ЦП.

Answer 3

После некоторого эксперимента я сделал временный вывод: стабильность tsc связана с настройкой ACPI. Я тестировал с Aptio BIOS версии 2.15.1236 и стандартным ядром Linux 3.2.68.

Сначала я включил ACPI в конфигурации ядра и построил один bzImage, чей tsc оказался работоспособным (с другими источниками acpi_pm и hpet). Кроме того, даже я попытался использовать acpi=off в командной строке ядра для отключения acpi, clocksource tsc все еще хорошо работал с clocksource jiffies.

Во второй раз я выключаю ACPI в конфигурации ядра. В это время источник clock tsc был неустойчивым в построенном изображении ядра.Единственным оставшимся источником синхронизации является jiffies.

После некоторых других экспериментов я подозреваю, что tsc стабилен только тогда, когда BIOS и ядро ​​поддерживают ACPI. Я проверил некоторый форум и был проинформирован о том, что ACPI не был полностью отключен даже с acpi=off в командной строке Linux bootup. У моей собственной BIOS BIOS была некоторая ошибка в таблице ACPI, и поэтому она не смогла поддерживать стабильную tsc в изображении ядра Linux.

Однако это только мое предположение. Хотелось бы, чтобы эксперты говорили мне, прав я или нет. Я попытаюсь исправить ошибки таблицы ACPI в BIOS моей компании и обновить результаты моих дальнейших экспериментов.