Неравномерный приход прерываний

[V-ctor]

Проблема такая: с PCI карты валится прерывание, в зависимости от его типа с карты либо чтется блок данных (Rx) , либо пишется (Tx).
По идее частота событий Rx и Tx  одинакова, т.е. они должны идти друг за дружкой, так и происходит 1-2 секунды потом например приходит пачка прерываний чисто Тх, а при этом пачка прерываний Rx потеряна (я это вижу по нумерации пакетов на плате), а заней так же может пачка прерываний Rx. Потом снова 1-2 секунды нормально и снова повторяется глюк.
Ресурсы системы подъедены на 50%. Из них 40 - это лог по которому я и сужу, может если выкинуть лог все станет хорошо, но как тогда что узнать?
Если гнать один тип прерывния , то он работает исправно, без тормозов.
Частота (период точнее) каждого не менее 700 мкс. Друг относительно друга сдвинуты минимум на 100 мкс.
Пакеты не более 300 байт.
ISR минимален. Преывание в User mode по событию, а там вычитывание байтика с платы  и колбэк на Rx или Tx обработчики.
Машина Celeron 400.
Надеюсь подробно описал ситуацию.

В чем проблемина?
Может для таких времянок надо машину шустрее?
Или в DPC дергать разные события и завесить соотв. в юзер моде 2 процесса на каждый?
Или для таких скоростей уже DMA надо ставить?
Или просто напросто где-то ввести синхронизацию? Какое решение более грамотное?

P.S. простой поток прерываний с периодом 300-400 мкс отлавливаться успевает даже с логом хотя и загруз почти на 100%.

[grozny]

лог пишет на жёсткий диск?

[V-ctor]

Да.

[SlavaI]

ISR минимален. Преывание в User mode по событию, а там вычитывание байтика с платы и колбэк на Rx или Tx обработчики.

Я вот этот момент не понял. Это как? Ты вызываешь KeSetEvent из ISR? Если да, то его можно только на IRQL <= DISPATCH_LEVEL вызывать, но это не может быть причиной потери прерываний, просто предупредил. Если ты вызывешь его из DPC то все нормально.

а там вычитывание байтика с платы и колбэк на Rx или Tx обработчики.

Там - это где? Если в юзерском потоке(не будем выяснять как ты с железом напрямую из юзер мода работаешь, но это в принципе возможно), то это и есть как-бы причина потери прерываний, если ты подсчет из юзерского потока ведешь. Установка события не приводит к мгновенному переключению на ждущий поток, этот поток только планируют на выполнение, а вот когда он начнет выполняться- неизвестно, а если в нем и ведут подсчет- это и есть причина "как-бы" потери прерываний, так как пока поток запланирован, но не выполняется, еще куча прерываний может придти, и установка KeSetEvent никак не влияет, событие и так уже в сигнальном состоянии, а поток еще не начал работать.

Еще вопрос- у тебя приореты у DPC какие, не выходит ли так, что DPC одного прерывания в начало очереди на процессоре вставляется, а другого прерывания - в конец очереди.

Вопрос в том- где и как ты ведешь подсчет пришедших прерываний. Наиболее правильно делать это в ISR. Если ты там и считаешь, и происходят потери, то это очень странно. Если плата шлет их всегда в последовательности первое-второе-первое-второе, то почему ISR не вызывается? Тут только случай долго зависания на высоком IRQL, то есть ISR первого перекрывает по времени интервал между первым и вторым прерыванием. И еще почему плата шлет прерывание не дождавшись пока ей это разрешат, обработав ранее пришедшее прерывание, это такая конструкция платы?

[V-ctor]

Я вот этот момент не понял. Это как? Ты вызываешь KeSetEvent из ISR? Если да, то его можно только на IRQL <= DISPATCH_LEVEL вызывать, но это не может быть причиной потери прерываний, просто предупредил. Если ты вызывешь его из DPC то все нормально.

Из DPC. В ISR токо проверка моего бита и сброс его.

Там - это где? Если в юзерском потоке(не будем выяснять как ты с железом напрямую из юзер мода работаешь, но это в принципе возможно), то это и есть как-бы причина потери прерываний, если ты подсчет из юзерского потока ведешь.

Да вычитывание байта в юзер моде, но через дривер (это ж по честному?)

Установка события не приводит к мгновенному переключению на ждущий поток, этот поток только планируют на выполнение, а вот когда он начнет выполняться- неизвестно, а если в нем и ведут подсчет, то в этот момент еще куча прерываний может придти, и установка KeSetEvent никак не влияет, событие и так уже в сигнальном состоянии, а поток еще не начал работать.

Очень неудобно, хотя я понимаю, что винда не риалтайм ОС, а расчитана на человека, но нельзя ли никак ускорить реагирование на прерывание? Пусть будут съедатся ресурсы проца, если это поможет.

Еще вопрос- у тебя приореты у DPC какие, не выходит ли так, что DPC одного прерывания в начало очереди на процессоре вставляется, а другого прерывания - в конец очереди.

А что-то я как-то проглядел про приоритеты DPC. Это где задается?
Да и DPC -то у меня одно т.к. иисточник прерывания один. И соответственно разве он может то в начало то в конец очереди ставится?

Вопрос в том- где и как ты ведешь подсчет пришедших прерываний. Наиболее правильно делать это в ISR. Если ты там и считаешь, и происходят потери, то это очень странно.

Нет. Подсчет веду в юзер моде (кидаю лог и по нему смотрю).
Вряд ли теряется в ISR, хотя не знаю как там вести подсчет, что б потом смотреть? Т.к. дебажные сообщения тормозят работу и применять их в ISR наверно будет жестоко и не правильно. Или тоже лог в файл вести? Но и это ведь долго.

И еще почему плата шлет прерывание не дождавшись пока ей это разрешат, обработав ранее пришедшее прерывание, это такая конструкция платы?

Да такова природа платы, это что-то типа сетевог опротокола, прием и передача идут непрерывно и ждать не могут. Буферы не решат проблемы т.к. отклик должен быть моментальный.

[SlavaI]

Я думал что у тебя два прерывания. Если одно- то все рассуждения про ISR и DPC пропусти. Потери связаны с твоим KeSetEvent и планировкой потоков и возможными потерями в том, что в очереди DPC может быть только одно DPC для данного прерывания.

Очень неудобно, хотя я понимаю, что винда не риалтайм ОС, а расчитана на человека, но нельзя ли никак ускорить реагирование на прерывание? Пусть будут съедатся ресурсы проца, если это поможет.

Хочешь сделать планировку потока более частой- подними его приоритет. KeSetThreadPriority для системных потоков и SetThreadPriority для пользовательских. Но это не способ. Потери всегда будут или система тормознет.

[V-ctor]

Но должен же быть какой-то выход, может качественно иной?
Пусть аппаратный (например действительно иметь 2 аппаратных прерывания).
Или программный делать колбэк не по событию, а как (а)синхронное чтение/запись? Коли я так понимаю прикручивание еще одного события не улучшит дело.
Как-то ведь фурычат драйверы сетевых плат, я так понимаю там аналогично постоянно валятся пакеты и постоянно их надо выплевывать без задержек.
Хочу подобное.

[SlavaI]

Как-то ведь фурычат драйверы сетевых плат, я так понимаю там аналогично постоянно валятся пакеты и постоянно их надо выплевывать без задержек.

Почему это без задержек. Во первых там буфер на плате есть. Во вторых DMA используется поэтому проц не грузится. Если буфер на плате заполнится то пакеты не принимают, переслать их второй раз-задача высокоуровневых протоколов типа TCP- не подтвержденные пакеты он пересылает второй раз, вот так и работает. То есть у сетевых карт есть высокоуровневая программная поддержка.

А у тебя выход- только real time OS, если так критично не потерять ни одного прерывания в твоей системе.

[V-ctor]

Ну буферы прикрутить и ПО высокого уровне не проблема. А вот DMA  в моем PCI контроллере нету (понадеялся, что и без него справится). В связи с тем что его за пару-тройку дней не прикрутить вопросы:
1 насколько DMA в таких случаях облегчает жизнь? Ведь пакеты малые и сама пересылка много времени не ест. Или его предлесть как раз в том, что он сам будет лазить за пакетоами не дергая всякие прерывания? И так же их класть?
Считается , что сами пакеты обрабатываются моментально.
2 как трудно реализовать поддержку в драйвере? Везде как мне показалось народ много мучается, т.е. это довольно сложная тема?

А у тебя выход- только real time OS,

Это QNX и все такое?

[SlavaI]

1 насколько DMA в таких случаях облегчает жизнь? Ведь пакеты малые и сама пересылка много времени не ест. Или его предлесть как раз в том, что он сам будет лазить за пакетоами не дергая всякие прерывания? И так же их класть?
Считается , что сами пакеты обрабатываются моментально.

Облегчает жизнь только для больших пакетов, размером в килобайты(каковыми и являются сетевые- до 1500 байт, да еще в буфере накопленные). Для 100 байтных пакетов надо оценивать. Тут прелесть в том, что при DMA происходит захват шины(PCI) когда арбитор разрешит и данные передаются без участия проца в оперативку, через контроллер PCI-Системная шина(Шлюз PCI), причем процессор может тоже кое что делать и даже в память лазить. А если он будет сам вынимать с платы тут еще все зависит от реактивности платы, она может его сильно тормознуть(будет ждать ответа). Процессор только учавствует в инициализации DMA, создает структуры, которые понимает DMA контроллер на плате и дает команду на начало операции. Далее DMA контроллер и шина сами разбираются столько времени сколько им надо, а процессор в это время переходит к другой работе, лазит в оперативную память, пишет туда и т.д., а паралельно постепенно идет передача данных с устройства в память или наоборот. То есть DMA удобна как способ передачи работы другому.

2 как трудно реализовать поддержку в драйвере? Везде как мне показалось народ много мучается, т.е. это довольно сложная тема?

Да не очень сложная. Проблемы мы тут все решаем. Они обычно из-за невнимательности.

Это QNX и все такое?

Она самая.

[V-ctor]

А вот еще про KeSetPriorityThread . Я могу изменить приоретет для DPC?
Или нужно создать отдельный поток и в нем дергать событие и повысить приоретет этого потока?
Тогда я не пойму как обмениваться с этим потоком? Т.е. как ему сказать, что б он повысил приоретет?

[SlavaI]

А вот еще про KeSetPriorityThread . Я могу изменить приоретет для DPC?

KeSetPriorityThread предназначена для системных, не пользовательских, потоков. Приоритет потока и приоритет DPC- абсолютно разные вещи и не связаны между собой никак. DPC вызывается в контексте произвольного потока и всегда на IRQL==DISPATCH_LEVEL. Приоритет DPC влияет на то в начало или конец очереди его поставят. Приоритет(важность) DPC определяется членом Importance структуры DPC. Лучше его не трогай, а если хочешь тронуть- то используй KeSetImportanceDpc.
Для повышения приоритета пользовательского потока используй KeSetBasePriorityThread, если делаешь это из драйвера.

[maaaaaad]

Ресурсы системы подъедены на 50%. Из них 40 - это лог по которому я и сужу, может если выкинуть лог все станет хорошо, но как тогда что узнать?

Виден стиль программеров джинго. Обработка прераваний в юзер мод это все их идеи. Может послать камикадзе подорвать их офис?
Еще бы вам реалтайм.....ваша прога будет отражать окна в реалтайме, а те же сетевые драйвера тормозить будут. Это есть по-вашему реал тайм? Идеология окон юсер мод - это то, что они для человека и реалтайм тут не нужен.
Нормально - вы сами потеряли половину ваших прерываний и жалуетесь....на кого?

 Я могу изменить приоретет для DPC?

Только растановкой в очередь.
Другие пути это расширения - ртх ядра и написания его самому (резервировать прерывание ниже захваченного устройством и там работать с ограничениями DIRQ) и роутить прерыванияя туда, (желательно все это писать на асме).
Или подождите лонгхон =) может там введут честный приоритет дпс.....
Блин нада сайт ms зафлудить этими предложениями.....может сделают...

[SlavaI]

Нормально - вы сами потеряли половину ваших прерываний и жалуетесь

Я бы так сказал- как не извращайся, но если карта сама генерит прерывания без оглядки на программу(драйвер) которая с ней взаимодействует, то дать гарантию непотери прерываний в >=Windows NT нельзя. А тут еще все усугублено тем, что через юзерский поток все ходит и event используется. То есть используется планировщик потоков- а дать гарантию на время задержки между KeSetEvent и переключением процессора на выполнение ожидающего потока нельзя.

[SlavaI]

Как вариант могу предложить сразу выцарапывать данные с карты в ISR и вставлять их в какой-то буфер, где они накапливаются, ставить DPC, в нем SetEvent, будить поток, желательно системный(PsCreateSystemThread) и в нем с буфером разбираться, вынимая из него данные от нескольких прерываний. Для удобства буферов можно два завести и переключаться между ними, сначала один использовать, потом другой. Тогда синхронизация при записи в буфер не нужна. Вынимание данных в ISR - это плохо, но это лучше чем полная потеря большого количества данных.

[V-ctor]

2 CrashMaker
не Джинго, а нумега.
И потом что значит разбиратся в юзер моде? А как еще-то? Почти все прерывания так или иначе уходят туда. Иначе смыл-то в них? Про них будет знать токо ядро и больше никто.
То что вынь не рилтайм итак известно никто тут и не жалуется, просто надо знать в чем затык и рыть дальше. И рилтайм ось тут не нужна. я знаю такое устр-во (как мое) работает под w2k чудесно.
Просто надо определится что совершенствовать: дривер, ПО верхнего ур-я, прикручивать DMA или выносить часть функций на борт платы, что бы снизить нагрузку на хост.

[V-ctor]

2 SlavaI
Что-то не удается приделать KeSetImportanceDpc. Почему-то он оказывается не в wdm.h ,а в ntddk.h. И что-то линковщик ругается. Ему либу надо ?
Как её заполучить? Я же не могу откомпилить ка кпростой исходник

До этого всегда обходился функциями из wdm

[maaaaaad]

То что вынь не рилтайм итак известно никто тут и не жалуется

Кому нада реалтайм - он ее имеет.

просто надо знать в чем затык и рыть дальше

То есть используется планировщик потоков- а дать гарантию на время задержки между KeSetEvent и переключением процессора на выполнение ожидающего потока нельзя

Вот только не надо пытаться выкрутиться из ситуации. Надо ее честно решить. Проблемы с неопределенностью установкой/сброса события ("честных механизмов распределения процессорного времени ms") - этого, я думаю, честными методами не решить. Нада выкручиваться=)) Как? Убрать ее. Вариантов много. Я все никак не могу понять зачем понадобилось строить такую цепочку иср-дпс-событие-поток юзермод???
Потоки в юзер мод не нуждаются в реалтайме т.к взаимодействуют только с нами или совсем не критичными по времени процессами. А мы не способны в полной мере обрабатывать информацию в реальном времени, а стоит это дорого.

И потом что значит разбиратся в юзер моде? А как еще-то? Почти все прерывания так или иначе уходят туда. Иначе смыл-то в них?

Куда куда уходит? =)

KeSetImportanceDpc

Не выход.
Из той же песни:могу посоветовать дисаблить прерывания от сетевой карты и винта. Прерывания могут прийти и от них, а их иср загадят дпс очередь.

я знаю такое устр-во (как мое) работает под w2k чудесно.

чудеснее некуда.


И вобще нельзя так....выйти, помахать руками и надеяться что кто то чем то поможет. Мне вот интересно но на ваши вопросы появляется еще куча встречных вопросов которые просто влом спрашивать...кто зачем куда как


Если Slaval вас понял (я ничерта не понял) то так обычно и делают - все в очередь в isr или dpc, а извлекают данные из очереди в юсер мод.

2Slaval

дать гарантию непотери прерываний в >=Windows NT нельзя

Физически его никак не потерять. Его можно сделать бесполезным и то, если тайм из реал, но это решается приоритетностью дпс или эмуляции этой приоритетностью, когда запрос на дпс можно поставить не только в начало или конец. Как это понимать?

[maaaaaad]

а совсем правильно - для потоковых устройств () реализация циклического буфера аппаратно, например, как для сетевых карт.

[SlavaI]

2 SlavaI
Что-то не удается приделать KeSetImportanceDpc. Почему-то он оказывается не в wdm.h ,а в ntddk.h. И что-то линковщик ругается. Ему либу надо ?
Как её заполучить? Я же не могу откомпилить ка кпростой исходник  

До этого всегда обходился функциями из wdm

Ну а с чего ему в wdm.h находится. Функция древняя. Нужен ntoskrnl.lib. Но без него ты драйвер не соберешь, как ты раньше то без этого lib файла собирал?
Ф-ция экспортируется ядром. У меня например под 607 номером по смещению 0x1662A.

[SlavaI]

Физически его никак не потерять. Его можно сделать бесполезным и то, если тайм из реал, но это решается приоритетностью дпс или эмуляции этой приоритетностью, когда запрос на дпс можно поставить не только в начало или конец. Как это понимать?

CrashMaker, ты сам с собой разговариваешь или со мной? Обсуждать твое сообщение про потери прерываний я не буду, это типичное передергивание, кто понимает обработку прерываний понял о чем шла речь. Выше по посту ты крикнул, что KeSetImportanceDpc - это не выход, а ниже спрашиваешь что такое установка DPC в начало и конец очереди. Хмм, так ты понимаешь зачем нужна KeSetImportanceDpc или нет? Если нет зачем кричал что это не выход, если да- то зачем спрашиваешь про установку DPC в начало и конец очереди? Кстати- по умолчанию если Importance DPС не равна двум их в конец очереди ставят, а меньше двух эта Importance у всех DPC созданных с параметрами по умолчанию.
И хватит тут кричать, возмущаться и наезжать на людей. Я понял что спрашивали и как все там работает и сказал в чем причина потери прерываний(как бы это слово тебе не нравилось я его буду употреблять). Не знаешь ответа - не отвечай, не понял- спроси, но не надо пытаться объяснить всем какие они дураки.

[V-ctor]

Кому нада реалтайм - он ее имеет.

Если б смысл того сервера где будет моя карта  сводился токо к тому что б её обслуживать, т оя бы тут и не лез с вопросами, но карта эта далеко не цель во всем проекте. Есть еще куча высокоуровнего софта и оно под w2k. И его переписывать дороже чем купить фирменных таких плат.

Куда куда уходит? =)

В юзер мод. Когда я давлю клавишу, чем оно заканчивается? Да тем что напр. ворд мне символ рисует или ворд у нак в кернел моде? )
Весь вопрос в том какую часть задачи вынести на плату, какую в дривер, какую в юзер.

чудеснее некуда.

Кстати плата от Intel (думаю там не самые тупые инженеры и программисты.) Просто когда я сказал такая же это не значило совсем, что она работает именно так, просто делает то же , что и моя. Если б я точно знал как так же бы и сделал давно.

И в самом деле, CrashMaker, если есть полезные советы, то скажи, нету... а переливать из пустого в порожнее... Что прям никто никогда не ошибался? Вот Слава подсказал, что нефиг требовать молниеносного выполнения прерываний, что буферы полезная тут штука. Ну дык и прикрутим эти буферы.
Одного бы  хотелось... избежать DMA по возможности, просто потому, что дофига переделывать по части железа.

[SlavaI]

что буферы полезная тут штука. Ну дык и прикрутим эти буферы.

Вполне возможно, что это поможет. Вся проблема ведь в потери данных из-за того, что система не успевает их вынуть с платы. Значит как выход подходит сохранение этих данных от нескольких прерываний в буфере на плате. Может проще пихать в буфер, а потом выдавать прерывание для очистки буфера(оно будет в несколько раз реже приходить), при этом переключать запись в плате на другой буфер. Ну и если на уровне железа не удастся обеспечить 100% гарантию не потери данных, то сделать корректирующий программный алгоритм.

[V-ctor]

Хорошо, идею понял!
А что если буферизировать в дривере? Ведь я так понял главный тормоз в том что между устанвкой события и тем когда это собычие очухается в юзер моде довольно долгое время (ну там планирвщики рулят это переключение и все такое). Что если в DPC я буду накапливать буфер , а потом дергать событие? Конечно, в плате буфер сделать это лучше, но сложнее и ресурсов её хотелось бы поберечь.

[SlavaI]

А что если буферизировать в дривере?

Для этого нужна уверенность в том, что ISR будет вызвана для каждого прерывания, а это может быть не так, если какой нибудь ISR с большим DIRQL перекроет два твоих прерывания- одно пропадет. К тому же пока ты там вынимаешь данные может придти следующее прерываний- читай ниже.

Что если в DPC я буду накапливать буфер

Помни-данный конкретный DPC в очереди только один, повторные попытки поставить тот же DPC, пока он в очереди(то есть еще не вызван на исполнение) ни к чему не приведут. Это в основном и есть причина потери инфы в других драйверах. Можно пытаться из ISR закидывать инфу в буфер, но тут ситуация долгого блокирования процессора на высоком DIRQL из-за необходимости чтения данных из девайса. Смотри как это согласуется с возможностью обработки прерываний с более низким DIRQL. А также с тем что тебя могут прервать в ISR прерыванием с более высоким DIRQL и будет ли из-за этого у тебя гарантия, что ты закончишь вынимать данные до того, как придет следующее прерывание и данные изменятся- в итоге вынешь смесь данных.
Вся проблема из-за отсутствия синхронизации драйвер-плата. Если данные терять нельзя, то следующее прерывание плата должна выдавать только после того как ей скажут, что прошлое прерывание нормально обработано и данные вынуты с платы. А у тебя они сыпятся без оглядки на драйвер. Тут нужен высокоуровневый протокол коррекции, который или откорректирует потерянные данные или попросит повторной передачи(как протокол TCP).

[V-ctor]

А в DPC не могут прервать во время чтения блока?

Все же попробую делать в DPC, т.к. когда у меня ходит токо одно прерывание (например от применика), то все срабатывает. Я понимаю, что это не гарантирует, что так будет всегда и везде, но надо хотя бы отладить алгоритмы и ПО верхнего уровня так, а потом уж вылизывать код.

[SlavaI]

А в DPC не могут прервать во время чтения блока?

Могут- любое прерывание. Даже ISR могут прервать прерывания с более высоким DIRQL.

[point]

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

если железное устройство выдает данные с достаточно высокой частотой, то оно просто обязано буферить эти данные в своем собственном аппаратном буфере. механизм прерываний в PC может использоваться лишь для сигнализации о получении нового блока данных и не гарантирует что данные успеют забрать до появления следующего блока. програмный обработчик этих прерываний должен забрать максимально большое количество данных из внутреннего буфера устройства (желательно забрать все), иначе потери данных избежать не удастся.

point.

[V-ctor]

ладно, убдили в необходимости аппаратного буфера

Щас вот вопрос наскоко оправдано будет применения ДМА.
Т.к. аппетиты растут и уже завтра захочется не один сетевой линк, а 4, а потом 16 и т.д.
Просто всю жизнь думал, что ДМА нужен тогда когда большие блоки (>=десятков кБ) данных гоняются, ну там типа для видео или для звука.
Или же ДМА начинает сказываться уже и на килобайтах?

[point]

я уже не помню детали, но человек, который у нас отвечал за железки предлагал использовать dma для передачи данных размером начиная от нескольких килобайт (4K или более). на сколько это реально лучше PIO режима мне сейчас сказать трудно - уже лет пять как я не занимаюсь разработкой подобных драйверов.

point.