[vls-devel] Re: Network QoS Measurement
James at superbug.demon.co.uk
Thu Jul 31 16:21:20 CEST 2003
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
> My best regards,
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 vls-devel mailing-list, see http://www.videolan.org/streaming/
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 vls-devel