Netgear FS108 report
Robert G. Brown
rgb@phy.duke.edu
Tue, 17 Aug 1999 16:13:54 -0400
On Tue, 17 Aug 1999, Mark Hahn wrote:
> > I did indeed get the FS108 for my house last week and have done limited
> > tests with it. Below is a very short report on the switch.
>
> it would be very nice to have a bandwidth/latency comparison between it
> and a more "serious" switch. actually versus switches and hubs.
> I have yet to see a beowulf site that explicitly examined whether
> their code could benefit from the lower latency of a hub...
Hmmm, I expect that you mean a bottom-line comparison like netperf
running RR and/or STREAMS for small packets? Or do you mean reading off
the specs? Both are somewhat questionable in that the performance of
the NIC and TCP stack are mixed in to whatever you get from netperf, and
the specs are in the best of all possible worlds and may not reflect the
real one.
According to the specs, the FS108 does store and forward with 15 usec
maximum latency -- its more expensive cousin the FS508 (for more than
twice as much money) does cut through and has a spec of 11 usec maximum
latency.
I have only two serious systems connected to the switch so far (at home,
remember) and just benched:
rgb@rgb|T:56>>netperf -t UDP_STREAM -l 10 -H eve -- -s 65535 -S 65535 -m
1472
UDP UNIDIRECTIONAL SEND TEST to eve
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
131070 1472 10.00 80727 0 95.07
131070 10.00 80727 95.07
which is respectable although not spectacular. This is with a genuine
21141 Tulip on one end (:-) and a $20 generic RTL8139 on the other --
not a spectacular NIC, according to Don Becker, although it does ok
here.
With SMALL messages, I get:
rgb@rgb|T:57>>netperf -t UDP_STREAM -l 10 -H eve -- -s 65535 -S 65535 -m
1
UDP UNIDIRECTIONAL SEND TEST to eve
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
131070 1 9.99 985963 0 0.79
131070 9.99 8356 0.01
Which sucks on the receiver side (the RTL8139). Coming back the other
way I get:
rgb@rgb|T:58>>eve netperf -t UDP_STREAM -l 10 -H adam -- -s 65535 -S
65535 -m 1
UDP UNIDIRECTIONAL SEND TEST to adam
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
131070 1 10.31 386262 0 0.30
131070 10.31 30288 0.02
which STILL sucks. Compared to eepro100 to eepro100 through a Cisco
C5000:
rgb@b2|T:2>netperf -t UDP_STREAM -l 10 -H b10 -- -s 65535 -S 65535 -m 1
UDP UNIDIRECTIONAL SEND TEST to b10
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
65535 1 9.99 794197 0 0.64
65535 9.99 341481 0.27
or tulip to eepro100 through a Cisco Cat 5000:
rgb@ganesh|T:21>netperf -t UDP_STREAM -l 10 -H b10 -- -s 65535 -S 65535
-m 1
UDP UNIDIRECTIONAL SEND TEST to b10
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
65535 1 10.00 452337 0 0.36
65535 10.00 436887 0.35
they are both abysmal, but unless I take the spare tulip out of my
gateway system and trade it for an RTL8139 (I don't need horsepower on
my ADSL link) and pop it into the other system I have up at home I won't
be able to control for NIC. I'm presuming that the CPU differences are
irrelevant as well -- all of the ones in question are 300 MHz or better.
TCP RR also sucks on the home network:
rgb@rgb|T:62>>eve netperf -t TCP_RR -H adam
TCP REQUEST/RESPONSE TEST to adam
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
65535 65535 1 1 10.00 1325.41
65535 65535
and is pretty symmetric. This has to be compared to:
rgb@ganesh|T:24>netperf -t TCP_RR -H b10
TCP REQUEST/RESPONSE TEST to b10
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
65535 65535 1 1 10.00 4749.19
65535 65535
(tulip to eepro from a 300 MHz dual PII to 400 MHz dual PII, with 5664
for eepro-eepro, both 400 MHz, through the cat 5K).
This pretty much supports my contention that the switch is suitable for
home play, prototyping, and big message stuff, but it looks like it
MIGHT be a poor performer for small messages or lots of messages. Of
course, it isn't possible (yet) to see if the "problem" is the switch or
the RTL NIC (I know it isn't the tulip).
BTW, I'm running 2.2.10 (2.2.11 with the RTL and tulip linked memory
leaked sounded like a bad bet).
It would also be interesting to see the same tests done for the FS508.
I'm sorry I don't have a more uniform collection of NICs. I might pick
up a $30 Netgear 310 (new tulip?) and see how it does -- the RTL8139's
were VERY cheap but may well not have been worth their very cheap price.
rgb
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu