[Winpcap-users] Îòâåò: WinPCAP packets capture delay..
gianluca.varenni at cacetech.com
Wed Sep 22 09:48:46 PDT 2010
From: ""Fish" (David B. Trout)" <fish at infidels.org>
Sent: Wednesday, September 22, 2010 1:37 AM
To: <winpcap-users at winpcap.org>
Subject: Re: [Winpcap-users]Îòâåò: WinPCAP packets capture delay..
> Gianluca Varenni wrote:
>> 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.
> Yes, but... are the packets actually stamped during interrupt (DPC)
> processing? You say "usually", but there *are* exceptions, are there not?
> Presuming there are, what are the exceptions?
The function in the driver that receives packets and timestamps them is
called directly by NDIS (i.e. the Windows networking infrastructure) which
is in turn called directly by the NIC miniport driver that wants to notify
the upper layers for the reception of a packet. WinPcap has no control over
this. Now, all the NIC miniports that I've seen notify the upper layers of a
new packet from within their DPC routine. However a NIC could also notify
packets from within a work item, which is basically a system thread. Things
get even more complicated if you have any sort of NDIS intermediate driver
in the packet reception path (WinPcap sits on top of them).
Perhaps that is what he is
> seeing here: the exceptions.
> I guess what I'm getting at is this: a packet comes which causes an
> interrupt, but WinPCap doesn't process that interrupt, the miniport for
> NIC does, correct?
> Then, sometime later, NDIS hands it over to WinPCap. Thus
> the time delay between when the packet actually arrived and the time when
> WinPCap gets a chance to timestamp it could be the delay he is seeing.
If the packet is delivered from the DPC routine of the NIC driver, a delay
of some milliseconds would most probably mean a bug in the NIC driver (if
the NIC driver delays a packet of some milliseconds, you would have a huge
> And I was simply presuming (perhaps erroneously so) that the cause of the
> delay was normal thread dispatching by the core operating system (kernel).
> Let me ask you this: based on YOUR understanding of his situation, can YOU
> explain where the delay might be occurring? (That's not a demand or a dare
> but an honest plea for help!)
As I wrote in the other mail, I don't have an explanation. That's why I
would test the issue with different NIC boards and I would make sure that
the transmitter is actually generating packets at a fixed rate (i.e. the
transmitter is not introducing the 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.
>> ... 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.
> I already knew that but admit the way I said it could be interpreted that
> way and was thus misleading.
> Sorry. :(
> But THANK YOU for clearing up my potentially misleading information,
> Gianluca. I *do* appreciate it!
> I like helping people, but I *don't* like misleading them.
> Even unintentionally.
Have a nice day
> "Fish" (David B. Trout)
> fish at softdevlabs.com
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
More information about the Winpcap-users