I've got the generic 586 0.4 load running on a Dell GX110 Pentium III 550 mhz system with 384K of ram. Is there anything I can check further?
On 12/20/06, Kristian Kielhofner <[EMAIL PROTECTED]> wrote: > Tom Lynn wrote: > > Darrick, > > I completely understand. But over half of my download bandwidth > > evaporated by following the directions. I'd say I'm experiencing > > abnormal results, so I'm wondering if anybody has some advice on using > > this feature. > > > > Tom, > > What hardware are you using? > > Either way, here is the story on Linux traffic shaping... > > To properly keep track of and schedule packets, you need to have a > timing source. The Linux kernel gives you three options (at compile > time) of which to use: > > - gettimeofday() > - timer interrupt > - TSC cycle counter > > gettimeofday() is pretty bad. > > Timer interrupt is good except that it doesn't have high enough > resolution so it becomes useless and wildly unpredictable at "high" > speeds, which I have found to be even a few megabits. > > The TSC cycle counter is best. It is only available on Pentium/586 > CPUs (another reason AstLinux requires at least a 586), is well > synchronized, and has high enough resolution to do traffic shaping into > the tens of megabits. > > However... Some CPUs turn off the TSC to save power. The SC1100 used > in the Soekris/WRAP boards is one of these. > > People (Ingmar, among others) have noticed that when Linux is using the > TSC to keep system time, for instance, NTP has trouble keeping the > system synced and in some cases either crashes or gives up trying to > because the system clock is all over the place. > > The 2.6.18 kernel introduced GTS (generic timekeeping system), which > allowed the kernel to test a series of clocks to find out which was the > most stable on a given system. Luckily, the sc1100 also has a 27.xxx > MHZ high resolution timer (scx200_hrt, I believe), that newer kernels > (2.6.19+) can use instead of the tsc for system time. > > Back to traffic shaping... So, a couple of problems: > > - there is nothing like GTS for traffic shaping - the kernel has no way > of knowing which timing sources are accurate, and it will use whatever > it was told to use at compile time. So, if the kernel is compiled to > use TSC and you are running on a Soekris, you will get strange results > because the SC1100 will go into standby and throw off your traffic shaping. > > - timer interrupt/gettimeofday() aren't really practical for low powered > embedded systems that need to do traffic shaping on "modern" internet > connections > > However, there is a work-around for the sc1100 boards - if you pass > "idle=poll" on the kernel command line AND you are using the TSC, you > should have pretty good traffic shaping results with those boards. The > only problem is it will use more power and generate more heat. In my > very preliminary tests, it ran the CPU ~7 degrees (F) hotter than normal > after about 24 hours of operation. YMMV. > > As far as traffic shaping goes in general... Yes, to do effective > traffic shaping with VoIP services on "standard" internet connections, > you really should limit the overall transfer capacity to about %90 of > what is capable on the link. > > Just like Darren described, if you don't artificially limit the speed > of the link your ISP will, and their send queues are not tuned like > yours are... So, if you run at %100, and they start queuing, they are > going to use whatever algorithm that they have (probably a simple FIFO > with a buffer) to schedule outgoing packets. This isn't what you want! > Limiting the speed of the link prevents this queuing and will give you > a better experience for VoIP (and any other service that uses large > amounts of relatively small packets - gaming for instance). > > In summary, yes, using astshape will reduce the speed of your link by > about %10. However, the results that you are seeing could be a result > of using the timer interrupt for QoS, or, a misbehaving TSC on your > system. The question again is: what hardware are you using? > > -- > Kristian Kielhofner > _______________________________________________ > Astlinux-users mailing list > [email protected] > http://lists.kriscompanies.com/mailman/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to [EMAIL > PROTECTED] > _______________________________________________ Astlinux-users mailing list [email protected] http://lists.kriscompanies.com/mailman/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to [EMAIL PROTECTED]
