Всегда ли источник тактовых импульсов tsc нестабилен, если единственным другим источником тактовых импульсов является jiffies?

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

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

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

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

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


linux tsc
person Walkingmind    schedule 02.05.2015    source источник
comment
Сегодня я протестировал образ CentOS 6.6 i386 с минимальной установкой. Ядро по умолчанию имеет три источника времени: tsc, acpi_pm и jiffies. Clocksource tsc используется.   -  person Walkingmind    schedule 04.05.2015

Ответы (3)


arrow_upward
2
arrow_downward

Сегодня я протестировал образ 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 и уже отключает управление питанием процессора.

person Walkingmind    schedule 04.05.2015

arrow_upward
1
arrow_downward

В Linux — в пользовательских приложениях — прочитайте время(7) и не используйте непосредственно TSC, а используйте clock_gettime(2) (вероятно, с CLOCK_REALTIME).

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

person Basile Starynkevitch    schedule 03.05.2015
comment
Я знаю это, но моей команде нужно провести некоторые специальные аппаратные тесты, которые зависят от этих источников тактовых импульсов. Когда нет tsc, тесты используют jiffies, но получают неточные результаты. Однако, если tsc нестабилен, результату теста нельзя доверять. - person Walkingmind; 04.05.2015
comment
Поэтому вам нужно использовать clock_gettime(3) и, возможно, clock_getres(3) - person Basile Starynkevitch; 04.05.2015
comment
Спасибо, завтра попробую в своей компании. - person Walkingmind; 04.05.2015

arrow_upward
1
arrow_downward

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

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

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

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

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

person Walkingmind    schedule 22.05.2015