Vero 4k+
590 as client and 510 as server.
That doesn’t indicate a hardware problem to me; but possibly limitations on your network.
cat6a stp requires shielding throughout - different patch panel, different wallplates etc. if some component isn’t shielded then you can end up with grounding issues and worse performance than regular old cat6 utp.
oddly enough my speed issues seem to have solved themselves, possibly as i removed the hdmi sender from my patch panel (never went via the switch) or moved my router to another switchport (not that the packets traversed the router). getting way over 900mbps both ways now between various devices on my network.
1 Like
Interesting. I’m glad this has improved for you.
1 Like
It really depends on all systems involved.
My NAS - xeon CPU and hardware that is aged some years shows me an average of 850Mbps both directions.
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 1.03 GBytes 884 Mbits/sec 625 sender
[ 4] 0.00-10.00 sec 1.02 GBytes 878 Mbits/sec receiver
Of course, my daughter was watching something too over the NAS.
From my workstation, fairly new i7 8550U CPU + gigabit chip etc, where the switch separates the traffic from the others in the LAN:
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 1.09 GBytes 937 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 1.09 GBytes 936 Mbits/sec receiver
For me - all are Ok 
Is this meant for me? I got a performance testing report together with the cable when i bought it that I can provide.
It is for general use. Depenbding on the endpoint devices (Especially the used network chip), speed can be different. For one, I know that the mac mini has faster speed in Rx than in Tx. Any test I did proved it.
My new device has a RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller which seems to do fairly well in Gigabit speed on both directions.
One other thing I noticed during my career is that the overrall speed of packets flowing through the network will be limited by the slowest component. Like a one-lane road. If you have 150 cars (packets) going into one direction, the slowest will determine the overall speed for all cars.
Also seen in congested networks is, that the overall speed available will depend on the congestion on the same path. Lots of congestions will slow down the overall transfer speeds.
Hello
Is it possible that the affected units mount the ZTE ZX2AA500 gigabit phy?
I doubt it, from one of the logs where someone reports slow speeds I see PHY ID 001cc916
And that one is based on your post on corelec a Realtek
The problem in my opinion is caused by signal integrity problem in the RGMII interface. It is possible to tune the tx clock shift on the MAC side changing a property in the emac binding in DTS
The TX delay of 2ns is already added to the MAC.
This is the expected skew based on the tracks on the board. However there was a bug where the PHY if reset would also add the 2ns skew. This would result in symptoms such as <10Mbps in TX direction.
All devices use RTL8211F.
BTW from testing PHYs early this year, your ZTE issue is caused by UBoot not initialising PHY properly. The kernel doesn’t do a complete job. I don’t have much more info on it but your vendor may have some patches
Hi
The init function of RTL8211F actually always insert screw in rx direction (not tx). Later in vanilla kernel this screw has been moved in gen_phy unit with clause 42 mma access if instructed to do so by a property in the new phy dts bindings. When it comes to ZTE, the problem we have on other android TV box is ridiculous slow RX gigabit Ethernet speed (rx meaning received by the amlogic chip) in CoreELEC but perfect speed in android stock firmware. I have built a simple tool that can dump and write mdio registers via MIIREG ioctl. I have compared the first 32 registers between android and CoreELEC and I have seen that a lot of settings on the vendor specific registers (from 16) are different. I have tried to align them but without improving the RX speed in CoreELEC. I suspect that something shall be done in shadow registers, but without the data sheet or the registers description I cannot do anything more. I don’t think the problem in in Uboot, because it is the same than boot android or CoreELEC in the device
The skew for RX I believe is set by cali_val. This caused us to have lots of performance problems, particularly when the device got warm.
If you ran stress or cpuburn with iperf, you could see performance drop. After removing this, TX and RX stayed solid for almost all units.
This register and AML calibration code is not documented anywhere: in the 4.9 drop there is also cali code for internal and external PHYs.
I think you can dump all the registers via sysfs already. If there is something new with your tool it would be great to see
Sam
You can dump mdio register from the phy via mii bus in sysfs? I didn’t know. I have this tool, GitHub - Menion2k/mdio-tool on menion_master branch. It is easy to compile also with NDK. There are some prebuilt executable also
I was just poking via /sys/class/ethernet. But only PHY and DMAC so far
For the cali_val values explanation you can check dmac glue driver in meson mainline project for amlogic. For the ZTE I have tried to change clock screw but it did not help
cali_val is not used as it’s not seen as needed. I think you are confusing it for mc_val which indicates MAC TX skew in 2ns increments
Yes it is the mc_val sorry.
I am checking the sysfs interface for phy, it is a custom implementation of amlogic. So, there is the chance that, referring to the ZTE problem, the android firmware configure the ZTE PHY via some bash file and echo to the sysfs… I have to study how the init sequence works in android, do you have some knowledge of if?
I’d be surprised if they did it there. If you unpack the image you can check the init.amlogic which is vendor specific.
I would also check for them passing some parameter via insmod.
Check my dumps here:
It demonstrate that something in android stock configure the registers. Cannot be insmod parameters since the phy driver cannot be built as modules