Прерывания в LInux (+)

Все о программировании под *nix
Anonymous

Прерывания в LInux (+)

Сообщение Anonymous »

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

Аватара пользователя
Llama
Неотъемлемая часть форума
Сообщения: 9749
Зарегистрирован: 06 фев 2002, 11:40
Откуда: Менск

Сообщение Llama »

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

Аватара пользователя
red f0x
Неотъемлемая часть форума
Сообщения: 338
Зарегистрирован: 08 мар 2004, 01:41

Сообщение red f0x »

A s kakogo takogo perepugu obrabotka preryvaniy uje v hertsax izmeraetsa?
Ну какая работа со строками может быть в языке, название которого является не строкой, а символом? (c) Sergue E. Leontiev

Aleksey Kondratenko
Неотъемлемая часть форума
Сообщения: 250
Зарегистрирован: 12 авг 2003, 03:55
Контактная информация:

Сообщение Aleksey Kondratenko »

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

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

Aleksey Kondratenko
Неотъемлемая часть форума
Сообщения: 250
Зарегистрирован: 12 авг 2003, 03:55
Контактная информация:

Сообщение Aleksey Kondratenko »

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

dimm_coder
Интересующийся
Сообщения: 65
Зарегистрирован: 19 авг 2003, 10:56
Откуда: Anwerpen, Belgium / Belarus
Контактная информация:

Сообщение dimm_coder »

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
Интересующийся
Сообщения: 65
Зарегистрирован: 19 авг 2003, 10:56
Откуда: Anwerpen, Belgium / Belarus
Контактная информация:

Сообщение dimm_coder »

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).

Ответить