headers
Lucas Brasilino | 3 Apr 2002 12:52
Picon

Re: Question on using patch for nf

> Hi...

	Hi

>    Thanks for the reply. Another basic question from this newbie, if you
> don't mind. Do i need to get the whole new kernel (2.4.18) or
> i just need to download a patch / upgrade ? I currently do not have access
> to the internet through my laptop (where my linux is) and thus downloading
> the whole kernel (which is 20++MB) could be daunting. I found a patch
> though which can fit into a diskette at www.kernel.org.
> 
>    The question is:
> can i just download the patch from www.kernel.org? It says "latest stable
> version of the Linux kernel"... but i'm not sure whether it is applicable
> on my current linux kernel (again, it is 2.4.7-10).

	Since you can't download the whole kernel, you should upgrade your kernel 
this way:

	Install RedHat source kernel rpm:
		 rpm -ihv kernel-2.4.7-10.src.rpm

	Extract kernel source:
		cd /usr/src
		tar jxvf /usr/src/redhat/SOURCES/linux-2.4.7.tar.bz2

	Upgrade kernel:
		cd linux
		gzip -dc patch-2.4.18.gz | patch -p1
		(it's normal if some files has it's patch reject due it has *been* patched)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Henrik Nordstrom | 3 Apr 2002 14:01

Re: Question on using patch for nf

Lucas Brasilino wrote:

> 	Extract kernel source:
> 		cd /usr/src
> 		tar jxvf /usr/src/redhat/SOURCES/linux-2.4.7.tar.bz2
>
> 	Upgrade kernel:
> 		cd linux
> 		gzip -dc patch-2.4.18.gz | patch -p1
> 		(it's normal if some files has it's patch reject due it has *been*
> patched)

You also need to apply all the other incremental patches between 2.4.7 and 
2.4.18 in the correct order.

And no, it is not normal to have rejects when patching the kernel tree. If 
you get any rejects then you have done something wrong.

Regards
Henrik
Permalink | Reply | 2 comments |
headers
Bart De Schuymer | 3 Apr 2002 23:16
Picon

ebtables v2.0pre1 released

Hello,

ebtables v2.0 is a complete rewrite of the old code to make it modular and
look nicer. All ebtables versions 1.x will become unmaintained so please use
version 2.0.
Feel free to try to crash it, should be hard (I hope).
The modular property makes it easier to add new features (and is basically
just alot cooler)...
The kernel patch is vs 2.4.18 and should be applied after applying the 0.0.6
bridge-nf patch.
See the homepage:
http://users.pandora.be/bart.de.schuymer/ebtables/

cheers,
Bart
Permalink | Reply | 0 comments |
headers
Lennert Buytenhek | 4 Apr 2002 00:01
Picon

Re: Bridge - Does performance suffer with gig n/w ?


On Wed, Mar 27, 2002 at 11:02:09PM -0500, Kunal Trivedi wrote:

> > limitations of interrupt driven I/O.  Interrupts are expensive, and when
> > you're pushing 100Mbit of data, that's 100k Interrupts/sec.  Eventually,
> > interrupts are so frequent that the machine is not able to do anything
> > useful between them and the interrupt handlers consume all of the CPU's
> > time.  I suspect this is what is happening.  That would explain why the
> > throughput goes down when you pound the machine harder (more interrupts
> > consume more time, and the ability of the machine to process packets
> > decreases).
> 
> yes, we thought about it but then i found that cpu is not
> reaching its max. utilization. During these experiments, cpu
> was used 17%. It was idle for 83%.

Did you just look at 'top' for determining this?  Time spent in
interrupt context isn't counted in that figure :-)

Try Andrew Morton's cyclesoak.

	http://www.zip.com.au/~akpm/linux/#zc

cheers,
Lennert
Permalink | Reply | 0 comments |
headers
Lennert Buytenhek | 4 Apr 2002 00:14
Picon

Re: VPN on bridge-firewall?

Should be no problem.. a bridge looks like a single host on a
subnet as far as application software is concerned.

On Mon, Apr 01, 2002 at 05:04:09PM -0500, Tim Riley wrote:

> Hello again,
> 
> Just wondering if anyone has had any luck installing VPN software
> (particularly FreesWAN) on a
> bridge-firewall, or if it is even possible?  My bridge/firewall is
> assigned a real IP, so I'm thinking this shouldn't be a problem.  Any
> insight would be greatly appreciated.
> 
> Thanks,
> 
> Tim
> 
> _______________________________________________
> Bridge mailing list
> Bridge <at> math.leidenuniv.nl
> http://www.math.leidenuniv.nl/mailman/listinfo/bridge
Permalink | Reply | 0 comments |
headers
Lennert Buytenhek | 3 Apr 2002 23:47
Picon

Re: Too much work in interrupt, status e401 + bridge code = ?

On Wed, Mar 20, 2002 at 04:17:17PM -0500, Andrew Park wrote:

> Hi,

Hi,

> I have two NICs (3com 59x vortex) on my firewall
> (bridge code 0.0.3 + 2.4.14 kernel + 1.2.4 netfilter)  this morning there
> was *MASSIVE* amount of probes from outside and at numerous point the
> firewall log gave the following message
> 
> 	eth0: Too much work in interrupt, status e401.

Have you tried the last item from this?

	http://bridge.sf.net/faq.html

> I understand that it appears if the driver cannot handle the interrupt
> within the specified time, but my question, then is what happens to the
> packet that arrived at eth0?  Does it get passed through to the other
> interface without being checked my the netfilter rules?

No, a firewall would never do that.

> And for how long does this state last?

Probably until the flood stops :-)

cheers,
Lennert
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lennert Buytenhek | 3 Apr 2002 23:57
Picon

Re: Bridge - Does performance suffer with gig n/w ?

On Wed, Mar 27, 2002 at 07:35:28PM -0500, Logan Bowers wrote:

> Hi, 

Hi,

> I'm not Lennert,

:-)

> but I suspect your problem is due to the fundamental
> limitations of interrupt driven I/O.  Interrupts are expensive, and when
> you're pushing 100Mbit of data, that's 100k Interrupts/sec.  Eventually,
> interrupts are so frequent that the machine is not able to do anything
> useful between them and the interrupt handlers consume all of the CPU's
> time.  I suspect this is what is happening.  That would explain why the
> throughput goes down when you pound the machine harder (more interrupts
> consume more time, and the ability of the machine to process packets
> decreases).  

Yeah, this is exactly what happens.

> I don't know what state the project is in, but do a google search for
> the Click Modular Router Project.  They continuously poll the ethernet
> cards instead of using interrupts as a way to increase the total
> throughput.  Supposedly they should be able to achieve ultra-high
> throughputs very efficiently using this method.  

You can also try NAPI, which is a kernel patch for linux that
also enables polling (net drivers still have to be slightly
(Continue reading)

Permalink | Reply | 4 comments |
headers
Lennert Buytenhek | 4 Apr 2002 00:05
Picon

Re: packet loss problem

On Mon, Apr 01, 2002 at 05:43:32PM +0200, Marek Kierdelewicz wrote:

> Hello

Hi!

>     I'm using Slackware Linux 8.0 running on kernel 2.4.18 patched with
> bridge-nf-0.0.6-against-2.4.18.diff. My linux box consists of P166,32MB RAM
> and 2xNIC (3c59x, I also tried realtek8139). My bridge has just two ports
> (becouse this box is suppose to do some transparent bandwidth shaping at
> sub-10mbit speeds), i'm not using STP.
>     Here is my problem - after more then 20-30h of functioning bridge is
> starting to drop packets at rates up to 40% avarage. After reboot everything
> works fine for another couple of hours ...

I've heard about this before.. and I really would have no idea what
is causing it.

Are you familiar with tcpdump?  Can you try running tcpdump on the
bridge, and check whether the packets you are sending through it
are

	1. Arriving at one end of the bridge at all?
	2. (if they arrive) leaving at the other end?

I would really suspect a driver problem here, but I've heard this
too many times with different cards now.

cheers,
Lennert
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kunal Trivedi | 4 Apr 2002 02:07
Picon

Re: Bridge - Does performance suffer with gig n/w ?

Lennert:

> Did you just look at 'top' for determining this?  Time spent in
> interrupt context isn't counted in that figure :-)
 I used 'vmstat'.

******* I am sorry to send too long mail.

Here, are some results. I used 'iperf' and 'nttcp' both. Before, you read
further in details, I got performance of around 520-580 Mbits/sec both in
UDP/TCP (using both iperf and ttcp). And one of my end machines is running
FreeBSD 4.5

Please read /Questions/ at the end of the results.

My observation during testing was, Linux box could not push more than 580
Mbits/sec ( I am using Interl 82543 Gigcards, P-III 1.26 GHz, 133 MHz bus
speed and 1 GB memory on all machines).

Setup: (/nttcp/)
	nttcp sender	: test-machine  (OS: Linux-2.4.18)
	bridge		: br-machine    (OS: Linux-2.4.18)
	nttcp receiver	: test-machine2 (OS: FreeBSD 4.5) // Please Note
	l=local, 1=remote(receiver),
	For man page of 'nttcp'
	goto:   http://www.leo.org/~elmar/nttcp/nttcp.1.html

1) UDP:
    -n 252144 (that many number of pkt has been sent, each has 4096Bytes
long)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lennert Buytenhek | 4 Apr 2002 00:27
Picon

Re: Network Performance

Hi,

Are you using a lot of firewall rules in the FORWARD chain, maybe?
Or are you using expensive tests like the string match?

cheers,
Lennert

On Fri, Mar 22, 2002 at 06:57:41PM +0100, Cezary Sydlo wrote:

> Hello,
> 
> i checked the performance of a P90 64MB with kernel 2.4.18
> the firewall itself shows me connections (any computer to firewall) of
> 9.6Mb on both network cards (measured with pathchar from
> http://www-nrg.ee.lbl.gov/),
> but when i check the performance from one computer to another across the
> firewall the performance drops to 4.8Mb.
> Is this normal? Do I have to change some settings?
> 
> Greetings
> Cezary
> -- 
> Dipl.-Ing. Cezary Sydlo
> Institut fuer Hochfrequenztechnik, TU Darmstadt
> Merckstrasse 25, D-64283 Darmstadt, Germany
> Tel : ++49  (0) 6151 16 2662
> FAX : ++49  (0) 6151 16 4367
> E-Mail: c_sydlo <at> hf.tu-darmstadt.de
> _______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |

Gmane