We are using 3 Server 2008 servers in an Hyper-V setup.
they are equiped with Intel 82576 gigabit nic's (ad onn card) and onboard Intel 82574L dual nic.
They connect to an iscsi storage unit.
when we enable jumbo packets (9014) on the machines to improve the speed it works for 2 of the machines, but on the 3th the speed drops from 85mega byte per second to 300kilo byte per second. This is to the Iscsi server (nexenta) and when we transfer a file (iso) from one node to another.
At the moment everything is running on the frame size of 4088, and that is running fine, but i would like to know some next stepts to solve this 'problem'
No one thing jumps out at me, but the description at first glance seems like an issue where one link partner cannot handle the larger frame size. Is the slow connection with the large jumbo frames related to a particular port? Is that port on the connecting switch possibly configured differently?
Are the NIC ports teamed?
If you are sure the configuration for everything is the same and if you are concerned about the driver for the NIC, you could try completely uninstalling the Intel Network Connections software including the base drivers. Then do a clean software install. That should clear out registry settings as well as replacing all the files for the NICs.
How does the overall transfer rate compare on the machine with the 9014 jumbo frames to the machine with the 4088 jumbo frames? If the performance is similar, you might consider keeping the 4088 frame setting.
We have 3 identical machines (only the first witht he problems is 'older' then the other 2)
All the testing is over the same switches with jumbo packets enabled, We dont team the nic's.
every server has an total of 6 NIC's connected to 2 switches.
2 for management / live migration.
2 for ISCSI with Microsoft MPIO to our nexenta storage
2 in an High Available Failover team, providing the connections for the virtual machines.
Also, as far as my knowledge goes, i believed that when one link partner doesnt allow the jumbo packets it would negotiate an size that suits both...
that makes this so strange.
At the moment we runn them on 4088 size, but i was searching for some more clue's, mabye this will give us more problems in the future, but at the moment it isnt an priority anymore.