Linux QOS is not efficient enough for VoIP over shared WANs

Forums Network Management ZeroShell Linux QOS is not efficient enough for VoIP over shared WANs

  • This topic is empty.
Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
  • #40910

    I’m working in the voip area and i can say that the default Linux QOS is not really efficient to keep a low level of jitter.

    Most of the time, it is sufficient for asterisk use, as we can compensate with the asterisk jitterbuffer.

    But some VoIP providers do not like to see more than about 10ms of jitter, because they don’t have deep jitterbuffers on there SS7 routers.

    If the Linux kernel could be patched for QOS efficiency, this could be nice, if there is no side effect like reliability concerns.

    The biggest problem with VoIP is WAN links. To be able to keep the jitter to a few ms, there is no other way than fragmenting the traffic. A 1500 bytes MTU is too big for realtime traffic on ADSL or SDSL links, because even with the best QOS algorythm, transmitting a 1500 bytes paquet on a 1 MB/s link does take about 12 ms, giving a horrible jitter…

    This is well explained here :

    The problem does not come from VoIP paquets themselves, as they have generally a low size, but from FTP or HTTP paquets, during heavy files transfers.

    This is the reason why ATM is using 53 bytes paquets…

    As of today, i’m not aware of a QOS method on Linux allowing auto fragmentation of paquets to solve the jitter problem on medium speed WAN links. (most links are medium speed today, ADSL is about 800 kbit/s upload in the best case).

    Using RSVP does not solve the problem.

    There is no other solution (as of today), using IP protocol and low cost Linux routers, than to use dedicated WAN links for perfect VoIP results.

    Conclusion : VoIP over a shared QOS enabled Wan link can work, but this is far from perfect.

    Cisco routers did implement LFI (Link fragmentation and interleaving) and RTPC (RTP header compression) to solve the problem. It would be nice to try this with linux.

    This is quite interesting to see that after many years of developpment, Linux still lack an efficient and reliable QOS system like we can have on Cisco routers, as well as a multi-wan load balancing system. I hope this will change asap :=)

    Each new Linux kernel gives toons of very beautifull functions for experts, but we still miss the basics…



    Thanks! This post is very interesting. I am going to investigate as soon as possible if Linux Kernel can be configured/patched to solve the Jitter problem.



    IMHO if my main concern would be performance, i definitively would go with a commercial product, even with Linux, i would buy a Linksys WRT54G, and switch firmware to some OpenWRT or DD-WRT.

    Because… using ZeroShell even in the best available machine on the market is still a slow solution, remember that a router like the Linksys already have dedicated hardware for routing, and internally they know that the hardware will not change, that’s a very big advantage for “low level” programmers.

    it’s like putting a Ferrarri engine(the best software) on a car with no aerodynamics(Hardware that was not tunned for that specific job). The thing will not perform as good as a Ferrari(as the Hardware that was prepared for routing).

    Best regards. Joel Rocha.


    I know quite well Openwrt, and DD-WRT. The last one do not have a perfect stability, is not as polyvalent, but the GUI is better.

    The first one do have a good stability, but does exhibit ping latence rising after some days of use.

    Kamikaze, the next openwrt version, should be better, but is still beta, bugged, and miss some usefull libraries, like ncurses, so that we can’t use MTR or similar tools on it. It does not support broadcom wifi on the 2.6 kernel neither.

    I’m almost sure that the linksys do not have a hardware level 3 wired router in it. According to my knowledge, only the integrated level 2 switch is fully hardware.

    When you need to route with Openwrt and linksys hardware, the level2 traffic is going to the 200 Mhz risk processor for serial processing through vlan traffic inside a shared 100 Mbps link to the 5 ports switches.

    Zeroshell does the same function, but do have a really better interface, is easy to install and use a more standard Linux environement. It does not have the shared 100 Mbps limitation : you can use 1 Gbps network cards, and each card has full bandwith.

    More, it will run on normal PCs; using 2 Ghz or more processors, lot of memory…

    To get the level of performance you are talking about, you need to use Cisco or Juniper like products, with DSPs inside. This is not the same price… And not really easy to use.


    Yes, ZeroShell is great. πŸ˜‰

    And i am sure that if i benchmark my PII400 with 256Mb of RAM and 5 100Mbits Ethernet cards + wifi, with Zeroshell, it will not perform as good as a WRT54G with 200Mhz, 32Mb RAM and wifidog, plus it saves me money, because the WRT54G consumes less energy, so, it does not pollute so much the environment. 😎 It’s a PII400 it should perform at least twice as good πŸ˜†

    I have some friends that have the WRT54G and wifidog in a business environment, and they do not complain. They tried it once, and a few months later they buyed many more… i wonder why…

    But, wifidog does not have a RADIUS server, that’s is the main reason i’m not concerned about it’s performance, and that’s is the reason why i use it, and support it. I’ve never seen a router with RADIUS capabilities. Until i tried ZeroShell. πŸ™„

    Just one more thing, i’ve seen also some WRT54G that constantly rebooted from time to time, so… you must be careful with the hardware revision of the WRT54G that you buy…. that is a major setback. 😳


    @rochajoel wrote:

    I’ve never seen a router with RADIUS capabilities. Until i tried ZeroShell. πŸ™„

    I used to use the above before I setup Zeroshell as my RADIUS Server. Its a wireless router with a built-in PEAP Server. Worked very well, and was easy to set up.


    Who is using 400 Mhz PC computers today ? You can find second hand computers, with miniature desktop cases, 1.6 Ghz Intel Pentium 4 processors, 256 or 512 Mo DRAM, for less than 100 euros.

    They are not power hungry, and you can do a lot more than linksys soho routers and similar embeded products with them.

    As soon as you are using OpenVPN on small embeded routers, the performance drop because the processor is not fast enough.

    That’s why i think that for small enterprise routers, specially if you need VoIP and VPNs at the same time, it’s better to use standard PC hardware with a distribution like zeroshell.

    If you try to use small soho embeded routers in the field with this setup, you will see that it does not work correctly as soon as the traffic rise to a few simultaneous calls with VPN traffic at the same time.

    Zeroshell, Vyatta, and similar projects do not have this limitation.

    More i’ve found the Zeroshell GUI very clear, fast and easy to use.

    Behind the professionel usefullness of projects like zeroshell, there is a fantastic opportunity for informatic enthousiasts to learn more easily the IP network technologies.



    I dont agree with you assumptions on QOS.

    Cisco does implement LFI (Link fragmentation) but only on sync serial data lines running PPP (MLPPP) and it is only needed on line under 768kbit/sec.

    Having 12ms jitter should not be a problem, as Voip channels implement jitter buffers.

    Maximum one way delay for Voip is 150msec.

    The problem is with ADSL, as you have a highspeed (e.g. 100Mbit/sec) ether net link to the ADSL modem there is no queue on the linux box, and thus no way to apply QOS, one way around this is to limit the outgoing speed on the Linux port to be lower than the ADSL speed and force the queue to build on the linux box where you can apply QOS rules, and ensure that the Queue on the ADSL modem is always empty.

    This is for out going, for incoming you have no control. One way to reduce this impact is to throttle incoming connection to try and limit buildup of queue on incoming line, but this can never be fully achieved.

Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.