Unable to get full through-put on HP port trunk

[Scott Peron]

Hi all,

I've got a situation here for which I'm at a bit of a loss.

We have two switches, a 2810-48G and an older 4000m.  The 2810 is located in our server room, and the 4000m is in our wiring closet to serve the wall jacks of our office.  The 4000m has been filled out to have 8 10/100Mbit cards 8-port , and 2 1Gbit port cards.

To tie the two switches together, I've set up the 2 1Gbit ports on the 4000m as an HP port trunk, and assigned two ports on the 2810-48G to also be trunked together (also using an HP port trunk).  Cabling wise, it's two 30' CAT 5e cables doing the job.

Now this setup works.  However, it seems that 1 100Mbit connection going flat-out on either of the two ports of the trunk seems to fully utlilize that line (so say someone is copying a massive amount of data from a server to a workstation, that half of the trunk is fully used).  Which I don't understand, it's 1Gbit link, yet a 100Mbit connection seems to saturate it.

I'm not sure how to correct this.  Any thoughts?

[Scott Peron]

Just to add:

Both switches show the ports as up and running at 1000FDx, Flow control is off.  No VLANs are involved. 

[scifan3]

Trunks are load balanced based on mac addresses... depending on your test source and test destination, it may be impossible to fully utilize both ports.

I don't remember is the 4k a non-blocking switch?  (those are pretty old...)

[Scott Peron]

It's not a question of load balancing.  It's a situation where either of the two lines in the trunk seems unable to carry more than 100Mbit of traffic, even though it's a 1Gbit link.

This means that another source and destination even (say another desktop, trying to talk to another server), where if it crosses on the same link, gets bogged down, because the link behaves like it's 100% utilized.

E.g.

Desktop A is pulling 150GB of data off Server B

Another user, on Desktop C, tries accessing something on Server D, just happens to use the same port on the trunk as the first connection, and gets completely bogged down. 

The desktops are all 100Mbit connections, each link in the trunk is 1GBit.  To my thinking, there's no reason why each link in the trunk can't handle 10 such connections going flat out, at least.

[scifan3]

You could try using Iperf for your traffic test to rule out other factor's....

I should run a couple of tests to verify what I see across my gear... (I'm gig to the desktop back to a 10GB attached Hyper-V farm...)

I see this across my network:

c:\test>iperf -c cylon -t 60 -i 5

------------------------------------------------------------
Client connecting to cylon, TCP port 5001
TCP window size: 63.0 KByte (default)
------------------------------------------------------------
[300] local 10.2.1.211 port 53678 connected with 10.230.100.65 port 5001
[ ID] Interval       Transfer     Bandwidth
[300]  0.0- 5.0 sec   557 MBytes   934 Mbits/sec
[300]  5.0-10.0 sec   538 MBytes   903 Mbits/sec
[300] 10.0-15.0 sec   558 MBytes   936 Mbits/sec
[300] 15.0-20.0 sec   512 MBytes   859 Mbits/sec
[300] 20.0-25.0 sec   554 MBytes   929 Mbits/sec
[300] 25.0-30.0 sec   560 MBytes   939 Mbits/sec
[300] 30.0-35.0 sec   555 MBytes   930 Mbits/sec
[300] 35.0-40.0 sec   558 MBytes   937 Mbits/sec
[300] 40.0-45.0 sec   558 MBytes   937 Mbits/sec
[300] 45.0-50.0 sec   559 MBytes   937 Mbits/sec
[300] 50.0-55.0 sec   559 MBytes   937 Mbits/sec
[300] 55.0-60.0 sec   559 MBytes   938 Mbits/sec
[300]  0.0-60.0 sec  6.47 GBytes   926 Mbits/sec

See what you can get and post the results... also look for errors in both of your event logs. 

[Richard Brodie_1]

What do the individual interface statistics look like on the trunk links?

Also you could try pulling each of the links in turn to see if the problem is specific to one link. Or even temporarily reconfiguring as plain links.