Franky66 Posted May 29, 2019 Posted May 29, 2019 Armbianmonitor: http://ix.io/1Knj I have big problems with the network throughput on my odroid n2 after a new fresh installation of the armbian image 5.87_debian_stretch_default_4.9.177. I was wondering why the update procedure with apt or some tests with installation for omv is taking so long. Does anyone has the same problems or some hints for solving this? So for know I - switched the network cable (no result and with the same cables different other computers are connected with gigabit and no problem - changed speed from 1 gbit to 100 mbit but with no successfull result on the lan switch (no problems with all other connections on this hp lan switch!) - did some small "iperf" test hardware information for the network card - Realtek RTL8211F driver: lan78xx version: 1.0.6 firmware-version: expansion-rom-version: bus-info: usb-3f980000.usb-1.1.1 supports-statistics: yes supports-test: no supports-eeprom-access: yes supports-register-dump: no supports-priv-flags: no - outgoing traffic to another server connected on the same switch -> super - round about gigabit speed [ 5] local 192.168.150.50 port 5201 connected to 192.168.150.20 port 64828 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 5] 0.00-1.00 sec 111 MBytes 932 Mbits/sec 0 418 KBytes [ 5] 1.00-2.00 sec 114 MBytes 953 Mbits/sec 0 418 KBytes [ 5] 2.00-3.00 sec 113 MBytes 949 Mbits/sec 0 461 KBytes [ 5] 3.00-4.00 sec 113 MBytes 945 Mbits/sec 0 461 KBytes [ 5] 4.00-5.00 sec 113 MBytes 947 Mbits/sec 0 461 KBytes [ 5] 5.00-6.00 sec 113 MBytes 949 Mbits/sec 0 461 KBytes [ 5] 6.00-7.00 sec 113 MBytes 949 Mbits/sec 0 461 KBytes [ 5] 7.00-8.00 sec 113 MBytes 947 Mbits/sec 0 461 KBytes [ 5] 8.00-9.00 sec 113 MBytes 948 Mbits/sec 0 461 KBytes [ 5] 9.00-10.00 sec 113 MBytes 949 Mbits/sec 0 461 KBytes [ 5] 10.00-10.03 sec 3.75 MBytes 988 Mbits/sec 0 461 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 5] 0.00-10.03 sec 1.11 GBytes 947 Mbits/sec 0 sender [ 5] 0.00-10.03 sec 0.00 Bytes 0.00 bits/sec receiver - incoming traffic from another server connected on the same switch or connected directly to the dsl lan router -> very bad - a little or no network throughput [ 5] local 192.168.150.50 port 5201 connected to 192.168.150.20 port 64821 [ ID] Interval Transfer Bandwidth [ 5] 0.00-1.00 sec 22.8 KBytes 187 Kbits/sec [ 5] 1.00-2.00 sec 12.8 KBytes 105 Kbits/sec [ 5] 2.00-3.00 sec 2.85 KBytes 23.4 Kbits/sec [ 5] 3.00-4.00 sec 5.70 KBytes 46.7 Kbits/sec [ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec [ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec [ 5] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec [ 5] 7.00-8.00 sec 35.6 KBytes 292 Kbits/sec [ 5] 8.00-9.00 sec 7.13 KBytes 58.4 Kbits/sec [ 5] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec [ 5] 10.00-10.03 sec 0.00 Bytes 0.00 bits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 5] 0.00-10.03 sec 0.00 Bytes 0.00 bits/sec sender [ 5] 0.00-10.03 sec 87.0 KBytes 71.0 Kbits/sec receiver Feature output for "ethtool -k eth0" Features for eth0: rx-checksumming: on tx-checksumming: on tx-checksum-ipv4: off [fixed] tx-checksum-ip-generic: on tx-checksum-ipv6: off [fixed] tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed] scatter-gather: on tx-scatter-gather: on tx-scatter-gather-fraglist: off [fixed] tcp-segmentation-offload: on tx-tcp-segmentation: on tx-tcp-ecn-segmentation: off [fixed] tx-tcp-mangleid-segmentation: off tx-tcp6-segmentation: on udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: on large-receive-offload: off [fixed] rx-vlan-offload: off [fixed] tx-vlan-offload: off [fixed] ntuple-filters: off [fixed] receive-hashing: off [fixed] highdma: off [fixed] rx-vlan-filter: off [fixed] vlan-challenged: off [fixed] tx-lockless: off [fixed] netns-local: off [fixed] tx-gso-robust: off [fixed] tx-fcoe-segmentation: off [fixed] tx-gre-segmentation: off [fixed] tx-gre-csum-segmentation: off [fixed] tx-ipxip4-segmentation: off [fixed] tx-ipxip6-segmentation: off [fixed] tx-udp_tnl-segmentation: off [fixed] tx-udp_tnl-csum-segmentation: off [fixed] tx-gso-partial: off [fixed] tx-sctp-segmentation: off [fixed] tx-esp-segmentation: off [fixed] fcoe-mtu: off [fixed] tx-nocache-copy: off loopback: off [fixed] rx-fcs: off [fixed] rx-all: off [fixed] tx-vlan-stag-hw-insert: off [fixed] rx-vlan-stag-hw-parse: off [fixed] rx-vlan-stag-filter: off [fixed] l2-fwd-offload: off [fixed] hw-tc-offload: off [fixed] esp-hw-offload: off [fixed] esp-tx-csum-hw-offload: off [fixed] rx-udp_tunnel-port-offload: off [fixed] Network statistic: NIC statistics: mmc_tx_octetcount_gb: 0 mmc_tx_framecount_gb: 0 mmc_tx_broadcastframe_g: 0 mmc_tx_multicastframe_g: 0 mmc_tx_64_octets_gb: 0 mmc_tx_65_to_127_octets_gb: 0 mmc_tx_128_to_255_octets_gb: 0 mmc_tx_256_to_511_octets_gb: 0 mmc_tx_512_to_1023_octets_gb: 0 mmc_tx_1024_to_max_octets_gb: 0 mmc_tx_unicast_gb: 0 mmc_tx_multicast_gb: 0 mmc_tx_broadcast_gb: 0 mmc_tx_underflow_error: 0 mmc_tx_singlecol_g: 0 mmc_tx_multicol_g: 0 mmc_tx_deferred: 0 mmc_tx_latecol: 0 mmc_tx_exesscol: 0 mmc_tx_carrier_error: 0 mmc_tx_octetcount_g: 0 mmc_tx_framecount_g: 0 mmc_tx_excessdef: 0 mmc_tx_pause_frame: 0 mmc_tx_vlan_frame_g: 0 mmc_rx_framecount_gb: 154260 mmc_rx_octetcount_gb: 10966937 mmc_rx_octetcount_g: 10728461 mmc_rx_broadcastframe_g: 50794 mmc_rx_multicastframe_g: 4049 mmc_rx_crc_error: 3124 mmc_rx_align_error: 0 mmc_rx_run_error: 0 mmc_rx_jabber_error: 0 mmc_rx_undersize_g: 0 mmc_rx_oversize_g: 0 mmc_rx_64_octets_gb: 132282 mmc_rx_65_to_127_octets_gb: 17887 mmc_rx_128_to_255_octets_gb: 1955 mmc_rx_256_to_511_octets_gb: 1998 mmc_rx_512_to_1023_octets_gb: 47 mmc_rx_1024_to_max_octets_gb: 91 mmc_rx_unicast_g: 96293 mmc_rx_length_error: 0 mmc_rx_autofrangetype: 0 mmc_rx_pause_frames: 0 mmc_rx_fifo_overflow: 0 mmc_rx_vlan_frames_gb: 0 mmc_rx_watchdog_error: 0 mmc_rx_ipc_intr_mask: 1073692671 mmc_rx_ipc_intr: 0 mmc_rx_ipv4_gd: 104170 mmc_rx_ipv4_hderr: 346 mmc_rx_ipv4_nopay: 96 mmc_rx_ipv4_frag: 0 mmc_rx_ipv4_udsbl: 0 mmc_rx_ipv4_gd_octets: 4854250 mmc_rx_ipv4_hderr_octets: 13968 mmc_rx_ipv4_nopay_octets: 4416 mmc_rx_ipv4_frag_octets: 0 mmc_rx_ipv4_udsbl_octets: 0 mmc_rx_ipv6_gd_octets: 427127 mmc_rx_ipv6_hderr_octets: 0 mmc_rx_ipv6_nopay_octets: 0 mmc_rx_ipv6_gd: 1165 mmc_rx_ipv6_hderr: 0 mmc_rx_ipv6_nopay: 0 mmc_rx_udp_gd: 8923 mmc_rx_udp_err: 17 mmc_rx_tcp_gd: 96329 mmc_rx_tcp_err: 799 mmc_rx_icmp_gd: 83 mmc_rx_icmp_err: 0 mmc_rx_udp_gd_octets: 1081938 mmc_rx_udp_err_octets: 4248 mmc_rx_tcp_gd_octets: 2063871 mmc_rx_tcp_err_octets: 47072 mmc_rx_icmp_gd_octets: 5568 mmc_rx_icmp_err_octets: 0 tx_underflow: 0 tx_carrier: 0 tx_losscarrier: 0 vlan_tag: 0 tx_deferred: 0 tx_vlan: 0 tx_jabber: 0 tx_frame_flushed: 0 tx_payload_error: 0 tx_ip_header_error: 0 rx_desc: 0 sa_filter_fail: 0 overflow_error: 0 ipc_csum_error: 0 rx_collision: 0 rx_crc: 0 dribbling_bit: 0 rx_length: 0 rx_mii: 0 rx_multicast: 0 rx_gmac_overflow: 0 rx_watchdog: 0 da_rx_filter_fail: 0 sa_rx_filter_fail: 0 rx_missed_cntr: 0 rx_overflow_cntr: 0 rx_vlan: 0 tx_undeflow_irq: 0 tx_process_stopped_irq: 0 tx_jabber_irq: 0 rx_overflow_irq: 0 rx_buf_unav_irq: 0 rx_process_stopped_irq: 0 rx_watchdog_irq: 0 tx_early_irq: 0 fatal_bus_error_irq: 0 rx_early_irq: 20112 threshold: 1 tx_pkt_n: 815258 rx_pkt_n: 151136 normal_irq_n: 87250 rx_normal_irq_n: 62229 napi_poll: 87225 tx_normal_irq_n: 25734 tx_clean: 88024 tx_set_ic_bit: 25758 irq_receive_pmt_irq_n: 0 mmc_tx_irq_n: 0 mmc_rx_irq_n: 0 mmc_rx_csum_offload_irq_n: 0 irq_tx_path_in_lpi_mode_n: 0 irq_tx_path_exit_lpi_mode_n: 0 irq_rx_path_in_lpi_mode_n: 0 irq_rx_path_exit_lpi_mode_n: 0 phy_eee_wakeup_error_n: 0 ip_hdr_err: 0 ip_payload_err: 0 ip_csum_bypassed: 0 ipv4_pkt_rcvd: 0 ipv6_pkt_rcvd: 0 no_ptp_rx_msg_type_ext: 0 ptp_rx_msg_type_sync: 0 ptp_rx_msg_type_follow_up: 0 ptp_rx_msg_type_delay_req: 0 ptp_rx_msg_type_delay_resp: 0 ptp_rx_msg_type_pdelay_req: 0 ptp_rx_msg_type_pdelay_resp: 0 ptp_rx_msg_type_pdelay_follow_up: 0 ptp_rx_msg_type_announce: 0 ptp_rx_msg_type_management: 0 ptp_rx_msg_pkt_reserved_type: 0 ptp_frame_type: 0 ptp_ver: 0 timestamp_dropped: 0 av_pkt_rcvd: 0 av_tagged_pkt_rcvd: 0 vlan_tag_priority_val: 0 l3_filter_match: 0 l4_filter_match: 0 l3_l4_filter_no_match: 0 irq_pcs_ane_n: 0 irq_pcs_link_n: 0 irq_rgmii_n: 0 mtl_tx_status_fifo_full: 0 mtl_tx_fifo_not_empty: 0 mmtl_fifo_ctrl: 0 mtl_tx_fifo_read_ctrl_write: 0 mtl_tx_fifo_read_ctrl_wait: 0 mtl_tx_fifo_read_ctrl_read: 0 mtl_tx_fifo_read_ctrl_idle: 0 mac_tx_in_pause: 0 mac_tx_frame_ctrl_xfer: 0 mac_tx_frame_ctrl_idle: 0 mac_tx_frame_ctrl_wait: 0 mac_tx_frame_ctrl_pause: 0 mac_gmii_tx_proto_engine: 0 mtl_rx_fifo_fill_level_full: 0 mtl_rx_fifo_fill_above_thresh: 0 mtl_rx_fifo_fill_below_thresh: 0 mtl_rx_fifo_fill_level_empty: 0 mtl_rx_fifo_read_ctrl_flush: 0 mtl_rx_fifo_read_ctrl_read_data: 0 mtl_rx_fifo_read_ctrl_status: 0 mtl_rx_fifo_read_ctrl_idle: 0 mtl_rx_fifo_ctrl_active: 0 mac_rx_frame_ctrl_fifo: 0 mac_gmii_rx_proto_engine: 0 tx_tso_frames: 0 tx_tso_nfrags: 0
Franky66 Posted May 29, 2019 Author Posted May 29, 2019 One hint from the hardkernel forum is to flash the latest u-boot release to the sd card. But I don't know how to adapt this to the armbian image if possible. Maybe the image is not build the same way as the original hardkernel ubuntu image. Checked with another network cable directly attached to dsl router avm fritzbox 7490. got better throughput in receive about 200 - 300 mbit, but this should be not a final cabeling. checked some small soho lan router from cisco, also bad throughput. what a strange device
Igor Posted May 31, 2019 Posted May 31, 2019 On 5/29/2019 at 3:11 PM, Franky66 said: how to adapt this to the armbian image if possible. apt update & apt upgrade armbian-config -> system -> install/update boot loader On 5/29/2019 at 3:11 PM, Franky66 said: Maybe the image is not build the same way as the original hardkernel ubuntu image. U-boot is build from the same source with compilers they provide. Our changes in that area are minimal and in the area to support booting also from ext2 partitions. Their u-boot supports only FAT boot method.Images were rebuild few days ago and are more recent than their builds. Perhaps that is the problem. My testings show no troubles (both ways and over two switches): [ 5] 0.00-1.00 sec 107 MBytes 898 Mbits/sec [ 5] 1.00-2.00 sec 112 MBytes 939 Mbits/sec [ 5] 2.00-3.00 sec 112 MBytes 939 Mbits/sec [ 5] 3.00-4.00 sec 112 MBytes 939 Mbits/sec [ 5] 4.00-5.00 sec 112 MBytes 939 Mbits/sec [ 5] 5.00-6.00 sec 112 MBytes 939 Mbits/sec [ 5] 6.00-7.00 sec 112 MBytes 939 Mbits/sec [ 5] 7.00-8.00 sec 112 MBytes 939 Mbits/sec [ 5] 8.00-9.00 sec 112 MBytes 939 Mbits/sec [ 5] 9.00-10.00 sec 112 MBytes 939 Mbits/sec Todays nightly build: http://ix.io/1KwM And do test without installing OMV first.
Franky66 Posted May 31, 2019 Author Posted May 31, 2019 Thankx for your answer, I will test again. Made myself a few sd card installations for testing with various os releases. until now did not find a reason for the poor incoming traffice throughput. Also in contact in the odroid forum for finding a solution.
Igor Posted May 31, 2019 Posted May 31, 2019 11 minutes ago, Franky66 said: Thankx for your answer, I will test again. Made myself a few sd card installations for testing with various os releases. until now did not find a reason for the poor incoming traffice throughput. Also in contact in the odroid forum for finding a solution. There is only one u-boot/kernel (and early modern 5.2.y -> kernel will emerge soon) so testing many OS releases won't help. We provide best environment for dealing with those troubles - clean OS, to rule out potential influential user space bugs, build system and nightly automated updates (armbian-config - > system -> switch to nightly), which we provide also for all other boards. Images with nightly updates are up2date with Hardkernel development branch, changes are actively monitored. Even their official images are older. If they fix something you will get it the next day without a need to recompile on your own. But it is also possible that there is some hw defect on a board itself. Its fairly new board and certain undiscovered glitches surely exists. Some can fixed with software, some not.
Franky66 Posted May 31, 2019 Author Posted May 31, 2019 1 hour ago, Igor said: There is only one u-boot/kernel (and early modern 5.2.y -> kernel will emerge soon) so testing many OS releases won't help. We provide best environment for dealing with those troubles - clean OS, to rule out potential influential user space bugs, build system and nightly automated updates (armbian-config - > system -> switch to nightly), which we provide also for all other boards. Images with nightly updates are up2date with Hardkernel development branch, changes are actively monitored. Even their official images are older. If they fix something you will get it the next day without a need to recompile on your own. Ok thankx for this important understanding for me. I thought already that there are small to no changes between the os images as the network kernel driver etc. was the same in all os versions. so I will switch to the armbian ubuntu image and will do some more testing. got two new different length network cables here from work and test again with them.
Franky66 Posted May 31, 2019 Author Posted May 31, 2019 It would be nice to know which hardware revision you board is. My board has revision 0.4 with the plastic case from hardkernel. Ticket in odroid forum discussing this problem: https://forum.odroid.com/viewtopic.php?f=181&t=35203
Igor Posted May 31, 2019 Posted May 31, 2019 Just now, Franky66 said: It would be nice to know which hardware revision you board is. v0.3
NicoD Posted May 31, 2019 Posted May 31, 2019 Hi. Did you try with other devices on your network? Just to be shure it's the N2 and not a router issue. There were simular problems in the beginning with the N2. Those were indeed fixed with the latest uboot. This was also not with all N2's the same. Mine had it, some other didn't have this problem. Ethernet worked when put at 100Mbit, but wat Gb it lost all it's packages and was as slow as B/s. This problem is still not fixed in the Mate image to my knowledge(only after upgrade) Meveric did update his Stretch last week to fix this. Have you tried that image? Here was a fix for that problem. I do not expect you've got the same problem. I do think it could be related. Quote of myself : There's an easy fix for that. Quote from fromport: So powered down my N2, put the SD card in a USB reader connected to my linux desktop. Downloaded new uboot from https://github.com/hardkernel/u-boot/releases I used the odroidn2-22 image. Downloaded and extracted the tgz file (not source) used the supplied script to install it to my uSD card: Code: Select all cd sd_fuse ./sd_fusing.sh /dev/sdb #<- that is where my system detected the uSD card 1664+1 records in 1664+1 records out 852336 bytes (852 kB, 832 KiB) copied, 0.113748 s, 7.5 MB/s Finished. End Quote. I've got the same issue with both Ubuntu and Stretch. But with Ubuntu wifi works out of the box, while in Stetch you need to be able to download a few things to get it to work. And that doesn't work without internet...
Franky66 Posted May 31, 2019 Author Posted May 31, 2019 Hi yes actually I changed the setup but without any success. The N2 is still the problem with his own network access. For now I tested with: - armbian ubuntu latest build for N2 and switch to nightly build with all updates - Cat 5e cables 1 m / 10 m - Cat 6 cables 3 m / 5 m N2 connected to FritzBox directly or to LAN Switch HP PS1810-8G. Crosschecked iperf3 with two raspi's modell 3. Yes the had a problem on an unmanaged switch between the 100 mbit and 1 gbit modell after 10 sec. if I do iperf between them. so I connected them back to the fritzbox and put the unmanaged switch away. On my HP PS1810 I have windows client / server etc. connected and all with gigabit speed without any problem or so such lazy speed. Maybe the people at odroid have some more hint. I saw only ONE difference between Igor's N2 and mine on comparing the support output: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 -> my N2 eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 -> Igor's N2
Franky66 Posted May 31, 2019 Author Posted May 31, 2019 As I wrote in the odroid forum I did also some ping tests from the petiboot shell and with different paket sizes the N2 loses 1 - 2 pakets per 10 pakets to different targets. Maybe the N2 has a hardware problem.
Franky66 Posted May 31, 2019 Author Posted May 31, 2019 Just found one usb 3.0 ethernet adapter and connected it to the N2 and to the "old" network cable, voila working : [ 1550.073189] ax88179_178a 2-1.4:1.0 eth1: register 'ax88179_178a' at usb-xhci-hcd.0.auto-1.4, ASIX AX88179 USB 3.0 Gigabit Ethernet, 74:da:38:4a:28:23 [ 1550.073308] usbcore: registered new interface driver ax88179_178a [ 1550.161967] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready [ 1550.492764] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready [ 1553.102308] ax88179_178a 2-1.4:1.0 eth1: ax88179 - Link status is: 1 [ 1553.110418] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready Incoming traffic [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 1013 MBytes 850 Mbits/sec sender [ 4] 0.00-10.00 sec 1013 MBytes 850 Mbits/sec receiver Outgoing traffic [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 845 MBytes 709 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 844 MBytes 708 Mbits/sec receiver
Franky66 Posted July 6, 2019 Author Posted July 6, 2019 After waiting for a long time and discussing with my local reseller I got today a new odroid n2 with mac adress "ether 00:1e:06:42:1b:1f". Plugged in everything, bootet armbian or your own ubuntu image and got perfect network gigabit speed without problems. Tried the same with the original odroid n2 still lying here for sending it back and poor performance. so the old odroid n2 has some bug with the network card and will now be returned. happy now to get starting building up my new odroid n2 to replace the raspi 3b.
Recommended Posts