Support for RTL838x based managed switches

Could be that the SFP manufacturer didn't want to test anything besides 10G, therefore only claimed 10G support.
A lot of the product descriptions lack details on support for DOM/DDM and 1G/10G rates, plus the model number is often practically the same, I think SFP-10G-TS80 appears as a model from several different vendors.

Or to maximize compatibility (and therefore minimize potential refunds/returns). Many switches on the market support 10G and nothing else in their SFP+ slots, so SFP+ vendors will likely disable link speeds that would cause the PHY to try talking to the switch at anything else than 10G.

Yes, my SKS-8300X lists the following confusing line on the product page:

Backward compatible with 1000M/2.5Gbps transmission rate;

10Gbps SFP+ optical modules are required,

So which is it?

1gig SFPs work fine, assuming my Onti ONT-S508CL-8S is identical to the Xikestor SKS-8300X. The Linux sfp and phylink system negotiates different interfaces as required, calling the rtl93xxx driver hooks to configure the mac.

Notice how a 10gig copper, and 1gig fibre and 1gig copper all end up using different interfaces for the mac<->phy link:

[141355.058564] sfp sfp-p8: module FS               SFP-10G-T        rev      sn F2220644072      dc 220824  
[141361.904062] phylink_sfp_set_config: rtl83xx-switch switch@1b000000 lan8: requesting link mode inband/10gbase-r with support 00,00000000,00018000,0008706c
[158907.322969] sfp sfp-p1: module FiberStore       SFP1G-SX-85      rev      sn D87B2312464      dc 171202  
[158907.916151] phylink_sfp_set_config: rtl83xx-switch switch@1b000000 lan1: requesting link mode inband/1000base-x with support 00,00000000,00000200,00006440
[158920.484366] sfp sfp-p5: module OEM              GLC-T            rev B    sn M0312A804        dc 130823  
[158921.999615] phylink_sfp_set_config: rtl83xx-switch switch@1b000000 lan5: requesting link mode inband/sgmii with support 00,00000000,00000200,000062ff

This is completely automatic. The mac just switches to an interface supported by the SFP.

Not sure about 2.5gig SFPs. Don't have any. And the interface is a bit more obscure. And my 10GBase-T SFP doesn't switch interfaces when changing speeds. It is always running 10GBase-R even when the link is 100Base-TX.

3 Likes

Did some more research on 10gbase SFPs. According to https://forums.servethehome.com/index.php?threads/10gb-sfp-rj45-100m.45817/page-2 the 80m ones from https://www.aliexpress.com/item/1005006875162404.html run decently cool and at 30ish USD the premium over 30m ones is quite ok I would say....

There are also 100m ones around but with pricing higher than the entire 8port switches (https://www.aliexpress.com/item/1005008119459901.html being the possible exception at 50ish USD) and some claim them to be simply better binned chips so probably little actual difference to the 80m ones.

FWIW Onti themselves have 80m ones but at 50ish USD.

1 Like

Ouch. This one doesn't seem to actually work now that I finally tried it with something in the other end. Should have tested that before instead of just assuming that recognized is good.

sgmii configuration issue, maybe? Don't know how well the driver is tested with that? My guess is not at all. I remember we spent some time trying to get this to work properly on the rtl8380

I've ordered a couple of 80m 10Gbase-T SFP+ and a couple of 1Gbase-T SFP, both with DDM, for testing.
Used the link that @buz posted, good price; now to see if they work!

Let us know how it works (particularly interested in sub-10G support, too) - I am still waiting for the switch itself (and a bunch of cheapo SFP)...

I also have a couple of those on a slow boat somewhere. Hopig they get here before the estimated March 3rd

Sort of "fixed" my sgmii issues by simply adding tests for PHY_INTERFACE_MODE_SGMII wherever we have PHY_INTERFACE_MODE_1000BASEX in the rtl930x code. Pretty sure we also need some idea about inband management and auto negotiation, but this is enough to make my 1000Base-T SFP work for now.

There's so much duplicated and "magic" code scattered around here that I have no idea how it all works. The fact that most of this code is in drivers/net/phy/rtl83xx-phy.c makes so little sense to me that I am sure I do not understand the design.

I've force updated my WiP branch in case someone wants to look/test: https://github.com/bmork/openwrt/tree/realtek-rtl93xx-fixes

4 Likes

Hi all,
please excuse if that has been mentioned before, but will a plain 10G-SR SFP+ transceiver now work in a XGS1250 oder XGS1210 now with the version in realtek-rtl93xx-fixes (or any better version)?
BR
Michael

I believe that should work without any fixes. Doesn't it? My fixes are mainly related to copper SFPs, when they're not disguising as fibre SFPs

for me, this PR fixed the spf+ functionality for DAC cables and some mixed 10G optical modules

The high temperature measurements made me revive my thermal driver, and experiment with thermal zones for the SFP slots:

Tested and working on both Zyxel GS1900-10HP and XikeStor SKS8300-8X (Onti ONT-S508CL-8S).

root@gs1900-10hp:~# grep . /sys/class/thermal/thermal_zone*/t???
/sys/class/thermal/thermal_zone0/temp:23000
/sys/class/thermal/thermal_zone0/type:cpu-thermal
/sys/class/thermal/thermal_zone1/temp:11008
/sys/class/thermal/thermal_zone1/type:sfp-thermal
root@s508cl:~# grep . /sys/class/thermal/thermal_zone*/t???
/sys/class/thermal/thermal_zone0/temp:72000
/sys/class/thermal/thermal_zone0/type:cpu-thermal
/sys/class/thermal/thermal_zone1/temp:58906
/sys/class/thermal/thermal_zone1/type:sfp-thermal
/sys/class/thermal/thermal_zone2/temp:78488
/sys/class/thermal/thermal_zone2/type:sfp-thermal
/sys/class/thermal/thermal_zone3/temp:108906
/sys/class/thermal/thermal_zone3/type:sfp-thermal

Yes, those temperatures are all real. The GS1900 is in my garage without any heating. And tz3 on the Onti switch is the AQR113C internal sensor. It gets that hot after a while on a 10gig link. It's more usable on 5gig or 2.5gig. Just running it on 10gig for temperature testing - trying to hit a critical trip point :wink:

BTW, I opened a PR for my SFP copper fixes for rtl930x too since it is starting to look good enough for me:

5 Likes

Thank you, moar daata for my home-assistant :slight_smile:

Just a quick Q: Does this read temps from the SFP modules? or the actual slots, even if empty?
Am going to compile some new snapshots later today, but can't reboot my Switches with SFP-slots until later this WE.

1 Like

No. The driver only reads the SoC internal temp sensor.

The additional SFP thermal-zones will use whatever SFP sensors are already monitored. It doesn't add any new sensors. So still nothing for empty slots or SFPs without DDM.

Not sure how useful the SFP thermal-zone thing is. More of an experiment. It should shutdown the switch if one of the SFPs is overheating. Could also be used to control active cooling devices, but I don't know if that's relevant for SFP slots in any switch.

Note that it creates a thernal-zone for every SFP temperature sensor. I.e. two zones for my 10GBase-T in slot 8, since it has both an SFP sensor and a phy sensor. Not very logic. I expected multiple sensors per zone, but it doesn't seem to work that way

1 Like

Got 3 SFP today. Tested on a BPI R4 (as my Onti seems to be taking a sail boat or something):

Interested in how you are gathering temperature data, I've been using zabbix with a script to scrape hwmon but it's a heavy install for OpenWRT and only sensible on larger x86 boxes.

1 Like

I wrote a small sh-script instrumenting mosquitto_client (linked somewhere above in this thread), that runs on the Openwrt device, and reports POE data, and allows to control power/link on the LAN ports. It send MQTT discovery messages, so everything is plug and play.
I was planning to add the temperature data in there, and clean it up a little (maybe this weekend, but it's valentines day, so my GF might object...).
In essence, this script turns a POE switch into a power-monitoring multi-plug.

3 Likes

I have not really done it yet, but intuitively I would try to wire up collectd and mqtt and lo and behold, https://github.com/lukdwo/OpenWRT-collectd-MQTT-HA

Will give it a shot tomorrow. The utility of it is a bit dubious, but hey, moar data :joy:

1 Like

Edit: Removed my misreading of diff syntax.

Also, there is a spelling mistake in the patch name: "therNal" vs "therMal".