Prev: Performance Problem
Next: prepress softwares bentley autodesk full download crack prepress 2010 rapidshare megaupload torrents BnuT==(GZB
From: Asaf Shelly on 6 Oct 2010 16:42
Still with a driver that is opening a COM port.
The driver is issuing a read request to the COM port.
On completion the driver is saving the buffer and queuing a DPC which will
issue the next read to the COM port. This way the driver is reading as fast
as it can.
Or at least this is what I thought. It looks like reads are completed with 0
timer ticks (100ns) repeatedly when there is more to read.
If there is nothing to read then the next read will be in average of the
real data sent but in multiples of 15 milliseconds exactly.
For example if 10 bytes are sent every 100ms then the driver will read all
10 bytes with zero delay (less than 100ns). After 100ms the next 10 bytes are
received but the read will start at a delay of either 93ms or 108ms, instead
This 15ms magic number appears with any COM port we used: USB, pciexpress,
It is not the port's FIFO.
The question is: is this part of the limitation that Windows OS has by
design, is it something configurable, or are we doing something wrong?