Slower can be better

For heavily loaded networks, switched 10M bit/sec Ethernet beats its big brother, shared 100M bit/sec.

By Robert Currier
Network World, 3/9/98

Whoa. Slow down, literally. When we set up a workgroup configuration where 11 clients and one server heavily loaded the network with a steady stream of bidirectional 100K byte files, we found that switched 10M bit/sec Ethernet to every desktop gave us better performance.

The reason is quite simple. With shared 100M bit/sec technology, you'll get inordinately high collision rates when the network is heavily loaded, resulting in more bandwidth being consumed for retransmissions. Switched 10M bit/sec Ethernet distributes traffic more evenly, nearly eliminating collisions and ultimately delivering more data in the same amount of time. In fact, we found switched 10M bit/sec Ethernet managed to squeeze roughly 9% more bytes through the network than shared 100M bit/sec.

When we had clients sending less bandwidth-consuming traffic, shared 100M bit/sec Ethernet outperformed switched 10M bit/sec by nearly two to one. However, when you factor in the cost of equipment, switched 10M bit/sec Ethernet still comes out better because the price you'll pay for 100M bit/sec equipment outweighs what you will gain in performance.

In fact, you can get a 10M bit/sec Ethernet switch with 24 full-duplex client ports, a 100M bit/sec full-duplex server port, support for four Remote Monitoring (RMON) groups, an 8K media access control table, front panel LEDs for management and an open slot for a management module for $1,299. A less-functional 24-port shared 100M bit/sec hub with front-panel LEDs for management and support for SNMP without RMON costs $1,379.

This is what we learned from the testing of two configurations supporting our 11 clients and a single server. The first used a 100M bit/sec shared Ethernet repeating hub where each client and the server shared access to 100M bit/sec of bandwidth. The other employed a 10M bit/sec Ethernet switch where each client had a dedi-cated 10M bit/sec to the switch and the switch aggregated traffic from all clients on a dedicated 100M bit/sec link to the server.

We measured throughput and response time for two different traffic mixes in each environment. In our first test, we fully loaded the network with the bidirectional 100K-byte file transfers. Next, we had some clients transferring files while others performed SNMP operations, established telnet sessions, checked for mail using Post Office Protocol 3, downloaded Web pages using HTTP or received PointCast network broadcasts. Using mixed protocol traffic lightened the overall load because some of the protocols are bursty in nature and required less bandwidth than the more steady bandwidth-consuming file transfer.

Switched 10 handles heavy burden

Our weakest performing clients, averaging less than 6M bit/sec each, were an OS/2-based machine with a 233-MHz Pentium processor and 32M bytes of RAM, and a Dell Computer Corp. Dimension XPS with a 100-MHz Pentium and 16M bytes of RAM. The OS/2 machine had an IP stack that performed poorly. The Dell's performance lagged primarily because it was underpowered compared with our other Dell clients, which had processors ranging from a 166-MHz Pentium to a 233-MHz Pentium II and 64M bytes of RAM.

The server sustained a blistering 87.5M bit/sec transfer rate to the switch's 100M bit/sec port. It successfully pushed 652M bytes of data through the pipe at the end of our one-minute test run, leaving just 12.5% of capacity unused. These numbers demonstrate the advantage offered by a full-duplex 100M bit/sec server port. The lack of collisions on that port allowed the server to handle each workstation's datastream without dropping any frames. Furthermore, the server left it up to the switch to redistribute data to the appropriate clients as fast as that data came in.

Changing the network interface card (NIC) in our server to operate in 100M bit/sec half-duplex mode reduced throughput by 20%, from 87.5M bit/sec to 70M bit/sec. The switch also passed 527M bytes of data to the clients in half-duplex mode, 125M bytes less than it did in full duplex.

On the client side, the average transfer rate slipped from 8.5M to 6.5M bit/sec in half-duplex mode. The 2M bit/sec drop occurred primarily because we were getting fewer bytes through the half-duplex server port and the switch throttled back clients appropriately.

There's a moral to this story: Don't run your server in half-duplex mode, especially on heavily loaded networks. The majority of NICs sold today provide both full- and half-duplex modes. As long as your switch provides a full-duplex server port, there's no excuse not to take advantage of the increase in performance you're bound to get. When we turned our attention to the shared 100M bit/sec hub, we quickly found that throughput was all over the place. Prior to the test, we performed loop-back testing in which each client sent data to itself. This loop-back gave us an indication of how fast clients would be able to submit traffic to the network if they were not constrained by the physical limitations of the topology.

When attached to the 100M bit/sec hub, workstations capable of putting 45M bit/sec of traffic on the network were reduced to just under 1M bit/sec, while those we clocked at 99M bit/sec were only grabbing 18M bit/sec. Looking at the front panel of the 100M bit/sec Ethernet hub provided the answer to this bandwidth quandary. Collisions were putting a cap on performance. While we weren't able to capture any collision statistics because of the lack of management software on our hub, the solid-red collision LED light gave us a pretty clear indication of what was happening.

Because it was constrained by collisions, the 100M bit/sec hub successfully pushed only 598M bytes to clients during the test run, while the server averaged 80M bit/sec of throughput across the hub's shared backplane. You'd think that the hub with the higher bandwidth would have beaten the pants off the switch. However, with all the clients sending as much data as they could to the hub, there was a lot of contention for that bandwidth. As a result, little of that data was successfully getting through.

Because the switch gave each client 10M bit/sec of dedicated bandwidth, it did not have to deal with collisions and thus was able to successfully deliver nearly every bit of data it received from cli-ents. The 100M bit/sec dedicated server port helped in this regard by aggregating traffic from clients on a high-speed link with few, if any, collisions.

When faster is better

The hub successfully got 348M bytes of data to clients in the allotted test time, while the switch delivered 171M bytes in full-duplex mode and 173M in half-duplex. We didn't see any performance improvement in full-duplex mode in this test because the network was not as heavily loaded as it was in the file transfer test.

The server throughput on the hub was 73M bit/sec compared with 52M bit/sec on the switch in full- or half-duplex mode. The primary reason for the turnaround is that mixing high bit stream file transfer with bursty traffic acted as an artificial bandwidth allocation mechanism. For instance, the clients configured to send file transfers were able to grab as much of the 100M bit/sec of bandwidth as they could get. The fact that the other clients were sending bursty traffic kept the number of collisionsdown, enabling those file transfer clients to successfully get more data through the network.

We verified this by watching the front panel LEDs on the hub. In the file transfer test, all clients were dumping as much data as they could on the network and keeping the hub's collision light brightly lit. However, with the lighter traffic generated by the mixed protocols, we observed only a flickering collision light, indicating that the hub was successfully delivering more data as opposed to dealing with continual retransmissions.

But the switch throttled back the file transfer clients because of its inherent speed limitation of 10M bit/sec. Those clients were capable of sending data at 70M to 80M bit/sec, but the switch only gave them 10M bit/sec of useable bandwidth. At the same time, the switch handled the bursty traffic as it was being sent.

In short, the hub performed better under the lighter load because it enabled the couple of bandwidth hogs to grab as much capacity as they could, while the switch had to throttle them back.

As noted, there wasn't much difference in the performance of the switch as we went from full- to half-duplex mode. The load on the network was light enough that the advantages provided by full-duplex didn't make any difference. Still, with the low price per port of today's 10M bit/sec switches and the solid numbers we observed in the file transfer test, switched 10M bit/sec can give you better price performance on heavily loaded networks and acceptable performance for less money on lightly loaded nets. Unless 100M bit/sec hub pricing takes a big drop, the advantages offered by switching give it the edge.