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

[Gianluca Varenni]

--------------------------------------------------
From: ""Fish" (David B. Trout)" <fish at infidels.org>
Sent: Tuesday, September 21, 2010 2:32 AM
To: <winpcap-users at winpcap.org>
Subject: Re: [Winpcap-users]Îòâåò:  WinPCAP packets capture delay..

> 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.

Not exactly.

Supposing that he is talking about the WinPcap timestamps, then they are 
generated by the driver, in a context that is *usually* a DPC routine 
(somewhat similar to a software interrupt), so not affected by thread 
scheduling. *Usually* because it actually depends by the NIC driver and by 
NDIS itself.

>
>
>> 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.
>

Here you are assuming that the timestamps are generated from within a thread 
(his application thread), which is not the case. Timestamps are generated 
within a function in the winpcap driver that does not run within his 
application thread.

> 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.

Using high priority threads (where "high" has to be defined) can definitely 
be dangerous because it can affect some critical threads/processed in the 
system. Having said that, I would be careful in talking about "system 
threads that handle .... interrupts". Interrupts are NOT handled in system 
threads. Since they interrupts, they are handled in an interrupt service 
routine that has higher "priority" over whatever thread you might have 
running on the system.

GV