Russell Stuart wrote: > 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.
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. > 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. 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, ...). - 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
