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]
