[vlc-devel] Re: [vls-devel] Re: Network QoS Measurement
Danilo Ferraz Daher de Ornellas
danilo at telemidia.puc-rio.br
Fri Aug 1 19:48:27 CEST 2003
Thank you for clarifying the idea of latency. Actually, I´m meaning the
My framework is designed to provide end-to-end QoS. It means that
even the test devices (e.g. Digital Camera attached to a PC) are committed
with low latency traffic such as voice and video. So, what I really want
is to measure the network delay, to make sure that intermediary nodes
(routers) are achieving the proper QoS.
Hope I made myself clear.
Thanks in advance,
On Thu, 31 Jul 2003, James Courtier-Dutton wrote:
> Danilo Ferraz Daher de Ornellas wrote:
> > Hello folks,
> > I´m developing a QoS Framework to be applied to Linux operating
> > systems and over routers along two network edges.
> > So, I want to send packets from a VLS station to another one
> > running VLC. My purpose is measure the actual bitrate my whole network is
> > achieving. In other words, I want to know the overall delay from server
> > to client station, so that I can validate my framework.
> > Here goes my question: Is there any funcionality provided by
> > either VLC or VLS that would fulfill the requirements abovementioned?
> > If answer is negative, does anyone envision any solution
> > to this
> > problem?
> > My best regards,
> > Danilo
> Measuring QoS is fairly difficult.
> "bitrate" is not the same as "delay" (or latency).
> The QoS you achieve will be dependent on what other network traffic
> there is on the network. Do all devices on the network prioritise some
> traffic over other traffic. How is this prioritisation acheived. E.g.
> Low latency traffic needs to be able to jump the buffer queues in
> network devices, and if they are perceived to be too old, just dropped,
> whereas normal ftp data traffic can happily be buffered as the latency
> for that does not matter.
> If you are measuring latency, then you need to know if the latency is
> caused but the test device itself( time it takes for network packet to
> reach the test devices CPU), or the actual network.
> Generally, for multicast video over IP, latency is not the issue, as the
> video gets displayed, it does not matter if it is displayed 1ms or
> 10seconds after being transmitted, the user will be happy with either,
> with the client side doing buffering to adjust for jitter.
> Latency is certainly an issue for VoIP or Video Conferencing, where one
> wants two way low latency traffic.
> There are very few, if any network devices out there that can propery
> prioritise network traffic when the links are 100% utilised. If you are
> planning a QoS network, design it to never be more that 50% utilised.
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>
More information about the vlc-devel