molybtek wrote:

Chris Robertson-2 wrote:
molybtek wrote:
Chris Robertson-2 wrote:
This is getting a bit off the path of your original question, but...

Have you changed quick_abort_min, quick_abort_max or quick_abort_pct? How about read_ahead_gap?

Delay pools should not download from the 'net faster than the data is delivered to the client*.

Chris

* If the client cancels the request, but the quick_abort_(min|max|pct) directive causes Squid to finish downloading the object, the delay pool is no longer used.


The Quick abort settings I have are as follows:
quick_abort_min 4 KB
quick_abort_max 4 KB
quick_abort_pct 98

Read ahead gap is not set, so default to 16kb.

Should I set them to zero or are the current settings okay?
Those all look fine. One other directive that might cause issues is range_offset_limit. An other would be the "no-delay" argument to cache_peer.

Chris



We're not using any cache_peer or the range_offset_limit.
I've just tested some downloads using download accelerators again -
everything looks good now with the download getting restricted to the amount
set in the delay pool. Thanks.

I think what's happening is since I've been reloading pretty often trying to
tweak squid, any connections at the time of the reload are no longer
restricted by the delay pool so they not restricted, and hence they are able
to download at the maximum speed of our connection. Could this be true?

Yes its a known bug in older versions of Squid. Now fixed AFAIK.

Amos
--
Please be using
  Current Stable Squid 2.7.STABLE6 or 3.0.STABLE14
  Current Beta Squid 3.1.0.7

Reply via email to