I’m actually on a conference call discussing this now. We really appreciate all the suggestions. We did look into other possible interrupting options, this chip ONLY supports an FIFO_EMPTY interrupt. We have approximately 360 microseconds after the empty interrupt to put more data into the buffer before that final word is done being transmitted.
We only have a single core processor as we disabled hyperthreading. Hyperthreading was causing lots and lots of problems with timings and our very deterministic application. Is it possible to “hijack” the only core we have? When we still had hyperthreading enabled, I tried reassigning our driver to the second “core” and it appears the framework still executes all ISRs on the primary “core”.
Cheers,
Brad
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Marion Bond
Sent: Tuesday, April 14, 2015 5:20 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: [ntdev] IRQL Priority Problems
The dedicated thread approach, coupled with high IRQL is called hijacking a core and is valid if you control everything about your environment.
Sent from Surface Pro
From: xxxxx@hotmail.commailto:xxxxx
Sent: Tuesday, April 14, 2015 12:59 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
If I’m understanding your issue correctly the undesired behavior is that there is too much latency between subsequent transmit WORDs due to an underrun condition.
The sequence of events is:
(1) receive a buffer empty interrupt
(2) Run your DPC to put more data in the buffer
The I/O with hardware in the DPC has very slow transactions.
The transmitter is able to transmit the entire contents of the buffer before you can provide more
data to transmit. This introduces latency between subsequent WORDs.
It may seem that responding to the interrupt more quickly would be a suitable solution, but really the underlying issue is that you need to keep the buffer from emptying. One approach would be to look for an alternate interrupt condition that would notify you when the buffer is ‘almost’ empty. This would give you time to add more data to the buffer before the transmitter drains it. What you really need to figure out is just how long your I/O transactions with the device are taking. Then you need to instrument how quickly your transmitter can drain the buffer. If you know these two things you can then figure out just how low you can allow the buffer to get before you are approaching your underrun condition. If you don’t know this information and need a shotgun approach, your best option it to likely abandon the interrupt driven model and fill the buffer in a separate thread. You could have the thread have an arbitrary wait interval and the sole responsibility of the thread is to keep feeding that buffer.
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>