lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1169677979.5776.150.camel@ras.pc.brisbane.lube>
Date:	Thu, 25 Jan 2007 08:32:59 +1000
From:	Russell Stuart <russell-tcatm@...art.id.au>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	hadi@...erus.ca, netdev@...r.kernel.org,
	Jesper Dangaard Brouer <hawk@...u.dk>
Subject: Re:
	[PATCH	REPOST	1/2]	NET:	Accurate	packet	scheduling	for	ATM/ADSL (kernel)

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ