Switch performance with many-to-one port traffic

Sounds like a duplex mismatch.

"gigabit NICs" and "gigabit switch" doesn't tell us anything about the real throughput capacities of the PCs or of the switch. You can put a gigabit interface onto a tin-can telephone, if you have a way of dealing with the buffering.

Very few full-duplex switches do cut-through: cut-through does not work when you have differences in rates between ports, and cut-through does not support multicast (or ARP broadcasts) unless it -happens- that all the output port queues are empty. Cut-through also doesn't work with priority queuing, or packet filtering or rate shaping. Cut-through is effectively a thing of the past.

Overflowing a switch's buffers is possible but when you get that big of a difference in speeds, the reason is almost always duplex mismatches.

One of the first things I checked. There is no duplex mismatch.

The workstations are Apple G5s and the server is a Dell PowerEdge 1650. All subsystems for each computer have been checked and are not the limiting facter here.

The switch is an HP 4108gl. Is this performance pattern consistent with a buffer overload scenario? I believe the buffers on this switch are pretty small, like 1MB.

My first thought is that the server is busy doing the work, and can't process both of them that fast.

Maybe both are accessing the same disk drive, and it takes many more disk seeks to respond to both.

-- glen

How far did you go in checking for a duplex mismatch?

Is that PowerEdge running Windows 2000 or Windows XP? I have seen Windows 2000 -lie- about the duplex that it negotiated: every level on the W2K server reported that the link was full duplex, but I happened to have a Fluke LanMeter with me and was able to show that it was half duplex that was being auto negotiated. We nailed the interface to full duplex / 100 at both sides and the performance problem immediately went away in that instance.

?!? Duplex mismatch would have been visible with just one client sending to the server. It wouldn't require both sending at once.

Having said that, it _would_ be good for Chris to check statistics everywhere possible - TCP level on clients and servers (eg netstat) link-level statistics on clients and servers (OS specific) and swtich stats.

I would say packet losses, _possibly_ from duplex, but could be other things.

rick jones

35 MB/s is only 280 Mb/s. We can assume there is no great latency in the circuit as no WAN or long distance link was mentioned, just a single gigabit switch. In a follow-up the poster said Mac G5; I wouldn't think those would have any problem transmitting more than 280 Mb/s. The Dell PowerEdge 1850 I'd have to investigate the architecture of.

Anyhow, there is the possibility that there is -already- some duplex problem just with a single client; the effect is possibly being reduced with SAK.

When both clients are going, there are more ACKs coming back, and more duplex clash opportunities. -Maybe- even a reduced window size relative to the single client.

Mind you, I would ask about the quality of the gigabit switch, the number of ports, and which device is plugged into which port. If it has more than 5 ports, it probably has more than one gigabit chip in it, and greater throughput might -potentially- be achievable by redistributing the connections so that the big transmitters (the clients) are on differerent chips (thus different buffers.)

Without a Fluke Lanmeter, is there any way to know 100% for sure what the Win2K machine is negotiating?

Modulo the default socket buffer size(s) under Mac OS X... To take file systems out of the equation it might be good for the OP to run some netperf and play around with socket buffer/window sizes.

rick jones

In article , Chris McFarling wrote: [snipping the attribution for my words... tsk tsk]

Try the other approach: nail the interface speeds and see what happens.

However, you mentioned that this is gigabit ports; autonegotiation of some parameters is mandatory for gigabit (that is actually being used as gigabit.) The extent to which you can lock down the ports to particular speeds or duplexes might be limited.

Let's see... if you were to lock the ports to 100/Full then you'd have 12.5 MB/s of bandwidth going in to the PowerEdge, share that equally between two systems and the average would be about 6 MB/s each, which by coincidence is the same figure you mention achieving now. It'd be an interesting test, to lock both to 100/Full and see if you get the 6 MB/s each...

I think that is a managed switch. If so you can telnet into it and see what the error counts look like. Then check out the various other details and stats on the ports. Plus you can see what the switch is connecting at and the G5s are doing. On the G5s look under the last tab on the network control panel for the Ethernet port on the Network System Preference.

6 MBytes/s (I assume MB/s was for MegaBYTES not MegaBITS) is 48 Mbps - barely idling for a gigabit link, and should not be much of a challenge for any modern server.

I would, as several other posters already have, say duplex mismatch - except that doesn't happen at gigabit (yes, there IS a half duplex standard, but no one has made any half duplex equipment).

If you are measuring this performance with file copies some filesystems can suffer severe performance degradation under moderate congestion (Microsoft SMB definitely can, NFS also, possibly others).

I would NOT assume the workstations ard server are not to blame. Switch buffers could be.

And also wrote:

How have they been "checked"?

The 4108 is only capable of gigabit on the three transceiver ports or if you have added additional modules (the 72 ports on the 3 J4862B modules are 10/100 only). How are your machines connected to the

4108?

You couldn't get 35 MBytes/s through a 10/100 port, but OS and filesystem issues (caching) could mis-lead you into thinking you are.

6 MBytes/s each is 96 Mbps for two machines, just about what you can get from a 100 Mbps link.

The 4108 is managed so I would check it and see what speed/duplex it thinks the ports are running at and compare that to what your machines say. Also check for any error counters (collisions, fragments, FCS errors, etc.). You can take disk and filesystem questions out of the equation by running a synthetic benchmark like netperf.

OK, since this is a Mac is this speed based on Finder copies or something else. The Finder isn't all that optimized for speed.