RE: Delay Pools

        1.
>It's as if nothing were matching the ACL. Are you sure you don't
have a
>delay_class2_access deny all earlier in the config file, or have it
always
>so that the requests are already matched by delay_class1_access?

        Actually what was needed was an explicit class1 deny, (even when no
class1 allow was previously there). After that it started seeing
delay_class2_access.
         (Why don't have both? This way you could define a general bandwidth
rate for all users and then make it more specific for the teams of users.
Would it impose a heavy constraint on pool searches? )

        2. Using class2, delay pools do not make use of the individual pool
capacity. This comes down to:
        a. if you have defined only an aggregate class2 pool, it is used and
controls bandwidth (no matter what you have done with the individual pools)
        b. if you don't have defined an aggregate class2 pool, no bandwidth
rate control is effected regardless of individual settings. (again, no
matter...)

        3. It is clear about the peers, thanks. Both cases could happen.

        4. You are right, multiple class2 and class3 groups are really
needed to really leverage delay pools.

        Hope these help in debugging/development, because delay pools add
great practical value to Squid.

        Best,

        Evaghelos.

> -----Original Message-----
> From: David Luyer [SMTP:luyer@ucs.uwa.edu.au]
> Sent: Tuesday, October 20, 1998 6:52 AM
> To: Evaghelos Tsiotsios
> Cc: squid-users@ircache.net
> Subject: Re: Delay Pools
>
> > Dear all,
> >
> > Using Squid 2.0, we want to apply delay pools since we don't have a
> high-bw
> > link.
> > > We have a group C subnet: 194.30.234.xxx.
> > >
> > > Aggregate pool (class1) works OK and straightforward for one host, a
> group
> > > of hosts or the whole network.
> > > But, what we need is to define some groups of IP addresses that will
> match
> > > the users we want to categorize and assign different burstiness and of
> > > course rate. I have completely understood the concept of the pools.
> > > What I miss is how to define the different groups with ACL and how
> Squid
> > > will recognise them.
> > > I made an attempt with two groups in delay_class2 but it failed. Even
> only
> > > one group failed in delay_class2.
>
> Note that the current implementation can only have one class1 group, one
> class2 group and one class3 group. It seems that multiple class1 and
> class2
> groups might be something there is some demand for and I will consider
> making
> a patch for this if I get the time. At present, the memory for the pools
> is
> statically allocated (dynamic allocation would be less efficient) so
> multiple
> class3 pools would probably be too memory-expensive, unless you someone
> really
> needs them.
>
> > > This is what I put in squid.conf:
> > >
> > > acl etsiot_host src xxx.xx.xxx.200-xxx.xx.xxx.210/255.255.255.255
> > > delay_class2_access allow etsiot_host
> > > delay_class2_aggregate_max 25000 (to be able to handle bursts)
> > > delay_class2_individual_max 5000 -//-
> > > delay_class2_aggregate_restore 100
> > > delay_class2_individual_restore 500
> > >
> > > This didn't work. I also gave it a try with also defining a class 1
> pool
> > > for the same acl (class1+class2 with acl etsiot_host). In this case it
> > > used the class 1 settings and ignored the class 2.
>
> That is intended and documented - an access is only affected by the lowest
> numbered delay pool which it is in.
>
> > > One observation: In the cachemgr, for class 2 settings the current
> value
> > > remains blank.
>
> It's as if nothing were matching the ACL. Are you sure you don't have a
> delay_class2_access deny all earlier in the config file, or have it always
> so that the requests are already matched by delay_class1_access?
>
> Maybe you should also add a delay_class1_access deny all to make sure that
> the
> requests aren't being accidentally matched by class1.
>
> > > Could you provide an example of how to define two different groups of
> IP
> > > hosts with different settings?
>
> This looks right to me. I'm not sure why it didn't work, but I'm not
> currently
> using 2.0 and I'm quite busy for the next couple of weeks so I can't
> verify
> that it works here. The original patch I did for 1.2.X definitely did.
>
> > > Additionally, since we have two caches, can you help on how to define
> a
> > > peer host (the other cache in each case), that should not get affected
> by
> > > delay pools?
>
> If you mean that a request satisfied by the peer host should not affect
> the
> delay pool of the client requesting it (and should be transferred at full
> speed), then simply add the "no-delay" tag to the end of the "neighbor"
> line
> for that peer.
>
> If you mean that cache misses for requests from the peer host should be
> satisfied without delay, just modify the acl to exclude it, ie:
> delay_class2_access allow !peerhost localnethost
>
> If all of this still doesn't help, email me privately with more details
> (and more of the relevant parts of your config) and I'll try to work it
> out.
>
> David.
Received on Tue Oct 20 1998 - 04:43:51 MDT