This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
Surprisingly slow throughput on GigE ports of GS110EMX
I have a pair of NETGEAR GS110EMX switches, one connected via port 10 to the 2.5Gbps port of an Orbi RBRE960 router, and the second connected "back to back" to the first switch through their 10Gbps ports (port 9 on each switch). The final high-speed port (10) is connected to a server PC with a 2.5Gb NIC card. Lots of other devices, including PCs, are connected to the 16 (8 x 2) remaining GigE ports.
I have a 2Gbps cable service through Xfinity and can reliably and repeatedly get >2Gbps to speedtest.net from the server PC with the 2.5Gbps LAN card. The problem occurs when I try to do a speed test through any of the GigE ports (1-8). Rather than getting close to 1000Mbps, I consistently get less than 300Mbps. Moving the same PC directly to the Orbi router's GigE port gives me 950Mbps, which is what you'd expect over a GigE port.
Has anyone run into this strange situation with the GS110EMX managed switch? I've tried changing several settings, including a factory default and installing the latest firmware (1.0.2.8), but am still capped at this surprisingly slow download speed on the GigE ports. Again, the 10Gb ports, negotiating a 2.5Gbps speed, work great -- really great.
Thanks for any suggestions or hints on how to get the most out of my pair of GX110EMX switches.
SOLVED: Surprisingly slow throughput on GigE ports of GS110EMX
Flow control! It was always FLOW CONTROL.
After GPTing around looking for a solution, I decided to try enabling port-based flow control on the upstream (10Gbps) port, thinking perhaps, as I mentioned above, that I was experiencing buffer overflows downstream to the GigE port. Sure enough, with Flow Control enabled on the higher speed interface, I'm now getting 960Mbps on the lower speed GigE port.
I really, really wish I'd have tried that before ripping the house apart, and purchasing another 8-port 10GigE switch. Ah well. Lesson learned. Hopefully this will help someone else out in the future.
<RANT>
Coming from a commercial networking world, I'm surprised and a bit disappointed that the NETGEAR switch just doesn't "work" out of the box. Perhaps with a 10:1 port speed mismatch, flow control is the only solution.
Has anyone run into this strange situation with the GS110EMX managed switch?
Hello Dave,
Have run in the past a lot of Beta testing, before the GS110EMX (and the GS810EMX aka. the Nighthawk SX10 Pro Gaming 10-Gigabit/Multi-Gigabit Switch) appeared in the wild Internet., never spotted such a massive performance impact. Still operating a GS110EMX here at home on a 10 GbE Uplink.
Let me allow one comment: This is in no aspect a managed switch, much more a switch built around an unmanaged switch core, extended with some uC to drive the NSDP (for both discovery and if enabled the L2 configuration protocol implemented in the ProSafe Plus Configuration Utility, and Web UI.
Have run in the past a lot of Beta testing, before the GS110EMX (and the GS810EMX aka. the Nighthawk SX10 Pro Gaming 10-Gigabit/Multi-Gigabit Switch) appeared in the wild Internet., never spotted such a massive performance impact. Still operating a GS110EMX here at home on a 10 GbE Uplink.
Thanks for the reply and confirmation about the abilities of the GS110EMX. It's a bit perplexing to me, because:
it's happening to both switches
10GbE (negotiated 2.5Gbps) → 10GbE (negotiated 2.5Gbps) works fantastically fast; almost to PHY limits
It's almost as if, by forwarding a 2.5Gbps stream to a GigE port, I'm overflowing some flow control or packet buffers, causing retransmissions and a low effective RX speed.
SOLVED: Surprisingly slow throughput on GigE ports of GS110EMX
Flow control! It was always FLOW CONTROL.
After GPTing around looking for a solution, I decided to try enabling port-based flow control on the upstream (10Gbps) port, thinking perhaps, as I mentioned above, that I was experiencing buffer overflows downstream to the GigE port. Sure enough, with Flow Control enabled on the higher speed interface, I'm now getting 960Mbps on the lower speed GigE port.
I really, really wish I'd have tried that before ripping the house apart, and purchasing another 8-port 10GigE switch. Ah well. Lesson learned. Hopefully this will help someone else out in the future.
<RANT>
Coming from a commercial networking world, I'm surprised and a bit disappointed that the NETGEAR switch just doesn't "work" out of the box. Perhaps with a 10:1 port speed mismatch, flow control is the only solution.
Re: SOLVED: Surprisingly slow throughput on GigE ports of GS110EMX
The documentation on the switch is very clear.
Manage flow control Flow control works by pausing a port if the port becomes oversubscribed. It drops all traffic for small intervals of time during the congestion condition. You can enable or disable IEEE 802.3x flow control. By default, flow control is disabled.
Take it that enabling flow control per default is a bad advise. No unmanaged switch on this world does it, some poorly designed/implemented/tested switches fail filtering the pause (stop) frame, and are re-distributing it over all connected devices. According to my small experience, many systems on this planet (and up to the lower orbit) deployed in enterprise applications don't do flow control by default, (old DEC, IBM AIX, ...) regardless of the speeds supported - certainly not on Ethernet ports. Of course, enabling flow control on these switches makes sense in certain applications. Very different when it comes to the now more or less legacy serial consoles, where XON/XOFF is indeed the de-facto default. There I can strongly agree.
Manage flow control Flow control works by pausing a port if the port becomes oversubscribed. It drops all traffic for small intervals of time during the congestion condition. You can enable or disable IEEE 802.3x flow control. By default, flow control is disabled.
Yep, I know how flow control works, and that it was an option. I just didn't think the switch would not be able to handle the 10:1 packet forwarding by default, instead relying on the user having to enable 802.3x on all upstream higher speed ports. Flow control on all ports, all the time, is sub-optimal, but for a switch touted as being able to support 100Mbps all the way up to 10Gbps, you'd think it'd "just work".
