On Wed, 2007-01-24 at 17:38 +0100, Patrick McHardy wrote:
> > The two RTAB's are different. Thus you must send
> > different RTAB's to pre-STAB and post-STAB kernels.
> > How is "tc" to decide which one to send? I did add
> > code that checked uname once to solve a very
> > similar problem in "tc", but that got my wrist
> > slapped.
>
> If the users asks to use STABs, send the modified RTAB.
> If the kernel doesn't support STABs it will return an error,
> which is good enough.
Yuk! Now the user has to say whether he wants to use
STAB's or not? Currently, apart from some debugging
params to tc, the user isn't even aware that the
traffic control is implemented in terms of RTAB's.
That is how it should be - it is an implementation
detail.
> I think this is a different problem. If you replace RTABs
> by STABs you again can't use it for anything that is only
> interested in the size, not the transmission time (HFSC,
> SFQ, ...).
I was a little too brief.
The comment stems from the observation that in all
current implementations:
const A_CONSTANT;
for (i = 0; i < 256; i += 1)
assert(RTAB[i] == STAB[i] * A_CONSTANT);
Ergo, if in addition to implementing STAB as you
plan to, A_CONSTANT was shipped to the kernel then
RTAB could be replaced. A_CONSTANT could be set
so the calculation would return the time it would
take to send a packet in micro seconds, say (a
figure I just pulled out of the air). This is
1000 times more precise than the kernel can do
now.
It wouldn't be perfect - the kernel would send the
packets in bursts. But it would be good enough
to solve my problem with VOIP, I think.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
