Статьи Галерея Форум Чат Файлы HowTo Ссылки Поиск
Текущее время: 17 сен 2019, 04:22




Начать новую тему Ответить на тему  [ Сообщений: 7 ] 
Автор Сообщение
 Заголовок сообщения: Прерывания в LInux (+)
СообщениеДобавлено: 31 янв 2005, 12:58 
Машинка целерон 300. Успеваю обрабатывать 75 килогерц прерываний с PCI платы. а надо бы 150 килогерц. Так и должно быть?


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 31 янв 2005, 15:53 
Неотъемлемая часть форума
Аватара пользователя

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

_________________
Опыт растет прямо пропорционально выведенному из строя оборудованию


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 28 фев 2005, 21:51 
Неотъемлемая часть форума
Аватара пользователя

У нас с: 08.03.2004
Сообщения: 338
A s kakogo takogo perepugu obrabotka preryvaniy uje v hertsax izmeraetsa?

_________________
Ну какая работа со строками может быть в языке, название которого является не строкой, а символом? (c) Sergue E. Leontiev


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 28 фев 2005, 22:52 
Неотъемлемая часть форума

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

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


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 28 фев 2005, 23:24 
Неотъемлемая часть форума

У нас с: 12.08.2003
Сообщения: 250
Померяй, реди интереса длительность твоей ISR через rdtsc().


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 21 мар 2005, 17:18 
Интересующийся

У нас с: 19.08.2003
Сообщения: 65
Откуда: Anwerpen, Belgium / Belarus
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.


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 21 мар 2005, 19:20 
Интересующийся

У нас с: 19.08.2003
Сообщения: 65
Откуда: Anwerpen, Belgium / Belarus
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).


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 7 ] 


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
[ All resources are available under GNU GPL ] [ Support ] [ Hosted by DataHata | MyCloud.by ] [ Powered by phpBB® Forum Software © phpBB Group ]

LVEE Winter LVEE Rambler's Top100