Ethernet speed

    Is it possible to slow down the ethernet port on the RPi4?

    I know it sounds a bit daft but I'm using powerline ethernet and my laptops / desktops have a 100MB port, most of my powerline adaptors are 100MB. My current setup with 2 RPi3s has a 100MB powerline adaptor with a 5 port 10/100 minihub. The RPi3s are about to be replaced with an RPi4 and I want to replace the 100MB adaptor & minihub with a 2 port 1GB adaptor. 1 port for the Pi and 1 port for the TV.

    With both TV & RPi4 plugged in the Pi (or possibly adaptor, router or mains wiring) doesn't play well at 1GB, lots of lost packets. So if I can slow the Pi down to the same speed as everything else the network may be good.

    I have a 6TB HDD plugged into the Pi so I'm happy with 100MB as network speed for the occasions I need to transfer files.

    Thanks - I shall experiment later on today.

    Its later on, and I've tested and its looking good. Using the cables supplied with the BT powerline adaptor I tried pinging - about 50% of packets lost. Typed in the magic command "ethtool -s eth0 speed 100 duplex full autoneg off" and no packets lost, plugged the TV in to the adaptor ping that and the RPi4 and ..... no packets lost.

    Now to add to autostart.sh and figure out how to remind myself to do it again if I have to reinstall.

    Edited once, last by LybsterKodi (December 2, 2022 at 8:26 AM).

    One minor problem - doesn't seem to cause any harm but now when I turn the Pi on I get

    remote communications server failed to start

    I've made sure wait for network is enabled and increased it to 30 seconds. Any thoughts / suggestions?

    1. autostart.sh is very late in the boot process and called after Wait For Network. You may consider an UDEV rule for eth0.
    2. Disabling autonegotiation may cause Duplex Mismatch. Better use ethtool -s eth0 advertise 0x008 to limit the connection speed.
    Quote from LybsterKodi

    I do not speak fluent Linux, but I'm learning slowly, so can you please explain. I googled UDEV and the answers I found were far to techie.

    Was afraid of such an answer :-). Have to test is myself later.

    Quote from LybsterKodi

    Using the cables supplied with the BT powerline adaptor I tried pinging - about 50% of packets lost.

    After reading this again: looks like using CAT5 cables or less for gigabit connection. At least CAT5e cables are required.

    Quote from mglae

    Was afraid of such an answer :-). Have to test is myself later.

    I'm glad its just not myself :)

    Quote from mglae

    After reading this again: looks like using CAT5 cables or less for gigabit connection. At least CAT5e cables are required.

    Way back I thought that was the problem. I bought a Cat6 cable - no better. BUT without the TV plugged in the connection worked at both 100MB and 1GB - no lost pings. As soon as I included the TV I started to loose pings so I've concluded that whatever the cause since everything works properly at 100MB that's what they will all do. I think I've only got 1 device (the RPi4) other than the BT adaptors that will run over 100MB anyway.

    I'm not sure what has caused it but now I can't ping the RPi4 at all. I tried plugging one of my laptops into the same powerline adaptor. Just unplugged the Pi and plugged the laptop in so using same cable, plug socket etc and it was fine.

    Rebooted the router and nothing.

    I'm going to try an install of the latest nightly.

    Quote from LybsterKodi

    I'm not sure what has caused it but now I can't ping the RPi4 at all.

    Hopefully not a broken RJ45 connector.

    Calling ethtool directly from udev is not working because the PHY needs to be UP. As work around I used a delay but this may not be bullet proof.

    Code: /storage/.config/udev.d/99-eth0-100mb.rules
    ACTION!="add", GOTO="end"
SUBSYSTEM!="net", GOTO="end"
ENV{INTERFACE}!="eth*", GOTO="end"

RUN+="/usr/bin/systemd-run --no-block --on-active=3 --timer-property=AccuracySec=100ms /usr/sbin/ethtool -s $env{INTERFACE} advertise 0x008"

LABEL="end"

    Yes, but you have to be careful with dependencies to not geting the same behavior as with autostart below.

    Adding ExecStartPost=... to connman service may be possible too.

    I did a clean install from the nightly and things seem to be working. I haven't yet reinstalled TVHeadend since I only have the one tuner device and its on the RPi3 and I haven't seen the "remote communications server failed to start" message again so I'm suspecting its TVHeadend that's causing it.

    Quote from LybsterKodi

    I did a clean install from the nightly and things seem to be working. I haven't yet reinstalled TVHeadend since I only have the one tuner device and its on the RPi3 and I haven't seen the "remote communications server failed to start" message again so I'm suspecting its TVHeadend that's causing it.

    What versions of LE did you tried? Did you tried to change the "Wait for network before starting Kodi" in LibreELEC settings?

    I don't know if what I experienced is the same.... Where I live probably because of old electrical grid, sometime we have 1 second power down. Sometimes 1-2 per day, sometimes without a single power down in a month. So, I had some kind of network issues after the short power down. Mostly with TVheadend, but in that case the weather app was not functional too. After a reboot always was functional again. That was when I used the LE 10.0.2 (3x RPi3). Tried to switch to Le11 nightly, increased the "wait-for-network" time (from 10 sec. to 120) in LibreElec settings. I think was something when the router wasn't back yet and the LE don't wait enough for network (?). Now I'm using the LE 10.0.3 stable with increased "wait-for-network" and looks like without network issue...

    Just in the case if any of these information useful for you...