["Martin Mathieson" <martin.r.mathieson@xxxxxxxxxxxxxx>]

On 5/23/07, Eram Khan <eramk2003@xxxxxxxx> wrote:
> 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

No. 1932 ms is the time elapsed between sending one report out and
receiving an incoming report whose LSR refers to the first report.
Endpoints will send out reports based on a timer or some other
trigger.  Some endpoints may send a report as soon as they receive
one, but that didn't happen in this example.

We calculated the actual network propagation roundtrip delay as 13ms.
Which as Wireshark shows is the calculated time taken for a 2-way
roundtrip.


>   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?

I'm not sure where these values come from.  They may well be one-way,
in which case you would probably divide the roundtrip delay by 2 to
get the delay (assuming the route taken is the same for both
directions...).

>   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.