Hi all! Another note: The delay_parameters can only take 31 bits (signed int) as argument for the bucket size, so .../2147483647 is the maximum you will get. Maybe this should be noted in the documentation? Regards, Johannes On Fri, 26 Dec 2008 18:14:40 +0100 Johannes Buchner <buchner.johannes@xxxxxx> wrote: > Hi all! > > I tested delay pools to answer my question using this configuration: > > 1> acl night time 1:00-7:00 > 2> acl testtime time 17:46-17:48 > 3> delay_pools 2 > 4> delay_class 1 1 # full bandwith > 5> delay_class 2 2 # limited per user > 6> delay_parameters 1 -1/-1 > 7> delay_parameters 2 -1/-1 1000/1000000 > 8> delay_access 1 allow night testtime all > 9> delay_access 2 allow !night !testtime all > A> delay_initial_bucket_level 100 > > - Download a file of 51 MB at 17:44 > - first 1 MB is full speed (from pool 2, line 7). full speed is > 400KB/s here. > - then the speed is 1000B/s (from pool 2, line 7). > - at 17:46 the download continues to go with 1000B/s. The pool is not > switched. > - I am restarting the transfer: full speed for the whole > transfer. If it takes longer than the time-acl is limited to, the full > speed is still given. > > Conclusion: The pools are used connectionwise, and do not switch over > when the time-acl becomes active. In other words, the delay_pools are > chosen by looking at the acls only at the beginning of the transfer. I > assume this is a wise design decision, as continueous checks would > decrease performance. > > It means however, that one can start a huge transfer in the 'night' > and block the traffic during the day. The effect can be minimized by > using request_body_max_size. > > To my original question: > If you drained your bucket at the end of the acl time, how full is it > at the beginning of the acl time the next time. Is it full, is it > delay_initial_bucket_level, is it stored from the last fill state, > does it refill in the time the acl is inactive? > > My test showed that it in fact refills during the time the acl is > inactive. If the acl is inactive 3 minutes (if testtime is 3 minutes > long), the bucket should be filled with 1000*3*60 Bytes, and my tests > confirmed this. > > I assume the calculation behind it is invoked on a new connection and > just looks at the time passed since the last transfer and calculates > the new fill state from the timespan. Calculating in the time-acls > would be too complex, as the acls can be configured in quite complex > ways. > > Best regards, > Johannes > > On Wed, 24 Dec 2008 15:47:12 +1300 > Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > > > Johannes Buchner wrote: > > > Hi! > > > > > > I have a question about delay_pools: If I make a time-based acl > > > with a delay-pool, does it refill in the time the acl is inactive > > > or is the amount "stopped" and continued when the acl starts > > > again? > > > > Pools refill at the constant rate unless the are full or > > reconfigured. Client usage is not taken into consideration on the > > filling, only on the emptying. > > > > > > > > Like, if I have a pool acl going from 9:00 till 20:00 with a size > > > of 3GB and a rate of 1200 B/s, and a client runs low on the bucket > > > at 20:00. What will he be able to download at 9:00 the next day? > > > > > > Also, if I would define one bucket for 9:00 till 20:00 and another > > > one for 20:00 till 9:00 of different sizes and rates, would they > > > share their amount? Probably not I guess. > > > > Correct. No. They are different pools. > > > > Amos > > -- > > Please be using > > Current Stable Squid 2.7.STABLE5 or 3.0.STABLE11 > > Current Beta Squid 3.1.0.3 > > > -- > Emails können geändert, gefälscht und eingesehen werden. Signiere oder > verschüssele deine Mails mit GPG. > http://web.student.tuwien.ac.at/~e0625457/pgp.html > -- Emails können geändert, gefälscht und eingesehen werden. Signiere oder verschüssele deine Mails mit GPG. http://web.student.tuwien.ac.at/~e0625457/pgp.html
Attachment:
pgpGIFQejZXX3.pgp
Description: PGP signature
