паузы в работе OC на 5мс - откуда? может кто стал&#

[Ochkarik]

Проблема такая: какой то процесс(возможно системный) тормозит обработку DPC ровно на время 5,0-5,2 мс.(длительность не меняется!)

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

то есть:
1 приходит пакет - генерится аппаратное прерывание.
2 из контроллера 1394 вычитывается пакет. ставится в очередь DPC.
3 после выполнения этого DPC - отсылается Response пакет, подтверждающий, что пакет обработан.
4 и только после этого устройство может отослать второй пакет.
соответственно любая пауза между аппаратным прерыванием и DPC приводит к паузам между пакетами. а эти паузы и гадят потоковой передаче - не хватает FIFO..(увы - с этим не можем побороться)

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

у кого какие идеи? может кто то сталкивался с подобным?

PS вроде винда голая - ноут только купили.

[Sla]

может быть это связано с типом системного чипа, возможно 1394 имитация через PCI, возможно еще как-то (не знаю как)

[Ochkarik]

Sla,
нет, специально приобрел карту Express Card (ноутбучные, фактически это PCI-Express) с Texas-овским чипом.
так вот на одном ноуте (Dell) - паузы есть, на другом(Sony и Asus-V6j) - нет

а вообще немного разобрался с проблеммой... не до конца, к сожалению, но основного виновника нашел - им оказался SATA контроллер
в общем в соньке и других компах на которых пауз не было - стоит два контроллера: SATA для HDD и ATA для CD-ROM, причем в каждом использован лишь Channel-0.

в долбаном Dell-е стоит ОДИН SATA-шный контроллер который на Channel-0 обслуживает HDD, на Channel-1 CD-ROM.
так вот - программно выгружаю драйвер CD-ROMа - тут же пропадают 5мс паузы(которые каждые 30сек происходят). однозначно он. такой эффект и на Viste Ultimate и на XP!

а не доконца разобрался - потому что все равно раз в пол часа-час бывают аналогичные сбои.. непонятно что с ними впринципе делать при таком кривом стеке 1394... остается правда вариант использовать стек от Unibrain, но там полностью свой интерфейс. либо взять коды от линукса(не представляю где еще искать доку по портам I/O для OHCI), и покопавшись написать свой драйвер для ohci1394.... оба варианта не радуют

[Aleck D.Shadow]

Ochkarik ,а как проблему нашел ? Какие счетчики использовал?

[Ochkarik]

Aleck D.Shadow,
в общем толком счетчики не помогли, хотя я долго и тупо смотрел подчти на все)
мне же надо практическую импульсную нагрузку на проц поймать - а там все счетчики с усреднением. думал по % загрузки ядра увижу - ничего подобного. смотрел по длинне очереди DPC- тоже не видно, хотя проблемма скорее всего в этом - в задержке между прерыванием и выполнением связанного с ним DPC.

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

Или вы имели в виду - как вообще про 5 мс узнал? - это я свою оценку производительности делал в DPC драйвера(до прерывания не добрался - его ohci1394.sys обслуживает, мне только DPC отдает):

Код:

LONGLONG Performance64;
DWORD Temp;
Temp = (DWORD)&Performance64;
    __asm 
    {
        rdtsc; //сохранение 64 битного счетчика времени в edx:eax
        mov ecx,Temp;
        mov [ecx], eax;
        mov [ecx+4], edx;        
    }

ну а дальше пересылал в приложение такую таблицу и там анализировал в пакете ошибки.

[Aleck D.Shadow]

Ochkarik,
да я вот типовой проблемой тоже озадачен, правда временной период гораздо больше.Вопрос уж задавал:
https://forum.shelek.ru/index.php/topic,11817.0.html
Толи кэш винда сбрасывает, то ли что. Не понятно.
Самое интересное что на простом компе те же проги подвисают всего на 1 секунду и менее.
А на более мощном серваке со SCSI винтами и всё такое, виснет на 3 секунды. 
Использовал и kernelprof но там только функция появляется связанная с dma.

[Sla]

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

[Ochkarik]

Sla, хм, вобще это от сети все работало... и вроде выставлял все что можно... но идея интересная. сенькс! проверю!
PS только этим операционка должна заниматься. а она как раз совсем не ноутбучная была) обычный диск.

[Sla]

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

Offtopic:

попалось как-то чудо в руки, винт все время засыпал, и не просыпался, выставили все нужные и не нужные бимбы в ОС, потом полезли в биос, там отключили хрень, потом полезли во внутрь - осталась в руках лишняя деталь - и все стало ок

[Ochkarik]

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

попозже еще поиграюсь)