[vlc-devel] Re: [vls-devel] Re: Network QoS Measurement

[Danilo Ferraz Daher de Ornellas]

	Thank you for clarifying the idea of latency. Actually, I´m meaning the 
last one. 
	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,

Danilo

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

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