Russell Stuart wrote: > On Tue, 2006-07-18 at 22:46 +0100, Andy Furniss wrote: > >>FWIW I think it may be possible to do it Patricks' way, as if I read it >>properly he will end up with the ATM cell train length which gets >>shifted by cell_log and looked up as before. The ATM length will be in >>steps of 53 so with cell_log 3 or 4 I think there will be no collisions >>- so special rate tables for ATM can still be made perfect.
Please excuse my silence, I was travelling and am still catching up with my mails. > Patrick is proposing that the packet lengths be sent to > the kernel in a similar way to how transmission times (ie > RTAB) is sent now. I agree that is how things should be > done - but it doesn't have much to do with the ATM patch, > other than he has allowed for ATM in the way he does the > calculation in the kernel [1]. > > In particular: > > - As it stands, it doesn't help the qdiscs that use > RTAB. So unless he proposes to remove RTAB entirely > the ATM patch as it will still have to go in. Why? The length calculated by my STABs (or something similar) is used by _all_ qdiscs. Not only for transmission time calculation, but also for statistics and estimators. If the length calculation doesn't fit for ATM, that can be fixed. > - A bit of effort was put into making this current > ATM patch both backwards and forwards compatible. > Patricks patch would work with newer kernels, > obviously. Older kernels, and in particular the > kernel that Debian is Etch is likely to distribute > would miss out. True, but it provides more consistency, and making current kernels behave better is more important than old kernels. > If Patrick did intend remove RTAB entirely then he > needs to add a fair bit more into his patch. Since > RTAB is just STAB scaled, its certainly possible. > The kernel will have to do a shift and a division > for each packet, which I assume is permissible. You seem to have misunderstood my patch. It doesn't need to touch RTABs, it just calculates the packet length as seen on the wire (whereever it is) and uses that thoughout the entire qdisc layer. >>As you say, I think mpu should be added aswell - so eth/other can benefit. > > > Not really. The MPU is reflected in the STAB table, > just as it is for RTAB. > > One other point - the optimisation Patrick proposes > for STAB (over RTAB) was to make the number of entries > variable. This seems like a good idea. However there > is no such thing as a free lunch, and if you did > indeed reduce the number of entries to 16 for Ethernet > (as I think Patrick suggested), then each entry would > cover 1500/16 = 93 different packet lengths. Ie, > entry 0 would cover packet lengths 0..93, entry 1 > 94..186, and so on. A single entry can't be right > for all those packet lengths, so again we are back > to a average 30% error for typical VOIP length > packets. My patch doesn't uses fixed sized cells, so it can deal with anything, worst case is you use one cell per packet size. Optimizing size and lookup speed for ethernet makes a lot more sense than optimizing for ADSL. - 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
