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

Wed Sep 22 07:48:49 PDT 2010

I've got a few questions/comments to add...

#1 Are you sending UDP or TCP packets?

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

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

#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/

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

________________________________

From: winpcap-users-bounces at winpcap.org on behalf of Alimjan Kuramshin
Sent: Wed 9/22/2010 8:44 AM
To: winpcap-users at winpcap.org
Subject: EXTERNAL:Re: [Winpcap-users] WinPCAP packets capture delay..

Hello, Gianluca! Thanks for the test and detailed answer..

> Let's step back and analyze the whole issue. Correct me if any of the
> following statements is wrong.
>
> - You have your custom ethernet hardware that is used to generate packets.
        Quite correct, yes..

> - your hardware is able to generate packets at a constant rate, and you can
> prove that the packets are transmitted at a constant rate with an
> oscilloscope.

        Yes, i've got access to the good oscilloscope, Lecroy with an several Gs/s..

> - when you use a WinPcap-based app (e.g. wireshark) to capture packets,
> every now and then you see something weird in the timestamps. Instead of
> being all equally spaced, every now and then you see a big gap of some
> microseconds. For example you see 40us, 40us..., 10000us, 40us...

        And that is wright. But also, i've notice some interesting thing: sometimes timestamp of the next packet from the delay is toooo small,
for example, i've got, us: .. 43 46 48 42 1500 2 49 41 35 48.. So, 2us difference of time stamps a little bit strange i guess.

> Here are my questions/suggestions:
> - are you sure that NO packets are dropped on the receiver side?

        Well, when my device send about 10000 packets NO, no drops, but delay still present. But when my device send a 1000000
packets my laptop/ethernet card or Wireshark drop about 5-10 packets and at the same time connection information from the
network property page of the network adapter show exactly 1000000 packets received for all the test repeats :/

> - when you measure with the oscilloscope, are you 100% sure that you are
> looking at the gap between ALL the packets?

        Well yes, i've got not only the TX line signal but some other ethernet controller help signals on the oscilloscope screen (4 channels)
and found nothing strange with any of the test i've done..

> - how are you running your tests? What I would do is the following:
>  + have your hardware transmitter generate a fixed number of packets (e.g.
> 1 million). Put an incremental counter in every packet.
>  + capture the packets with the winpcap-based app, and make sure that ALL
> the packets are received. If you didn't receive 1 million packets, check the
> incremental counter within each packet.
        And at this time You absolutely wright, i've done exactly the same thing and a lot of variation. It is really easy to say what i've don't try :(

> - you say that you encounter this issue on your laptop with XP/Vista/Win7.
> So always the same hardware (and NIC card).
> - Do you see the same exact issue with another PC running a totally
> different NIC board (hint: use an intel one, they are extremely reliable in
> my experience)?
        I've tried some PC and laptops, i can't remember really all of the hardware parameters, but card was: BroadCom, Intel i guess and Realtek..
And different OS'es. Not so old hardware ~ 2,66-3Ghz CPU's and huge RAM 4-8 Gb..

        My laptop Asus G1S has 2.2 Ghz Intel Core2 CPU unit, 2 G RAM and Realtek 8111B/8168B network card.

> Have a nice day
> GV

 Well, such a grief i've got :(

Many thanks for Your attention, i am really grateful to you, with many thanks and best wishes, bye-bye..
_______________________________________________
Winpcap-users mailing list
Winpcap-users at winpcap.org
https://www.winpcap.org/mailman/listinfo/winpcap-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 8849 bytes
Desc: not available
Url : http://www.winpcap.org/pipermail/winpcap-users/attachments/20100922/42c2e0b6/attachment-0001.bin 