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.
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?
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.
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.
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)
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
