Motorcomm YT8821 on SFP module

Banana Pi Router design
28

This is cool! Is this tool available for experiments?

29

The tool does just that now :wink:

30
31

Any news about this?

32

I have no news on the yt8821 nor the sfp module.

33

I noticed that some modules seems to fail to work without rollball quirk on current openwrt snapshot, any idea about it? @ericwoud

34

For Rollball it is a fixup, not a quirk.

Do you have a YT8821 module or a rtl8221b? This is the topic for the YT8821.

Maybe this for the rtl8221b:

But I do not use openwrt myself.

35

My module is rtl8221, and they are also 8221… That’s the weird thing,

Edit: found the problem, wrong br.nominal value settings

36

Hello, I would like to ask if that change would be helpful to improve sfp with motorcom chipset

37

Hi Dan,

We were not successful communicating with the phy on the sfp module at all. The author of the yt8821 driver has hardwired an yt8821 to the BPI-R3, he did not use a RollBall sfp module.

Perhaps Marek has made some progession, I do not know.

1 Like
38

Hey, Stupid question: is it possible to change somehow the SFP module that would be recognized not as OEM but that it contains yt8821? Another question: do you have also an issue with upload on that module? Is it possible somehow to improve usage of that module? On the BPI-R4, when I connect to the WAN interface, I have 940/940Mbit, but which SFP with yt8821 it is just 900/550Mbit

EDIT: I tried to change the module name from OEM to something else, like:

curl -LO https://github.com/ericwoud/i2csfp/releases/download/aarch64/i2csfp
chmod +x i2csfp
./i2csfp /dev/i2c-3  eepromfix -V OEM -N SFP-2.5G-T

Seems to be recognized same as earlier. If changing SFP module name can help, I will move discussion to another thread ([BPI-R4] and SFP or I2csfp - sfp debugging via i2c)

EDIT: For those who read and don’t know what to do, first you need to find a password to be able to change the value (via bruteforce). If you are lucky, no bruteforce would be needed.

39

Just changing the name will not help.

You could try fiddling with ethtool --pause parameters, see if any options will improve the speed.

40

Maybe it is not needed. Probably my ISP got some troubles. Today bandwidth seems to be normal. Sorry for the noise.

Edit: speed for upload is like 80% what I have on wan

41

Try testing it with a local connection using iperf3

42

Just curious: what system are you using? Normally you should also be affected (I mean if you are using OpenWRT). By disabling sqm, I got 40% of the maximum upload bandwidth.

43

Archlinux Arm on BPI-R3 mostly

44

So definitely there is an issue with YT8821 and OpenWRT Snapshot (24.10) that is working on kernel 6.6.

For connection LAN<->WAN (network 1/1 Gbps, HW offload), I have 940/938Mbps (so it is correct).

For connection Wireless<->WAN(network 1/1Gbps, HW offload, WO disabled, AX, 160Mhz, 5GHz), I have 860/210Mbps (where testing network via iperf3 or librespeed-go that is running on the BPI-R4, for local connection I have 1640/1100Mbps, so definitely it is not wireless issue).

To get better performance, I can enable SQM with fq_codel + piece_of_cake, then the results are 908/730Mbps. I have done many speed tests, many tests even for dedicated servers - each time results are same.

So when I switch back to use port WAN (not sfp one), results are 915/890Mbps. I just want to share the results with others. Maybe it will help someone to avoid buying SFP with that chipset (for now).

EDIT: Found temporary “solution”: enabling flow control (ethtool -A eth2 rx on tx on) seems to improve upload, but download goes slower - I can accept that. Finally results after enabling flow control: 850/940Mbps

To make flow control enabled after upgrade:

cat <<EOF > /etc/rc.local
if ethtool -a eth2 | grep -i rx | grep -q off; then echo "Setting flow control..."; ethtool -A eth2 rx on tx on; ip link set eth2 down; sleep 2; ip link set eth2 up ; fi
exit 0
EOF
45

after the last major netifd update. flow control for sfp can be set using the network config file. cleaner.

config device                          
        option name 'eth2'                        
        option rxpause '1'             
        option txpause '1'
1 Like
46

Will do a test, thanks @glassdoor ! Should it be added into official wiki?

EDIT: Wiki updated.

EDIT: Just to leave someone a final solution:

  • I added into the /etc/rc.local
ethtool -s eth1 speed 1000 duplex full; ip link set eth1 down; ip link set eth1 up
ethtool -s eth2 speed 1000 duplex full; ip link set eth2 down; ip link set eth2 up
  • I added into the /etc/config/network:
(...)
config device
        option name 'eth1'
        option rxpause '1'
        option txpause '0'
        option autoneg '0'

config device
        option name 'eth2'
        option rxpause '1'
        option txpause '0'
        option autoneg '0'
(...)

Why txpause is set to 0:

root@BPI-R4:~# ethtool eth1
Settings for eth1:
        Supported ports: [ FIBRE ]
        Supported link modes:   2500baseX/Full
                                2500baseT/Full
        Supported pause frame use: Symmetric Receive-only    #### BECAUSE HERE IS AN ANSWER
        Supports auto-negotiation: No
        Supported FEC modes: Not reported
        Advertised link modes:  2500baseX/Full
                                2500baseT/Full
        Advertised pause frame use: Symmetric Receive-only    #### BECAUSE HERE IS AN ANSWER
        Advertised auto-negotiation: No
        Advertised FEC modes: Not reported
        Speed: 2500Mb/s
        Duplex: Full
        Auto-negotiation: off
        Port: FIBRE
        PHYAD: 0
        Transceiver: internal
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
        Link detected: yes

And now speeds are good as normally connected to WAN/LAN port.

47

imho no harm setting txpause to 1

if you see eth0 which is autoneg, both rx and tx pause are also set to 1 when it is symmetric receive-only. for that matter look at lan0-3 same as well. autoneg will set both rx and tx pause to 1.