All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rinse Kloek" <rinse@solcon.nl>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Bandwith limitation
Date: Mon, 10 Mar 2003 17:50:51 +0000	[thread overview]
Message-ID: <marc-lartc-104731922213318@msgid-missing> (raw)
In-Reply-To: <marc-lartc-104728577309146@msgid-missing>

> On Monday 10 March 2003 09:41, Rinse Kloek wrote:
> > We use a RedHat 7.3 machine as bridge on a P3 1.8 Ghz with 2 64 bits
> > Gigabit interfaces. On the machine we have a lot of iptables rules like
:
> >            all  --  213.134.225.0        0.0.0.0/0
> >            all  --  0.0.0.0/0            213.134.225.0
> > TOS    all  --  213.134.225.4        0.0.0.0/0          TOS set 0x08
> >            all  --  0.0.0.0/0            213.134.225.4
> >
> > Currently in the peak hours we have about 40 Megabit traffic. Also in
this
> > peak hours we have a CPU load of about 70%. What is the main reason of
this
> > CPU load, is it the high traffic or the iptables rules on the machine.
And
> > if the iptables rules are the reaseon of the high CPU load, does TOS
> > mangling use much CPU?
> I'm not sure, but I think the high traffic is the problem.  And for
iptables,
> I thinkg changing something (TOS or DNAT/SNAT) is the most CPU intensive.
> Maybe you can try to rearrange the iptables rules so the most matched
rules
> are in the beginning of your firewall script.
>
> Maybe you can create a test setup so you can generate 40 Megabit traffic
on a
> test bridge without iptables rules to see what the CPU does.
>
> Stef
>
> --
>
Stef,

We have about 3200 iptables rules on our bridge. I've tested today to remove
1000 of these rules. The load dropped from about 40% to 25%. So I think the
iptables rule take up the most of the CPU load. Do you think this is a
problem of ineffeciency of iptables or just a 'limitation' in the TCP/IP
stack of linux ?

regards Rinse

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

  parent reply	other threads:[~2003-03-10 17:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-10  8:41 [LARTC] Bandwith limitation Rinse Kloek
2003-03-10 17:41 ` Stef Coene
2003-03-10 17:50 ` Rinse Kloek [this message]
2003-03-10 18:00 ` Stef Coene
2003-03-10 18:42 ` Evgeni Gechev
2003-03-10 19:03 ` Raúl Alexis Betancort Santana

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-lartc-104731922213318@msgid-missing \
    --to=rinse@solcon.nl \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.