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

[Gianluca Varenni]

--------------------------------------------------
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 
> the
> NIC does, correct?

Yes.

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

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 
performance issue).

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

No worries.

Have a nice day
GV


>
> -- 
> "Fish" (David B. Trout)
> fish at softdevlabs.com
>
>
>
>
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users