Wireshark-users: Re: [Wireshark-users] Strange Delta Time
From: "Jim Young" <SYSJHY@xxxxxxxxxxxxxxx>
Date: Tue, 27 Jan 2009 14:11:37 -0500
>>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.
- References:
- Re: [Wireshark-users] Strange Delta Time
- From: Frank Pall
- Re: [Wireshark-users] Strange Delta Time
- From: Alexandre Aeschbach
- Re: [Wireshark-users] Strange Delta Time
- Prev by Date: Re: [Wireshark-users] Strange Delta Time
- Next by Date: [Wireshark-users] Link quality tests/analysis?
- Previous by thread: Re: [Wireshark-users] Strange Delta Time
- Next by thread: [Wireshark-users] Fw: Re: Strange Delta Time
- Index(es):
- Get Wireshark
- Download
- Code of Conduct