That’s a good observation and it touches on a key difference between the 1G ports and the 10G ports on UbiSwitch.
Before getting into that, it’s helpful to clarify the difference between a PHY and a MAC in Ethernet.
MAC vs PHY difference
The PHY (Physical Layer transceiver) handles the low-level details of data transmission, things like copper vs. optical signaling, link speed, voltage levels, etc. It sits at the “bottom” of the stack, directly interfacing with the physical network.
The MAC (Media Access Control), on the other hand, sits above the PHY and handles higher-level data framing. The MAC is generally agnostic to the PHY* (*not always, but this is typically the case).
Together, the MAC and PHY form a complete Ethernet port. Historically, most Ethernet switch chips exposed MAC-only ports, requiring an external PHY per port. This actually offers flexibility, since you can choose different PHY types (e.g., copper vs. fiber). However, since most applications today use standard copper Ethernet (10/100/1000BASE-T), switch vendors began integrating PHYs directly into the switch chip.
How UbiSwitch is constructed
In the case of UbiSwitch, the chip has 8 × 1G ports with embedded PHYs. This means both the MAC and PHY are inside the chip, and both can be configured via our software (which is why you see configuration options for those ports).
The 10G ports, however, are MAC-only. They are intended to connect to an external PHY to form a complete Ethernet port. On the UbiSwitch BaseBoard, these MAC ports are routed to SFP ports, and the PHY resides inside the SFP module.
This is why you can’t configure PHY-level settings on the 10G ports, the switch chip itself has no direct control over the PHY. As a result, our software doesn’t either.
In principle, we could add functionality to communicate directly with the SFP module to influence its behavior. However, most 10G RJ45 SFPs rely on auto-negotiation and don’t support forcing a fixed speed (like 2.5G). While our software can communicate with SFPs, this is currently limited to reading status information.
Because of this, SFPs typically negotiate to the highest supported speed, and forcing them to operate at 2.5G isn’t generally possible.
How this could be possible
To enable that kind of control, the hardware would need to change, specifically, replacing the SFP-based design with onboard PHYs. We actually offer a board like this: UbiSwitch BaseBoard 10G. This version integrates 10G PHYs directly on the board instead of using SFPs.
In theory, this would allow our software to directly control the PHY and potentially limit it to 2.5G. In practice, we haven’t implemented that functionality yet, and it’s not currently on our roadmap (though I’d be interested to hear more about your use case for this).
The goal of the UbiSwitch BaseBoard 10G was to reduce size and power consumption for 10G copper deployments. In fact, UbiSwitch + UbiSwitch 10G BaseBoard is one of the most compact and low-power ways to achieve a 38 Gbps aggregate data rate.
Let me know if that helps clarify things, also curious to hear more about your use case and why a 2.5G cap is important.