I have similar configuration, the download of the user its not more than 128 bytes, but the squid consume all the bandwidth. squid 3.0 STABLE1 On Thu, Jun 7, 2012 at 6:43 AM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 1/06/2012 2:20 p.m., Cameron Charles wrote: >> >> Hi all, im just after some clarification on using delay pools with >> external acls as triggers, i have a good understanding of the >> components of delay pools and how they operate but most documentation >> only mentions users aka ip addresses as the method of triggering the >> restriction, i would like to use an external acl to decide whether a >> request should be limited or not regardless of any other factors, so >> any and all traffic coming through squid, if a match to this acl, is >> restricted to say 128bps, is this possible and is the following the >> correct way to achieve this??? >> >> acl bandwidth_UNIQUENAME_acl external bandwidth_check_ext_acl_type >> UNIQUENAME >> http_reply_access allow bandwidth_UNIQUENAME_acl !all >> delay_class 1 1 >> delay_parameters 1 128.0/128.0 >> delay_access 1 allow bandwidth_128.0_acl >> delay_initial_bucket_level 1 100 >> >> additionally im a inexperienced when it comes to actually testing >> bandwidth limits is it possible to simply download a file that is >> known to be a match to the ext acl and observe that it doesn't >> download at over the bandwidth restriction or is testing this more >> complicated. > > > Yes that is pretty much it when testing. Max download should be no more than > 128 bytes per second according to that config. > > If that shows a problem the other thing is to set debug_options ALL,5 (or > the specific delay pools, comm, external ACL and access control levels > specifically) and watch for external ACL results and delay pool operations > to see if the issue shows up. > > Amos