All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: hadi@cyberus.ca
Cc: Jesper Dangaard Brouer <hawk@comx.dk>,
	hawk@diku.dk, russell-tcatm@stuart.id.au, lartc@mailman.ds9a.nl,
	netdev@vger.kernel.org, Stephen Hemminger <shemminger@osdl.org>
Subject: [LARTC] Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
Date: Tue, 20 Jun 2006 00:54:36 +0000	[thread overview]
Message-ID: <4497474C.4050706@trash.net> (raw)
In-Reply-To: <1150286766.5233.15.camel@jzny2>

jamal wrote:
> - For further reflection: Have you considered the case where the rate
> table has already been considered on some link speed in user space and
> then somewhere post-config the physical link speed changes? This would
> happen in the case where ethernet AN is involved and the partner makes
> some changes (use ethtool). 
> 
> I would say the last bullet is a more interesting problem than a corner
> case of some link layer technology that has high overhead.
> Your work would be more interesting if it was generic for many link
> layers instead of just ATM.

I've thought about this a couple of times, scaling the virtual clock
rate should be enough for "simple" qdiscs like TBF or HTB, which have
a linear relation between time and bandwidth. I haven't really thought
about the effects on HFSC yet, on a small scale the relation is
non-linear. But this is a different problem from trying to accomodate
for link-layer overhead.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

WARNING: multiple messages have this Message-ID (diff)
From: Patrick McHardy <kaber@trash.net>
To: hadi@cyberus.ca
Cc: Jesper Dangaard Brouer <hawk@comx.dk>,
	hawk@diku.dk, russell-tcatm@stuart.id.au, lartc@mailman.ds9a.nl,
	netdev@vger.kernel.org, Stephen Hemminger <shemminger@osdl.org>
Subject: Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
Date: Tue, 20 Jun 2006 02:54:36 +0200	[thread overview]
Message-ID: <4497474C.4050706@trash.net> (raw)
In-Reply-To: <1150286766.5233.15.camel@jzny2>

jamal wrote:
> - For further reflection: Have you considered the case where the rate
> table has already been considered on some link speed in user space and
> then somewhere post-config the physical link speed changes? This would
> happen in the case where ethernet AN is involved and the partner makes
> some changes (use ethtool). 
> 
> I would say the last bullet is a more interesting problem than a corner
> case of some link layer technology that has high overhead.
> Your work would be more interesting if it was generic for many link
> layers instead of just ATM.

I've thought about this a couple of times, scaling the virtual clock
rate should be enough for "simple" qdiscs like TBF or HTB, which have
a linear relation between time and bandwidth. I haven't really thought
about the effects on HFSC yet, on a small scale the relation is
non-linear. But this is a different problem from trying to accomodate
for link-layer overhead.

  parent reply	other threads:[~2006-06-20  0:54 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-14  9:40 [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL Jesper Dangaard Brouer
2006-06-14 12:06 ` jamal
2006-06-14 12:55   ` Jesper Dangaard Brouer
2006-06-15 12:57     ` jamal
2006-06-15 13:16     ` jamal
2006-06-20  1:04       ` [LARTC] " Patrick McHardy
2006-06-20  1:04         ` Patrick McHardy
2006-06-20 14:59         ` jamal
2006-06-20 15:16           ` [LARTC] " Patrick McHardy
2006-06-20 15:16             ` Patrick McHardy
2006-06-21 12:21             ` Krzysztof Matusik
2006-06-21 12:54               ` Patrick McHardy
2006-06-21 14:33                 ` Krzysztof Matusik
2006-06-14 15:32   ` [LARTC] " Andy Furniss
2006-06-14 15:32     ` Andy Furniss
2006-06-20  0:54   ` Patrick McHardy [this message]
2006-06-20  0:54     ` Patrick McHardy
2006-06-20 14:56     ` jamal
2006-06-20 15:09       ` [LARTC] " Patrick McHardy
2006-06-20 15:09         ` Patrick McHardy
2006-06-22 18:41         ` jamal
2006-06-23 14:32           ` Patrick McHardy
2006-06-24 14:39             ` jamal
2006-06-26 11:21               ` Patrick McHardy
2006-06-27 13:01                 ` jamal
2006-07-02  4:23                   ` Patrick McHardy
2006-07-02 13:59                     ` jamal
     [not found]   ` <1150287983.3246.27.camel@ras.pc.brisbane.lube>
     [not found]     ` <1150292693.5197.1.camel@jzny2>
     [not found]       ` <1150843471.17455.2.camel@ras.pc.brisbane.lube>
     [not found]         ` <15653CE98281AD4FBD7F70BCEE3666E53CD54A@comxexch01.comx.local>
     [not found]           ` <1151000966.5392.34.camel@jzny2>
2006-06-23 12:37             ` [LARTC] " Russell Stuart
2006-06-23 12:37               ` Russell Stuart
2006-06-23 15:21               ` Patrick McHardy
2006-06-26  0:45                 ` [LARTC] " Russell Stuart
2006-06-26  0:45                   ` Russell Stuart
2006-06-26 11:10                   ` Patrick McHardy
2006-06-27  6:19                     ` [LARTC] " Russell Stuart
2006-06-27  6:19                       ` Russell Stuart
2006-06-27 17:18                       ` Patrick McHardy
2006-07-04 13:29                       ` Patrick McHardy
2006-07-04 19:29                         ` jamal
2006-07-04 23:53                           ` Patrick McHardy
2006-07-06  0:39                         ` [LARTC] " Russell Stuart
2006-07-06  0:39                           ` Russell Stuart
2006-07-07  8:00                           ` Patrick McHardy
2006-07-10  8:44                             ` [LARTC] " Russell Stuart
2006-07-10  8:44                               ` Russell Stuart
2006-06-24 14:13               ` jamal
2006-06-26  4:23                 ` [LARTC] " Russell Stuart
2006-06-26  4:23                   ` Russell Stuart
2006-07-18  2:06                 ` [LARTC] " Russell Stuart
2006-07-18  2:06                   ` Russell Stuart
2006-07-18 13:35                   ` jamal
2006-07-18 21:46                   ` Andy Furniss
2006-07-19  1:02                     ` Russell Stuart
2006-07-19 14:42                       ` Andy Furniss
2006-07-19 14:54                         ` Patrick McHardy
2006-07-19 20:26                         ` [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL (RTAB BUG) Jesper Dangaard Brouer
2006-07-19 21:00                           ` Alexey Kuznetsov
2006-07-20  5:47                             ` [LARTC] Re: [PATCH 0/2] NET: Accurate packet scheduling for Russell Stuart
2006-07-20  5:47                               ` [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL (RTAB BUG) Russell Stuart
2006-07-20 23:49                               ` Alexey Kuznetsov
2006-07-19 14:50                       ` [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL Patrick McHardy
2006-07-20  4:56                         ` [LARTC] " Russell Stuart
2006-07-20  4:56                           ` Russell Stuart
2006-07-30 23:06                           ` [LARTC] " Russell Stuart
2006-07-30 23:06                             ` Russell Stuart
2006-08-08 22:01                             ` Russell Stuart
2006-08-09 11:33                               ` jamal
2006-09-04 10:37                                 ` Russell Stuart
2006-06-14 14:27 ` Phillip Susi
2006-06-14 15:08   ` Jesper Dangaard Brouer
2006-06-20  5:35 ` Chris Wedgwood
2006-06-20  7:33   ` Jesper Dangaard Brouer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4497474C.4050706@trash.net \
    --to=kaber@trash.net \
    --cc=hadi@cyberus.ca \
    --cc=hawk@comx.dk \
    --cc=hawk@diku.dk \
    --cc=lartc@mailman.ds9a.nl \
    --cc=netdev@vger.kernel.org \
    --cc=russell-tcatm@stuart.id.au \
    --cc=shemminger@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.