pine64 512MB network unusable - Printable Version +- PINE64 (https://forum.pine64.org) +-- Forum: PINE A64(+) (https://forum.pine64.org/forumdisplay.php?fid=4) +--- Forum: Linux on Pine A64(+) (https://forum.pine64.org/forumdisplay.php?fid=6) +--- Thread: pine64 512MB network unusable (/showthread.php?tid=846) Pages:
1
2
|
pine64 512MB network unusable - Manilow - 04-29-2016 Hello all, I received my pine64 (512MB) and my pine64+ (1GB) and realize, that the pine64 is unusable! While the 64+ has only a slow network (there are other threads about that), the pain64 network is not usable. I installed the debian image (longsleep 20160421), as that seems to be the only viable option for the 512MB version. Network connectivity is somewhat close to not existent. Downloading files from internet is below 25 kB/sec, while the same file loads from other PCs with 30MB/sec. Local ssh connections are hanging after pressing enter several times, while entering commands you have to wait sometimes for the single letters to appear on the console. Ssh sessions are disconnecting after some minutes. Watching the connection with wireshark , I see many duplicates and out-of-order packets coming from the pain64. I tried almost every meaningful interface setting with ethtool, setting it to 10MB 100MB full and half duplex, but that does not help. I thought, that the the pines could be a very good alternative to raspberry pi, because the network interface has direct connectivity to the SoC, but that seems to be wrong. Any Ideas? RE: pine64 512MB network unusable - tkaiser - 04-29-2016 (04-29-2016, 08:05 AM)Manilow Wrote: I installed the debian image (longsleep 20160421), as that seems to be the only viable option for the 512MB version. All OS images here are based on longsleep's work and he prepared a simple method to update all these images so they can benefit from latest fixes. I don't understand why this important information is not featured in the download section in the wiki. Code: bash <(curl -s https://raw.githubusercontent.com/longsleep/build-pine64-image/master/simpleimage/platform-scripts/pine64_update_uboot.sh) Regarding the Ethernet problems. None of the devs that do the real work here experienced these problems so far (only the integer overflow issue affecting the 2GB boards that has been fixed by longsleep within a few days 4 weeks ago). Since you're the first here not only whining but using the right equipment what about putting a pcap trace online so that others are able to look through? And just a thought: When you install on both machines iperf or iperf3 and then connect Pine64 <--> Pine64+ directly. Do you also get duplicate packets and how does performance look like (+85 Mbits/sec is what should be expected) RE: pine64 512MB network unusable - longsleep - 04-29-2016 pain64 made my day. Please push the network dump - might be interesting. Also try to change the MAC address to something else than the auto generated local administrated one. Eg. use the one printed on the backside of the board (add it to /boot/uEnv.txt like ethaddr=xx:xx...) and reboot. RE: pine64 512MB network unusable - androsch - 04-29-2016 (04-29-2016, 11:23 AM)longsleep Wrote: pain64 made my day. Please push the network dump - might be interesting. While i'm also one of those guys with a Pine64+ Rev. B board and slow ethernet speed i can also offer a tcpdump or similar. While i'm only a user some code/instruction for the dump may help to provide a sufficient file... I already sent some figures with iperf3 towards Lenny Raposo, but got no response yet, maybe he also is not exactly the right person to adress this to. Gesendet von meinem K00L mit Tapatalk RE: pine64 512MB network unusable - Manilow - 05-01-2016 Hi, here my iperf and iperf3 stats. First the tests with the PINE64+, which works, but performs not as expected: iperf as client running on the PINE64+ against Server on the same switch Code: ------------------------------------------------------------ iperf3 as client running on the PINE64+ against Server on the same switch Code: Connecting to host 192.168.168.140, port 5201 iperf running as server on the PINE64+ connected from client on the same switch Code: Client connecting to 192.168.168.138, TCP port 5001 iperf3 running as server on the PINE64+ connected from client on the same switch Code: Connecting to host 192.168.168.138, port 5201 Now the tests with the 512MB pine64 (w/o +) iperf as client running on the PINE64+ against Server on the same switch Code: Client connecting to 192.168.168.140, TCP port 5001 iperf3 as client running on the PINE64+ against Server on the same switch Code: Connecting to host 192.168.168.140, port 5201 iperf running as server on the PINE64+ connected from client on the same switch Code: Client connecting to 192.168.168.138, TCP port 5001 iperf3 running as server on the PINE64+ connected from client on the same switch Code: Connecting to host 192.168.168.138, port 5201 The Duplicates are in most cases SACK (selective acknowledgements). I will try tomorrow to get some stripped tcpdumps, I can post here RE: pine64 512MB network unusable - tkaiser - 05-01-2016 (05-01-2016, 11:33 AM)Manilow Wrote: First the tests with the PINE64+, which works, but performs not as expected: Well, quoting you: 'Downloading files from internet is below 25 kB/sec'. And now you get +90 Mbits/sec with Pine64. I wouldn't call this 'Ethernet problem' but 'Internet problem' instead (for whatever reasons, as already said, BSP Ethernet drivers are known to be somewhat crappy). Might be interesting to see traces of Internet downloads instead. RE: pine64 512MB network unusable - Manilow - 05-01-2016 Its for sure not the internet! One more fact: Starting wget http://cdn.kernel.org/pub/linux/kernel/v...5.2.tar.xz on the PINE (512MB) results in a download rate starting with 70 KB/s, dropping to 22 KB/s after 30sec. on the PINE+ (1GB) the download starts with 4MB/s and rises to 5.5MB/s after 10 sec When I download a similar sized file from a server in the same network, the connection rate on the PINE64+ rises to 35MB/s the download rate of the 512MB version starts with 1.5MB/s and drops to 100KB/s after some seconds And watch the rates for the PINE+ compared to the PINE without "+" RE: pine64 512MB network unusable - tkaiser - 05-01-2016 (05-01-2016, 11:57 AM)Manilow Wrote: Its for sure not the internet! Sorry, misunderstanding. I do network debugging for a living and should've been more precise Obviously we're NOT talking about Ethernet or general network problems (layer 2) but stuff that 'only' affects connections to the outside behind a router. You're the first in the forums who's not just whining but is able to provide at least pieces of information regarding these performance drops so we might be able to resolve the problem soon. Please keep in mind that Pine64 only has a Fast Ethernet PHY (you won't exceed 95 MBits/sec with Fast Ethernet) and that the Ethernet driver is crappy and might also need further 'TX delay' adjustments --> that might explain the mismatch between TX/RX speed you experience on Pine64+ -- please don't make the mistake to expect +940 Mbit/sec in both directions with 'tablet grade' ARM SoCs, the A64 is not known to be fast but cheap instead!) Are you able to check for MTU mismatches between Pine64 and the router? And/or tracing at the wire between board and router or at the router itself (might give a different picture compared to a host only trace)? RE: pine64 512MB network unusable - Manilow - 05-02-2016 I know abot all that! I do my tests with exact the same ethernet cable on the same switch and I change the SD-card as well between both Pines, to make sure, that I have no hidden problem. I know, that the PINE 512 has just a 100Mbit device, but that should not be the reason fort the BIG performance issues I see! Again: I am not able to work on the ssh command line (the pine is running headless), command line is via ssh. There is no immediate feedback, characters appearing on the console in chunks. You see the high retry-rate in iperf3 statistics! To debug that problem (and make it as well independent from crypto stuff), i have now created a small shell-script using netcat talking to the core debian xinetd based echo service. (Port 7). Code: #!/bin/bash I am now able to run that script from the pine to my local server and vice versa. Results for the Pine (512MB): Running on Pine connecting to echo port on local server Code: ######## Running on the Server connecting to echo port of the Pine Code: Elapsed: 14 And again the same test with th PINE64+ Results for the PINE64+ (1GB): Running on Pine connecting to echo port on local server Code: ######## Running on the Server connecting to echo port of the Pine Code: ######## Using echo I have removed a lot of overhead from the tcpdump, comparing to ssh. It is now very easy to debug single sessions out of an larger tcpdump. I see now, that the roundtrips of single packets are quiet OK. The data and the FIN packet of the echo-request is ACKed immediately, however the response packet is just delayed 5 to 10 seconds. In the attached tcpdump the second echo request is delayed by 2 sec, the forth delayed by 10sec and the 9th is delayed by 5sec! For me it looks like, that something must be wrong deep in the tcp-stack. Probably it has to do with the NIC-driver, as that is the only difference between PINE64 and PINE64+ I am clueless right now. If there are some more tools, how i can produce other logs , especially about the dataflow through the TCP-stack, please provide me with hints. RE: pine64 512MB network unusable - Manilow - 05-02-2016 I have now updated to the newest available debian (Debian Linux with Mate GUI Image [20160501] by lenny.raposo), which behaves just the same. The pain64 (512MB) is still unresponsive, while the PINE64+ is ok. I have now STRACEd the xinetd-echo process on the PINE, while I run my echo script against. (strace -r -e trace=network -p PID-OF-XINETD -ff -o ./strace.log) I have written some scripts, which have searched for TCP-retries in tcpdump, extracted those sessions, and matched them against the corresponding strace-file, which could be identified by the port number. It looks like, that all sessions with retries are not longer than 1 sec delayed. The sessions running running longer have no retries. |