On 12/6/05, Andy Furniss <andy.furniss@xxxxxxxxxxxxx> wrote: > Kenneth Kalmer wrote: > > On 12/6/05, Andy Furniss <andy.furniss@xxxxxxxxxxxxx> wrote: > > > >>Kenneth Kalmer wrote: > >> > >> > >>>ADSL, 512kbps down and 256kbps up. Parent for the internet traffic is > >>>set at 500kbps, to make sure it becomes the bottleneck... > >> > >>I used to use 400 when I had 512 ingress, so I am amazed that works - > >>but then you say ingress not the problem. > > > > > > I'll tone it down to see if it makes a difference, but I need to keep > > it as close as possible to the 512 because the line gets very > > congested... > > Yes 400 may be a bit far I used it because latency was important to me. > > Remember queueing traffic on the wrong end of a bottleneck is not ideal > - if you want to run at 99% then the queue will only grow 1 packet for > every 100 it passes - useless really. You need to be the one that > decides which packets get dropped to have some influence over the > sharing out of the bandwidth - too close to the limit and the dropping > will just happen at the isp/teleco FIFO. Understood, I didn't think the difference needs to be that big though... > It's for the same reason that I am concerned about queue length - if > it/they are too long then the other end won't know about the tail drop > quickly enough as it will take time for the packets infront to clear. (I > hacked esfq to head drop for this reason - though there are issues with > it to do with imq that I haven't sorted yet. It seems to work and is > stable for me, but could do with a bit more rigorous testing). > > > > > > >>>I attach an esfq to each child HTB, but as you say it would be less > >>>relevenat for egress... > >> > >>Were it ingress I woud say have just one class with esfq for sharing out > >>bulk traffic per user. > > > > > > I meant on traffic going to the network (egress) I attached an esfq to > > each users' limit > > Hmm - maybe our ingresses and egresses are getting confused - when I say > ingress I refer to traffic coming in on the bottleneck (internet) link - > even if you are shaping it as egress on your lan facing interface. > > So to be clear the Problem is actually what I call ingress - the 512kbit > traffic - yes? Yip, I meant that I shape the internet link as network egress so to speak... On the ingress side (IMQ) I'm playing with protocol prioritization for things like DNS, SSL & TCP/ACK. > > > > > > >>>>Do you know what type of connection you have eg pppoa/e or bridged ip > >>>>etc. I assume whatever it is ends up as atm cells? > >>> > >>>Barely, as said above it's 512/256 VPN. Underneath the VPN it runs > >>>PPPoE, but the service simulates a leased line, static ip's, the > >>>works... > >> > >>I bet there are alot of overheads on that - and if you are pushing the > >>rate close to limit like you are on ingress I suspect you are going > >>overlimits. Even if you test with an upload and find a rate that seems > >>OK it will all fall apart when the traffic consists of small packets. > > > > > > Amazingly not, we have the same line in the office, no shaping, and we > > often sustain 110% capacity for very long periods of time. I believe > > the provider uses very heavy compression on the line. Still, it's > > blazingly fast compared to the traditional ADSL offerings available > > here. > > Nice in some ways, but if compression is being used you effectivly have > variable bandwidth depending on traffic type, which is going to be a > pain to set a rate for. Are you sure it's compression and not a more > generous sync rate - your modem should tell you - it would be > interesting to know. I don't have access to the modem, it's a Cisco router that they control. However, I know the physical capacity of the link from the telco is 512kbps downstream, and I shape according to that. > > > > > > >>You have real ips aswell > > > The students are NATted, and firewalled to hell and back, so > > filesharing is not a problem. They try, but who wouldn't... > > > > Ahh OK. :) > > Andy. > > PS - I am getting undeliverable mails when replying in this thread. Same here, might be a list member... > > Failed to deliver to '6734440@xxxxxxxxxxxx' > SMTP module(domain terminator.swip.net) reports: > host terminator.swip.net says: > 550 Recipient not allowed to receive email (GOT_TO) > > -- Kenneth Kalmer kenneth.kalmer@xxxxxxxxx Folding@home stats http://fah-web.stanford.edu/cgi-bin/main.py?qtype=userpage&username=kenneth%2Ekalmer _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
