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.
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.
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
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
BTW, I opened a PR for my SFP copper fixes for rtl930x too since it is starting to look good enough for me:
Thank you, moar daata for my home-assistant
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.
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
Got 3 SFP today. Tested on a BPI R4 (as my Onti seems to be taking a sail boat or something):
- https://www.aliexpress.com/item/1005002636459209.html?spm=a2g0o.order_list.order_list_main.23.20dd18028Hc7oz supports DDM and pretends to be a 10G fiber SFP. Can't properly test it (lacking another 10gbase-t port for not) and it does weird things on 2.5gbit (it works, downstream at 2.5gbit but upstream clocks in at almost exactly 1000mbit (?), I tried with another 2.5gbit device on the same switch, that one reliably does 2.5gbit symmetric).
- https://www.aliexpress.com/item/1005007031904753.html?spm=a2g0o.order_list.order_list_main.29.20dd18028Hc7oz does not support DDM, reports as 1000BASE-LX
- https://www.aliexpress.com/item/1005007128485925.html?spm=a2g0o.order_list.order_list_main.17.20dd18028Hc7oz does not support DDM, reports as 1000BASE-SX (but at 4.40 USD I won't complain too loudly)
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.
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.
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
Edit: Removed my misreading of diff syntax.
Also, there is a spelling mistake in the patch name: "therNal" vs "therMal".