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

[Fish" (David B. Trout]

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? 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? 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?
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!)


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

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