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