Thanks to Evaghelos Tsiotsios for his description of delay pools. A few
clarifying comments are below;
> The Aggregate_* settings work almost the same way as the individual with one
> distinction: in class 2 (this is what I use) and class3 the aggregate delay
> pool is used only if no individual pool is defined.
This assumption (and related comments later) is incorrect. (Or if it is
correct it is a coding error.) The aggregate and individual totals both
act to limit the traffic, if either is empty then the request is delayed.
For example, I run approx 64kbps peak rate (with small 'bucket size') on
one of the delay_class2 pools and then give each user in it approx 8kbps (with
large 'bucket size'). The large bucket size on individual users lets each user
get a web page "instantly" but if they start downloading a large file it is
slow. The small bucket size on the aggregate means that the 64kbps is the
limit of bandwidth use (modulo overheads) for these users.
Also, I didn't notice any mention of the 'no-delay' tag you can put on
neighbors - this will prevent traffic fetched from that peer from being
'taken out of the bucket'; for example if you have a fast, "free traffic"
ATM network to local universities but anything further away costs money,
and you peer caches with local universities, you can put the 'no-delay'
tag on these peers cache_host lines.
Regarding class2/3 delay pools:
It could take some time before I'm able to do any work on multiple delay
pools of a given class. How I think it should work is this (sorry, sparse
documentation on this, but I hope enough to show anyone whose interested
and understands the current system what it means):
delay_pools 3 # 3 delay pools
delay_class 1 1 # pool 1 is class 1
delay_class 2 1 # pool 2 is class 1
delay_class 3 3 # pool 3 is class 3
delay_access 1 allow staff
delay_access 1 deny all
delay_access 2 allow students
delay_access 2 deny all
delay_access 3 allow college
delay_access 3 deny all
delay_parameters 1 640000/640000
delay_parameters 2 64000/64000
delay_parameters 3 64000/64000 32000/64000 6400/32000
# ttl_rest/ttl_max net_rest/net_max ind_rest/ind_max
The acls and delay pool data could then be dynamically allocated. Maybe
once this was done delay pools could be put into squid by default as the
cost of disabled delay pools would be very close to zero (simply a few
checks if delay_pools number was 0).
David.
Received on Wed Nov 11 1998 - 18:10:36 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:43:00 MST