[LARTC] filter ingress policy rates -> slow!!

[LARTC] filter ingress policy rates -> slow!!

[Edulix]

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/

Re: [LARTC] filter ingress policy rates -> slow!!

[Stef Coene]

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/

Re: [LARTC] filter ingress policy rates -> slow!!

[Edulix]

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/

Re: [LARTC] filter ingress policy rates -> slow!!

[gypsy]

"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/

Re: [LARTC] filter ingress policy rates -> slow!!

[gypsy]

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/

Re: [LARTC] filter ingress policy rates -> slow!!

[Edulix]

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.
>
> buck

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 :-).

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/

Re: [LARTC] filter ingress policy rates -> slow!!

[Ed Wildgoose]

>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/

Re: [LARTC] filter ingress policy rates -> slow!!

[Edulix]

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 done

Of 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/

Re: [LARTC] filter ingress policy rates -> slow!!

[Ed Wildgoose]

>
>
>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/

Re: [LARTC] filter ingress policy rates -> slow!!

[gypsy]

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 2

If 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/

Re: [LARTC] filter ingress policy rates -> slow!!

[Edulix]

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/

Re: [LARTC] filter ingress policy rates -> slow!!

[gypsy]

"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\x10250

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/