[Winpcap-users] EXTERNAL:Re: WinPCAP packets capture delay..

[Alimjan Kuramshin]

Hello, Michael! It is pleasure to see that some one is wondering: hm, interesting, what a problem really is? 
It's make me not so hopeless, thanks for Your comments/remark and questions!!

> I've got a few questions/comments to add...
> 
> #1 Are you sending UDP or TCP packets?

	Neither UDP nor TCP, it is a custom frame data format..

> 
> #2 You do realize that you have a queue which receives packets from the OS and that Winpcap pulls from the queue, right?  I don't know about your generating device but it probably has the same thing on the outgoing side.
> 
> #3 Your 2us time is probably due to the fact that an interrupt was immediately available to pull from the input queue as at least one packet was queued up while you were busy task swapping.

	I can't really say, but i guess You are right.. I'm not an expert, my device and ethernet connection, it's just a hobby project, so.. :/

> 
> #4 You don't say what your packet size is (or I may have missed/forgotten by now). 10,000 packets might fit inside the queue/processing space completely whereas 100,000 obviously does not.  The behavior you'll see if you look at the queue usage while running is that the queue gradually fills up if you're not processing fast enough.  Eventually you end up having to drop packets when the queue is full.
> 

	Well, i've tried packets with size of 100-1400 in step of 50/100 bytes, e.g. 100, 150 .. and others till 1400. And always the same result with abnormal delay :(
The problem in my case not in the packets drops, but in the some huge 'delays' with packets capture using the Wireshark(and winpcap examples). Under word of 'delay' i mean that difference
between timestamps of the neighborhood packets has a huge spread, some times reaches a several milliseconds :(

> #5 I'd put the transmit time in the packet along with the packet# and then compare those on the receiving side for inter-packet time delay.  You'll still see dropouts and such but your time will be constant with the transmitter and not the receiver and will ignore the queue/interrup delays.  I guess it depends on exactly what it is your trying to measure.
> 
> #6 If your netstats show the correct # of packets but your app does not then you are not pulling from the queue fast enough.  The IP queue got everything but had to toss stuff when it was full.
> 
> #7 What are your queue sizes?  See http://www.psc.edu/networking/projects/tcptune/
> 

	Hm.. Thanks for the interesting article i will study it carefully may be some remarks would be useful.

> Michael D. Black
> Senior Scientist
> Advanced Analytics Directorate
> Northrop Grumman Information Systems
> 

	Many thanks Michael. Bye.