80MB/s in ubuntu, 300KB/s on Windows10 and Android (both Wifi)!?

    • 80MB/s in ubuntu, 300KB/s on Windows10 and Android (both Wifi)!?

      I use OMV 4 with Samba 4.5 on and odroid XU4, and for some reason the file transfer is super slow over the WLAN.
      My test results:

      • always: 80-100MB/s transfer from an ubuntu box (wired, same rates for SMB and NFS)
      • always: 80-100MB/s transfer from Windows 10 (wired, LSO disabled)
      • most of the time: 200-300 KB/s transfer from an Android tablet (2.4Ghz WLAN), ES File explorer
      • most of the time: 355KB/s transfer from same Windows10 laptop as above (2.4GHz WLAN)
      • sometimes, the transfer speed for the two wireless devices spikes up to 4MB/s, but I haven't figured out when; it happens very rare.


      Any options in smb.conf do not seem to make a difference, I tried everything from blank to

      Source Code

      1. socket options = TCP_NODELAY IPTOS_LOWDELAY
      2. read raw = yes
      3. write raw = yes
      4. oplocks = yes
      5. max xmit = 65535
      6. dead time = 15
      7. getwd cache = yes
      I do not expect super high speeds and really do not care about it, but the 300KB/s makes my NAS pretty much unusable with wireless devices. Anyone an idea?
    • I got myself a 3 node 5GHz WiFi mesh. Asus Lyra. That helped up my WiFi speed a lot. I live in the countryside without any competing WiWi stations. With 2.4 GHz I used to get 2-3 MB/s. Now I get 20-30 MB/s. The mesh nodes can in good circumstances connect to each other using two 5GHz channels. So I can get up towards 60 MB/s between two nodes. I have my NAS "cluster" attached to one mesh node and my desktop PC attached to another. Line of sight with a door open. Fast enough so I don't have to bother with cabling.

      However the reach for full speed through walls is not very impressive. I also have a couple of 2.4 GHz WiFi APs and a couple repeaters to cover a MUCH wider area with slower speed 2.4 GHz WiFi. Some devices, like ESP32/ESP8266 MCUs for local IoT stuff, can't handle 5GHz.
      OMV 4, 7 x ODROID HC2, 1 x ODROID HC1, 3 x 12TB, 2 x 8TB, 1 x 4TB, 1 x 2TB SSHD, 1 x 500GB SSD, GbE, WiFi mesh
    • Hey guys, thanks for your answers! Even if the 2.4GHz band is crowded, I would expect a little more than just 355KB/s...

      I just dug out my old ubuntu laptop and tested the speed there: 11.5 MB/s on wireless, while Windows10 and Android both stuck at around 300KB/s, so it can't be the neighbors. Also, if you google "windows file copy 355KB/s" you get a LOT of results, so I guess this 355KB/s is not a random number, but some sort of misconfiguration.

      My updated speeds with my NAS (ext4 drive):

      ubuntu wired (NFS): 80-100 MB/s (expected)
      ubuntu wired (SMB): 70 MB/s (expected)
      ubuntu wireless (SMB): 11 MB/s (expected)
      Win10 wired: >100 MB/s (expected, only after turning large send offload off)

      Win10 wireless (SMB): 355KB/s, one out of 10 times 4 MB/s (????, the wireless card has no large send offload option)
      Android wireless (SMB): 300KB/s, one out of 10 times 4 MB/s (???)

      I am really puzzled, it seems that the network is working fine, and also the wireless network is working within its capacity, only the samba server does not work well with Win10 on wireless and android. Also, this re-occuring number of exactly 355KB/s on win10 disturbs me.
    • Addition: I analyzed the TCP traffic with tsharkr during a fast (wireless ubuntu laptop) and a slow (wireless windows10 laptop) transfer; the results do not tell me much, but there is clearly a difference:


      Fast one:

      Source Code

      1. 26970 14.708199323 192.168.178.42 → 192.168.178.22 TCP 66 445 → 46456 [ACK] Seq=23814 Ack=146145973 Win=14146 Len=0 TSval=89163909 TSecr=2839143224
      2. 26971 14.708208656 192.168.178.22 → 192.168.178.42 TCP 2962 46456 → 445 [ACK] Seq=146145973 Ack=23814 Win=1324 Len=2896 TSval=2839143224 TSecr=89163900 [TCP segment of a reassembled PDU]
      3. 26972 14.708231614 192.168.178.22 → 192.168.178.42 TCP 5858 46456 → 445 [ACK] Seq=146148869 Ack=23814 Win=1324 Len=5792 TSval=2839143226 TSecr=89163900 [TCP segment of a reassembled PDU]
      4. 26973 14.708315698 192.168.178.42 → 192.168.178.22 TCP 66 445 → 46456 [ACK] Seq=23814 Ack=146154661 Win=14146 Len=0 TSval=89163909 TSecr=2839143224
      5. 26974 14.708376532 192.168.178.22 → 192.168.178.42 TCP 11650 46456 → 445 [ACK] Seq=146154661 Ack=23814 Win=1324 Len=11584 TSval=2839143226 TSecr=89163900 [TCP segment of a reassembled PDU]
      6. 26975 14.708450407 192.168.178.42 → 192.168.178.22 TCP 66 445 → 46456 [ACK] Seq=23814 Ack=146166245 Win=14146 Len=0 TSval=89163910 TSecr=2839143226
      7. 26976 14.709220534 192.168.178.22 → 192.168.178.42 TCP 11650 46456 → 445 [ACK] Seq=146166245 Ack=23814 Win=1324 Len=11584 TSval=2839143226 TSecr=89163900 [TCP segment of a reassembled PDU]
      8. 26977 14.709327909 192.168.178.42 → 192.168.178.22 TCP 66 445 → 46456 [ACK] Seq=23814 Ack=146177829 Win=14146 Len=0 TSval=89163910 TSecr=2839143226
      9. 26978 14.709363993 192.168.178.22 → 192.168.178.42 TCP 11650 46456 → 445 [ACK] Seq=146177829 Ack=23814 Win=1324 Len=11584 TSval=2839143226 TSecr=89163900 [TCP segment of a reassembled PDU]
      10. 26979 14.709403451 192.168.178.22 → 192.168.178.42 TCP 11650 46456 → 445 [ACK] Seq=146189413 Ack=23814 Win=1324 Len=11584 TSval=2839143226 TSecr=89163900 [TCP segment of a reassembled PDU]
      11. 26980 14.709493618 192.168.178.22 → 192.168.178.42 TCP 11650 46456 → 445 [ACK] Seq=146200997 Ack=23814 Win=1324 Len=11584 TSval=2839143226 TSecr=89163900 [TCP segment of a reassembled PDU]
      12. 26981 14.709525826 192.168.178.42 → 192.168.178.22 TCP 66 445 → 46456 [ACK] Seq=23814 Ack=146200997 Win=14146 Len=0 TSval=89163911 TSecr=2839143226
      13. 26982 14.709588702 192.168.178.22 → 192.168.178.42 TCP 8754 46456 → 445 [ACK] Seq=146212581 Ack=23814 Win=1324 Len=8688 TSval=2839143226 TSecr=89163900 [TCP segment of a reassembled PDU]
      14. 26983 14.709613035 192.168.178.42 → 192.168.178.22 TCP 66 445 → 46456 [ACK] Seq=23814 Ack=146212581 Win=14146 Len=0 TSval=89163911 TSecr=2839143226
      15. 26984 14.709672785 192.168.178.42 → 192.168.178.22 TCP 66 445 → 46456 [ACK] Seq=23814 Ack=146221269 Win=14146 Len=0 TSval=89163911 TSecr=2839143226
      16. 26985 14.709725327 192.168.178.22 → 192.168.178.42 TCP 14546 46456 → 445 [ACK] Seq=146221269 Ack=23814 Win=1324 Len=14480 TSval=2839143226 TSecr=89163900 [TCP segment of a reassembled PDU]
      17. 26986 14.709807202 192.168.178.42 → 192.168.178.22 TCP 66 445 → 46456 [ACK] Seq=23814 Ack=146235749 Win=14146 Len=0 TSval=89163911 TSecr=2839143226
      18. 26987 14.709851161 192.168.178.22 → 192.168.178.42 TCP 14546 46456 → 445 [ACK] Seq=146235749 Ack=23814 Win=1324 Len=14480 TSval=2839143226 TSecr=89163900 [TCP segment of a reassembled PDU]
      19. 26988 14.709936702 192.168.178.42 → 192.168.178.22 TCP 66 445 → 46456 [ACK] Seq=23814 Ack=146250229 Win=14146 Len=0 TSval=89163911 TSecr=2839143226
      20. 26989 14.710740621 192.168.178.22 → 192.168.178.42 TCP 11650 46456 → 445 [ACK] Seq=146250229 Ack=23814 Win=1324 Len=11584 TSval=2839143226 TSecr=89163900 [TCP segment of a reassembled PDU]
      Display All


      Slow one:

      Source Code

      1. 1442 5.546532868 192.168.178.42 → 192.168.178.51 TCP 1514 445 → 51467 [ACK] Seq=954841 Ack=118 Win=1119 Len=1460 [TCP segment of a reassembled PDU]
      2. 1443 5.548431373 192.168.178.51 → 192.168.178.42 TCP 60 51467 → 445 [ACK] Seq=118 Ack=956301 Win=256 Len=0
      3. 1444 5.548517123 192.168.178.42 → 192.168.178.51 TCP 1514 445 → 51467 [ACK] Seq=956301 Ack=118 Win=1119 Len=1460 [TCP segment of a reassembled PDU]
      4. 1445 5.548542665 192.168.178.42 → 192.168.178.51 TCP 1514 445 → 51467 [ACK] Seq=957761 Ack=118 Win=1119 Len=1460 [TCP segment of a reassembled PDU]
      5. 1446 5.579983918 192.168.178.42 → 192.168.178.51 TCP 1514 445 → 51467 [ACK] Seq=959221 Ack=118 Win=1119 Len=1460 [TCP segment of a reassembled PDU]
      6. 1447 5.582002632 192.168.178.51 → 192.168.178.42 TCP 66 [TCP Dup ACK 1443#1] 51467 → 445 [ACK] Seq=118 Ack=956301 Win=256 Len=0 SLE=959221 SRE=960681
      7. 1448 5.582090466 192.168.178.42 → 192.168.178.51 TCP 1514 [TCP Out-Of-Order] 445 → 51467 [ACK] Seq=956301 Ack=118 Win=1119 Len=1460 [TCP segment of a reassembled PDU]
      8. 1449 5.584181346 192.168.178.51 → 192.168.178.42 TCP 66 51467 → 445 [ACK] Seq=118 Ack=957761 Win=256 Len=0 SLE=959221 SRE=960681
      9. 1450 5.584242763 192.168.178.42 → 192.168.178.51 TCP 1514 [TCP Retransmission] 445 → 51467 [ACK] Seq=957761 Ack=118 Win=1119 Len=1460
      10. 1451 5.584265930 192.168.178.42 → 192.168.178.51 TCP 1514 445 → 51467 [ACK] Seq=960681 Ack=118 Win=1119 Len=1460 [TCP segment of a reassembled PDU]
      11. 1452 5.586492436 192.168.178.51 → 192.168.178.42 TCP 60 51467 → 445 [ACK] Seq=118 Ack=960681 Win=256 Len=0
      12. 1453 5.586555978 192.168.178.42 → 192.168.178.51 TCP 1514 445 → 51467 [ACK] Seq=962141 Ack=118 Win=1119 Len=1460 [TCP segment of a reassembled PDU]
      13. 1454 5.589252610 192.168.178.51 → 192.168.178.42 TCP 60 51467 → 445 [ACK] Seq=118 Ack=963601 Win=256 Len=0
      14. 1455 5.589339235 192.168.178.42 → 192.168.178.51 TCP 1514 445 → 51467 [ACK] Seq=963601 Ack=118 Win=1119 Len=1460 [TCP segment of a reassembled PDU]
      15. 1456 5.589360777 192.168.178.42 → 192.168.178.51 TCP 1514 445 → 51467 [ACK] Seq=965061 Ack=118 Win=1119 Len=1460 [TCP segment of a reassembled PDU]
      16. 1457 5.629981139 192.168.178.42 → 192.168.178.51 TCP 1514 445 → 51467 [ACK] Seq=966521 Ack=118 Win=1119 Len=1460 [TCP segment of a reassembled PDU]
      Display All
    • mischa.mole wrote:

      Even if the 2.4GHz band is crowded, I would expect a little more than just 355KB/s...

      Why? It's 'shared medium'. You measure at the TCP layer but some magic happens below. IMO it's pointless to try to diagnose bad Wi-Fi performance when all you could get is a huge dependency on the other bandwidth consumers in the 2.4 GHz band (and 'bandwidth' is misleading since you need to look at latency as well)
    • Because at the same time, I get 10-12 MB/s from all the ubuntu wireless devices I tried. Its just Windows and Android that have these problem, so I am sure that its some samba/network misconfiguration. Additionally, on windows, speed is ALWAYS EXACTLY shown as 355KB/s, which would be IMO a huge coincdence if its just a congested 2.4GHz band. Googling this 355KB/s file copying speed leads to a ton of results, but none ofnthem helped me so far.
    • mischa.mole wrote:

      at the same time, I get 10-12 MB/s from all the ubuntu wireless devices I tried
      I tested with 802.11n in 2.4 GHz band only once two years ago and the best I got with 2 spatial streams was below 8 MB/s at the application layer. Are you sure this is 2.4GHz here and what's your MIMO setup?

      Asides this can't help since neither using Windows nor Android. Only possible advice is to test with iperf/jperf to get Samba out of the way and maybe Helios LanTest (differences to Explorer explained here).