jamal wrote:
> On Tue, 2006-20-06 at 18:51 +0200, Patrick McHardy wrote:
>
>> [..]
>>
>>contrary to a local link that would be best managed
>>in work-conserving mode. And I think for better accuracy it is
>>necessary to manage effective throughput, especially if you're
>>interested in guaranteed d
On Tue, 2006-20-06 at 18:51 +0200, Patrick McHardy wrote:
> jamal wrote:
> > The issue is really is whether Linux should be interested in the
> > throughput it is told about or the goodput (also known as effective
> > throughput) the service provider offers. Two different issues by
> > definition.
jamal wrote:
> On Tue, 2006-20-06 at 16:45 +0200, Patrick McHardy wrote:
>
>>Actually in the PPPoE case Linux doesn't know about ethernet
>>headers either, since shaping is usually done on the PPP device.
>>But that doesn't really matter since the ethernet link is not
>>the bottleneck - although i
On Tue, 2006-20-06 at 16:45 +0200, Patrick McHardy wrote:
> jamal wrote:
[..]
> Actually in the PPPoE case Linux doesn't know about ethernet
> headers either, since shaping is usually done on the PPP device.
> But that doesn't really matter since the ethernet link is not
> the bottleneck - althou
jamal wrote:
> Heres the standard setup as i understand it(at least in north america, I
> know Europeans love their ATM with a little gravy on top):
>
>
> |Linux| --ethernet-- |Modem| --DSL-- |DSLAM| --ATM-- |BRAS|
>
>
took off lartc off the list because it doesnt allow me to post
and i refuse to subscribe.
On Mon, 2006-19-06 at 21:31 +0200, Jesper Dangaard Brouer wrote:
>
> On Thu, 15 Jun 2006, jamal wrote:
> > It is probably doable by just looking at netdevice->type and figuring
> > the link layer technology
On Thu, 15 Jun 2006, jamal wrote:
On Thu, 2006-15-06 at 10:47 +1000, Russell Stuart wrote:
On Wed, 2006-06-14 at 11:57 +0100, Alan Cox wrote:
The other problem I see with this code is it is very tightly tied to ATM
cell sizes, not to solving the generic question of packetisation.
Others ha
On Thu, 2006-15-06 at 10:47 +1000, Russell Stuart wrote:
> On Wed, 2006-06-14 at 11:57 +0100, Alan Cox wrote:
> > The other problem I see with this code is it is very tightly tied to ATM
> > cell sizes, not to solving the generic question of packetisation.
>
> Others have made this point also. I
On Wed, 2006-06-14 at 11:57 +0100, Alan Cox wrote:
> The other problem I see with this code is it is very tightly tied to ATM
> cell sizes, not to solving the generic question of packetisation.
Others have made this point also. I can't speak for Jesper,
but I did consider making it generic. The
On Wed, 2006-06-14 at 11:57 +0100, Alan Cox wrote:
> Ar Mer, 2006-06-14 am 11:40 +0200, ysgrifennodd Jesper Dangaard Brouer:
> > option to calculate traffic transmission times (rate table)
> > over all ATM links, including ADSL, with perfect accuracy.
>
> The other problem I see with this code is i
Ar Mer, 2006-06-14 am 11:40 +0200, ysgrifennodd Jesper Dangaard Brouer:
> option to calculate traffic transmission times (rate table)
> over all ATM links, including ADSL, with perfect accuracy.
Only if the lowest level is encoded in a time linear manner. If you are
using NRZ, NRZI etc at the bot
The Linux traffic's control engine inaccurately calculates
transmission times for packets sent over ADSL links. For
some packet sizes the error rises to over 50%. This occurs
because ADSL uses ATM as its link layer transport, and ATM
transmits packets in fixed sized 53 byte cells.
This changes
12 matches
Mail list logo
