Ладно, попробую развернуть факты лицом другим манером.
Я спорить не хочу, но я за истину и факты и четкое понимание сути явлений.
Надеюсь на этом закончим с этим делом.
Если предположить, что классические вещи типа int0(irq0) очень нестабильны, как это предположил
Serge, тогда непонятно,
как объяснить обратное - его стабильность???
Я имею ввиду то, что если присмотреться, то получается есть достаточно длительные интервалы времени, когда все стабильно, причем весьма!
Весьма настолько, что "такты лежат"
на одной линии, на четкой горизонтальной полке!
На картиночке про 915 это характерно видно, ниже даю укрупненный характерный кусок с выбросом для созерцания и медитации.
Макс точка выброса вверх - отсчет №4310 в массиве отсчетов.
Остается непонятным и необъяснимым, с точки зрения поверхностных, книжечных знаний о PC, почему вдруг точность ухудшается в некоторые моменты времени, причем аж на 2000, 3000 тактов процессора...?
И еще. Эти моменты имеют как бы "четкий рисунок" на оси времени и
похоже даже свою периодичность жизни...
Все знают (из книженок), что на всех машинах есть int0 созданную еще в XT древности.
Тогда еще недоумение - почему разные машины этот базовый, я бы сказал, механизм имеют
настолько разный?
Настолько некачественные кварцы? Настолько корявые или прогрессивные чипсеты? Настолько крива или хороша ФАПЧ??? Где больше погрешность таймера или период тактовой проца?
А может все же:
"линейка" и "микрометр" использованы верно и налицо потусторонняя жизнь
процессора где то, куда то, зачем то...
И тогда,
сей простой и дубовый метод выявляют главный факт -
отложенность аппаратных прерываний. Всех! Любых!
Похер SMMy чем как и кто пользуется HPET, LAPIC...
Он падла, сожрёт процессорного времени столько,
сколько папуаскод потребует (фактический фрагмент кода выше был).
Проц
проваливается в нирвану почти хаотическим образом и главное безобразие в том, что:
- ОС про это ничего не знает!
- ОС на это никак не повлияет, не изменит сути явления, его масштаб и т.д.!
- ОС предсказать ЭТО НЕ МОЖЕТ!
ну это для тех, кому в ОСестроении не нужны дребезги исчисляемые тысячами тактов проца, конечно.
Или для тех, кто четко хочет понимать, что достижимо в приложениях этой ОСи в плане равномерных временных вещей, "пульса", а что нет в принципе.
Теперь эти типа экстремумы.
ВСЕГДА рядом с большим выбросом есть УМЕНЬШЕННЫЙ соседний интервал.
Объяснение одно - SMI максимально неблагоприятно наложился на край int0 и тем самым возможно, что полностью показался из тени!
Тогда что такое тень?
"Полная тень" в данном случае - когда обработка SMI полностью умещается в интервале int0.
Вот тут то, в этом случае и лежат они "на полочке" ровненько ровненько, подрагивая видимо из за незначительных нестабильностей умножения, ФАПЧ, кварцев, набега двух фаз разного периода....
Когда же он вылезает (значит irq0 выставлен, но проц занят SMM и на него не реагирует никак), то это и объясняет, почему вдруг интервал прерывания увеличился и рядом другая соcедняя цифра - обязательно уменьшилась.
Как это выглядит изнутри (скептикам можно не читать).
В SMI есть ветвления конечно в зависимости от причин, условий, показаний... ,
поэтому процессорное время обработки меняется, а значит в некоторых случаях
наложение причин приводят к макимальным затратам процессора (такты), максимальной "длине" кода обработчика.
Допустим появился флаг, говорящий, что нужно кулер разогнать больше, т.к. порог температуры превышен.
Значит, нужно дополнительно отправить по SMBus сетевому адресу nn, допустим 4 байта.
SMBus шина очень медленная (это I2C по сути), особенно для современных процов.
Папуасский код
в угоду работы по медленной этой шине использует WAITы, что приводил выше, т.е. УБИВАЕТ полезное для нас, для ОСи процессорное время в тупейшим методом ECX+LOOP (грея проц между прочим)!
А ведь надо охлаждаться то, да!? Порог ведь превышен. Здорово получается.
LOOP это тебе не HLT.
Но это я так, к слову для полноты, этим количеством разогрева можно пренебречь.
Но это еще не все прелести.
Размышляем, усугубляемся...
Если вам "повезло" настолько, что на матери "запаяли", родили SMBus туповатый, медленный(а скорости там могут быть разными на порядок(и) ),
а проц очень скоростной, то дабы SMBus работал правильно, без сбоев, нужно...
Теперь внимание!
Нужно,
убить больше тактов проца методом ECX+LOOP!
Быстрее процессор - больше его тормозим ECX+LOOP!
Т.е. в ECX загружается бОльшая константа.
Это естественно т.к. это жертва, чтобы выдержать во временной диаграмме работы шины выдержку ту же, допустим 100мкс.
Худший случай с матерью (что можно сказать тоже, как неповезло), если производитель все барахло мониторинга задоровья, как раз на SMBus и навесил.
Таким образом возьмем два одинаковых проца, но на разных матерях их "потустороняя жизнь" будет отличаться. Жаль я не работаю в фирмочке, где свинчивают и продают машинки(материнки) публике. Вот бы статистички где набрать...