Linux.by
https://forum.linux.by/

Прерывания в LInux (+)
https://forum.linux.by/viewtopic.php?f=6&t=4476
Страница 1 из 1

Автор:  Anonymous [ 31 янв 2005, 12:58 ]
Заголовок сообщения:  Прерывания в LInux (+)

Машинка целерон 300. Успеваю обрабатывать 75 килогерц прерываний с PCI платы. а надо бы 150 килогерц. Так и должно быть?

Автор:  Llama [ 31 янв 2005, 15:53 ]
Заголовок сообщения: 

yuragv, завасит от ядра ИМХО.
Для 2.4 я бы предложил пересобрать vanilla + lck патчи (в частности premptible, O1 sheduler и variable HZ)
В 2.6 - разве что попробывать увеличить те же Hz

Автор:  red f0x [ 28 фев 2005, 21:51 ]
Заголовок сообщения: 

A s kakogo takogo perepugu obrabotka preryvaniy uje v hertsax izmeraetsa?

Автор:  Aleksey Kondratenko [ 28 фев 2005, 22:52 ]
Заголовок сообщения: 

1. Увеличение частоты системного таймера может только ухудшить время отклика не прерывания.
2. А почему бы и не в герцах ? Размерность и физический смысл адекватны.

По сути дела: насколько это нормально сказать трудно. Думаю тебе стоит спросить у людей, которые занимаются rtlinux. Если твой ISR простой, то, пожалуй, 4к тактов в среднем на прерывание это многовато.
(Хотя если учесть что каждый доступ к твоему девайсу и контроллеру прерываний весит десятки, а то и сотни тактов может это и нормально)

Автор:  Aleksey Kondratenko [ 28 фев 2005, 23:24 ]
Заголовок сообщения: 

Померяй, реди интереса длительность твоей ISR через rdtsc().

Автор:  dimm_coder [ 21 мар 2005, 17:18 ]
Заголовок сообщения: 

Another important question here, in addition to the time the isr takes to be executed, is the irq latency the vanilla kernel provides (without/with additional load). Although, I know nothing about your PCI card, even 75 Khz sounds quite high for the pure vanilla Linux kernel. I would not be so surprised if upon adding some additional irq pressure (high disk/network activity), you will lose even these 75KHz. Anyway, if you know that the analogue device works successfuly under pure vanilla kernel, you may play more with the vanilla kernel, otherwise take a look e.g. rtai.org.

Автор:  dimm_coder [ 21 мар 2005, 19:20 ]
Заголовок сообщения: 

Just to show your an example. In case, might be of interest to you.

The target system: PCI device generates cyclic interrupts with a frequency of 6 KHz (that's once in ~ 166 us). The driver has to react on every one of them and have to accomplish some action not late than the next one occurs.

For all tests the sequence of interrupts == 50000.

1) Pure vanilla Linux 2.6.9 + the interrup handler has been registered without SA_INTERRUPT flag.

test of cyclic interrupt:
min: 129 us
max: 203 us <--- the max latency of 36 us
avg: 166 us <--- that's we have in average, good
jit (times):
[163; 169] = 505
[157; 177] = 435
[147; 187] = 434
[137; 197] = 384 <---- means, 384 times we had a latency of <= 30 us but >= 20 us
[127; 207] = 0


Ok, (50000 - 505) times we had a latency <= 3 us and that's good, but e.g. 384 times - the latency of 20-30 us.

2) Vanilla kernel + SA_INTERRUPT - all other interrupts are off when isr is running

test of cyclic interrupt:
min: 136 us
max: 196 us
avg: 166 us
jit (times):
[163; 169] = 433 less than 505 in the prev. test, it's better
[157; 177] = 433
[147; 187] = 431
[137; 197] = 1
[127; 207] = 0

3) Vanilla kernel + Fusion/RTAI extension. The interrupt handler has been registered in the primary domain (real-time)

test of cyclic interrupt:
min: 164 us
max: 168 us
avg: 166 us
jit (times):
[163; 169] = 0
[157; 177] = 0
[147; 187] = 0
[137; 197] = 0
[127; 207] = 0

As you can see, the max latency now ~2 us. Under high disk/network irq activity - up to 6 us.

Another interesting issue is SMI interrupts (exist on the recent Intel-based machines, thus your Celeron is likely not affected). All 3 tests which are mentioned above has been running with SMI interrupts disabled and it's P4 machine (although, through the special workaround and non-standard way)

test of cyclic interrupt:
min: 8 us
max: 922 us <--- the latency of 760 us
avg: 166 us
jit (times):
[163; 169] = 122
[157; 177] = 116
[147; 187] = 114
[137; 197] = 111
[127; 207] = 106

These ones are even known as real-time "killers".

So the outcome from all that stuff follows:

if there's a requirenment to react on the interrupt not late than the next one of this type occurs - it's a must that the latency must be less than a period of this interrupt.

e.g. Having the max. latency of 30 us, we can serve a frequency <= 30 KHz (+ depends on the time your isr takes to be executed).

Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/