Optimizing Network Performance/Reducing latency

Forum: LinuxTotal Replies: 12
Author Content
techiem2

Nov 07, 2007
10:28 AM EDT
We are currently rebuilding one of our boxes in preparation for installing a multi-wan router and are trying to optimize it's network performance.

My boss has done a couple tests and noted that with the box (which will be our proxy/content filter/etc) between the broadband router and a client machine (with the box just doing straight nat routing - no proxy or anything setup yet), that the speed tests were @.5-.75Mb slower than with the client connected directly to the broadband router.

Any tips or resources for optimizing the performance and reducing latency on the box?

Thanks.

Mark II
dinotrac

Nov 07, 2007
11:40 AM EDT
>Any tips or resources for optimizing the performance and reducing latency on the box?

There may be a better approach, but have you tried string, tin-cans, and a couple of people who can type really, really fast?
techiem2

Nov 07, 2007
11:41 AM EDT
ROFL
tuxchick

Nov 07, 2007
11:56 AM EDT
Anything that touches your packets is going to slow them down, and NAT has to touch every single packet each way. Another reason to hasten IPv6 and retire NAT forever.

Once you add proxying and content filtering it's going to drop even more. If you're using an HTTP proxy that will speed up Web-surfing, but everything else is going to see a performance hit.
techiem2

Nov 07, 2007
12:06 PM EDT
Yeah..I think he's a bit surprised at the amount of loss though. So anything that can be done to minimize it is good. I've searching around for useful information, but there doesn't seem to be a whole lot of it out there.
jdixon

Nov 07, 2007
12:45 PM EDT
You could try recompiling your kernel and iptables to optimize them for your machine, but other than that I can't think of anything which will greatly improve the performance of NAT, though O'Reilly probably has a book on the subject somewhere it their library.

You might want to take a look at one of the BSD's for that task. Their networking code is considered to be superior to Linux's by some. For a case such as this, it may be worth a quick test to see which works better.
hkwint

Nov 07, 2007
12:47 PM EDT
When using the WAN-router for the net, maybe some cache could help?
hkwint

Nov 07, 2007
1:15 PM EDT
This might be a nice paper:

http://www.academypublisher.com/jnw/vol02/no03/jnw02030617.p...
Bob_Robertson

Nov 07, 2007
1:23 PM EDT
As sort of a network hack myself, I agree with what has already been said. The more you ask the box to do, the more it will interfere with throughput.

I happen to like NAT, and think IPv6 suffers from a nasty case of Second System Syndrome. But that's just me.

I noticed that running IPv4 NAT, IPv6 tunnel and Bittorrent on a 500MHz Celeron box with two ethernet ports, it was fully capable of driving the CableModem at 4MB/sec line speed. So I have to wonder, even though there is an increase in latency, is it really interfering with your bandwidth utilization?

Unless you're driving a large office, I wouldn't bother with a caching proxy. Caching is only useful with a large number of users.

Even though the string-and-cans acoustic setup is faster, I find RFC 1149 "Packet delivery by avian carrier" to be far more slow, difficult and unreliable. But one must never underestimate the bandwidth of a 747 full of DAT tapes even if the latency sucks.
techiem2

Nov 07, 2007
2:14 PM EDT
We will eventually have squid on it. We are serving a fairly large number of people as it's a college campus. Probably a couple hundred at any one time?

We've decided that the online speed tests are too variable to be used to measure latency introduced by the box, so we're going to make up our own system (i.e. have a system/couple systems and dump a particular file to-from it/them from both sides of the box and such to get a more proper reading of what latency the box and it's services introduce).

I'll check out the pdf.

I've got a few other sources to look over too. Hopefully we'll find something that will at least help the overall performance and latency a tad. Every bit helps when you're dealing with office personnel and students. :)

Sander_Marechal

Nov 07, 2007
2:28 PM EDT
Quoting:Anything that touches your packets is going to slow them down, and NAT has to touch every single packet each way. Another reason to hasten IPv6 and retire NAT forever.


Perhaps configuring the network to use jumbo frames might help? If I understand it correctly then the packets would become bigger (9K-64K bytes). You could have more overhead if you transmit a lot of data that's smaller than that, but you could also gain a lot because NAT has to touch fewer packets.
gus3

Nov 07, 2007
6:49 PM EDT
Squid will slow things down even more than NAT. The NAT in standard iptables is capable of interpreting individual TCP/UDP packets (i.e. IRC and FTP commands), but Squid needs to be aware of the entire stream's context. It will be doing much more stateful examination of the network connection, probably by a couple orders of magnitude.

That said, my suggestion is not to worry about it. The time lost in network latency will be made up in Squid caching.
tuxchick

Nov 07, 2007
7:24 PM EDT
techiem, what CPU, how much RAM, and what kind of RAM are on the box itself? These will all affect performance. For example, the older Soekris boards that use the old 486-133 processors and SDRAM top at around 17 Mbps. The newer boards with faster processors and DDR-SDRAM hit 50 Mbps and better.

There are also differences in NICs- "server" quality NICs really are better.

Don't forget the inherent latency in the different types of networking and protocols; latency in an Ethernet interface is around 0.3 milliseconds, which you can measure by pinging localhost. DSL/cable are around 20ms, and T1/T3 have a latency of about 4ms.

Then there is TCP queueing, which is always fun. This is the 'txqueuelen:1000' value in ifconfig output, and you can tweak it with ifconfig:

# ifconfig eth1 txqueuelen 10000

If the value is too small relative to your line speed it will slow you down.

You cannot post until you login.