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: [email protected] on behalf of Alimjan Kuramshin
Sent: Wed 9/22/2010 8:44 AM
To: [email protected]
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
[email protected]
https://www.winpcap.org/mailman/listinfo/winpcap-users


<<winmail.dat>>

_______________________________________________
Winpcap-users mailing list
[email protected]
https://www.winpcap.org/mailman/listinfo/winpcap-users

Reply via email to