1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

QoS Help (sticky links are broken)

Discussion in 'Tomato Firmware' started by HWmonkey, Jun 16, 2012.

  1. HWmonkey

    HWmonkey Serious Server Member

    I am posting this because the sticky links are broken, and have been for weeks, so I am not able to read the FAQs on QoS.

    I have what I perceive to be a typical, simple, QoS question. In Motorola realm, QoS serves to allow you to set priority bandwidth by device, specifying an actual bitrate, not a percentage, allocated as a priority. Unspecified devices are given a generic prioritization.

    I am attempting to apply this sort of QoS logic to Tomato. I have an Ooma VoIP device that I want to give priority. The company says it takes 384 kbit. This seems high. Tomato shows it using 30-40 kbit when in use, which I find believable.

    I setup a QoS classification for the device, based on the IP (which is assigned using DHCP and a static IP), then I gave this classification the highest priority. Furthermore, I went to allocate bandwidth in QoS, and I can only do it as a percentage. Can't this be done by bitrate, so that when the available bandwidth varies, a "guaranteed" amount of bandwidth can go to VoIP (dedicated bandwidth)? This is a more familiar method to me, as it is how my employer (ISP) sells bandwidth. It seems much more logical for non-commercial bandwidth customers too.

    Am I missing something, or is this just confusion over the GUI or something?

  2. Toastman

    Toastman Super Moderator Staff Member Member

  3. BikeHelmet

    BikeHelmet Networkin' Nut Member

    The percentages control the minimum (guaranteed) and maximum (ceiling) bitrates.

    As a high priority class, your VOIP traffic will likely grab however much bandwidth it requires, so long as your ceiling is reasonably high. (lets say 256kbit) Your minimum can be just about anything. I would set it to at least 64kbit, since if it isn't in use it shares it with other classes.

    Make sure your minimums for all classes do not exceed 99%. (That is why it presents you with percentages rather than bitrates. It's easier to count.)
  4. Dark_Shadow

    Dark_Shadow LI Guru Member

  5. Toastman

    Toastman Super Moderator Staff Member Member

    Yeah ... looks like a forum software issue ... :-(
  6. BikeHelmet

    BikeHelmet Networkin' Nut Member

    Use a different web browser?
  7. Dark_Shadow

    Dark_Shadow LI Guru Member

    No the links are formatted differently now.
  8. BikeHelmet

    BikeHelmet Networkin' Nut Member

    I don't know... they used to be completely broken for me in Firefox. Links wouldn't go anywhere, and I couldn't even flip pages in a thread. But Chrome worked fine.

    Now every browser is working fine. Whatever they changed, it seems to be working fine for me? (unless I'm misunderstanding what's broken?)
  9. gfunkdave

    gfunkdave LI Guru Member

    The links in that thread need to be updated to the new format. The old format looks like this:

    The new format is SEO optimized and looks like this:

    Both links are for the same thread; the first doesn't work but the second does.
  10. BikeHelmet

    BikeHelmet Networkin' Nut Member

    Oh, I see what you mean now. I just assumed those sticky posts had a few dead links in them, since they were posted years ago. If anyone can track down the old threads they were pointing to and get new links, fire them off to Toastman!
  11. Toastman

    Toastman Super Moderator Staff Member Member

    Yeah, but it's supposed to also support the old format - it always worked before ... funny thing is I just tried this and actually it worked OK for a few seconds .. before stopping again. I'm sure Simon will fix it ... changing all the old links isn't really an option.
  12. BikeHelmet

    BikeHelmet Networkin' Nut Member

    It's a PITA right now, but if it starts working again it is doable. It should only take 10 or 15 minutes to do all the stickies if you can just click on them and grab the new links. But as it is currently, having to hunt them all down...? No.
  13. HWmonkey

    HWmonkey Serious Server Member

    Okay. The easy way to resolve outstanding issues is to clear all the SEO cachings. Then, run a webspider or a site mapping tool. This will re-generate all the SEO links. I know it sounds like I am out of my mind, but I have managed many websites with SEO and forums.
  14. HWmonkey

    HWmonkey Serious Server Member

    Thanks for the reply. I want to use rates like you mentioned (64 kbit-256kbit), but first, I want to see it behave as expected.

    For clarification, let me use an example. You run tests and determine that your downlink is 2 mbit and uplink is 1 mbit. So, you set your max INBOUND 1.5 mbit and OUTBOUND to 768 mbit. VOIP is set to 39% min and 50% max to achieve 299-384 OUTBOUND and 70% OUTBOUND (1050 kbit) -- numbers that should ample. It is the highest priority item in the CLASS list. Then, under QoS CLASSIFICATION, a rule is created for the IP address permitting all UDP and TCP, and the rule is moved to the top of the list. Under the BANDWIDTH LIMITER, the DLRate is set to 128 kbit with a DLceiling of 384 and UL is 128 with a ULCeiling of 384, and the entire device is given HIGHEST priority.

    With that setup, I would assume that when a device that is downloading media (with lower class and classification) and a call is made, one can watch the REAL TIME IP TRAFFIC and watch the bandwidth to the video get slowed down and the VoIP get priority. But in reality, there is no dip (at all) in the video traffic (according to the graph).

    So, it it not being slowed down because there is more bandwidth available at that moment? Should I try clogging up bandwidth more (using iperf or something) and watch the test because maybe it is just the graph or something? Is it locking into the fixed numbers (384 kbit) or the percentage (39%)?

    Thanks again for the clarification. I really think this firmware is awesome and the answer to many sorrows.
  15. Toastman

    Toastman Super Moderator Staff Member Member

    Without me poring over this, it is useful to remember that providing that there is sufficient bandwidth available for both the VOIP *AND* the video, then the video shouldn't be slowed down.

    Are you using a recent Toastman version? There should be no need to use the bandwidth limiter, the normal QOS ingress mechanism is now sufficient for most purposes.
  16. BikeHelmet

    BikeHelmet Networkin' Nut Member

    Yep. I can have two Youtube videos going, VOIP, email coming in, webpages loading, Steam games downloading, other people playing, etc.; the QOS copes well with all that, and I'm on 6mbit. (7040/640 sync rate)

    +1 for what Toastman said. Priorities are generally sufficient. When I look at my bandwidth graph and see a flatline across the top, yet everything is working properly, that makes me feel good. :)

    It sounds like he wants it as a backup. If something gets mis-classified, he can stop it from hogging all the bandwidth. That's actually a not bad failsafe for situations like VOIP hardware deciding to download a massive firmware update. (Wouldn't happen for me, since I configure all my own hardware - but if you had ISP provided hardware, it might. They can do remote updates.)
  17. Toastman

    Toastman Super Moderator Staff Member Member

    BTW - all internal links that used the old VBulletin-style format are broken, we're trying to regenerate them now.
  18. Toastman

    Toastman Super Moderator Staff Member Member

    Links should all be fixed now, many thanks Simon!

Share This Page