"Edulix (by way of Edulix )" wrote: > "eshaper status" told me that there were many many packets dropped. I tried > to transfer files without any tc rules (executed "eshaper stop" for cleaning > them) and it went at 10 Mb/s - files transfered much faster. > > I haven't checked CPU usage in this tests though... it might be a good idea. > > Any ideas? What to do now ? I'm still looking for compiling my sister's kernel Now that you have an accurate timer, it is time to find out how much deviation there is between what you expect and what you get. Create a script with these lines, replacing "#" with the correct number. tc qdisc del dev eth# ingress 2> /dev/null tc qdisc add dev eth# handle ffff: ingress tc filter add dev eth# parent ffff: protocol ip \ prio 50 u32 match ip src 0.0.0.0/0 police rate \ 82000Kbit burst 10k drop flowid :1 Read the LARTC documentation to see why I used 82000Kbit. Hint: 82000/8=10250 If necessary, increase 82000 until there are no more dropped packets when you transfer a file, then back it down until you start getting a few drops. Play with the 10k to see what effect changing burst has. I like it big. When you've found the maximum rate, please post your script (for google) and show us the counters. If you find that the CPU load is significant, I shall be VERY surprised. gypsy _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
