Read this through twice now. I'm assuming that my P3 machine qualifies for the generic 586 and since I'm not using any funky power saving settings, I'd assume the TSC timer is available to me. I mis-spoke earlier. I'm on Astlinux 0.4.3, kernel 2.6.16.12. Is it safe to assume this kernel was compiled to use the TSC timer? It appears to have been compiled by yourself.
Can I also assume that if it was compiled to use TSC that with my results it's simply not available for whatever reason? Is there any reason to suspect upgrading my Astlinux version will have any positive effect? Thanks, and Merry Christmas - Tom 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] REMEMBER: AstLinux mailing lists are moving soon: http://sourceforge.net/mail/?group_id=170462 Please move any discussions ASAP!
