RE: DELAY_POOLS: How to setup

From: Evaghelos Tsiotsios <etsiot@dont-contact.us>
Date: Thu, 12 Nov 1998 10:35:38 +0200

Dear David,

1) Actually this is the piece of code I saw that made me say this:
Always the last nbytes value is used.

2) You are right about the no-delay tag. I forgot about it.

3) I agree with you about the structure of a future multiple delay pools
setup.
Makes it much easier to put on the fly new groups. Neat!!

Cheers,

Evaghelos.

delayBytesWanted(delay_id d, int min, int max)
{
..............
    case 2:
        if (Config.Delay.class2.aggregate.restore_bps != -1)
<----------
            nbytes = XMIN(nbytes, delay_data.class2_aggregate);
        if (Config.Delay.class2.individual.restore_bps != -1)
<--------
            nbytes = XMIN(nbytes, delay_data.class2_individual[position]);
        break;

    case 3:
        if (Config.Delay.class3.aggregate.restore_bps != -1)
<---------
            nbytes = XMIN(nbytes, delay_data.class3_aggregate);
        if (Config.Delay.class3.individual.restore_bps != -1)
<----------
            nbytes = XMIN(nbytes, delay_data.class3_individual[position]);
        if (Config.Delay.class3.network.restore_bps != -1)
<----------
            nbytes = XMIN(nbytes, delay_data.class3_network[position >> 8]);
        break;

> -----Original Message-----
> From: David Luyer [SMTP:luyer@ucs.uwa.edu.au]
> Sent: Thursday, November 12, 1998 3:29 AM
> To: Evaghelos Tsiotsios
> Cc: squid-users@ircache.net; tarkhil@synchroline.ru
> Subject: Re: DELAY_POOLS: How to setup
>
> 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 Thu Nov 12 1998 - 01:51:20 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:43:00 MST