>>Frank Pall schrieb:
>> Hello,
>> i have some more tests in the meanwhile...Today i tried to connect two
>> pcs with a cross cable,installed wireshark on both the pcs and made a
>> test,and i clearly see a difference in the packets time stamps...
>> I attach you the two capture files relative to a single test
>> ("Source.pcap" is the file captured from the "source" pc,"Dest.pcap"
>> the one captured from the destination one)
>> Any clue about it?
>
> Alexandre Aeschbach <lex@xxxxxxxxxxx> 01/27/09 12:17 PM >>>
> Really strange things happen after packet 55 in source and destination -
> after a "long" gap of about 50ms everything seems to be ok with a delta
> of 10ms between the packets. In both files.
>
> How do you implement the networking part of you application?
> Do you buffer the packets on the receiving side and poll them out of it?
I second those questions! ;-)
With a cross-over cable in place you've taken any L2 switch buffering
out of the game, but both the sending and receiving NIC cards can
buffer packets.
>From the "Source" Wireshark's point-of-view it looks like the sending side
was initially seeing these 66 byte packets every 0.004 seconds (+/-)
until packet 54 when there is a gap an order of magnitude longer
(0.047 seconds) than the previous gaps. After frame 54 subsequent
gaps were about 0.01 seconds apart. But these gaps may not
necessarily be consistent with the pacing that the NIC card itself sent
the packets out the interface.
On the sending side have you implemented synchronous/blocking writes
to the network stack or asynchronous/non-blocking writes or some
other method to wake up and send the next packet?
>From the "Dest" Wireshark's point-of-view these packets are retrieved at
fairly consistent 0.01 second intervals.
On the receiving side have you implemented polling with synchronous/blocking
reads or asynchronous/non-blocking reads or some type other methods or
waking up and fetching the data?
I'm wondering if you run longer tests if you will at some point in time
start detecting some missing packets?
For testing purposes you might want to try to exaggerate/manipulate
the inter-packet delay by sending bigger sized packets, or sending
them at more frequent or less frequent intervals and seeing what
bearing these changes have on the receiving side. Unless your
receive side is terribly inefficient (e.g. has a lot of work to do with
each inbound packet read) I would expect your writes (sends) will
should start failing first. But I could very likely be wrong. That's
why one tests!
While these were interesting traces, 79 packets over 3/4 of a second
may NOT a big enough sample to draw any real conclusions from! ;-)
Jim Y.
