Have you tried to enable EEE, it can be set via ethtool for each port? Especially when there is only a link and no traffic, the effect should be large.
To compare 28MP and GS308P (home use unmanaged 4poe 8ports switch) is like comparing a modern fighter jet with ww1 bi-plane!
- You have to understand the difference between PoE power and operational power.
- The fans are PoE power, not operational power.
- This is business class network equipment, it is made to sit in a cabinet and move data 24/7/365,25.
- Every standard PoE port have a 16,25W power budget on D-Link.
- 28ports, well don’t buy more than you need if your main concern is power budget, this detail is actually all there is to it.
According to the d-link datasheet.
28MP:
Pconsumtion poeon=424,8W
Pconsumtion poeoff=29W
Pstby=17,1W
10MP (fanless):
Pconsumtion poeon=148,7W
Pconsumtion poeoff=9,4W
Pstby=5,2W
So you actually use less power than the data sheet say for standby pwr, but I guess D-link specify the power with all ports connected.
“Boot pwr” is pretty worthless to look at since you only boot it once every upgrade of firmware. At least that is what it is designed to do.
(EDITED: I initially lied about the lan2 link - confused myself by changing things around. it does have eee, and I now turned it on).
Good point. Yes, the GS108Tv3 and the SG250-08 are both doing EEE. The SLM2008 is not dong EEE at all- assuming it's unsupported. As seen from the Cisco PoE switch:
GS108Tv3:
c3560cx#sh eee status interface Gi1/0/1
Gi1/0/1 is up
EEE(efficient-ethernet): Operational
Rx LPI Status : Received
Tx LPI Status : Received
Wake Error Count : 0
EEE Enabled (ASIC) : yes
Tx LPI Active (ASIC) : yes
Rx LPI Detected (ASIC) : yes
SLM2008:
c3560cx#sh eee status interface Gi1/0/3
Gi1/0/3 is up
EEE(efficient-ethernet): Disagreed
Rx LPI Status : None
Tx LPI Status : None
Wake Error Count : 0
EEE Enabled (ASIC) : yes
Tx LPI Active (ASIC) : yes
Rx LPI Detected (ASIC) : yes
SG250-08:
c3560cx#sh eee status interface Gi1/0/4
Gi1/0/4 is up
EEE(efficient-ethernet): Operational
Rx LPI Status : Received
Tx LPI Status : Received
Wake Error Count : 0
EEE Enabled (ASIC) : yes
Tx LPI Active (ASIC) : yes
Rx LPI Detected (ASIC) : yes
Good thing you asked, because this reminded me of a semi-serious bug I've been meaning to research and report but never gotten around to: Running ethtool --show-eee lan1 on the GS108Tv3 breaks networking completely, and it's dead until rebooted. This happens only with lan1, which is the PD port in case that matters.
This is how it looks like:
root@OpenWrt:/# ethtool --show-eee lan1
EEE Settings for lan1:
EEE status: enabled - active
Tx LPI: disabled
Supported EEE link modes: 100baseT/Full
1000baseT/Full
Advertised EEE link modes: 100baseT/Full
1000baseT/Full
Link partner advertised EEE link modes: 100baseT/Full
1000baseT/Full
root@OpenWrt:/# [3699674.824702] rtl83xx-switch switch@1b000000 lan1: Link is Down
[3699674.831440] switch: port 1(lan1) entered disabled state
[3699675.067970] rtl83xx-switch switch@1b000000 lan2: Link is Down
[3699675.074832] switch: port 2(lan2) entered disabled state
As you can see, the command seems to work. But it causes both active links to go down and stay down until reboot. Running the same command on other ports is fine (this is after a reboot with links restored).
I have no such problems with any of my ZyXEL GS1900 switches either. It's specifically only lan1 on the GS108Tv3:
Enabling EEE on lan2 takes the linke down and up (this is normal, but is it necessary?). Running show works fine:
root@OpenWrt:/# ethtool --set-eee lan2 eee on
[ 528.467044] Globally enabling EEE
[ 528.470774] Setting up EEE, state: 1
[ 528.474949] Enabled EEE for port 9
[ 528.478764] In rtl8218b_set_eee, port 9, enabled 1
[ 528.570513] rtl8218b_set_eee done
[ 528.578912] RTL8380 Link change: status: 1, ports 200
[ 528.604636] rtl83xx-switch switch@1b000000 lan2: Link is Down
[ 528.611165] switch: port 2(lan2) entered disabled state
[ 528.621446] rtl83xx-switch switch@1b000000 lan2: Link is Up - 1Gbps/Full - flow control rx/tx
[ 528.631975] switch: port 2(lan2) entered blocking state
[ 528.637928] switch: port 2(lan2) entered forwarding state
root@OpenWrt:/# [ 528.666628] rtl83xx-switch switch@1b000000 lan2: Link is Down
[ 528.673279] switch: port 2(lan2) entered disabled state
root@OpenWrt:/# [ 531.850796] RTL8380 Link change: status: 1, ports 200
root@OpenWrt:/# [ 532.828112] rtl83xx-switch switch@1b000000 lan2: Link is Up - 1Gbps/Full - flow control rx/tx
[ 532.837842] switch: port 2(lan2) entered blocking state
[ 532.843859] switch: port 2(lan2) entered forwarding state
root@OpenWrt:/# ethtool --show-eee lan2
EEE Settings for lan2:
EEE status: enabled - active
Tx LPI: disabled
Supported EEE link modes: 100baseT/Full
1000baseT/Full
Advertised EEE link modes: 100baseT/Full
1000baseT/Full
Link partner advertised EEE link modes: 100baseT/Full
1000baseT/Full
1 Like
I don't have a GS108Tv3, but I will test on a Zyxel GS1900-10HP, which also supports PoE. From a software point of view there is no interrelationship between PoE and EEE, the PHY is completely agnostic about PoE. @svanheule thanks for the link to the issue. I need to see whether I can also reproduce this on e.g. the GS1900-10HP.
Yes, I know. My assumption is that Netgear has done something weird with the hardware on that port. Testing with OEM firmware is on my list of things I should do when I get some time.
My GS1900-10HP switches are fine. But actually getting EEE up can be a bit cumbersome. There is something about the local/remote enable order which makes if fail a times.
This is a port on one GS1900-10HP connected to a Unifi 6 Lite (MT7621 with MT7530 switch running OpenWrt):
root@gs1900-10hp-f:~# ethtool --show-eee lan6
EEE settings for lan6:
EEE status: enabled - inactive
Tx LPI: disabled
Supported EEE link modes: 100baseT/Full
1000baseT/Full
Advertised EEE link modes: 100baseT/Full
1000baseT/Full
Link partner advertised EEE link modes: Not reported
This is the other end of that link:
root@u6-2:~# ethtool --show-eee lan
EEE Settings for lan:
EEE status: enabled - inactive
Tx LPI: 30 (us)
Supported EEE link modes: 100baseT/Full
1000baseT/Full
Advertised EEE link modes: 100baseT/Full
1000baseT/Full
Link partner advertised EEE link modes: Not reported
So enabled on both ends, but both ends claim the partner doesn't advertise it. Toggling on the Unifi 6 Lite makes no difference. But toggling on the GS1900 makes it work:
root@gs1900-10hp-f:~# ethtool --set-eee lan6 eee off
root@gs1900-10hp-f:~# ethtool --set-eee lan6 eee on
root@gs1900-10hp-f:~# ethtool --show-eee lan6
EEE settings for lan6:
EEE status: enabled - active
Tx LPI: disabled
Supported EEE link modes: 100baseT/Full
1000baseT/Full
Advertised EEE link modes: 100baseT/Full
1000baseT/Full
Link partner advertised EEE link modes: 100baseT/Full
1000baseT/Full
root@u6-2:~# ethtool --show-eee lan
EEE Settings for lan:
EEE status: enabled - active
Tx LPI: 30 (us)
Supported EEE link modes: 100baseT/Full
1000baseT/Full
Advertised EEE link modes: 100baseT/Full
1000baseT/Full
Link partner advertised EEE link modes: 100baseT/Full
1000baseT/Full
EDIT: Note BTW wrt the PD subject that the Unifi 6 Lite is powered by the GS1900-10HP. Which supports the claim that this is supposed to be completely unrelated.
I'm unable to do that. It consistently breaks on the GS108Tv3 but works fine on the GS1900-10HP. Which is why I suspect there is something about the hardware/wiring on the GS108Tv3. Possibly related to how Netgear does the PD stuff, even though it shouldn't make any difference?
1 Like
Strange that they both report the other side to not support EEE. It's as if both devices might have a bug.
for reference:
The DGS-1210-24P (its like the 28MP; but less power-budet) uses 9W after powerup w/o any devices atteched.
with 2 IP Cameras, 5 Wifi-APs, 1 nanopi4-Router (all connected over PoE) + 1 Vigor DSL modem (not over PoE, but same outlet) the total power consumptions
goes up to 65 Watts.
In comparision, the same setup, but the Ubiquity 24-port switch and its USG4 Pro-firewall consumed 85 Watts.
(This difference sums up to ~75 € / yr power-costs)
Hope this helps
You wish 
I see the exact same thing with a RPi4. EEE won't work until I toggle it off/on on the GS1900-10HP port the Pi is conncted to.
root@gs1900-10hp-f:~# ethtool --show-eee lan8
EEE settings for lan8:
EEE status: enabled - inactive
Tx LPI: disabled
Supported EEE link modes: 100baseT/Full
1000baseT/Full
Advertised EEE link modes: 100baseT/Full
1000baseT/Full
Link partner advertised EEE link modes: Not reported
root@gs1900-10hp-f:~# ethtool --set-eee lan8 eee off
root@gs1900-10hp-f:~# ethtool --set-eee lan8 eee on
root@gs1900-10hp-f:~# ethtool --show-eee lan8
EEE settings for lan8:
EEE status: enabled - active
Tx LPI: disabled
Supported EEE link modes: 100baseT/Full
1000baseT/Full
Advertised EEE link modes: 100baseT/Full
1000baseT/Full
Link partner advertised EEE link modes: 100baseT/Full
1000baseT/Full
RPI4 before the toggle
root@idefix:/tmp# ethtool --show-eee eth0
EEE settings for eth0:
EEE status: enabled - inactive
Tx LPI: disabled
Supported EEE link modes: 100baseT/Full
1000baseT/Full
Advertised EEE link modes: 100baseT/Full
1000baseT/Full
Link partner advertised EEE link modes: Not reported
and after:
root@idefix:/tmp# ethtool --show-eee eth0
EEE settings for eth0:
EEE status: enabled - active
Tx LPI: disabled
Supported EEE link modes: 100baseT/Full
1000baseT/Full
Advertised EEE link modes: 100baseT/Full
1000baseT/Full
Link partner advertised EEE link modes: 100baseT/Full
1000baseT/Full
The only common factor here is the GS1900.
1 Like
I'll look into this. I anyway wanted to work on EEE on the RTL93xx.
3 Likes
I can only partially reproduce your finding. When the remote side has EEE enabled and I bring up the switch, then turn on eee on the connecting port locally, then I get working EEE. However, if I then switch it off and on again locally, the remote EEE capability is no longer detected and consequently EEE disabled. I can fix this by toggling EEE on the remote end, but not on the local side.
To me this looks like the remote EEE capabilities are not always correctly identified, I need to dig more into this.
Another question: I am having difficulties offloading frame checksum calculation on the RTL93xx. I thought this worked for RTL83xx, but now I don't see them. Do you see these with wireshark for packets coming from the router? And why is it OK if packets do not have that at all?
I added complete image generation including mtdsplit and working sysupgrade to my HPE 1920 branch. This includes support for HPE 1920-8G/-16G/-24G/-48G, although only the 16G variant is tested so far, as I don't have any of the other devices. But at least the 24G model is also very likely to work, as it seems to use the same board.
Instructions for running an initramfs image from memory, as well as permanent installation are in the commit message.
For anyone trying this, it would be nice if you could check if the MAC address assignment matches stock firmware, as I'm not entirely sure if it is correct. You can get the interface MAC addresses and lots of additional information using these commands on stock firmware:
_cmdline-mode on # enable full command-line access
Jinhua1920unauthorized # password
display diagnostic-information
There are still a few things that need cleanup (but for testing this shouldn't matter):
-
The firmware-utils part obviously doesn't belong in this repository, but for now it is easier this way.
-
7z compression relies on the
7zcommand line tool being available on the build host. While the source of thelzmahost package includes code for 7z archives, the7zcommand line tool seems to be Windows-only in that old version. I don't really like the 7z command line tool anyway, as it doesn't provide a way to explicitly specify an unencoded header (as required by the bootloader). It looks like that just happens to be the default in some cases. But I'm also not sure what the alternative would be. -
A proper fix to avoid LED initialization in
arch/mips/rtl838x/setup.cis needed. I assume this is actually necessary for the system LED to work on other devices, so I don't know what a proper solution should look like?
1 Like
This is great work! I have to dig my HP devices out of the stack in my garage. I will try to find time to test the 1920-8G (JG922A) and 1920-16G (JG923A) that I have. I may also try to add support for the 1910-8 (JG537A) and 1910-24(JG539A) assuming that the stock firmware is similar to the 1920 series.
What if you connect/reboot a device on a switch port where EEE already is enabled (and possibly active)?
This is the most common use case for me, since I rarely reboot the PoE switches. And if I do, then all the powered devices will boot as well.... So the switch is running with EEE enabled and active. Then I reboot a device on one of the ports. And EEE fails until I toggle it off/on like shown.
I don't think I've ever seen the FCS when sniffing. Probably becasue I haven't tried or looked for it. According to Google/Stackoverflow, it's possible to disable FCS stripping on (some?) NICs: https://stackoverflow.com/questions/22101650/how-can-i-receive-the-wrong-ethernet-frames-and-disable-the-crc-fcs-calcul
I haven't tried that myself. I imagine the checksum has to be there on the wire, and be correct, or you wouldn't see any frame at all when sniffing. But as you know: This is likely driver dependent, and anything is possible...
Looking at the kernel code, I believe the rx-fcs gives you something similar to the vlan tags you see when sniffing - not really the bits from the wire, but a re-created view of those bits. Which is good enough for most purposes.
Ah, yes, this is something I see.
I have looked into the EEE code and it shows that some of it is from a very early time when u-boot code was used as reference for the drivers. Both in the linux kernel and in the available SDK things have become much cleaner. But it is quite complex with EEE being done in the MAC and PHY and I need a bit of time to clean this up. I hope I have something to test, soon.
You get to see it when it is wrong 
In that case the driver keeps it and it is made available in wireshark. I thought I had an issue on the RTL93xx hardware with the FCS not being calculated, but it turns out there was a different error. Mainly there was an assumption that 0 was not a correct port number in the CPU-tag: on the RTL83xx platforms, the ports usually start with 8 to 15 (PHY in SoC), 16 port switches then continue at 16 to 23, and only then are ports 0-7 being used. So here it was a rare error, but all the RTL93xx switches use port 0 for lan1. And that port is typically the one you run your tests with. What happens is that the CPU-tag is not removed from the packet and it is instead interpreted as the FCS, which made me think the RTL93xx switches were not able to calculate the FCS.
1 Like
Can you please explain how did you flashed XGS1210-12 on XGS1010-12?
I got one XGS1010-12, I connected with serial and I explored a bit both the RTK and Linux Shell
How did you flash the image? and which image did you flash?
I need only some hints and directions, not a full guide
Thanks you!
I did not flash the device, I merely run an initramfs. To flash I would follow this procedure:
Use a serial cable with the externally accessible serial connector and interrupt the boot procedurer pressing ESC. Then I usually do
RTL9300# # printenv
baudrate=115200
boardmodel=RTL8393M_DEMO
bootcmd=boota
bootdelay=5
ethact=rtl9300#0
ethaddr=00:E0:4C:00:00:00
ipaddr=192.168.2.118
ledModeInitSkip=0
loadcmd=tftpboot 0x84f00000 192.168.2.150:openwrt-realtek-rtl930x-zyxel_xgs1010-12-initramfs-kernel.bin
serverip=192.168.2.150
stderr=serial
stdin=serial
stdout=serial
RTL9300# # rtk network on
Enable network
RTCORE Driver Module Initialize
IOAL init
Hardware-profile probe (Forced profile: RTL9302B_8218D_2x8226_2xGE)
(RTL9302B_8218D_2x8226_2xGE)
Hardware-profile init
GPIO probe (unit 0): (found)
GPIO Init
Reset PHY gpio OK!
SPI init (unit 0) (type3)
SPI Master init
I2C probe (unit 0)
I2C init (unit 0)
RTL8231 probe (unit 0): (found)
RTL8231 init (unit 0)
NIC probe (unit 0)
Loader RTNIC Driver Module Initialize
IOAL init
RTK Driver Module Initialize
MAC probe (unit 0)
Chip 9302 (found)
MAC init (unit 0)
SMI protocol probe (unit 0)
PHY probe (unit 0)
Chip Construct (unit 0)
Chip Construct
Disable PHY Polling
PHY Reset
MAC Construct
Turn Off Serdes
Serdes Construct
PHY Construct
Turn On Serdes
Enable PHY Polling
Misc
PHY init (unit 0)
Mgmt_dev init (unit 0)
Please wait for PHY init-time ...
RTL9300# # run loadcmd
Using rtl9300#0 device
TFTP from server 192.168.2.150; our IP address is 192.168.2.118
Filename 'openwrt-realtek-rtl930x-zyxel_xgs1010-12-initramfs-kernel.bin'.
Load address: 0x84f00000
Loading: T T #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#############
done
Bytes transferred = 6866722 (68c722 hex)
RTL9300# # bootm
## Booting kernel from Legacy Image at 84f00000 ...
Image Name: MIPS OpenWrt Linux-5.10.64
Created: 2021-12-05 20:30:49 UTC
Image Type: MIPS Linux Kernel Image (gzip compressed)
Data Size: 6866658 Bytes = 6.5 MB
Load Address: 80000000
Entry Point: 80000400
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Starting kernel ...
[ 0.000000] Linux version 5.10.64 (birger@AMDDesktop) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 11.2.0 r17632+15-ad28d094ff) 11.2.0, GNU ld (GNU Binutils) 2.37) #0 Sun Dec 5 20:30:49 2021
[ 0.000000] RTL838X model is 0
[ 0.000000] RTL839X model is 0
[ 0.000000] RTL93XX model is 93021001
[ 0.000000] SoC Type: RTL9302B
[ 0.000000] Kernel command line:
[...]
[ 0.841311] Creating 6 MTD partitions on "spi0.0":
[ 0.846635] 0x000000000000-0x0000000e0000 : "u-boot"
[ 0.854382] 0x0000000e0000-0x0000000f0000 : "u-boot-env"
[ 0.861236] 0x0000000f0000-0x000000100000 : "u-boot-env2"
[ 0.869957] 0x000000100000-0x000000200000 : "jffs"
[ 0.876202] 0x000000200000-0x000000300000 : "jffs2"
[ 0.884242] 0x000000300000-0x000001000000 : "firmware"
[ 0.910722] libphy: Fixed MDIO Bus: probed
[...]
Since the partitions seem to be OK, I would then scp the squashfs image over to /tmp and do a sysupgrade. I have not done so yet, because this device has a wonderful diagnostic tool and I am using it as a twin of my XGS1210 to understand how it works all the time. Currently is is being used to debug EEE on the GS1900-10HP...
1 Like
@imwhocodes initramfs is the way to go when you're basically a guinea pig - there's no official images yet AFAIK. If that works well then you can flash.
1 Like
Better make a backup first. I guess there's no OEM firmware download available for this "unmanaged" switch?