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

Danilo Ferraz Daher de Ornellas <[email protected]>
Newsgroups gmane.comp.video.videolan.vlc.devel,gmane.comp.video.videolan.vls.devel
Message-ID <Pine.LNX.4.44.0308011442001.4995-100000@salgueiro.telemidia.puc-rio.br>
	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 <[email protected]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.