netdev - Re: [PATCH REPOST 1/2] NET: Accurate packet scheduling for ATM/ADSL (kernel)

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]

Date:	Sun, 21 Jan 2007 17:45:27 +1000
From:	Russell Stuart <russell-tcatm@...art.id.au>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	hadi@...erus.ca, netdev@...r.kernel.org,
	David Miller <davem@...emloft.net>
Subject: Re:
	[PATCH	REPOST	1/2]	NET:	Accurate	packet	scheduling	for	ATM/ADSL (kernel)

On Sat, 2007-01-20 at 09:47 +0100, Patrick McHardy wrote:
> Russell Stuart wrote:
> > b.  There is no compatibility problem.
> 
> Again, (b). You seem to have something in mind, it would be
> easier if you would just explain exactly where you think there
> is a problem.

I though I had :(.

Consider:
  Line speed is 256 K bits/sec.
  Protocol: ADSL/ATM (PPPoE VC/LLC) (Overhead is 42 bytes + cell pad).
  Kernel HZ is 1000.
  cell_log = 8.

Below is a table which shows the RTAB that would be sent
to a pre-STAB kernel:

              IP Datagram   Packet Size       Packet Size   Ticks to
              Packet Size   Seen by Kernel    On the Wire   Send packet
  RTAB[0]=2    -14..-7          0..7             53..53       1.656
  RTAB[1]=2     -6..1           8..15            53..53       1.656
  RTAB[2]=3      2..9          16..23            53..106      3.313
  RTAB[3]=3     10..17         24..31           106..106      3.313
   ...  
  RTAB[9]=5     58..63         72..79           106..159      4.968
  RTAB[10]=5    64..71         80..87           159..159      4.968

Below is the same thing for a post-STAB kernel:

              IP Datagram   Packet Size       Packet Size   Ticks to
              Packet Size   Seen by Kernel    On the Wire   Send packet
  RTAB[0]=0 - Undefined as no STAB entry is 0.
  RTAB[1]=0 - Undefined as no STAB entry is 0.
   ...
  RTAB[5]=0 - Undefined as no STAB entry is 0.
  RTAB[6]=2    -14..-7          0..7             53..53       1.656
  RTAB[7]=2     -6..1           8..15            53..53       1.656
  RTAB[8]=3      2..9          16..23            53..106      3.313
  RTAB[9]=3     10..17         24..31           106..106      3.313
   ...  
  RTAB[15]=5    58..63         72..79           106..159      4.968
  RTAB[16]=5    64..71         80..87           159..159      4.968

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.

Replacing RTAB with STAB would solve the problem, BTW,
as the post-STAB kernel would ignore the RTAB.

It would also solve another problem.  The granularity
of RTAB sucks for VOIP (my area of interest).  Eg on
a 2 M bit link, one ATM cell takes 0.0848 ticks to 
send, two cells 0.170 ticks, three cells 0.2544 ticks.  
RTP voice packets are typically two or three cells.  
RTAB only holds an integral number of ticks of course, 
making the current traffic control engine useless for 
VOIP links with speeds of around 2.5M bit or above.
This could be fixed in an STAB implementation.

-
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