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.
_______________________________________________
Winpcap-users mailing list
[email protected]
https://www.winpcap.org/mailman/listinfo/winpcap-users
