netdev
[Top] [All Lists]

Re: 2.2 performance on high network load much much better than 2.4 (fwd)

To: Santiago Garcia Mantinan <manty@xxxxxxxxx>
Subject: Re: 2.2 performance on high network load much much better than 2.4 (fwd)
From: jamal <hadi@xxxxxxxxxx>
Date: Tue, 9 Oct 2001 07:25:42 -0400 (EDT)
Cc: Martin Josefsson <gandalf@xxxxxxxxxxxxxx>, <netdev@xxxxxxxxxxx>
In-reply-to: <20011009105150.A953@man.beta.es>
Sender: owner-netdev@xxxxxxxxxxx

On Tue, 9 Oct 2001, Santiago Garcia Mantinan wrote:

> > Can you post how many packets were dropped by the hardware? just post the
> > output of ifconfig.
>
> As I said at the beginning of the message...

Just include it in your next post even if it is diffs in counters.

>
> > > I tried to spam 2.4.9ac18 with the same three machines I had used for the
> > > last 2.2.19 test but the machine was almost totally frozen, after 6 hours 
> > > of
> > > test I stopped it.
>
> > I am confused. Is this a different test?
> > You say above taht for that kernel "Time: 42 minutes 48 seconds" for
> > "RX packets (aprox): 109 million overruns: 664"
>
> Well, yes, I added one more machine sendding packages for this test, so the
> load was even higher on the system and the bunzip2 did get even less cpu
> time, the console started to give very slow response because of the high
> load that this extra machine put on it.
>

This is why it's confusing; run the same tests for both 2.2 and 2.4
Also the 2.4 kernels before ksoftirq was introduced; try 2.4.5 vs 2.4.10
(although iam sure those results will be inconclusive since there may be
other issues such as VM etc that might be affecting you).

> > And from you results above it is inconclusive that is the case.
> > It seems to me the time is proportional to the amount of packets received.
>
> Yes, time is proportional to the amount of packages as the packages/second
> was constant, I mean that I had all that time the two (or the three in that
> special test) machines running this program spamming at full speed, using
> the hole cpu to spam.
>

Lets be consistent: blast specific amount of traffic at target, run time
bzip2 on target and collect stats when complete.

> > I guess i am confused a little about your results.
> > Also what would help is to describe your packet sizes, send and
> > receive rates etc.
>
> The packages are 4 bytes udp packages they are sent at the full ratio at
> which a P200MMX running 2.2.19 and a P166 running 2.4.10 can, I haven't
> calculated any ratios, but If you want I can try to, one could guess that
> from the number of interrupts that 2.2.19 was showing, I suppose. If we
> assume that then it would be 38500 packages per second, but If I calculate
> that from the time of the test being run and the number of received packages
> shown by ifconfig I get 42500 wich seems a more exact number to me.
>

I think the number of interupts shown are useful, but too "white box".
Lets go "black box" for now. Some of the useful data to collect will be:
- ifconfig stats
- /proc/net/softnet_stats in 2.4
- user space time allocated to the bzip2 activity
- some vm stats on memory: Can someone point to good stats that can be
retrieved from /proc?
- get the output of /proc/interupts before and after run and calculate the
difference during each run.

> > One thing would help is to say what the packet sizes are etc. And the
>
> I'm attaching the code of udpspam.c from Simon Kirby as he has said that the
> license was GPL without any warranty, he also said that he would publish it
> on his web but I haven't been able to find it.
>

This is fine; you are probably better off just using pg3 at:
ftp://ftp.crc.ca/pub/mirrors/by-site/amber.inr.ac.ru/IProute/iputils-ss011002.tar.gz

package p3.c

BTW, Robert, this variant seems unidirectional and doesnt have latency
measurements

> > switch in between might cause issues; can you try one powerful machine
> > directly connected?
>
> I tried that also, but there was no noticeable difference.

It is a variable in the equation. The less variables, the easier the
computation.

cheers,
jamal



<Prev in Thread] Current Thread [Next in Thread>