[NCLUG] Bandwidth throttling when SIP connection is in progress.

[John Gilmore]

I really don't want to use that script. The download bandwidth is
throttled, but from what I can see upload and download aren't
specified separetely. And since they'd need to be, I'd have to figure
out what values they should have. 90% of max may be a reasonable
estimate, but it's still an estimate. And it's still 90%.

I figured out what was wrong - the "requiretty" clause in
/etc/sudoers. So now it works, and I get 100% when not using SIP, and
about 10% when using SIP. Since SIP is fairly rare, it's a better
solution that 90% 100% of the time. And I don't need to worry about
tuning it to get the best possible download speeds without interfering
with SIP.

On Mon, Oct 13, 2008 at 4:43 AM, Scott Scriven <nclug at toykeeper.net> wrote:
> * John Gilmore <jgilmore at glycou.com> wrote:
>> HTB doesn't have an equivalent to the "condition" match, so I'd
>> have to create or modify the rules when a SIP connection
>> started, and destroy or modify them when it stopped.
>
> No, that's not necessary.  When your high-priority SIP bucket is
> active, it will automatically tone down the other traffic
> appropriately.
>
> I had a voip phone for a while...  and a roommate who insisted on
> running 30+ torrents all the time.  He kept the connection
> completely saturated and refused to stop, so I fixed it.  He was
> bogging things down so much that ping times to my ISP ranged from
> 1000ms to 6000ms, and the phone was completely unusable.
>
> With a bit of QoS on my router, I reduced latency by two orders
> of magnitude and got the phone working nicely.  As a bonus, my
> ssh sessions also became responsive, no matter how overloaded the
> network got.
>
>> My understanding is that since my upstream provider (USCable)
>> doesn't implement QOS, to eliminate latency for the SIP calls
>> would require that I throttle bandwidth to quite a bit lower
>> than the actual limit - say 700KBps on a 1.2Mbps connection.
>
> I've found it works well to limit upstream bandwidth use to about
> 15/16ths of the capacity, though really anything from about 90%
> to 95% is probably good.
>
> Basically, that gives you just enough wiggle room to prevent lost
> packets, so your router decides what gets sent, instead of random
> chance.
>
>> Mostly this is a desire on my part to avoid the time-consuming
>> empirical testing ...
>
> I've done a bit of voip testing under load, and made something
> which works.  It's primitive, but you're free to use it if you
> like.  I've put a shortened version online:
>
>  http://narthex.xyzz.org/qos-init.sh
>
> You'll need to adjust the part which matches your voip packets.
> I had a voip appliance on its own IP address, so matching was
> easy.  You may need to do it based on tcp port instead, or
> whatever other mechanism is appropriate.  Also, be sure to set
> CEIL to about 90% of your uplink capacity.
>
>
> -- Scott
> _______________________________________________
> NCLUG mailing list       NCLUG at nclug.org
>
> To unsubscribe, subscribe, or modify
> your settings, go to:
> http://www.nclug.org/mailman/listinfo/nclug
>