задержка вызова обработчика IRQ

здрасти.

Столкнулся с проблемой - периодические задержки вызова обработчика IRQ.
Проводился эксперимент:
Устанавливался собственный обработчик IRQ0.
Программировался таймер0 на 2кГц.
В обработчике замерялось время от вызова до вызова прерывания.
Все остальный аппаратные прерывания замаскированы + NMI.
Операционка DOS.
Прога писалась в PM под PMODEW. Думал сначала изза PM.
Переписал в RM - глюк повторился.

Результат: приблизительно каждый 250мс происходила задержка вызова прерывания на 1мс.

Почему такое происходит или как от этого избавиться?


Памагите пажаласта)

 

Незнаю! Конечно есть предположение что это SMM. Но всетаки цифры у тебя странные. Может ошибква в коде измерения переолнения не учтено? А если проверить через другой таймер RTC, ACPI Timer?
Может приведешь точные цифры?

 

pyrodex,Pavia это 99% SMI обработчик хавает!!!
pyrodex я такие же эксперименты проводил и потом написал ряд тестов под дос,
где была цель выключить ВСЕ кроме IRQ0 (т.к. якобы самый самый приоритеный....) и выяснить его стабильность... но все оказалось весьма печально....
О! Вот кажись нашел свой последний исходничек этого дела! Прошу протестить кто хочет "набить" статистику "разлетов" между IRQ0 срабатываниями. Итак:

Код (Text):

1. ;
2. ;         (с)     <<< VaStaNi >>>          vastani....pochta.net
3. ;
4. ;  Программулина создания массива тактовых итервалов IRQ0.
5. ;  Интервалы измеряются количеством тактов процессора,
6. ;  затрачиваемых на АППАРАТНЫЙ интервал между запросами IRQ0.
7. ;  Запрещены ВСЕ IRQ кроме IRQ0.
8. ;  Массив пишется в файл по окончании требуемого количества периодов = LEN.
9. ;  ЦЕЛЬ:
10. ;  Анализ стабильности периода таймерных задач, основой которых является
11. ;  высокоприоритеный аппаратный запрос IRQ0 для таймерного обработчика.
12.  
13. LEN     =  6000
14.  
15.         ORG     0x100
16.  
17.         xor     ax, ax
18.         mov     fs, ax
19.         mov     ebx, [fs:0x20]          ; взять живой вектор IRQ0 из памяти
20.         mov     [SaveIRQ0], ebx         ; сохраним для восстановления по окончании работы
21.         cld
22.         cli                             ; выключим прерывания
23.         dec     al        ;   mov     al, 0xFF                ; маска запрета всех IRQ8..IRQ15
24.         out     0xA1, al
25.         dec     al                      ; AL = 0xFE --> разрешен только IRQ0 (маска запрета IRQ1..IRQ7)
26.         out     0x21, al
27.         mov     ax, EmptyIRQ0           ; это смещение на процедуру замера по IRQ0
28.         mov     [fs:0x20], ax           ; меняем вектор
29.         mov     [fs:0x22], cs           ; меняем сегмент на фактический для нашего кода
30.         mov     di, DumpRDTSC           ; начало дампа замеров
31.         mov     cx, LEN
32.         mov     ax, (1193180/10000)     ; 10000 Гц
33.         call    SetTimer0               ; установим тики таймерного канала 0 частотой 20 Гц (IRQ0)
34.         sti                             ; запустим работу только IRQ0
35.         hlt
36.         hlt
37.         hlt
38.         rdtsc
39.         mov     ebx, eax
40. @rep:   hlt
41.         rdtsc                           ; читаем счетчики!
42.         push    cx
43.         push    eax
44.         sub     eax, ebx
45.          jnc    @ncor
46.         not     eax
47.         inc     eax
48. @ncor:  call    Int32_to_String
49.         mov     ax, 0x0A0D
50.         stosw
51.         pop     ebx
52.         pop     cx
53.         loop    @rep
54.         cli                             ; Все! Намеряли! Будем анализировать дальше
55.         mov     eax, [SaveIRQ0]
56.         mov     [fs:0x20], eax          ; восстановим вектор
57.         xor     ax, ax
58.         out     0x21, al
59.         out     0xA1, al                ; сняли все маски
60.         call    SetTimer0               ; восстановим тики таймерного канала IRQ0
61.         sti
62.         xor     cx, cx
63.         mov     ah, 0x3C
64.         mov     dx, FileName
65.         int     0x21
66.         mov     bx, ax
67.         mov     ah, 0x40
68.         mov     dx, DumpRDTSC
69.         mov     cx, di
70.         sub     cx, dx
71.         int     0x21
72.         mov     ah, 0x3E
73.         int     0x21
74.         int     0x20
75. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
76.  
77. EmptyIRQ0:
78.         mov    al, 0x20
79.         out    0x20, al
80.            IRET
81. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
82.  
83. SetTimer0:
84.         push  ax
85.         mov   al, 0x36                  ; выбрать счетчик 0, шестнадцатеричный счет, загрузить младший байт, затем старший
86.         out   0x43, al
87.         pop   ax
88.         out   0x40, al                  ; младший байт
89.         mov   al, ah
90.         out   0x40, al                  ; старший байт
91.            RET
92. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
93.  
94. Int32_to_String:
95. ; Перевести число из двоичного кода в код BCD
96.         mov     [Data_Int32], eax
97.         fild    [Data_Int32]            ; Загрузить число в двоичном коде
98.         fbstp   [Data_BCD]              ; Извлечь число в коде BCD
99.         mov     si, Data_BCD
100. ; ПРЕОБРАЗОВАТЬ ЧИСЛО ИЗ КОДА BCD В КОД ASCII
101.         add     si, 8
102. ; Пропустить незначащие (нулевые) разряды слева
103.         mov     cx, 9
104. @@n1:   ;проверяем на 0 очередную пару разрядов
105.         cmp     byte [si], 0
106.          jne    @@n2
107.         dec     si
108.         loop    @@n1
109. ; Если значение числа равно нулю, записать символ
110. ; нуля в строку результата и выйти из программы
111.         mov     al, '0'
112.         stosb
113.         jmp  @@End
114.  
115. ; Пропустить незначащий ноль в старшей тетраде (если он есть)
116. @@n2:   ; Загрузить первую значащую пару разрядов
117.         mov     al, [si]
118.         mov     ah, al
119.         ; Выделить, перевести в ASCII и
120.         ; сохранить старшую тетраду
121.         shr     al, 4
122.         or      al, al
123.         ; Если 0 - пропустить старшую тетраду
124.          je     @@n3
125.         add     al, '0'
126.         stosb
127.         ; Выделить, перевести в ASCII и  сохранить младшую тетраду
128. @@n3:   mov     al, ah
129.         and     al, 0xF
130.         add     al, '0'
131.         stosb
132.         dec     si
133.         dec     cx
134.          jz     @@End     ;выход, если это последний разряд
135.  
136. ; Распаковать остальные разряды числа (если они есть)
137. @@n4:   ; Загрузить очередную пару разрядов
138.         mov     al, [si]
139.         mov     ah, al
140.         ; Выделить, перевести в ASCII и сохранить старшую тетраду
141.         shr     al, 4
142.         add     al, '0'
143.         stosb
144.         ; Выделить, перевести в ASCII и сохранить младшую тетраду
145.         mov     al, ah
146.         and     al, 0xF
147.         add     al, '0'
148.         stosb
149.         dec     si
150.         loop    @@n4
151. @@End:     RET
152.  
153. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
154. FileName        DB  'delta.txt', 0
155. SaveIRQ0        DD  0
156. Data_Int32      DD  ?                   ; 32-разрядное целое число
157. Data_BCD        DT  ?                   ; Число в BCD-формате
158. DumpRDTSC       DD  ?
159. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

 

Жаль тут прямо файло не цепляется. Короче файл статистики можно глазами конечно проверить, убедиться + взять калькуляток и посчитать, но... я еще накропал XLS файло с макросом ,который обработывает весь массив и наглядно показывает + периодичность "размыва" периода IRQ0 видна. Своего рода частотная модуляция Firq0 частотой Fsmi получается
А жрет SMI тактов немеряно особенно у некоторых вендоров материнок их архитектур... видимо и варианта кода самого обраб. SMI...
(все. бегу. пропадаю дня на 3.как вернусь почитаю тутычки, интересно ведь)

 

VaStaNi
я замеры делал через канал 2 таймера. в сам ИНТ запихал чтение значений таймера.
как ты праивльно выразился - происходит размыв. какоето аремя идёт стабильно, потом одна задержка, и опять стабильно. причем задержки повторяются с одинаковым периодом.

а как эту проблему побороть? прочитал что от SMI никак нельзя избавиться.

 

pyrodex
Можно часть источников SMI отключить, но железо зависимо.

 

можно поставить свой обработчик на SMI#
в обработчике только rsm
только скорее всего придется BIOS патчить, т. к на современных чипсетах есть аппаратная защита SMRAM (lock bit), а она как раз в BIOS включается

 

Pavia
как можно?

 

получается, что на PC-подобных машинах не возможно создать ОС реального времени. И все кто заявляет об этом просто пе..дят.

 

Ну почему же? 30кГц вроде получали в RTXv8.1

 

pyrodex
ОСРВ создать можно. Вот тут можешь почитай
ftp://ftp.prosoft.ru/pub/Hardware/Fastwel/QNX/6.3.x/technotes/SMI_handler_overlay_QNX.pdf

 

как её можно создать если есть задержки в 1мс при вызовах аппаратных прерываний?

или эти товарищи (создатели ОСРВ) знают как сделать так, чтобы этих задержек не было

 

pyrodex

Я же говорю что зависит от железа. Порылся в исходниках биоса ничего интерестного не нашел. Берем даташит на чипсет и согласно нему запрещаем SMI. В исходниках биоса конечно есть подсказка как включить SMRAM. Как записать туда данные.

Хотя тут прикольные строчки нашел. Пока не разобрался но по ощущением что в SMI идет работа с HDD.

 

pyrodex

ОСРВ можно, главное чтобы приложению требовалось переодичность не чаще 1-2мс. А вот ОСРЖВ уже нет.

 

Привет всем пытливым!

Было такое впечатление, но не долго, т.к. порассуждав, почитав, посчитав, понимаешь, что они вполне честно ПОЭТОМУ и приводят в своих хар-ках оси, что дескать гарантируем время отклика НЕ менее чем 10мс... Это почему собссссвенно? Задаешь себе вопрос. А что получается? Если скажем, основной пульс системы 5мс и он базирован на IRQ0 и "они2 знают, что некогда, в него вонзается доп "потеря тактов" плоть до 2...3 мс, то тогда, можно и гарантировать, что 5+(2..3) < 10!
Когда я еще и не догадывался про существование и "подпольную жизнь" SMI в машинах РС архитекруры (в том числе своей)), я все время думал, чего это они такие медленные оси РВ делают? Ведь можно и меньше квант (пульс) в системе сделать и обеспечить гораздо большие возможности, скажем для робототехники, точных манипуляторов, науки и пр...... Оказывается вот оно, что SMI!!! Самый крутой вирус из всех известных в мире. :
Суперминирование любой оси! Когда первый шок прошел, я понял, что это не иначе как жизнь внутри жизни блин. В тему (в фазу реплики) рекомендую прочитать кто не был здесь: http://www.rom.by/article/А_кто_управляет_Вашим_компьютером
Это мое мнение, выводы основы я привел. Рад буду прочесть другие суждения, факты, ссылки.
Теперь какбы поуспокоившись и зная правду и суть неугомонный разработчик(ну пусть я) думает, а как бы мне ОСЖРВ всеже сделать... ну хотябы замутить... ну хотябы попробовать замутить ЧЁТКИЙ пульс, базу отсчетов, дабы быть уверенным, что можно обеспечить, ну пусть 1мс! Но ЖЕЛЕЗНО, четко, без размыва?
Один из путей Pavia правильно сказал - рубить! В самом худшем случае ВООБЩЕ ЗАРУБИТЬ SMI!!! Задай сам себе вопрос, а ОНО НАДО мне(разработчику, заказчику, пользователю ОСЖРВ, конечному "агрегату", конечному результату)?
Думаю если рассмотреть, ЧТО делает SMI (хотя это почти супер секреты пентагона получаются для основной массы нас смертных, что неправильно, я считаю) - можно прожить и без ЭТОГО! Ну даже типа такой довод - жили же раньше, когда его нам НЕ ПОДКЛАДЫВАЛИ в бивис!?
Ну хрен с ними с этими спасениями аппаратуры от перегрева, от остановки кулера (а может у меня его вообще нет!), от питающих напряжений (а я их вообще сам буду и мерять в оси и оценивать быть может и делать свои выводы и действия в связи с этим...), ну и бибикать спикером в кризисах мне на кой, я и сам бибикну, да еще и лучше + там где надо мне(!), что-то еще о чем я не знаю!??? Ну и хрен с ним! Лучше спать будем, спокойней, что бомбы то нету и никто мой ОС-мозг не травмирует (может Чернобыля НЕ будет! Не дай Бог!).
Получается либо вообще рубить, либо писать свой, либо пытаться мириться с ним. Итого 3 варианта, которые стоит прикинуть исходя из своих ТЗ на разработку (пусть и сам себе режиссер, но таково должно быть, если не в песочницу играться!). Таксссс...

1. рубить. Нужно знать чипсет(ы) с которыми работать будем(!) и уметь убить правильно. Тогда ОСЖРВ - реальность на РС!
2. писать свой. Нужно еще больше знать чипсет(ы)!!! И очень правильно все сделать! Висяки могут быть очень серьёзные и система может очень уж НЕвосстановимо умирать! Большущие проблемы отладки кода, очень профессиональный НИЗКОУРОВНЕВЫЙ кодинг (равно как самому BIOS код разаб./отлаживать). "Вендоробезобразие" большой отдельный разговор......
3. мириться (типа ною-хаЮ). Тут предполагается, что если четко знать пульс проектируемой системы (элементарный квант) и ЗНАТЬ некий БАЗОВЫЙ период SMI (если он существует или его можно замерить адаптивно по принципу выше, скажем) то можно попытаться именно СИНХРОНИЗИРОВАТЬ IRQ0 и SMI (запустить IRQ0 в нужной фазе с известным периодом, который....), так чтобы SMIшные потери тактов ложились в временной интервал обработчика IRQ0 (все капец мне, выдал суперсекрет! пентагон уже звонит в мелкософт ).
Ну думается, что не совсем уроды должны(!) SMI код обработчика писать, то он должен(!) быть максимально краток, оптимален... дабы не влиять на..... НО Я в ЭТО НЕ верю! Если честно. Хотя нужно пробовать, это идея пока не окружена практикой... Факты бьют больно. Верю замерам. Можно попытаться, если много жрется, ЧАСТь SMI причин зарубить (см.Pavia), т.к. если накуриться даже поверхностно манов по чипсетам, то видно, что SMI - это сборище причин хаотически возможного срабатывания! Одно из которых - таймерное с довольно таки широким размахом вплоть до секундных, кажись.... (+ поправка на чипсет, вендорные бзыки, заморочки). Поправте меня если не так plz!
Вот это прорвало меня сегодня так сказать что накипело то и вывалил, надеюсь на продуктивное развитие и обсуждение и НЕравнодушие. Спасибо!

 

из исследовательского архивчика файлики (XLS демонстрирует любопытно-красивый экземпляр PC): http://openfile.ru/75115/

 

VaStaNi
1. Есть предположение что переключение в SMM занимает время также если небольше, как переключение процессора между задачами и защищенным режимом. Так что рубить выгледит более лучше.
2. Тут хитрый ACPI он вроде позволяет перевести часть обработчиков из SMI.
3. Есть два периуда 64мс и 2,3 с (воемя переполнения счетчика), но почемуто основная задержка приходиться на 250мс. Есть мнение что идет регулировка куллера. Сам я считаю что походу там несколько задачь выполняется.


На самом деле SMI не так уж сильно нужно. Отключение, включение компьютера.
USB клавиотура и мышь - задействован SMI
Про таймеры я говорил. Есть еще сигнал тревогу перегрев или скачки петания.
В отчетах QNX говориться о ISA DMA странно упоминанейней в мануалах что-то не встречал.
Полное отключение SMI возможно. Но можно частично отключить, чтобы он следил за безопасностью и выполня часть функций. Только порезать таймеры.

PS. Файл битый.

 

с п.1 - согласен. Чем ближе требования по РВ (ЖРВ), тем больше рубить, гасить, давить его как гада )
п.2 - на кой? Возни туева ...., нюансов и головомойки ух! Разве для очень подкованности в исключительно таких эксклюзивах!
п.3. Да. И кулер и температуры и выкл (скорее всего и программо-таймерный ВКЛ. там же!), и питания и USB клава и мышь (еше неизвестно какой кривости и тактов эта реализация, есть разные слухи по поводу).
Частично резать... все равно он ведь гад сдампит и восстановит кучу данных + время на переключение видимо около (в может и больше) игр с TSS! Я имею виду в тактах проца, конечно.
Самое красивое, конечно видится, это ЯДРО ОС ЖРВ вешать(делать) НА SMI! Т.е. использовать его дейстивельно как СУПЕР-ПУПЕР-МЕГА-АДМИНИСТРАЦИЯ ЯДРА на передмет НЕУБИЕННОСТИ ОСИ её живучести, надзор за целостностью, этакий WatchDOG системы. Но писаный он должен быть под Ось, под задачу, под ТАКТ!, под цели, а НЕ паразитически! Но это предполагает п.2 что писал выше. Кто знает, может некогда так и будет. И вообще неизвестно, как и какие ОСи его используют... Это все скрывается как то от ручек
Да, бит зараза, файл! Враги посекли, млин! Презалито: http://openfile.ru/75155/
Проверил сам вроде ОК!

 

Что то все молчат даже pyrodex не интересно?
Попытаться добить вопрос до точки и зарубить SMI, дабы снять статистику и в таком случае. Пробовал так

Код (Text):

1.                 ORG     0x100
2. ;Disable SMI
3.                 mov     cl, 30h
4.                 call    _Get_PMIO
5.                 and     al, not 1
6.                 call    _Set_PMIO
7.                 ret
8. _Get_PMIO:
9.                 push    dx
10.                 mov     dx, 4000h  ; port PMBase!
11.                 mov     dl, cl
12.                 in      al, dx
13.                 out     0EBh, al
14.                 pop     dx
15.                 retn
16. _Set_PMIO:
17.                 push    dx
18.                 mov     dx, 4000h
19.                 mov     dl, cl
20.                 out     dx, al
21.                 out     0EBh, al
22.                 pop     dx
23.                 retn

как я понял ничего не произошло, т.к. кнопкой выключился БП ATX, заначит SMI жив...
PMBase правильна, чипсетина древняя, известная, интел 815. Кто знает что не так?

 

Можно влезть в обсуждение?
На графиках (и на выложенном VaStaNi, и построенным для моего компа - http://diamondz.land.ru/irq0_d1.png, если кому интересно) видно, что от базовой точки идут отклонения как вверх, так и вниз, причём примерно в равном количестве. Но обслуживание SMI, очевидно, может только увеличивать время отклика из-за дополнительных затрат. Откуда тогда берётся уменьшение времени реакции?

Дык