Mailinglist Archive: opensuse (4547 mails)

< Previous Next >
Re: [SLE] 486 fast enough?
  • From: Dave Smith <Dave.Smith@xxxxxx>
  • Date: Wed, 5 May 2004 10:32:12 +0100
  • Message-id: <20040505093212.GA27832@xxxxxxxxxxxxxx>
On Sat, May 01, 2004 at 02:38:02PM +0200, Hans du Plooy wrote:
> Hi all,
>
> I have a 486 DX2-66 with 16mb RAM that I'd like to use as a firewall for
> dial-up at home. Network card is a 10-base ISA card, it has a vesa-localbus
> IDE controller and 1gb Maxtor disc. The disc was from a P-I of which the
> mobo went bad. The firewall was already setup with forwarding and squid
> proxy on the disc.
>
> I tried it once but the result was disappointing. I could not get anymore
> than about 1kbps download speed, and response was really slow. Even with the
> proxy and all other unnecessary services disabled, matters didn't improve. I
> tried both SuSE 6.3 and the latest IP-COP (www.ipcop.org) with all the
> patches loaded.
>
> The modem (external serial 56k v90) works fine and at full speed directly on
> my computer, so it's not that. I copy a large file - about 40mb - with scp
> to the 486, and it went at about 120kbps. Not sure where the bottleneck
> there is - hard disc write speed or network card - but at least I know
> networking should be able to keep up.
>
> Is a machine like this just too slow? Or is the RAM insufficient? It only
> serves two clients on normal analog dialup.

My firewall machine is a DX/2-66, although I think it might have a bit more
RAM. It runs IPCop 1.3.0. I can still saturate my 512 kb/s broadband link.

Some extra RAM will probably help (running "top" or "free" on the ipcop box
will tell you how much swap you're using).

Response *will* be slow on web pages, as it takes a while for the http
daemon to be swapped back in. This is particularly obvious if you use
https rather than http. Some extra RAM will help here.

Switching off any unnecessary processes will help. In particular, Squid
and Snort use a lot of resources.

scp is probably going to be slow anyway; the bottleneck here is probably
the CPU running the encryption/decryption algorithm, although it could
be the network card - remember that encryption increases the amount of
data that actually has to be sent, so the perceived data transfer rate
is lower than the actual data rate going through the network interface.

If you want more help, join the ipcop-user mailing list; we're all pretty
friendly.

HTH...

--
David Smith Work Email: Dave.Smith@xxxxxx
STMicroelectronics Home Email: David.Smith@xxxxxxxxxxxxxxxxxxxx
Bristol, England GPG Key: 0xF13192F2

< Previous Next >
References