Now that we are here learning, what is the latest bandwidth management tool squid have for the sysadmins? Delays pools like u mention are the old stuff. I want to get most from my squid. Thanks again Amos. On Fri, Mar 21, 2014 at 7:38 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 22/03/2014 4:31 a.m., Beto Moreno wrote: >> Hi, thanks Amos for always share your knowledge. >> >> "No there is 500KB/sec allocated to client response (download) traffic on >> "first-come basis. >> >> "This is effectively the same configuration as kernel routing QoS >> "controls allowing the Squid process to access 500KB/s of traffic inbound >> "for servers and unlimited upload traffic to servers. >> >> Here squid decide what we can share to each connection, the first >> machine get full bucket, if other machine arrive squid decide what he >> can receive from the bucket and continue the same to others users? >> Until they eat all the bucket and fill again the bucket to share? > > There is two things here: > 1) the delay pool bucket size > 2) the I/O buffer free space > > 500KB is larger than the maximum buffer size. The delay pool bucket gets > more data only once every second. > > So what happens is with only one machine, the client buffer gets to fill > its buffer several times over several reads until 500KB pool bucket is > empty. > The next second there are two machines, and each gets to fill its buffer > in turn until the delay pool bucket is empty. > > Problem: So long as the delay pool is larger than the client buffer size > there will be some (unbalanced) sharing of the buffer. If the client > buffer is smaller than the delay pool you may see unpredictable > situations where one client gets all the traffic for a few seconds then > switches to another. With many clients some may get all the bandwidth > and others none at all. > This pool type relies heavily on clients having traditional browser > behaviour. Whee a page was donloaded once then some time later another > page, etc. With big gaps of no traffic by each client. > >> >> example 2: >> >> delay_pool_count 1 >> delay_class 1 3 >> delay_parameters 1 500000/562500 -1/-1 4000/4000 >> delay_initial_bucket_level 100 >> >> Start will full bucket, here we have one bucket of 500kb/s burst >> 562kb/s for all my clients but each on my clients will get <= >> 32kb/s(max 32kb/s) from their single bucket? > > Remembering the sequence of sharing above. With this class-3 pool type > each client is only allowed to read up to 4000 bytes from the shared > pool when it fills its buffer. With a maximum of 4000 bytes total each > second if it tries to read a few bytes several times. > The total traffic by all clients gets to 500000 Bytes in one second > then reads are stopped until the global pool bucket refills. ie if 125 > clients all read their 4000 bytes each in one second the 126th client is > not permitted to read. > > This mostly resolves the balancing problem described above. Relating to > QoS this pool is effectively the same as QoS controls on the > client->Squid connections controlling how much traffic got delivered to > each client by Squid (downloads by client). > But still pools is slightly worse than proper QoS as it does not cover > requests/uploads, TCP packet overheads, and large response headers can > cause buckets to go negative. > >> >> About the QoS, is what I'm trying to manage, but I had been testing >> squid delay-pools and they help in some manner controlling users >> appetite. > > Yes. Any type of control helps in some manner. Squid delay pools are > just old technology with some strange limits (like not covering uploads > or TCP overheads). They do not work as well as newer QoS technology > which had more knowledge and experience behind the design. > >> >> QoS trying to see how to integrate with squid, because once squid >> start controlling inbound is came of difficult to me because 80/443 >> are only seen by single client(squid), QoS won't see my lan >> connections to those ports which are who eat my bandwidth, but working >> on. > > qos_flows directive in squid.conf can tag traffic by type so you can > control HIT/MISS with different rules if you want on the client<->squid > connections. > > tcp_outgoing_tos / tcp_outgoing_mark directives tag traffic on the > squid<->server connections according to ACL matches. > > As I understand it you setup QoS rules based on MARK or TOS to do the > bandwidth allocation you would be doing with delay pools class and > parameters directives. Then you setup squid.conf to tag the traffic into > the QoS pool types the same as you would have done with delay_pool_access. > > Amos
