All streaming media protocols need to deal with latency (or delay),
but more importantly variation in latency (or jitter). (Or as you put
it, fluctuation of latency). They accomplish this by having a jitter
buffer. When you start a stream, the receiver will buffer a certain
amount of data before playing it out. That way, if packets are delay,
a little, the receiver has something to play while it waits for the
outstanding data.
As such, absolute latency isn't important Provided that the buffer is
large enough to accommodate for the maximum jitter, it will always
have something to play. The receiver can wait as long it likes for the
first packet, as long as it doesn't start playing until it has enough
to accomodate with the variation in delay. Wireshark can show jitter
if the stream is carried inside RTP. Just look in Telephony:RTP. If
Jitter is exceeding your buffer size you have a problem.
Regards, Martin
MartinVisser99@xxxxxxxxx
On 2 February 2011 04:03, <jobhunts02@xxxxxxx> wrote:
> The reason I want this information is that I am streaming video over a communications link and am getting poor quality video. I used the program TPCAT and found that no packets are being lost. I assume that the poor video must be due to latency. I'd like to look at the total latency from source to destination and see if it fluctuates. If it does, I will then see if there is a backlog in Linux on either end or in the link. TPCAT is supposed to be able to measure latency but it stops responding when there are large numbers of packets like in a video stream. The author told me this is a known issue. I was hoping there might be an alternative tool to measure latency similar to TPCAT that compares pcap files for latency.
>
>
> On Jan 31, 2011, at 4:44 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
>>
>> On Jan 31, 2011, at 3:20 PM, Martin Visser wrote:
>>
>>> As Guy has said, you can't use the absolute times unless you can
>>> ensure the machines at each end are millisecond synchronized.
>>
>> ...and that the time stamps given to transmitted and received packets correspond to the times you're interested in. If you care *only* about transit time on the network - e.g., the time from the point at which the first bit of the packet is put onto the first network hop and the time at which the last bit of the packet is received from the last network hop - then those time stamps almost certainly do *not* correspond to the times you're interested in. If you care about latency *including network stack latency*, it might be better, although the time stamp applied to outgoing packets is probably later than the time at which the outgoing packet was initially handed to the network stack, and the time stamp applied to incoming packets is probably earlier than the time at which the incoming packet was handed up from the network stack.
>>
>> =
>> ___________________________________________________________________________
>> Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
>> Archives: http://www.wireshark.org/lists/wireshark-users
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
> ___________________________________________________________________________
> Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>