Andy Furniss wrote:
on leafs and burst/cburst 10b on bulk classes let's me never delay an
interactive packet longer than the transmit time of a bulk size packet.
Ii should really say almost never here as htb uses DRR so if there are
different sized packets in a stream then it can release more tha
Chris Bennett wrote:
Good recommendation. I read Jesper's thesis (well, okay, not ALL of
it... but the juicy bits) and it looks like the difference between the
overhead value that I expected to work (24) and the overhead value that
actually worked (50) can be explained by the fact that I neglec
uot;Chris Bennett" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, April 12, 2005 12:29 PM
Subject: Re: [LARTC] HTB ATM MPU OVERHEAD (without any patching)
HTB uses IP packet length, to which you then need to add your fixed
overhead - for pppoe that may include eth header + other have a loo
April 12, 2005 12:29 PM
Subject: Re: [LARTC] HTB ATM MPU OVERHEAD (without any patching)
To be safe you need overhead alot bigger than 24.
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Chris Bennett wrote:
I know there is that handy patch available to very efficiently use ATM
bandwidth, but I was wondering what the best values to use with a
non-patched iproute2 would be. Anyone here care to check my logic in
coming up with these numbers and perhaps suggest better values?
My
t;
To:
Sent: Monday, April 11, 2005 7:14 PM
Subject: Re: [LARTC] HTB ATM MPU OVERHEAD (without any patching)
Those are always the thoughts I had. I never successfully played around
with
overhead or MPU though. Did you compare results with and without using
overhead and mpu settings?
__
a
buffer somewhere is slowly filling up.
This is just preliminary... hopefully I'll have something more solid
tomorrow.
- Original Message -
From: "Jason Boxman" <[EMAIL PROTECTED]>
To:
Sent: Monday, April 11, 2005 7:14 PM
Subject: Re: [LARTC] HTB ATM MPU OVERHEAD (wi
On Monday 11 April 2005 20:01, Chris Bennett wrote:
> The maximum real bandwidth, assuming no waste of data, is 768 * 48 / 53 =
> 695. This accounts for the fact that ATM packets are 53 bytes, with bytes
> being overhead. So that's the overall rate that I'm working with.
Check.
> I then set th
I know there is that handy patch available to very efficiently use ATM
bandwidth, but I was wondering what the best values to use with a
non-patched iproute2 would be. Anyone here care to check my logic in coming
up with these numbers and perhaps suggest better values?
My transmit speed is 768
