[Winpcap-users] Îòâåò: WinPCAP packets capture delay..

[Fish" (David B. Trout]

Alimjan Kuramshin wrote:

[...]
> So, when my device send data to the PC, i'm using the Wireshark
> to capture incoming stream,

Okay.


> and found those delays, using oscilloscope on TX+/- line i don't
> see any delays between the packets, everything just fine.

Your oscilloscope is connected to the physical Ethernet cable, correct?


> And delay is very strange i guess,

By "delay" you mean what? Please define your "delay".

When you say there is a 50us delay, where did the 50us value come from?  How
did you calculate it?  What two time values are you subtracting from each
other that equals 50us?


> for example(delays in us): .. .. 45 46 44 48 49 1200 44 48 44 46 49
> 42 50 1530 .. and number of 'normal' delay between packets is very
> vary as delay itself, i can receive 200 packet with delay of 40-60 us

200 * 50us = 10000us = 10ms.

10ms happens to be the approximate timer resolution of the Windows operating
system timer, and approximately the maximum amount of CPU time that a thread
can consume before the operating system will remove it from the head of the
dispatchable threads list to the end of the list to wait for another "slice"
of processor time. This is completely normal.


> and then i've got huge timeout 1-3 ms, some times much greater,

This is completely normal. An interrupt probably occurred or else another
higher priority thread's wait completed, and so the system interrupted YOUR
thread (WinPCap's and/or Wireshark's) and dispatched the other higher
priority thread. Then 1-3 ms later, the other thread finished with what it
needed to do and so went back to sleep. The system then dispatched YOUR
thread again. Thus a 1-3 ms delay.

Again, this is completely normal in ANY multi-programming environment where
multiple threads/processes are running. Why are you so surprised by this?


> then 1000 packets normal and then again delay,

1000 * 50us = 50000us = 50ms

The other threads probably had no work to do for that 50ms interval, so your
thread was dispatched again and again. Five times in fact. Then, some other
higher priority thread (probably a system thread) needed to do something,
causing your thread to be delayed for 1-3ms. This is normal! Nothing you
have said so far is anything unusual. It is all completely normal and
expected.


> so i can't see no logic with it.

See above. :)


> From this point my question is: is it possible to archive stable
> receive with WinPCAP  during long period of transfer, i mean stable
> capture interval?!

Probably not.

As long as there are other equal or higher priority threads running on the
system (and as long as there are device interrupts occurring that need
servicing) your thread WILL be interrupted and experience delay. This is
normal multi-task (multi-thread) dispatching behavior and there's largely
nothing you can do to prevent it.

The ONLY way to prevent it is to ensure your thread is the highest priority
thread in the system, but be forewarned: doing so is *dangerous*! If, for
example, the system threads that handle keyboard and/or mouse and/or timer
and/or disk interrupts, etc, are not ever dispatched because your thread is
consuming all available CPU cycles, your system will lock up and become
unresponsive. You will have to do a hard power-off.

As long as you are using consumer-level hardware and a consumer-level
operating system instead of specialized hardware and a real-time operating
system, you are going to experience delay.

Windows is NOT a real-time operating system, nor was it ever meant to be.

-- 
"Fish" (David B. Trout) 
 fish at softdevlabs.com