Prev: SRB_FUNCTION_PNP response
Next: Performance Problem
From: Asaf Shelly on 6 Oct 2010 16:38
Hi all,

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
of 100ms.

This 15ms magic number appears with any COM port we used: USB, pciexpress,
and on-board.
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?

TIA,
Asaf
From: Pavel A. on 6 Oct 2010 20:47
"Asaf Shelly" <MSMediaForum(a)Shelly.co.il> wrote in message
news:04B5663E-2A75-4B09-A842-B9A2B49B5E05(a)microsoft.com...
> Hi all,
>
> Still with a driver that is opening a COM port.

Sure, these long holidays...

Symptom: "magic" 15 ms delay
Answer: this is the timer tick period.
Look for something that waits for event with timeout, or just for time, like
KeWaitForSingleObject, KeDelayExecutionThread, etc.
The com port i/o also has option for completion on timeout.

Regards,
-- pa

> 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
> of 100ms.
>
> This 15ms magic number appears with any COM port we used: USB, pciexpress,
> and on-board.
> 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?
>
> TIA,
> Asaf

 | 
Pages: 1
Prev: SRB_FUNCTION_PNP response
Next: Performance Problem