Wireshark · Wireshark-users: [Wireshark-users] Delay-Calculations

[Eram Khan <eramk2003@xxxxxxxx>]

Hi!! Martin,

 

Im calculating the delay as u hav told, I have another question about it:

 

Do I have to take timestamp of sending original report always as 0.00000 secs?

 

Because If i dont do that I get a negative value. I apply the filter rtcp in wireshark so that i can only see rtcp packets and the time format is the same as u hav told. Since Packet 1 is the first rtcp packet it has to be 0.000000 but since my settings are seconds since previous packet it shows me the secs as 5.478626 secs and the packet before the first rtcp pkt is an rtp pkt because i filter them out of a stream.The first rtcp packet is not the first packet of the stream before that are a lot of rtp pkts, this i hav kept invisible  because I hav kept filter as rtcp so that i can switch easily b/w rtcp pkts. Example:

 

In my case Packet 1 of rtcp has the Timestamp in wireshark column = 5.478626 secs

Packet 2 = 3.485609 secs, DLSR in Packet 2 = 3.484619 secs

 

(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)

3.485609 secs - 5.478626 secs - 3.484619 secs = -5.477636 secs = -5477.636 ms

 

If I take the timestamp as 0.00000 secs then its ok

 

3.485609 secs - 0.000000 secs - 3.484619 secs = 9.9 x 10^(-4) = 0.99 ms ~ 1ms

 

Ok its understandable that I take the timestamp as 0.00000 secs for the first rtcp pkt even if the software shows 5.478626 secs but do I hav to do it for all sender/receiver packets pair because next set of packets hav the same problem. Example

 

RTCP Packet 3 Timestamp = 1.574314 secs

RTCP Packet 4 Timestamp = 3.425670 secs

DLSR in Packet 4 = 3.424667 secs

 

3.425670 secs - 1.574314 secs - 3.424667 secs = -1.573311 secs = 1573.311 ms

 

This 1.574314 secs are the seconds since previous pkt which is pkt 2.

If  I take for Packet 3 timestamp = 0.00000 secs, then its ok.

 

3.425670 secs - 0.000000 secs - 3.424667 secs = 1.003 x 10^(-3) = 1.003 ms

 

I think I hav to take it as 0.000000 secs so that the calculation makes sense.

 

Just wanted to ask u if im right coz u know better about it.

 

Thanks a lot.

 

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

> On 5/23/07, Eram Khan 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 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
> > >

---

Was Sie schon immer wissen wollten aber nie zu Fragen trauten? Yahoo! Clever hilft Ihnen.