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

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

[maaaaaad]

а ниже спрашиваешь что такое установка DPC в начало и конец очереди.

Я этого не спрашивал. Я спрашивал почему Windows NT может терять перывания. Не почему может переписаться irr apic, а как сама windows nt теряет прерывание ибо это были Ваши слова, а я не знаю этого.

 

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

=)) Я не кричу не топаю и ни на кого не наезжаю.

Вопросы странные.....А почему моя программа на жабе тормозит и занимает много памяти? (см топик рядом) А почему у меня все время Enter залипает???























Юзер потоки не предназначенны для снятия данных и программирования устройств. И все тут.

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

Что за платка?

Одного бы хотелось... избежать DMA по возможности, просто потому, что дофига переделывать по части железа.

А чем дма может помочь в данном случае?

Щас вот вопрос наскоко оправдано будет применения ДМА.

Моя чисто умозрительная =))) прикидка составляет байт 100 =))))))))) для меньших буферов быстрее окажется копирование rep movsd чем инициализация дма.

[V-ctor]

Ясно, спасибо всем за советы.

[V-ctor]

А вот такой вопрос: если у меня будет 2 аппаратных прерыания с PCI и соответсвенно 2 обработчика, то не завершенный DPC одного не будет мешать другому?
Потму как я тут посмотрел осцилом , то выяснилось что плата генерит 2 разных по природе (Rx и Tx) прерывания, на одну линию и бывают просто моменты когда они приходят почти одновременно, что не есть хорошо (при этом у каждого свой  более менее фиксированный период , но из-за того что он слегка плавает такое и происходит). Вот я и подумал, если сделать 2 аппаратных прерывания и если ISRы будут успевать, то может это выход?

[point]

про dpc ничего не скажу - сорри...

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

point.

[V-ctor]

дак я так и делаю, но беда как я понял в том, что иногда они у меня приходят почти сподряд и тогда что присходит токо я влетаю в dpc ,как тут же еще одно пришло, а dpc-то не успел отработать и все теряется

[SlavaI]

А вот такой вопрос: если у меня будет 2 аппаратных прерыания с PCI и соответсвенно 2 обработчика, то не завершенный DPC одного не будет мешать другому?

DPC обрабатывают последовательно. Мешать они друг другу не могут в случае одинакового приоритета(Imortance), если у одного Importance равнв 2 то его всегда будут в начало очереди ставить, иначе- в конец.

[V-ctor]

Другими словами насколько оправдан такой подход? Вообще 2 прерывания на карту?
С точки зрения логики это красиво: прерывание на прием , прерывание на передачу. А реально даст ли это выигрышь в тех случаях, когда эти прерывания идут настолько близко по времени, что как одно системой не успевает отрабатываться? Возможно ли, что как 2 отдельных будет всё успеваться?
Или я не на правильном пути и это не есть грамотное решение проблемы?

[SlavaI]

С точки зрения логики это красиво: прерывание на прием , прерывание на передачу. А реально даст ли это выигрышь в тех случаях, когда эти прерывания идут настолько близко по времени, что как одно системой не успевает отрабатываться? Возможно ли, что как 2 отдельных будет всё успеваться?

Ну если одно прерывание, достаточно быстро за ним второе, потом пауза, превышающая интервал между ними, а потом все повторяется, тогда два прерывания лучше, если в DPC делать основную обработку. Если интервалы не определены- то без разницы, два или одно. У двух прерываний преимущество в двух DPC, хотя и от одного можно два DPC ставить поочередно. то есть два прерывания не дают большого преимущества, если их заменить одним прерыванием и двумя DPC.

[V-ctor]

Вот это очень интересно, нигде никогда не встречал такого , что б 2 DPC одному ISR.

Ни в DDK ни Они не нашел упоминаний про это. Думал так нельзя. Как тут грамотно проинициализить?
Я делаю два KeInitializeDpc, а в ISR по очереди дергаю IoRequestDpc то на один DPC, то на другой?

[SlavaI]

Я делаю два KeInitializeDpc, а в ISR по очереди дергаю IoRequestDpc то на один DPC, то на другой

Только IoRequestDpc нужен только для DPC object, вшитого в DEVICE_OBJECT, это как-бы бесплатный DPC, подаренный тебе системой.
А два так можно сделать- создавай два DPC object'а(один можешь использовать из DEVICE_OBJECT) и ставь их поочередно или в зависимости от типа запроса. Сначала KeInitializeDpc для двух DPC(один раз, например в AddDevice), а потом KeInsertQueueDpc(или  IoRequestDpc если этот DPC из DEVICE_OBJECT), и все- ставь столько DPC, сколько хочешь, только помни- один конкретный DPC object в очереди, пока его не вынут, вставить его копию(пусть и с другими аргументами) нельзя, поэтому и два DPC объекта тебе предлагаю, так можно два в очереди держать, если два прерывания близко идут, а потом большой перерыв, за который их успеют вынуть.

[maaaaaad]

Вот если кое-кому дали лопату и попросили нарубить дров этот кто то молча взял бы лопату и начал усердно рубить, паралельно рассказывая про оптимизацию нарубки дров лопатой и поясняя механизм.

Опять некрасивое решение!! Если уж тут зашел вопрос о дополнительных DPC очередях. Первый вопрос себе - Хорошо ли это? Чем не нравится одна очередь?
У сетевых карточек фактически 7 источников перрывания. Обходятся одним. И одним дпс обьектом. Такое количество прерываний ваще не выведешь на шину.

Присоединяюсь к поинту -)

[maaaaaad]

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

использование дополнительных дпс обьектов - наглое разбазаривание системных ресурсов (а память под обьект? а время на обслуживание обьекта?) это все в обмен на ничто.


господа, рубите дрова топором.

[SlavaI]

Вот если кое-кому дали лопату и попросили нарубить дров этот кто то молча взял бы лопату и начал усердно рубить, паралельно рассказывая про оптимизацию нарубки дров лопатой и поясняя механизм.

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

Ну понятно, разок сказали- не флуди и не оскорбляй тут, так началось. Прям как хищник в засаде. Внимательно вычитывются посты выдуманного обидчика и комментируются в нагловато-ехидной манере. Ну давай продолжай комментировать, удалять твои посты не буду, чтоб потом тебе было стыдно. Сам знаешь кто-то лает "а караван идет". Я ждал когда ты выступишь, и оказался прав.

использование дополнительных дпс обьектов - наглое разбазаривание системных ресурсов (а память под обьект? а время на обслуживание обьекта?) это все в обмен на ничто.

Сначала пойми о чем речь потом ругайся. Я ясно объяснил, что 2 DPC помогут если два прерывания один за одним идут, потом пауза. К тому же ты написал чепуху. Ну память- ладно, потратится(sizeof KDRC=0x20), а вот время на обработку причем тут. Человеку надо обязательно обработать прерывание и это время все равно будет потрачено. Подумай.

господа, рубите дрова топором.

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

Только не обижайся, а успокойся и проанализируй свое состояние. Почему такая агрессия. С чем это связано. Может и сменишь стиль общения.

[SlavaI]

Опять некрасивое решение!! Если уж тут зашел вопрос о дополнительных DPC очередях. Первый вопрос себе - Хорошо ли это? Чем не нравится одна очередь?

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

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

как видишь рубить дрова лопатой тоже надо уметь, топором все смогут, а лопатой? Вот и приходится объяснять.

[V-ctor]

DPC очередь всегда одна для процессора. Несколько их только в многопроцессорной системе, по одной на каждый процессор.

Сразу чисто из любопыства стало интересно на сколько тут ускоряет этот HyperThreading?

И еще
1) в развитии темы с 2-мя DPC: а если я на уровне ISR , буду выявлять чьё прерывание (Rx/Tx) и дергать, то одно DPC, то другое соотв для Rx и Тх, то может каждому дать свое событие и в юзер моде соотв. завести 2 потока со своими колбеками?
Просто не могу прикинуть как тут все эти плнировщики отработают такой алгоритм? Быстрее, медленней или так же.
Вообще, конечно, я слышал, что плодить потоки не есть хорошо, но ...
2) у меня щас вычитывание пакета происходит в юзер потоке и похоже, что из-за этого Rx теряется гораздо больше чем Tx, посему подумалось, что наверно правильнее вычитывать в DPC, а юзер мод заберет потом как токо сможет.
Вопрос: как расшарить память меж юзер модом и дривером?
Вроде я где-то натыкался на это в конфе. Но кажется еще в старой её версии.
Или тут проще уже сделать (а)синхронное чтение/запись?

Off: 2SlavaI  Слава, ваша помощь просто... просто мега! )) Порой кажется , что экономятся не просто часы, а то и дни

[SlavaI]

Сразу чисто из любопыства стало интересно на сколько тут ускоряет этот HyperThreading?

Хм. Не знаю. У меня нет HT системы. Все дело в том, что ядро знает что это HT система и ведет себя соотвественно, выставляя юзерам как-бы два проца, но учитывая, что работают они не так шустро как два реальных. Две или одна там очередь- не знаю. Скорее всего две. Но опять же, по умолчанию низкоприоритетные  DPC ставятся в очередь того процессора на котором вызваны ф-ции вставки DPC в очередь. Для высокоприоритетных это может быть не так. Надо документацию почитать.

Просто не могу прикинуть как тут все эти плнировщики отработают такой алгоритм? Быстрее, медленней или так же.
Вообще, конечно, я слышал, что плодить потоки не есть хорошо, но ...

На однопроцессорной лучше не плодить, а придумать что-то другое. Событие одно. Далее про однопроцессорную систему- DPC очередь обрабатывается вся сразу между обработками DPC могут ходить только прерывания, а потоки не могут выполняться. Если ты заведешь два потока и два события то сначала отработают оба DPC(сли так выйдет что они одновременно в очереди будут, если это случается- значит это решение помогает, если нет- два DPC излишни), потом первый поток, потом второй, да еще и с неизвестными задержками, наверно лучше все в одном потоке отработать. Выигрыша от двух на однопроцессорной системе не будет. На SMP системе возможно будет.

у меня щас вычитывание пакета происходит в юзер потоке и похоже, что из-за этого Rx теряется гораздо больше чем Tx, посему подумалось, что наверно правильнее вычитывать в DPC, а юзер мод заберет потом как токо сможет.
Вопрос: как расшарить память меж юзер модом и дривером?

Да наверно лучше в DPC память читать. Потери данных уменьшатся из-за уменьшения задержки между приходом прерывания и вычитыванием данных, так как следующее прерывание могло прийти до того как ты вынимал данные в юзер моде, что как я понимаю уничтожало старые данные на плате. Вот тут читай про разделение памяти-  http://www.osronline.com/article.cfm?id=39   статья "A Common Topic Explained - Sharing Memory Between Drivers and Applications".

Тут появилась оппозиция методу с двумя DPC, она наверно приведет свои способы обработки. Как я уже говорил два DPC спасут если прерывания летят один за одним, а потом пауза. То есть раньше ты терял второе, так как DPC уже была в очереди, но не была еще вынута. Подумай- так ли это было. Может одно DPC и чтение памяти с платы в нем спасут.

[SlavaI]

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

[point]

Принципиальных преимуществ в производительности там нет.

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

point.

[SlavaI]

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

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

[V-ctor]

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

Да это именно такой случай когда они летят один за другим, а потом пауза.
А с буферами выясняется такое, что Тх никак не буферизировать ввиду природы самого протокола. Это конечно не 100%, но человек , который им занимается так говорит. Rx буферизирование под вопросом.
Однако вроде бы можно разнести все прерывания равномерно , но пока это не совсем удается и хотелось бы повысить дополнительно надежность со стороны дриверов. Т.е. если вдруг влетит пара прерываний сподряд, потом пауза, а дальше они равномерно, то чтоб ничего не сбойнуло.

[SlavaI]

Т.е. если вдруг влетит пара прерываний сподряд, потом пауза, а дальше они равномерно, то чтоб ничего не сбойнуло.

подумай над тем что говрит point. Если ISR не успеет отработать(именно из-за того что они очень близко, а потом большая пауза), то можно потерять. Может в DPC еще проверять, как и было предложено- только не обработай одно и то же прерывание два раза, один раз в ISR, другой в DPC при проверке, ведь когда DPC вынуто ничто не мешает ISR поставить этот же DPC в очередь, а ты это прерывание в уже вынутом DPC отработаешь, а потом в поставленном в очередь.
И для Tx и Rx должны быть разные буфера.

[maaaaaad]

Ну память- ладно, потратится(sizeof KDRC=0x20), а вот время на обработку причем тут.

Это были первые слова разработчика языка Visual Basic. Всегда все плохое начинается с этих слов.


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

И никаких предложений из области программирования?

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

Вопросы связанные с наложением обработки обработчика и отложенного обработчика - вопросы железа (переформулируем вопрос так). И никак вы этого не решите, даже если организуете 10 обьектов дпс (честными методами по крайней мере) - чаще всего так и будет в зависимости от того, что мы делаем с девайсом на дпс. Работайте в иср. Если и они накладываются - ваш девайс последнее г* единственный выход - спустится ниже по irq и работать там . Сделайте свой дпс на иср сами. Я это уже говорил. ЕСЛИ вас этот код интересует - могу привести как часть ос RealOs, в которой так и писал года 2 назад.  Быстрее обработку иср сделать не возможно. Если и это не помогает - то я следующий раз подумаю, когда буду покупать мать вашу от интел. Значит инженеры там плохие.



SUBDESIGN InterruptController
(
   clk,reset,clr   :INPUT;
   UnBlock         :INPUT;
   InSignal[0..7]   :INPUT;
   OutSignal[0..7]   :OUTPUT;
   Signal         :OUTPUT;
)
VARIABLE
   ZombieLayer[0..7] :DFF;   % Zombie %
   State         :MACHINE WITH STATES (TRANSPARENT,ZOMBIE);
   
BEGIN
   DEFAULTS
      OutSignal[] = 0;
      Signal = GND;
   END DEFAULTS;

   State.clk = clk;
   State.clk = clk;
   ZombieLayer[].clk = clk;
   ZombieLayer[].clrn = !clr;
   
   CASE State IS
      WHEN ZOMBIE =>   % controller blocked and do't pass ints %
         IF InSignal[] > 0  THEN % we have interrupt %
            % WE CAN HAVE BLOOD EMERGENCY HERE. REACTOR BLAST %
            ZombieLayer[].d = ZombieLayer[].q AND InSignal[];  %accumulate ints%
         END IF;
         
         IF UnBlock THEN % we processed interrupts %
            IF ZombieLayer[].q > 0 THEN % We have zombie ints %
               OutSignal[] = ZombieLayer[].q;
               Signal = VCC;
            ELSE
               State = TRANSPARENT;      % we kill zombie %
            END IF;

         END IF;
            
      WHEN TRANSPARENT => % controller pass ints %
         IF InSignal[] > 0 THEN % we have interrupt %
            OutSignal[] = InSignal[];
            State = ZOMBIE;  % zombie awakes %
            Signal = VCC;
         END IF;
   END CASE;
END;


%При наличии поступлении прерывания контроллер выставляет
прерывание и входит в режим сбора прерываний без оповещеня.
при разблокирвке контроллера накопленные прерывания выставляются
все как у людей
%

А насчет совести все написанно ниже:

[SlavaI]

Это были первые слова разработчика языка Visual Basic. Всегда все плохое начинается с этих слов.

 
Ну это ты перебираешь. Иногда стоит пожертовать памятью ради производительности.

Вопросы связанные с наложением обработки обработчика и отложенного обработчика - вопросы железа (переформулируем вопрос так).

Ну дак никто и не спорит. Только решить его надо минимально возможными средствами. Самый верный способ с буферизацией нескольких запроссов был отвергнут разработчиками(см посты автора темы выше). Поэтому надо как-то выкручиваться. Вот и придумываем как наиболее дешевым способом им перепаять плату(ну там статусный регистр и т.д.) и далее увеличить реактивность имеющегося кода. Собственно мы почти пришли к нескольким решением(читай выше). Автор сам выберет. Ну в общем твое мнение понятно и вполне логично. Как говорил мой научный руководитель: "Приятно поговорить с умным человеком"

А на чем этот код? На Паскале? Модуле? С ужасом вспоминаю как я весной делал работы студентам МИФИ с заданием- программы на Паскале с ассемблерными вставками, до этого я Паскалем последний раз пользовался шесть лет назад и не знал что в нем есть ассемблерные вставки, оказалось есть в Borland Pascal.

[V-ctor]

Ну нихрена себе кусок рилтайм ОС!!!!
Я фигею ! Это знаете на чем писано? На языке AHDL!!! Язык Альтеры для написания прошивок под их ПЛИС!!! ПЛИС!!!
Это же камень! Там по определению все параллельно выполняется! Так хоть процессор свой написать можно!
Нет это конечно все классно, токо совсем из другой оперы!
На писюке при всем желании никаким боком это не приткнуть!
Или это совет создать полностью свою аппаратную платформу? Дак тяжко весь сетевой стек реализовывать на ПЛИС! А денег влетит... дешевле фирменные за килобаксы покупать.

Тут или CrashMaker не зама откуда это выдернул или уже я чего-то не понимаю в колбасных обрезках.

[V-ctor]

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

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

[maaaaaad]

2 Slaval
  Все впорядке. Если я обидел - извините. Рилакс. Это просто текст. ТЕКСТ на экране. Кучка разноцветных пикселей. А я просто не могу спокойно обсуждать животрепещущую тему.
А может быть
It's just one of those days. Where ya don't wanna wake up Everything is fu*ed, everybody su*s. You don't really know why. But you wanna justify rippin' someone's head off. It's just one of those days! It's all about the he said she said bull shit...
  забудьте про модулу и аду =) и про паскаль=)). И не надо вспоминать это.

Да и камень жирный больно нужен для таких целей

0. Контроллер прерывания (если много источников прерывания).
1. Буфер со страничной организацией (лучшее решение для сетевых систем) в возможностью переключать заданную страницу буфера на отображенную память. Или использовать DMA (чаще для сетевых) т.к. не известны физические страницы - буфера юзер.мод. - типа запросов receive().
2. фифо менеджер буфера.
3. Синхронизация доступа памяти девайс - драйвер и синхронизация с завершением обработки иср.
 и собственно pci ядро.

Но к сожалению жирность камня на котором это реализуется такая большая, что он не помещается на pci карте.

тяжко весь сетевой стек реализовывать на ПЛИС

А придется.

хотелсь все попростецки

По простецки все хорошо выходит на Visual Basic.

Да вы скажите наконец какой камень то?

Ну нихрена себе кусок рилтайм ОС!!!!

Блин, ну написано же в заголовке - InterruptController!!
Вам правда нужен кусок ос? Зачем вам это так нада?=)) Ок. Режим работы процессора - анреал. Дата производства кода - 2001 =)) упрощенная аналогия DPC-IRQ.

7. Менеджер прерываний

У контроллера прерываний есть недостаток: он блокируется при выполнении ISR для менее приоритетных прерываний. И получается, что ISR менее приоритетного прерывания должно ожидать завершение работы ISR более приоритетных прерываний.
При поступлении прерывания нужно лиши фиксировать факт прихода прерывания, разблокировать контроллер а затем уж приступать к обработке прерывания в обычном потоке , который может прерываться IRQ любого уровня.
это реализуется моим менеджером прерываний: (см kernel.asm)
 
сформируем в памяти стек, например в сегменте 5000h следующим образом

 Стек задач (2 задачи добавлены в стек)
 ES->+--------------+
    |              |
    +--------------+ <==SI-6 флаги будующей задачи
    | ??  |
    +--------------+ <==SI-4 сегмент будующей задачи
    | ??  |
    +--------------+ <==SI-2 смещение будующей задачи
    | ??  |
    +--------------+ <==SI (Указатель стека задач)
    | TASK2 FLAGS  |
    +--------------+ <==SI+2 сегмент задачи
    | TASK2 SEGMENT|
    +--------------+ <==SI+4 смещение задачи
    | TASK2 OFFSET |
    +--------------+ <==SI+6 флаги предидущей задачи
    | TASK1 FLAGS  |
    +--------------+
    | TASK1 SEGMENT|
    +--------------+
    | TASK1 OFFSET |
    +--------------+ <= 0FFFFh

рис. 5

сегмент ES - сегмент где располагается стек прерываний
этот сегмент заполняется снизу - со смещения FFFFh вверх
параметры прерывания - элементарная ячейка состоит из
а)флагов прерывания
б)сегмента, где располагается драйвер
в)смещения драйвера
переменная TSP - (Task Stask Pointer) указывает на позицию прерывания, которое было
добавленно в стек последним


@SYSLOOP:
; jmp @SYSLOOP
@EMPTYTEST:; проверка на наличие задач
cmp TSP,0FFFFh ; нет задач? (стек задач пуст)
je @HALT
jmp @PROCESS
@HALT: ; задач нет - останавливаем процессор и ждем прерываний
hlt
jmp @EMPTYTEST
обработка задач. Прочессор в свободное время будет занят двумя вещами:
поиск, исполнение и удаление завершившихся задач

@PROCESS: ; ищем поставленные задачи и чистим стек задач от завершившихся
test ES:[TSP],WORD PTR TASK_TERMINATED ; смотрим флаги задачи
jc @REMTASK
@EXEC: ; запуск дравера
mov ES:[TSP],WORD PTR TASK_TERMINATED ; пометим задачу как завершившуюся
call CS:[TSP+2] ; дальний косвенный вызов драйвера
jmp @SYSLOOP
@REMTASK: ; удаление задачи из стека задач
add TSP,6
jmp @EMPTYTEST

листинг 3 Реализация менеджера прерывания.

каждый ISR должен быть составлен по следующему правилу, которое
заключается в добавлении "записи" в стек задач.

ISRX proc
PUSHA
MOV AX,5000h
MOV ES,AX
; резервируем место для задачи
sub TSP,6
; добавляем задачу
mov ES:[TSP+4],offset DRIVERX
mov ES:[TSP+2],CS ; WORD PTR SEG DRIVERX
mov ES:[TSP+0],WORD PTR TASK_RING0
;
POPA
; завершающие действия ISR
; ...
iret
ISRX endp


листинг 4. добавление задач.

[V-ctor]

CrashMaker, слушай ты извини, но я с трудом тебя понимаю. Вообще твой подход к общению в конфе.

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

Да вы скажите наконец какой камень то?

У меня или в фирменной плате? Коли так интересно:
фирменная платка Septel (бывший DataKinetiks), сделана на камне MPC850 (или 860) Короче нехреновый такой камень, тянет токо 4 линка! Четыре!
У меня же камушек попроще ADSP2185.

Блин, ну написано же в заголовке - InterruptController!!
Вам правда нужен кусок ос? Зачем вам это так нада?=)) Ок. Режим работы процессора - анреал. Дата производства кода - 2001 =)) упрощенная аналогия DPC-IRQ.

Нет все понятно просто речь шла про кусок ОС , а потом этот исходник.
Нет мне кусок ОС совсем не нужен мне и без того хватает эротики (а порой и порнографии), что б еще реализацией своей ОС заняться.
Что мне надо дак это лучше понять работу ядра w2k и творить с учетом ЕЁ особенностей.

И красивые решения бывают не токо на вижал васике... просто продумывать надо все хорошо... ну или ключевые моменты... вот я упустил один такой. Но это не значит, что надо выкинуть плату и сесть за разработку новой СРАЗУ! Надо выжать тут все по макс, что бы программеры могли писать ПО верхнего уровня и отлаживать алгоритмы. Вот как выжму, если окажется ненадежно, то буду перекраивать железо.

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

Ну я как-то бы побоялся назвать это недостатком. По-мойму он так работает по определению. Просто нужно для приорететных прерываний задовать соотв. приоритет в контроллере. А иначе вообще что куда и на кого?
Еще не встречал ниразу иных алгоритмов контроллера.
А то что в винде мое прерывание не самое приоретеное... дык и впрямь так винда устроена и никто на неё не обижается за это.

Если я чего и путаю, думаю Слава нас рассудит (когда время будет для ... этого)

Спасибо за советы и исходники и текст песни Limp Bizkit.

[maaaaaad]

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

 Спокона! =) Я так =)

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

И вобще - мне сказали сделать перераспределение приоритетов програмно так я сделал =) Если вам не нравистя идея DPC в NT - извините =) В следующей версии подправлю =) Ждите релиза Windows Longhorn =))
Забирание нужных irq это отдельная тема. Кого на что повесить (а кого к стенке) решаете не вы, а решают за вас со всеми вытекающими.

[SlavaI]

Если вам не нравистя идея DPC в NT - извините =)

DPC в NT - это аналог нижней половины(bottom_half) обработчика прерываний в Linux(ф-цию do_bottom_half посмотрите!).А ISR- это аналог верхней половины. Вот такие аналогии. Так что и Linux не пойдет.

Ждите релиза Windows Longhorn =))

У тебя есть какая-то инфа про этот Longhorn? Тогда поделись- можно в привате.

[maaaaaad]

У тебя есть какая-то инфа про этот Longhorn? Тогда поделись- можно в привате.

Новый интерфейс (аппаратное ускорение + 3d окна)
Новая файловая система WinFS (обновленная ntfs?).
Новые система безопасности (обновленния + то, что удалось украсть=) чде то у них ведется обсуждение на эту тему - после бласта расгорелась работа по усовершенствонии системы обновлении=))).
По ядру ничего не известно (надеюсь на официальноую поддержку realtime иначе буду сильно разочарован. Думаю ms планирует занять позицию и на рынке rtos....сначала пользователи потом w2k аля nix - сети...что остается?)
(самому бы узнать хорошо=))) какие-то фичи появятся (само собой) только какие ума не приложу...вроде все есть
блин, оптимизацией бы занялись лучше...

на сайте ms где то ведется обсуждение WinFS. Мне это особо не интересно - не искал..
Про остальное-юзерские впечатления от прогонагона альфы лонгхон.
На сайте кое че выложенно.