Arthur van Leeuwen wrote: > On Wed, 1 Nov 2000, bert hubert wrote: > > > On Wed, Nov 01, 2000 at 01:24:09PM -0300, Aldrin Martoq A. wrote: > > > > > So, It doesn't make sense to mark packet (C) because it will never go to > > > the local network and I cannot control that bandwidth, because I just > > > receive it. And also It doesn't make sense to mark packet (D) because > > > SQUID will eat all the bandwidth with packets (B) and (C) anyway. > > > > Because squids repackets your data, any shaping information is lost. Once > > your data has left squid, there is no way to know anymore where it came > > from. > > > You can try to get the ingress policer working, which tries to do shaping on > > the receiving interface (before squid). This should work, except that people > > have been having trouble with the ingress policer. > > Or, alternately, you might try to configure one squid per bandwith-partition, > thereby getting back your shaping information. This does come at a cost, but > it is actually relatively easy to set up. You might need NAT to do it > though... ;) > Hrm. Throttling it on transmission on the internal network interface works for me....squid doesn't get too far out of control because it won't read too far ahead of the client. Unfortunately throttling at that point means that cache-hits get throttled, since I can't think of a good way to deal with this (I'm marking and queuing on egress into two bandwidth partitions [fast and slow]). Proxy/web traffic falls into the 'slow' category...and like I said...squid only reads ahead so far, thus winding up in synch with the client-read speed for any large objects...it's the cache hits that bite....From the end-user perspective, a hit looks like a miss...Ie: Same delivery rate. D
