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
