Jonathan Gazeley wrote:
Andy,
Thanks for your script. I've been looking at it a lot but still can't
get it to work in the way I need it to. While the script runs without
errors echoed to ssh, it doesn't have the desired effect. The clients
have a downlink shaped to 128kbit. However, each of my two test clients
will happily download at rates much higher than 128kbit. Client 1 gets a
rate of 160kB/s and Client 2 gets a rate of 250kB/s (yes, kilobytes, not
kilobit). I have no idea why this is and it's starting to get confusing.
I know you mentioned that CPU timing wouldn't be reliable on dual-core
CPUs (I have dual core) but you'd think the rate would be out by a
factor of 2. Here, I'm getting a factor of 10 for one client and a
factor of 16 for the other.
I don't know how much the CPU timing would affect things.
I assume you changed src to dst in the match.
Are you testing downloads from the wan or hosted on the box doing the
shaping?
After an overrate download can you post the output of -
tc -s class ls dev eth0 | grep "parent 1:X" -A 4
changing the X in "parent 1:X" to one less than the last part of the IP
address of the test machine.
When I actually went to the console of the box earlier, there was loads
of output from your script echoed to the console, each one saying that
the quantum was too small and I should consider adjusting r2q. I don't
really understand what this means.
That shouldn't really hurt too much, to fix it you could ether add
quantum 1514 to each of the two child classes or r2q 2 to the root class.
FWIW I tried browsing with this setup and downloading aswell and it's
not very nice with such a long queue. An ISP/teleco would never have
that long a fifo on a 128kbit line. It would be better to add an sfq to
the bulk class or limit the length of the fifo.
Andy.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
