Discussion:
Performance Problem
(too old to reply)
Asaf Shelly
2010-10-06 20:38:03 UTC
Permalink
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
Pavel A.
2010-10-07 00:47:48 UTC
Permalink
Post by Asaf Shelly
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
Post by Asaf Shelly
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
Asaf Shelly
2010-10-10 22:46:03 UTC
Permalink
Thanks Pavel,

What do I do if I need very accurate timing but don't want to poll the device?

Does this mean that the problem is with my device and if I had an upper
filter I would have received all the data immediately?

Thanks,
Asaf
Post by Pavel A.
Post by Asaf Shelly
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
Post by Asaf Shelly
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
.
Pavel A.
2010-10-10 23:07:14 UTC
Permalink
Post by Asaf Shelly
Thanks Pavel,
What do I do if I need very accurate timing but don't want to poll the device?
Use interrupts, or try to lower the timer resolution.
Post by Asaf Shelly
Does this mean that the problem is with my device and if I had an upper
filter I would have received all the data immediately?
Not sure.

Regards,
--pa
Post by Asaf Shelly
Thanks,
Asaf
Post by Pavel A.
Post by Asaf Shelly
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
Post by Asaf Shelly
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
.
Loading...