Jump to content

Orange PI PC - Ethernet Connectivity Slow/Erratic/Inconsistent


AnonymousPi

Recommended Posts

Edit: Nothing was wrong with the Orange PI. I turned out to be my switch.

 

Hi All,

 

Firstly, Armbian is just fantastic. Secondly, this issue is highly likely to have nothing to do with Armbian, but just the cheap crap you'd expect from a cheap SBC.

 

Essentially, after much pain and anguish having bizarre Ethernet connectivity issues with a shiny new Orange PI PC I bought a couple of days, which was:

 

1. When OPI was connected my network switch (which has four other devices connected to it: two Ethernet and two WiFi), none of the other devices can reliably 'ping' or SSH to the OPI... 25% to 100% packet loss.

2. When connecting the OPI physically directly to existing devices (i.e. PCs) with a crossover cable and using a static IP (same as in 1) above), I can use the Orange PI PC without issue. It's fast. 

3. When using the OPI itself to download or connect to the internet, it performs erratically (fantastic for minutes, then slow as hell again).

 

To ensure that it wasn't an issue with the switch or the other computers, I have tested connectivity between all of these and it has been flawless.

 

So, I was about to throw the OPI into the bin, then I decided to force the Ethernet device to half duplex with:

 

ethtool -s eth0 speed 10 duplex half

 

... and whilst I lose a whole bunch of speed, connectivity has been consistent.

 

I don't get any interesting errors in any of the kernel logs either.

 

Interestingly enough, if I attempted to ping other computers on my LAN from my OPI, the OPI would say there was about 50% packet loss. However, if I had a packet logger running on one of the machines, it would clearly log the received ICMP packet, as well as a response that the PC was sending back to the OPI. 

 

 

Q: Do you think I have a faulty board? 

Q: Is this something somebody else has experienced?

 

Unfortunately I don't have another switch to test with to truly rule out some obscure issue with it, but given I have at least two other devices connected by Ethernet which work flawlessly, I'm not convinced it is the switch. I suspect the OPI's oscillator for the 25Mhz signal PHY rate generated for the physical CAT5e might be busted, causing incompatibility.

 

It might be time to buy a cheap crap RealTek USB WiFi dongle instead - I'm sure that'll be a saga in itself.

 

Thanks for any advice in advance. 

Edited by AnonymousPi
Link to comment
Share on other sites

It seems that Orange PI may have problems with the PHY power (http://forum.armbian.com/index.php/topic/1757-orange-pi-plus-ethernet-problem/)

 

Please be careful, this is about the GbE equipped boards which use an external RTL8211E PHY (responsible for a huge increase in consumption if needed). I would suspect in this case it's a different simple hardware issue.

Link to comment
Share on other sites

Hi All,

 

As tkaiser said, this in Orange Pi PC, so no Gigabit Ethernet, stock standard 100baseT.

 

I am using the power supply from the official Orange Pi shop: http://www.aliexpress.com/store/product/orange-pi-orange-pi-plus-Europe-Power-Adapter-5V-2A-Europe-Power-Supply/1553371_32281484383.html?spm=2114.12010108.0.99.x7sufL

 

There is definitely something wrong with this device and I am going to request a refund. For the time being, I have had to stick a 'post-up' line in the /etc/network/interfaces file to force it to 10baseT/Half !

# Wired adapter #1
allow-hotplug eth0
#       iface eth0 inet dhcp
iface eth0 inet static
        pre-up ethtool -s eth0 speed 10 duplex half autoneg off
        address 192.168.1.10
        netmask 255.255.255.0
        gateway 192.168.1.1
        post-up sleep 6; /sbin/ethtool -s $IFACE speed 10 duplex half autoneg off

#       hwaddress ether # if you want to set MAC manually
#       pre-up /sbin/ifconfig eth0 mtu 3838 # setting MTU for DHCP, static just: mtu 3838

Link to comment
Share on other sites

Check the output of dmesg repeatedly. If you see a lot of ETH disconnects/connects, it is possible that your power supply is the issue. I had such an effect on a NanoPI M1, getting a lot of dis-/reconnects (and sometimes just settling at 10MBit after a while). The problem was the power supply, which simply wasn't stable enough. Used a different one (the charger of my Samsung phone), and the problem went away instantly.

 

BTW, power supply quality also plays a big role in the stability in general. With a bad supply i can freeze my boards reliably when starting "stress -c 4 -i 4". Sometimes almost immediately, sometimes after a few seconds, but it always happens.

 

Especially those cheap chinese supplies and cables are usually of really bad quality, causing all sorts of problems.

 

Greetings,

 

Chris

Link to comment
Share on other sites

It shouldn't be the power supply as I have bought the official one from the Orange Pi Ali express shop. Running any stress testing doesn't cause any problems, other than the CPU getting a bit hot, which I'm waiting for a heat sink to resolve.

 

I think there is something wrong with my board.

Link to comment
Share on other sites

What does the syslog/dmesg say? Does the ethernet disconnect and reconnect often?

 

Here's the thing with chinese vendors: They like to cut corners wherever they can. This doesn't mean that the OPi folks want it that way, it could easily be their own supplier. Cheap chinese power supplies are known for being of lousy quality (frankly, i personally wouldn't leave them plugged in unattended). Those QC stickers, if there are any, are just decoration.

 

I think it would be at least worth try, don't you think? Use the charger plug from your phone, assuming that is of a decent quality, and see what happens then.

 

Greetings,

 

Chris

Link to comment
Share on other sites

I think I have figured it out and it again goes to show what a black box these Chinese H3 devices are.

 

I have been using a 8GB Class 4 SD Card with this device without any issues, other than with Ethernet performance being dismal when using full duplex either at 100mbps or 10mbps port speed.

 

It seems this has been resolved with the use of a Transcend 32GB Class 10 SD Card!?? Although I am also using Armbian 5.20 now, instead of 5.14 on the Class 4 SD Card - so maybe that was it.

 

Who knows how these devices work. Maybe the bus frequency is reduced to match the frequency of the SD Card, which inadvertently kills the Ethernet? Maybe the Armbian 5.20 fixed something. 

 

Another one of life's mysteries. 

 

Edit: Absolutely nothing to do with the SD Card. Looking like my ISP provided an Over the Air update of my Router/Modem which fixed this bizarre Ethernet issue with the Orange PI PC. I can't seem the replicate the problem, even with the old SD Card or older version of Armbian.

Link to comment
Share on other sites

I have been using a 8GB Class 4 SD Card with this device without any issues, other than with Ethernet performance being dismal when using full duplex either at 100mbps or 10mbps port speed.

 

Please read through http://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card

 

'Class 4' is considered 'broken anyway', there can happen all sorts of insane stuff with such old cards. Please provide either F3 or H2testw output from the 'Class 4' card. I really don't want the forum full of mysteries since most if not all 'Armbian problems' are in reality either power supply or SD card.

Link to comment
Share on other sites

The Class 4 SD Card is fine from a storage perspective, but maybe it's the reduced bus speed that was killing other peripherals on the H3. 

Warning: Only 7439 of 7440 MByte tested.
Test finished without errors.
You can now delete the test files *.h2w or verify them again.
Writing speed: 7.07 MByte/s
Reading speed: 20.3 MByte/s
H2testw v1.4

 http://www.pcper.com/reviews/Editorial/SD-Card-Speed-Classes-Grades-Modes-and-File-Systems-Explained

Link to comment
Share on other sites

maybe it's the reduced bus speed that was killing other peripherals on the H3.

 

 

IMO very unlikely since Fast Ethernet on H3 is not even a 'bus' at all and should be totally unrelated to SDIO. BTW: Until now I've not seen a single Allwinner board exceeding 50 MHz @ 4 Bit (3.3V) with SD cards (maybe Olimex new A64 board being the first exception).

 

Anyway: I wasted already way too much time with SD card voodoo in my live (most of the times more related to broken burn processes but with a much higher probability using 'crap cards') so that everything that's not already Class 10 has been thrown in a box (for tests and for NFS installations where only basic stuff will be loaded from card and everything else through network).

 

Real world example: I ran out of SD cards a few days ago, so I pulled an Intenso 'Class 4' 4GB out of the 'crap box' (performance values here) and wrote an image with dd on it directly on my build host. Random failures later when testing with a board so I burned the image again (this time with 'bs=1M && sync && eject /dev/sde') and everything worked flawlessly. The only difference was 'bs=10M' vs. 'bs=1M'. I retried that days later with a Samsung EVO 32GB and wasn't able to reproduce this. Simple conclusion: prefer eMMC where available and if SD cards have to be used avoid everything below 'Class 10' and spend your time on more useful things.

Link to comment
Share on other sites

Well. Looks like I have wasted your time tkaiser. Sorry!

 

It seems my ISP provided an Over the Air update of my Router/Modem exactly the same time I upgraded to a 32GB Class 10 SD card. This OTA update looks to have fixed the Ethernet issue with the Orange PI PC. I can't seem the replicate the problem anymore, even with the old SD Card or older version of Armbian. If only I had another switch from the get go, I could have confirmed it was actually an issue with my networking hardware not the PI PC! 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines