[Eram Khan <eramk2003@xxxxxxxx>]

Ok!! I tried out with the view option and it works. Im surprised that its so easy to do it and I was using these complex calculations all the time. So 1932 ms is the round trip delay of the packets u sent me. Isnt it a high value coz wat I read round trip delay (d) should be

 

less than 150 ms => which is acceptable for all

and 150 ms < d < 300 ms => which is acceptable for some users

and d >300 ms => not acceptable.

 

Or are these values for one-way delays?

 

Thanks a lot  for ur help.

Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx> schrieb:

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 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 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@xxxxxxxxxxxxx
> 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@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users

---

Kennt man wirklich jeden �ber 3 Ecken? Die Antworten gibt's bei 
Yahoo! Clever.