I noticed that if I have a interface hard coded at 100Mbps FD on both the device and the switch throughput caps at ~30Mbps. If I set them to auto/auto I get whatever the wire rate is. I've found this on both older and newer versions of switch firmware connecting to a few different manufacturers devices (Mimosa, Mikrotik, Ubiquiti, Cisco). Flow control off or on makes no difference. No errors show on the switch port.
Why is this?
30Mbps Throughput on 100Mbps Hardcoded
-
SemperFi - Member
- Posts: 30
- Joined: Sat May 02, 2015 4:39 pm
- Location: Ontario
- Has thanked: 0 time
- Been thanked: 0 time
-
sirhc - Employee
- Posts: 7421
- Joined: Tue Apr 08, 2014 3:48 pm
- Location: Lancaster, PA
- Has thanked: 1609 times
- Been thanked: 1326 times
Re: 30Mbps Throughput on 100Mbps Hardcoded
All switching functions are handled in the switch core. This would not change from one version of the firmware to the next.
People who manufacture switches use "Switch Cores" which is why we say the switch can handle NON BLOCK LINE SPEED which means the switch core is designed to allow all ports to pass full line speed at all times. The CPU and Memory stats you see on the Device/Status TAB is simply the little tiny MIPS24K CPU that is used to run the CLI/UI and Daemons of the switch and has NOTHING to do with switch load other than possibly a broadcast storm which the Linux shell running the CLI/UI/Daemons intercepts broadcast, BPDU, and other special packets to control auto configuration of the core for things like LACP/MSTP and such.
We use the VSC-7427 switch core and UBNT used Broadcom.
Netiter UBNT nor Netonix writes the code in their respective switch cores we simply write the UI, and other features like our watts metering, passive POE control, SNMP Daemons and such.
It is common knowledge in the IT world that you should never hardcode speed duplex on Ethernet devices (Google the subject and read and learn why in more detail) as you are locking the modulation rate which means if errors occur on the line the packets are simply dropped instead if AUTO where the link would modulate down during events on the line.
A simple analogy would what happens if you hard code the speed duplex on a wireless link to stay 130/130 and not let the radio modulate down, your throughput would SUCK unless you had perfect LAB environment with no noise. Same thing with Ethernet communications.
People who manufacture switches use "Switch Cores" which is why we say the switch can handle NON BLOCK LINE SPEED which means the switch core is designed to allow all ports to pass full line speed at all times. The CPU and Memory stats you see on the Device/Status TAB is simply the little tiny MIPS24K CPU that is used to run the CLI/UI and Daemons of the switch and has NOTHING to do with switch load other than possibly a broadcast storm which the Linux shell running the CLI/UI/Daemons intercepts broadcast, BPDU, and other special packets to control auto configuration of the core for things like LACP/MSTP and such.
We use the VSC-7427 switch core and UBNT used Broadcom.
Netiter UBNT nor Netonix writes the code in their respective switch cores we simply write the UI, and other features like our watts metering, passive POE control, SNMP Daemons and such.
It is common knowledge in the IT world that you should never hardcode speed duplex on Ethernet devices (Google the subject and read and learn why in more detail) as you are locking the modulation rate which means if errors occur on the line the packets are simply dropped instead if AUTO where the link would modulate down during events on the line.
A simple analogy would what happens if you hard code the speed duplex on a wireless link to stay 130/130 and not let the radio modulate down, your throughput would SUCK unless you had perfect LAB environment with no noise. Same thing with Ethernet communications.
Support is handled on the Forums not in Emails and PMs.
Before you ask a question use the Search function to see it has been answered before.
To do an Advanced Search click the magnifying glass in the Search Box.
To upload pictures click the Upload attachment link below the BLUE SUBMIT BUTTON.
Before you ask a question use the Search function to see it has been answered before.
To do an Advanced Search click the magnifying glass in the Search Box.
To upload pictures click the Upload attachment link below the BLUE SUBMIT BUTTON.
-
SemperFi - Member
- Posts: 30
- Joined: Sat May 02, 2015 4:39 pm
- Location: Ontario
- Has thanked: 0 time
- Been thanked: 0 time
Re: 30Mbps Throughput on 100Mbps Hardcoded
This is in a lab environment with factory Cat6 jumpers. And I was just curious as to why is it consistently 30Mbps on a 100Mbps interface if both ends are hard coded. Was wondering if anyone had any insights. Guess not.
And back in the day we used to have to hard code everything BTW because interop sucked. Granted that was a few decades ago.
And back in the day we used to have to hard code everything BTW because interop sucked. Granted that was a few decades ago.
Re: 30Mbps Throughput on 100Mbps Hardcoded
10-30 Mbps on a 100 Mbps port could be a duplex mismatch. I have seen speedtests in this range several times with duplex mismatch.
Is the link hardcoded to use full duplex at both ends or is one end possibly configured to autonegotiate and just advertise full duplex?
If one end is forced and the other end is auto, the auto end might not get a response when negotiating and fall back to half duplex. The FD end will happily send frames even when receiving, but when the HD end is sending and see incoming traffic, it will stop mid frame. The HD end will report collisions, while the FD will report CRC errors (it does not know there is a duplex problem and just sees incomplete frames).
Check error counters.
Is the link hardcoded to use full duplex at both ends or is one end possibly configured to autonegotiate and just advertise full duplex?
If one end is forced and the other end is auto, the auto end might not get a response when negotiating and fall back to half duplex. The FD end will happily send frames even when receiving, but when the HD end is sending and see incoming traffic, it will stop mid frame. The HD end will report collisions, while the FD will report CRC errors (it does not know there is a duplex problem and just sees incomplete frames).
Check error counters.
4 posts
Page 1 of 1
Who is online
Users browsing this forum: No registered users and 42 guests