Just choose 'View | Time Display Format | Seconds since previous Displayed Packet', and you'll see that they are 1932ms apart. (I can't follow your calculations where you try to convert the absolute time to milliseconds - you don't need to do this).
Martin On 5/22/07, Eram Khan <[EMAIL PROTECTED]> wrote: > Hi!! Martin, well your explanation was quite helpful but I still have some > queries. > I used your 2 frames to do the delay calculation, I still get a negative > value. Maybe I am not calculating it correctly. Im using the 2 frames u hav > send to show it to u, maybe u can detect my mistake: > > Delay = (timestamp of receiving returned report, i.e. frame 2) – > (timestamp of sending original report, i.e frame 1) – ( DLSR, as seen in the > frame 2) > > Timestamp of receiving returned report i.e frame 2 = Oct 17,2006 > 17:13:48.145195000 > > (927377 h x60 x 60) + ( 13 min x 60) + 48 secs > = 3338557200 secs + 780 secs + 48 secs = 3338558028 secs = 0xc6fe5a4c > > 0.145195000 / (2 ^(-32)) = 623607776 = 0x252b7fe0 > > middle 32 bits of Arrival time = 0x5a4c252b = 1514939691 > > ð 0x5a4c | 0x252b > ð 15 | 9515 > ð 15 x 1 Second | 9515 x 2 ^(-16) seconds > ð 15 + 0.145187377 seconds > ð 15.14518738 seconds > ð 15145.18738 ms > > OR > ð 0x5a4c | 0x252b > ð 15 | 14939691 > ð 15 x 1 second | 14939691 x 2^(-32) seconds > ð 15 + 3.478417872 x 10-3 > ð 15.00347842 seconds > ð 15003.47842 ms > > Timestamp of sending original report, i.e frame 1 = Oct 17, 2006, > 17:13:46.212354000 > > (927377 h x60 x 60) + ( 13 min x 60) + 46 secs > = 3338557200 secs + 780 secs + 46 secs = 3338558026 secs = 0xc6fe5a4a > > 0.212354000 /(2^(-32)) = 912053485 = 0x365cd4ed > > middle 32 bits of Arrival time = 0x5a4a365c = 1514813020 > > ð 0x5a4a | 365c > ð 15 | 13916 > ð 15 x 1 | 13916 x 2^(-16) seconds > ð 15 + 0.212341308 > ð 15.21234131 seconds > ð 15212.34131 ms > > OR > ð 0x5a4a | 365c > ð 15 | 14813020 > ð 15 x 1 | 14813020 x 2^(-32) > ð 15 + 3.448924981 x 10-3 > ð 15.00344892 secs > ð 15003.44892 ms > > DLSR from frame 2 = 125830/65536 = 1.920013428 * 1000 = 1920.013428 ms > > Now the calculation: > > ð (15145.18738 ms - 15212.34131 ms) – 1920.013428 ms > ð - 67.15393 – 1920.013428 > ð -1987.167358 ms > > OR > ð (15003.47842 ms - 15003.44892 ms) - 1920.013428 ms > ð 0.0295 – 1920.013428 ms > ð - 1919.983928 ms > > > I think I have a problem with the conversions especially 2^(-32) or > 2^(-16). > Would be glad if u could comment on my calculation. Thanks for ur help. > > > Martin Mathieson <[EMAIL PROTECTED]> schrieb: On 5/22/07, > Eram Khan wrote: > > Hi!! I am Eram Khan from Germany. Studying Computer Enginerring at the > > Niederrhein University of Applied Sciences and currently busy with my > thesis > > project. > > > > I am testing the VoIP connections of a firm here in Germany with wireshark > > 0.99.5. They have here the Siemens Opticlient Telephone Software. Im using > > the RTCP- Packets to determine the parameters jitter, packet-loss and > delay. > > I have problems in delay calculations, according to RFC 3550 the formula > is > > : A - LSR - DLSR > > where A = the arrival time of the reception report, > > LSR = the middle 32 bits out of 64 bits in the NTP time stamp of the most > > recent sender report and DLSR = the delay expressed in 1/65536 between > > receiving the last SR packet from a source and sending the reception > report > > block. > > I have a confusion regarding the conversion of these values, I hav asked > > my Prof and his colleagues and the Network Administrator here in the firm, > > all hav different views. 2 of the views im describing below: > > > > View. 1 > > > > Delay (in ms) = Arrival time - (LSRx1000) - DLSR/(65536x1000) > > Arrival time and DLSR are from the same rtcp packet and LSR is also from > > the same packet. > > Arrival time conversion with respect to 01.01.1900. > > I get a negative value for delay. > > > > View. 2 > > Delay = Arrival time - LSR - DLSR > > Arrival time and DLSR are from the same rtcp packet and LSR is from the > > next rtcp packet ( which contradicts the definition of LSR) > > Arrival time conversion with respect to 01.01.1900. > > I get a negative value sometimes and sometimes an extremely high value for > > delay. > > > > I hav read the Wireshark guide too and found this: > > The internal format that Wireshark uses to keep a packet time stamp > > consists of the date (in days since 1.1.1970) and the time of day (in > > nanoseconds since midnight). > > > > But I calculate the Arrival time from 01.01.1900 as it is for > > NTP-timestamp. > > Im also confused with conversions of LSR and which value is correct. Could > > somebody send an example calculation where i can see step by step how the > > calculation is done. > > Thanks a heap!!! > > Attachments: View1-2 Arrival time calculation and View 2 Delay calculation > > using Frame 1114 in rtcp-test and rtcp-test (consist of rtcp packets only, > > open it with Notepad) > > > > > > I keep meaning to add a proper worked example to the wiki, but have > never gotten around to it. Please open the attached capture file and > follow along with this description: > > (1) Frame 1 is sent at time 0 (from the wireshark time column) > (2) Its (crazy) timestamp is from 1991, but the important thing to > note is that the middle bytes are 0x0000c8df > (3) Frame 2 is received 1.932841 seconds (= 1932ms) after frame 1. > (4) It also has a crazy timestamp (2036), but again this is not > important, because... > (5) The LSR does match the middle part of the timestamp from frame 1 > (0x0000c8df), so we can try to do a calculation > (6) The DLSR is 125830, which is 1920 ms (note that the current > wireshark source version shows this...) > (7) So, out of the 1932ms roundtrip, 1920 was spent between reports at > the far end (10.120.97.10), so the rest was the network propagation > roundtrip reported, which is reported (after rounding) as 13ms > > In this trace, the capture was probably done at 172.16.68.164 - if you > capture very close to one of the endpoints you will only see > measurably delays in one direction. > > The timestamps in the RTCP frames are only used by wireshark to > confirm that the DLSR corresponds to the same (earlier) frame that is > used in the calculation. If an endpoint does this calculation, it > uses the original timestamp and actual time of reception of the 2nd > frame. Wireshark can't - it uses the frame timestamps at the point of > capture. > > Relating this to the variables from the RFC: > > Delay = Arrival time - LSR - DLSR > = (timestamp of receiving returned report, i.e. frame 2) - > (timestamp of sending original report, i.e. frame 1) - > (DLSR, as seen in the frame 2) > > I hope this makes sense, > Martin > > > > > > > > --------------------------------- > > Yahoo! Clever - Sie haben Fragen? Yahoo! Nutzer antworten Ihnen. > _______________________________________________ > Wireshark-users mailing list > Wireshark-users@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-users > > > > --------------------------------- > Yahoo! Clever: Stellen Sie Fragen und finden Sie Antworten. Teilen Sie Ihr > Wissen. _______________________________________________ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
