Brian,
Great answer - exactly what I wanted. As you say it makes
sense to implement some kind of 'damage limitation' so
I've gone for the class 2 pool allowing up to 4 64k streams
with the 1MB max.
many thanks,
Mike
> Read the config section for this (it's more in-depth than the FAQ
> coverage). A class 1 pool limits squid's total download rate, so the
> behavior you saw is exactly what you should expect.
>
> > delay_parameters 1 262144/1048576 131072/1048576
>
> This is specifies a global pool of 1MB w/256k refill. That is enough to
> give two hosts a full 128k slow stream, but they share a 1MB burst pool.
> This isn't what you specified, but keep it in mind, since you may want to
> limit the damage a lot of fast streams can do.
>
> : delay_parameters 1 -1/-1 131072/1048576
>
> This is much closer to what you specified. There is no global pool, so
> each user is limited only by their own pool. Class 2 pools are assigned
> based on the last byte in the IP address, though, so this can only scale
> to 256 clients before you wind up with people sharing pools.
>
> : delay_parameters 1 -1/-1 -1/-1 131072/1048576
>
> This is a class 3 pool. That last pool is based on the 3rd and 4th bytes
> of the IP, so up to 65536 clients can have their own pool.
>
> -- Brian
>
> On Tuesday 31 July 2001 10:32 am, Mike Kiernan wrote:
> > Basically what I'm trying to achieve is:
> > mp3 files > 1MB downloaded are forced to a slower speed.
> > mp3 files < 1MB are downloaded without restriction.
> >
> > So, here's my delay pool stanza:
> >
> > acl magic_mpeg url_regex -i .mp3 .mpeg .mpa ....etc
> > delay_pools 1
> > delay_class 1 1
> > delay_parameters 1 131072/1045876 # - ie. 128k/1MB
> > delay access 1 allow magic_mpeg
> > delay access 1 deny all
> >
> > Download one x 2.5MB mp3 file - works fine - burst rate up to 1MB
> > and then downloads at 128k.
> >
> > Download two x 2.5MB mp3 file (different names!) - first one has burst
> > rate up to 1MB, then starts at 128k; 2nd one *does not* download at
> > the burst rate, but starts off at a slower rate. This is not what I
> > want.
> >
> > So, I tried with a Class 2 delaypool. With
> > delay_parameters 1 262144/1048576 131072/1048576
> >
> > This works *reasonably* well with up to 3 parallel downloads - ie. each
> > session does seem to get a burst rate up to the 1MB size. However, I'm
> > wondering
> > how scalable this is? ie. say I have 200 parallel downloads from 200
> > different IP's
> > - will each one get the burst rate for their IP bucket or are they all
> > sucking from
> > the global bucket too?
> >
> > thanks,
> > Mike
-- Onet.pl S.A. http://www.onet.pl/ Krakow, PolandReceived on Wed Aug 01 2001 - 06:09:20 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:01:26 MST