by way of Edulix <edulix@tumundoweb.com>) (by way of Edulix <edulix@tumundoweb.com>
2004-Jul-01 16:10 UTC
filter ingress policy rates -> slow!!
Hello one more time,
As others seem to already asked without reply, I''m getting lower speed
rates
than specified via ingress. How do I know. Because I have this in my script:
tc qdisc add dev $DEV handle ffff: ingress
# Filter intranet traffic, so fit it to intranet speed
tc filter add dev $DEV parent ffff: protocol ip prio 10 u32 \
match ip src $Q_2_HOSTS \
match ip dst $Q_2_HOSTS \
police rate ${LAN_SPEED}mbit burst 10k drop flowid :2
So let''s say I execute a X -query to the my pc. Everything goes fine
and
fluently till I activate my script ingress rules!Then kde seems sluggish. and
LAN_SPEED is "100" (mbit) !
I don''t think the problem is that I have many ingress filters because
even if
I deactivate them (i.e. comment on them in my script) kde slows down after
adding the tc filter mentioned above.
Please, have you got any idea what might be going on ? Any comments,
suggestions? Have you had the same experience ? What do you think the problem
might be ? Am I asking in the wrong forum ? Should report this bug to tc
developers ? Come on and reply me ;-).
Good luck,
Edulix.
--
[1] http://eshaper.sf.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Thursday 01 July 2004 18:10, Edulix wrote:> Hello one more time, > > As others seem to already asked without reply, I''m getting lower speed > rates than specified via ingress. How do I know. Because I have this in my > script: > > tc qdisc add dev $DEV handle ffff: ingress > > # Filter intranet traffic, so fit it to intranet speed > tc filter add dev $DEV parent ffff: protocol ip prio 10 u32 \ > match ip src $Q_2_HOSTS \ > match ip dst $Q_2_HOSTS \ > police rate ${LAN_SPEED}mbit burst 10k drop flowid :2 > > So let''s say I execute a X -query to the my pc. Everything goes fine and > fluently till I activate my script ingress rules!Then kde seems sluggish. > and LAN_SPEED is "100" (mbit) ! > > I don''t think the problem is that I have many ingress filters because even > if I deactivate them (i.e. comment on them in my script) kde slows down > after adding the tc filter mentioned above. > > Please, have you got any idea what might be going on ? Any comments, > suggestions? Have you had the same experience ? What do you think the > problem might be ? Am I asking in the wrong forum ? Should report this bug > to tc developers ? Come on and reply me ;-).Can you post the tc counters? tc -s -d qdisc filter ffff: Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
El Jueves, 1 de Julio de 2004 22:40, Stef Coene escribió:> Can you post the tc counters? > tc -s -d qdisc filter ffff: > > StefSure: BTW, that command d9oesn''t work fine here: [root@k12ltsp-server root]# tc -s -d qdisc filter ffff: Command "filter" is unknown, try "tc qdisc help". So let''s just print: [root@k12ltsp-server root]# /etc/init.d/eshaper start downlink Applying tc rules: [ OK ] (That command starts *only* ingress policies) [root@k12ltsp-server root]# tc -s -d qdisc qdisc ingress ffff: dev eth0 ---------------- Sent 384 bytes 3 pkts (dropped 0, overlimits 0) [root@k12ltsp-server root]# Is this normal or expected? Thanks for your time, Edulix. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Edulix wrote:> (That command starts *only* ingress policies) > [root@k12ltsp-server root]# tc -s -d qdisc > qdisc ingress ffff: dev eth0 ---------------- > Sent 384 bytes 3 pkts (dropped 0, overlimits 0) > [root@k12ltsp-server root]#This is a joke? You have not demonstrated any slowdown. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
by way of Edulix <edulix@tumundoweb.com>
2004-Jul-02 08:36 UTC
Re: filter ingress policy rates -> slow!!
El Viernes, 2 de Julio de 2004 03:46, gypsy escribió:> Edulix wrote: > > (That command starts *only* ingress policies) > > [root@k12ltsp-server root]# tc -s -d qdisc > > qdisc ingress ffff: dev eth0 ---------------- > > Sent 384 bytes 3 pkts (dropped 0, overlimits 0) > > [root@k12ltsp-server root]# > > This is a joke? You have not demonstrated any slowdown.Sorry, I didn''t undertand very well the thing :-P. Also, I haven''t got permanent access to other''s pc of the network (they''re not mine ;-)!) and that''s the reason because I posted the counters as is. Anyway, here you can all see the problem: # tc -s -d qdisc qdisc ingress ffff: dev eth0 ---------------- Sent 5109350 bytes 13696 pkts (dropped 935, overlimits 0) And the only tc rules I executed were: tc qdisc add dev eth0 handle ffff: ingress tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ match ip src 192.168..0.0/24 \ match ip dst 192.168..0.0/24 \ police rate 100mbit burst 10k drop flowid :2 In this test I did is just overing the kde''s taskbar and clicking in the K menu. BTW, I''ll tell you that many operations work fine, but there''are some (as the one''s Ive just refered to) that are rather slow. Now, let''s see what is the maximun ssh speed: # scp edulix@192.168.0.7:/home/edulix/videos/prodigy90_med.mpg /home/edulix/temp/ Warning: Permanently added ''192.168.0.7'' (RSA) to the list of known hosts. edulix@192.168.0.7''s password: prodigy90_med.mpg 11% 992KB 45.0KB/s Mamma mia! That must demostrate the problem hehe. In normal conditions that video is transfered in less than 3 seconds at 7-8 Mb/s! After doing that, I can see: # tc -s -d qdisc qdisc ingress ffff: dev eth0 ---------------- Sent 30133742 bytes 88401 pkts (dropped 4792, overlimits 0) Cheers, Edulix. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
"Edulix (by way of Edulix )" wrote:> Anyway, here you can all see the problem: > > # tc -s -d qdisc > qdisc ingress ffff: dev eth0 ---------------- > Sent 5109350 bytes 13696 pkts (dropped 935, overlimits 0) > > And the only tc rules I executed were: > > tc qdisc add dev eth0 handle ffff: ingress > tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ > match ip src 192.168..0.0/24 \ > match ip dst 192.168..0.0/24 \ > police rate 100mbit burst 10k drop flowid :2 > > In this test I did is just overing the kde''s taskbar and clicking in the K > menu. BTW, I''ll tell you that many operations work fine, but there''are some > (as the one''s Ive just refered to) that are rather slow. > > Now, let''s see what is the maximun ssh speed: > # scp > edulix@192.168.0.7:/home/edulix/videos/prodigy90_med.mpg /home/edulix/temp/ > prodigy90_med.mpg 11% 992KB 45.0KB/s > > Mamma mia! That must demostrate the problem hehe. In normal conditions that > video is transfered in less than 3 seconds at 7-8 Mb/s! After doing that, I > can see: > # tc -s -d qdisc > qdisc ingress ffff: dev eth0 ---------------- > Sent 30133742 bytes 88401 pkts (dropped 4792, overlimits 0) > > Cheers, > Edulix.Did you build your own kernel? If not, do. If so: 1) What kernel version? 2) Post results of grep "define PSCHED_CLOCK" /usr/src/linux/incluce/net/pkt_sched.h Google "LARTC accuracy" and whatever else you can find from this list regarding having to set the rate based on results rather than what you know the rate to be. Keep Steph involved; he''s The Master. gypsy _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
El Viernes, 2 de Julio de 2004 16:13, gypsy escribió:> Did you build your own kernel? If not, do. If so: > 1) What kernel version?Using 2.4.22 here (default of Fedora Core 1).> 2) Post results of > grep "define PSCHED_CLOCK" /usr/src/linux/incluce/net/pkt_sched.h# grep "define PSCHED_CLOCK" /usr/src/linux-2.4/include/net/pkt_sched.h #define PSCHED_CLOCK_SOURCE PSCHED_JIFFIES does it help ?> Google "LARTC accuracy" and whatever else you can find from this list > regarding having to set the rate based on results rather than what you > know the rate to be. > > Keep Steph involved; he''s The Master.Steph do you know anything about this problem ? keep involved! ;-P BTW, Now I''m just compiling the kernel from the SRPM, butdon''t think it''s that the problem. And yes, I''ve found at least one match; see http://marc.theaimsgroup.com/?l=lartc&m=108436626432730&w=2 . I think he had the same problem as me. I''ll keep searching.. Good luck, Edulix. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Edulix wrote:> Using 2.4.22 here (default of Fedora Core 1). > > > 2) Post results of > > grep "define PSCHED_CLOCK" /usr/src/linux/incluce/net/pkt_sched.h > > # grep "define PSCHED_CLOCK" /usr/src/linux-2.4/include/net/pkt_sched.h > #define PSCHED_CLOCK_SOURCE PSCHED_JIFFIES > > does it help ?Yes, it sure does. Edit pkt_sched.h and change from JIFFIES to CPU. Before you recompile the kernel, make config and make sure the CPU setting is higher than CONFIG_M486 or you''ll get an error message. If you have any of the schedule stuff (CONFIG_NET_SCH_blah) as modules (you do): make (YourFavoriteFlavorOf)config (checking/changing - if needed - the CPU) make clean ; make dep ; make bzImage make modules make modules_install Those "make"s are broken up like that for a reason. Just Do It, please. If you did not have to change the CPU type, you can just reload the ingress module: modprobe -r sch_ingress modprobe sch_ingress and test the setup. If you did change the CPU type, you should install your new kernel, run lilo and reboot using the new kernel. buck _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
El Sábado, 3 de Julio de 2004 06:14, gypsy escribió:> Edulix wrote: > > Using 2.4.22 here (default of Fedora Core 1). > > > > > 2) Post results of > > > grep "define PSCHED_CLOCK" /usr/src/linux/incluce/net/pkt_sched.h > > > > # grep "define PSCHED_CLOCK" /usr/src/linux-2.4/include/net/pkt_sched.h > > #define PSCHED_CLOCK_SOURCE PSCHED_JIFFIES > > > > does it help ? > > Yes, it sure does. > > Edit pkt_sched.h and change from JIFFIES to CPU. Before you recompile > the kernel, make config and make sure the CPU setting is higher than > CONFIG_M486 or you''ll get an error message. If you have any of the > schedule stuff (CONFIG_NET_SCH_blah) as modules (you do): > > make (YourFavoriteFlavorOf)config (checking/changing - if needed - the > CPU) > make clean ; make dep ; make bzImage > make modules > make modules_install > > Those "make"s are broken up like that for a reason. Just Do It, please. > > If you did not have to change the CPU type, you can just reload the > ingress module: > modprobe -r sch_ingress > modprobe sch_ingress > > and test the setup. If you did change the CPU type, you should install > your new kernel, run lilo and reboot using the new kernel. > > buckThanks for the info I don''t know why I''m having problems compiling the kernel image [1]. It looks like a linking issue or a bad module, but I doubt it''s easy to solve. I am going to change distro in a few days so I think that trying to find a solution might be not worthy :-). What''s more, I haven''t changed the CPU type (Athlon by default) so I''m trying to build modules even without having compiled successfully the kernel image. BTW, Should I warn the Fedora devels about the JIFFIES problem? Thanks for your time, Edulix. --- [1] In the execution of ''make bzImage'', I get: ---------- make[1]: Saliendo directorio `/usr/src/linux-2.4.22-1.2135.nptl/arch/i386/lib'' make[1]: Cambiando a directorio `/usr/src/linux-2.4.22-1.2135.nptl'' kallsyms pass 1 ld -m elf_i386 -T /usr/src/linux-2.4.22-1.2135.nptl/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o init/do_mounts.o --start-group arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o drivers/acpi/acpi.o drivers/cpufreq/cpufreq.o drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/char/drm/drm.o drivers/net/fc/fc.o drivers/net/appletalk/appletalk.o drivers/net/tokenring/tr.o drivers/net/wan/wan.o drivers/atm/atm.o drivers/ide/idedriver.o drivers/cdrom/driver.o drivers/pci/driver.o drivers/net/pcmcia/pcmcia_net.o drivers/net/wireless/wireless_net.o drivers/pnp/pnp.o drivers/video/video.o drivers/net/hamradio/hamradio.o drivers/media/media.o drivers/md/mddev.o drivers/isdn/vmlinux-obj.o crypto/crypto.o drivers/sensors/sensor.o net/network.o /usr/src/linux-2.4.22-1.2135.nptl/arch/i386/lib/lib.a /usr/src/linux-2.4.22-1.2135.nptl/lib/lib.a /usr/src/linux-2.4.22-1.2135.nptl/arch/i386/lib/lib.a --end-group -o .tmp_vmlinux1 drivers/ide/idedriver.o(.text+0x17570): En la función `ide_mediactl'': : undefined reference to `get_info_ptr'' make[1]: *** [kallsyms] Error 1 make[1]: Saliendo directorio `/usr/src/linux-2.4.22-1.2135.nptl'' make: *** [vmlinux] Error 2 ---------- _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>Thanks for the info I don''t know why I''m having problems compiling the kernel >image [1]. It looks like a linking issue or a bad module, but I doubt it''s >easy to solve. I am going to change distro in a few days so I think that >trying to find a solution might be not worthy :-). > >Unlikely to change anything... Compiling is somewhat independent of the rest of your system (perhaps depends on gcc version and some other stuff, but not too much in practice)>What''s more, I haven''t changed the CPU type (Athlon by default) so I''m trying >to build modules even without having compiled successfully the kernel image. > >Aha, but did you do all the "make" commands that you were told to do? It''s important that they are all done Ed W _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
El Sábado, 3 de Julio de 2004 13:09, Ed Wildgoose escribió:> >Thanks for the info I don''t know why I''m having problems compiling the > > kernel image [1]. It looks like a linking issue or a bad module, but I > > doubt it''s easy to solve. I am going to change distro in a few days so I > > think that trying to find a solution might be not worthy :-). > > Unlikely to change anything... Compiling is somewhat independent of the > rest of your system (perhaps depends on gcc version and some other > stuff, but not too much in practice)I think it will change because: I''m not going to use the same distro, but change from Fedora to Suse. What''s more, I''ve managed to compile this same kernel source time ago, so something wrong must be happening :-).> >What''s more, I haven''t changed the CPU type (Athlon by default) so I''m > > trying to build modules even without having compiled successfully the > > kernel image. > > Aha, but did you do all the "make" commands that you were told to do? > It''s important that they are all doneOf course I did =). BTW, I''ve been compiling (successfully most of the time) 2.4.x linux kernels since 2-3 years ago :-P. As I said, I''ll get Suse 9.1 Prof soon (the 10th most probably). I''m curious about the PSCHED_CLOCK_SOURCE value. Is it wrong or deprecated the default Fedora''s value (PSCHED_JIFFIES instead of PSCHED_CPU)? Or is it just that you have to compile your own kernel in order to get ingress rate policies working fine ? _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> > >I think it will change because: >I''m not going to use the same distro, but change from Fedora to Suse. >What''s more, I''ve managed to compile this same kernel source time ago, so >something wrong must be happening :-). > >One workaround is to look at which module is erroring (in your case an IDE bit of code). And then see if you live without that code (disable it). Also if you are using a redhat .config preprovided file then it tends to build everything as a module - in my experience this becomes very fragile. I prefer to have few or no modules (and this tends to fix a lot of compile probs as well)>As I said, I''ll get Suse 9.1 Prof soon (the 10th most probably). I''m curious >about the PSCHED_CLOCK_SOURCE value. Is it wrong or deprecated the default >Fedora''s value (PSCHED_JIFFIES instead of PSCHED_CPU)? Or is it just that you >have to compile your own kernel in order to get ingress rate policies working >fine ? > >I''m a BIG fan of gentoo. You never need to upgrade again...! (Debian sounds nice as well) I think the psched_clock_source code just changes how the scheduler works out how often to fire. Basically its hard to get accurate high resolution timers on most operating systems. I haven''t studied the details, but assume the CPU method gives more accurate results, perhaps at the expense of more CPU required..? Ed W _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Edulix wrote:> BTW, Should I warn the Fedora devels about the JIFFIES problem?No. It is set to JIFFIES because that is the setting required so that all the CPUs in the kernel .config list work. If you select 386 or 486 in ''make config'', make bzImage will fail because the CPU does not support a clock. ''cat /proc/cpuinfo | grep tsc'' - if that would work in a .h file - would return TRUE for CPUs that do support a clock. Otherwise, the Time Of Day clock (IRQ 8) or "jiffies" (IRQ 0) should be used.> Edulix. > drivers/ide/idedriver.o drivers/cdrom/driver.o drivers/pci/driver.o > drivers/net/pcmcia/pcmcia_net.o drivers/net/wireless/wireless_net.o > drivers/pnp/pnp.o drivers/video/video.o drivers/net/hamradio/hamradio.o > drivers/media/media.o drivers/md/mddev.o drivers/isdn/vmlinux-obj.o > crypto/crypto.o drivers/sensors/sensor.o > net/network.o /usr/src/linux-2.4.22-1.2135.nptl/arch/i386/lib/lib.a /usr/src/linux-2.4.22-1.2135.nptl/lib/lib.a /usr/src/linux-2.4.22-1.2135.nptl/arch/i386/lib/lib.a > --end-group -o .tmp_vmlinux1 > drivers/ide/idedriver.o(.text+0x17570): En la función `ide_mediactl'': > : undefined reference to `get_info_ptr'' > make[1]: *** [kallsyms] Error 1 > make[1]: Saliendo directorio `/usr/src/linux-2.4.22-1.2135.nptl'' > make: *** [vmlinux] Error 2If anything should be reported, this is it. It says to me that you either didn''t ''make clean ; make dep'' or that the idedriver.c is poorly written. But, since you intend to change distros, why waste your time on this? You may want to have a look at my notes about building a 2.4.25 kernel. They are Slackware specific but they do describe most of the steps, in order (but not in detail), I take. ftp://andthatsjazz.org/pub/lartc/BUILD-2.4.25 _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
by way of Edulix <edulix@tumundoweb.com>
2004-Jul-03 22:25 UTC
Re: filter ingress policy rates -> slow!!
El Sábado, 3 de Julio de 2004 17:02, gypsy escribió:> Edulix wrote: > > BTW, Should I warn the Fedora devels about the JIFFIES problem? > > No. It is set to JIFFIES because that is the setting required so that > all the CPUs in the kernel .config list work. If you select 386 or 486 > in ''make config'', make bzImage will fail because the CPU does not > support a clock. ''cat /proc/cpuinfo | grep tsc'' - if that would work in > a .h file - would return TRUE for CPUs that do support a clock. > Otherwise, the Time Of Day clock (IRQ 8) or "jiffies" (IRQ 0) should be > used.Well, a bit more info: I''ve tried to reproduce the same thing in my sister''s computer. Whereas I have a Athlon XP 2000+, she has a Celeron 2.4 Ghz. Whereas I use FC1, she uses SuSE 9.0. I saw in the sources that she also has JIFFIES configured. Basically, exactly the same problem happens in her computer, her rate instead of be of 44~ kb/s was of about... 400-700kb/s. After that, I just remembered that I''ve got gentoo installed in other partition of my PC. I rebooted, and went to kernel sources (using vanilla 2.6.1). I aw that it was using JIFFIES; so I changed to CPU. Then I executed make menuconfig to be sure that I selected Athlon as my cpu type and that QoS modules was selected (they were). So I didn''t need to change anything in the conifguration: Finally, I executed "make" and "make modules_install", did a "modprobe -r sch_ingress; modprobe sch_ingress. I executed : "eshaper start downlink" and assured with a "eshaper status" that the rules were there (no packets droped still). Then I tried copying file from my sister''s computer via scp and it went at about a 700 Kb/s to 1.2 Mb/s rate! Note that in Fedora, in the pretty same pc, it went at only 40 Kb/s. "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 with CPU instead of JIFFIES, because maybe it will go at desired speed - remember that even with JIFFIES the rate was of ~400-700 kb/s! Thanks for your time, Edulix. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
"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 kernelNow 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@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/