On Sat, 2003-03-22 at 17:08, Alan Dawson wrote: > Users are hosting mp3's avi's etc on on a web server with a limited bandwidth. > This in itself is not a problem, but when the bandwidth consumed by the > download sessions / and the time it takes for the large(ish) files being > downloaded affects the interactivity of other ip applications like webmail and > ssh sessions. > > I was hoping that I could > 1. use squid to accelerate the web server > 2. use the delay pools feature of squid to limit bandwidth based on file > extension (.mp3, .avi) or file size( >100kb) a proportion of the available > bandwidth (say 64kb/s) > > as mentioned in the http://tldp.org/HOWTO/Bandwidth-Limiting-HOWTO/ > > Firstly > Is this a viable solution , and secondly what are the pitfalls? > The pitfalls seem to be "why can't I download at full speed if the network is empty." I've been using The Hierarchy Token Bucket qdisc - you can classify ssh and interactive traffic by one filter - port 80 could be filtered by another rule. The interactive class can be assigned a higher priority than the web traffic. Both traffics can then have a ceiling of link speed, you might want to assign both classes a rate of 50%. - web traffic is committed 50% of the bandwidth - ssh is committed 50% of the bandiwdth - both classes may burst up to the ceiling (link speed) if the bandwidth exists. This doesn't really address the problem being specifically MP3's etc- but- does keep bandwidth available, and it goes a little way to give priority to non-web traffic. HTB may required a kernel recompilation (If you have RedHat 8.0 htb is in the kernel - but the version of 'tc' shipped with redhat is too old). Easier still, http://lartc.org/wondershaper/ - will do wonders for interactivity of ssh sessions- I used this for a good while as a stop gap while I got some htb rules working. http://www.docum.org/ and http://lartc.org/ are the best resources I've found so far. The lartc mailing list is quite active- and this may well have been asked in the past http://mailman.ds9a.nl/pipermail/lartc/. -- Regards, Adam "too busy to give you an answer - but here's a staring point (which might not make sense)" Allen. adam@dynamicinteraction.co.uk pgp http://search.keyserver.net:11371/pks/lookup?op=vindex&search=adam%40dynamicinteraction.co.uk
Attachment:
signature.asc
Description: This is a digitally signed message part