Since you were previously talking about RTP, if you had RTCP reports being sent in both directions, you can calculate the network rountrip propagation delay using the timestamps only from one side.
Wireshark already does this calculation, if you turn the appropriate preferences on for the RTCP dissector.
On Thu, Mar 13, 2008 at 11:01 AM, <
juan.wortley@xxxxxxx> wrote:
Hi Fabiana,
the only way to do that is if you know the time difference
between the machines.
It´s not so easy however if you use windows you could try
synchronizing both endpoints by using:
w32tm /config /manualpeerlist:[IP to synchronize to]
/update /syncfromflags:MANUAL
and
then monitor the time difference with:
w32tm
/stripchart /computer:[IP to synchronize to]
,you
always can have a delay reference by pinging and dividing by 2 the
RTT.
HTH
Juan
so ... it is not reliable if i substract the time i hav in the
client minus the time i have in the server to get my end the end
delay?
On 12/03/2008, Hansang
Bae <hbae@xxxxxxxxxx>
wrote:
Fabiana
moreno wrote:
> Hello there,
>
> I know wireshark is not
able to calculate the end-to-end delay of a
> packet when streaming. I
was just wondering if adjusting the clocks of
> my two
computers(sender and receiver) to the network time protocol and
>
having the sniffer at both ends i could calculate the
end-to-end-delay
> tracing each packet. Does this sound
logical?
>
It is within the limits of
ntp. Unless there is a WAN involved, the
packets are flying
around at an order of magnitude faster than what ntp
can provide (ms
resolution)
--
Thanks,
Hansang
_______________________________________________
Wireshark-users
mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users
_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users