Very slow network speed
Gaukur (2073) 8 posts |
I’m struggling with very slow network speed on my RISC OS machines. It seems that I’m stuck in time of ADSL or slower. I have made several speedtests on diffrent hardware and the result are not good. I thought first it was my Titanium machine that was the fault but it seems that other hardware are also showing low performance. Test 1: Download 120 MB file from ROOL, (SD card image RISC OS Pi) with various hardware and configuration. 1.1a) Titanium RO-5.24: 1.2) RPi3 RO-5.24: 1.3) VirtualRPC-DL ARM710 RO-4.02: 1.4) RiscPC StrongArm200 MHz RO-4.04, 10 Mbit/s network card: 1.5) Iyonix RO-5.18: 1.6) RPi-Linux: (same Pi as in test 1.2 with same net cable and switch port) 1.7) PC-Win10: Test 2: Network speed test using www.speedtest.net and www.brandonchecketts.com Speedtest: Brandonchecketts: Has anyone been able to get better performance with RISC OS machines? Or is this the network speed that we have to live with in near future? Can some one make a download test and download the SD card image for Pi using RISC OS browser and replay the results? |
Stuart Painting (5389) 678 posts |
I tried it with two files, just in case file size was a factor. RC5 RISC OS Pico – 3.78MB, 966.55kB/s, 4sec RISC OS Pi – 119.69MB, 806.31kB/s, 2min 32sec Hardware/Software: Raspberry Pi 3B desktop (!Boot on USB-connected SSD), RISC OS 5.24, NetSurf 3.8 My VDSL link is capable of 35Mbit/s on a good day, so these figures are slightly disappointing but not as bad as your figures. It is worth noting that network speed is not the only factor in play. Hardware issues (disc access times, USB2 bus speed) may also be relevant, and some software has been known to “cheat” by quoting the time taken to load the file in memory without saving it to disc. |
Dave Higton (1515) 3399 posts |
I downloaded the RISC OS Pi file from the ROOL web site to RAM disc in 2 min 52 sec. BBxM, RO 5.27 (20-Nov-18), NetSurf 3.9 (Dev CI #4525). My BT Home Hub shows a synchronous downlink speed of 44 Mb/s. Then I uploaded the file to my web site, which is hosted for me by a commercial provider somewhere. I downloaded that in 2 min 33 sec to RAM disc. It doesn’t show much, but it does point out that there are other factors out there beyond our individual control that can alter download speeds. |
Tristan M. (2946) 1035 posts |
I’ve always got maybe 10k/sec with RO, so if I have to download anything of any real size it’s easier to download it using something else and sneakernet it to the Pi. How are you all getting such fast speeds? |
Rick Murray (539) 13350 posts |
Mine, via a Vonets adaptor, is very prone to atmospheric conditions due to pushing a WiFi signal through a thick stone wall. Thankfully the RISC OS source archive is about the only large thing I ever download under RISC OS… |
Andrew Rawnsley (492) 1392 posts |
IIRC Netsurf is known to be pretty dreadful for downloading things – I recall Malcolm (of WeatherUK fame) wrote a downloader module/thingy for just this reason, with a goal of delivering significantly faster downloads by tuning things, and made substantial improvements in download time. What I’m saying is this may not be the OS itself, but rather the software that you choose to test with. For example, !FTPc is usually much faster, but then FTP is generally a faster download protocol that http, so… Also, on a Pi, you may end up using USB for both ethernet and storage, which (while it probably shouldn’t in theory) tends to bottleneck. I remember we saw this on the original ARMini (beagleboard) which used USB storage and ethernet. Moving to SDFS helped somewhat, but it is why we wanted to move away from USB-based ethernet for our newer machines. |
Timothy Baldwin (184) 242 posts |
Stuart, what client software are you using? 1.3) VirtualRPC-DL ARM710 RO-4.02: I understand VirtualRPC uses Windows TCP/IP implemention. Linux 4.14, ASUS Chromebook C100P, all on localhost, RAM to RAM. Test file is 154MB on Btrfs, destiniation, /tmp and !Scrap all on Tmpfs. For Webfs to wget I get 100MB/s to 300MB/s. For Webfs to Netsurf 3.7 on Linux port of RISC OS I get about 2MB/s, with little CPU use, and no attempt to enable Internet events. My quess is that Netsurf simply uses a timer (perhaps Wimp_PollIdle) to periodically check for new data. |
Timothy Baldwin (184) 242 posts |
No, FTP requires a TCP connection and multiple round-trips per file. HTTP only requires 1 round-trip plus TCP overhead and can reuse TCP connections. I expect RISC OS’s old TCP implementation to have poor performance on high bandwidth high latency networks due a small receive window, and for sending a lack of a modern congestion control algorithm. I might test this on rpcemu. |
Chris Mahoney (1684) 2093 posts |
Correct; I just did a test download of a 120 MB file using NetSurf and it took 73 seconds. My own HTTPLib can download the same file in 10 seconds, and I haven’t done any performance optimisation yet! Tests were to a local HTTP server to RAMFS so there are no latency/bandwidth/disc issues to contend with. |
David Feugey (2125) 2687 posts |
Correct.
Probably
Hum, do you use external USB disc as main drive? |
Clive Semmens (2335) 3110 posts |
Even when it’s not transferring data? Is there no way to slow it down? I’ve been considering upgrading my backup to a USB hard drive instead of a memory stick, but if it slows network access to a crawl that’s a killer. Or is the problem only if you use it for the OS instead of using the SD card? Or am I misunderstanding completely? |
David Pitt (3386) 1248 posts |
Both the Titanium and RPi3B+ download from the ROOL site at about 700kB/s using NetSurf. However, perhaps we should not be using ROOL’s bandwidth for testing purposes when this is available, https://www.thinkbroadband.com/download From this site NetSurf downloads at about 1.2MB/s.
I use a 100mb/s switch between the Titanium and Pi’s, ShareFS then works reliably from anywhere to everwhere else, which is not the case with a 1Gb/s switch and links that do work are not any faster. |
David Feugey (2125) 2687 posts |
USB2 bandwidth is limited… and shared by all USB peripherals, AKA the network chip too. |
Gaukur (2073) 8 posts |
Thanks all for quick respond. It all sounds like that RO is slow but I should be able to get better performance than I have now. I changed the broadband some months ago to fiber optic, maybe the problem started at that time but I’m not sure. |
David Pitt (3386) 1248 posts |
Using the RAM disc on the RPi3B+ did increase transfer rates from the Titanium from 4MB/s to 6MB/s. |
David Pitt (3386) 1248 posts |
The 100Mb/s switch here is mostly to with otherwise erratic ShareFS transfers, stalling in mid transfer. External downloads were not affected, they are anyway limited by the fibre at about 48Mb/s and NetSurf itself is slow. |
Timothy Baldwin (184) 242 posts |
I wrote a trivial TCP server:
I tested it with RISC OS 5.24 on Rpcemu 0.9.1 on Linux Debian 4.18.20-2~bpo9+1, pv piped to netcat as a client:
On a unrestricted virtual Ethernet link I get about 500MiB/s Linux to Linux and 35MiB/s Linux to RISC OS, with a 100Mbit bandwidth limit the virtual link is filled. However if I increase the latency to 15ms (round trip to Google from here):
Linux to RISC OS slows down to about 1.3MiB/s. For 256ms (round trip to www.govt.nz from here in UK) Linux to RISC OS slows down a crawling 62-78KiB/s, and Linux to Linux slows down to 9MiB/s with a slow start. |
Rob Heaton (274) 514 posts |
My VDSL link runs at approx 50 MBPS, I found on both my ARMX6 and Titanium that downloads with NetSurf would max out at approx 700K/sec. (Connected to a Gigabit switch) I use pfSense as a firewall on my network, so I installed the Squid Proxy server, with Netsurf using the proxy, download speeds are greatly improved to approx 22 MBPS. I’ve never been able to work out why using a Proxy helps! |
Timothy Baldwin (184) 242 posts |
The speed of light in glass is about 200,000,000 metres per second, the circumference of Earth is about 40,000,000 metres. A DSL link has a few milliseconds of delay. TCP flow control works by the receiver informing the sender how many more bytes it may send. RISC OS will give the sender permission to send just 17376 bytes, and the sender will not send more than that until it receives an acknowledgement. It might go as follows:
That results in 17376 * 5 = 86880 bytes per second. It you insert a proxy server with a modern TCP implementation the RISC OS – proxy TCP connection is fast as round trip time is less than a millisecond, and the proxy – server TCP connection is fast as the proxy gives permission for a lot more than 17376 bytes, I have observed Linux permitting 3145728 bytes with a 256 millisecond round-trip delay. |
Gaukur (2073) 8 posts |
I have made a test using Proxy at it changed a lot, downloader 200MB file from http://www.thinkbroadband.com/download, the average speed was 1.56 MB/s compare to 300kB/s. |
Dave Higton (1515) 3399 posts |
Timothy: that stuff you set out about the flow control is most interesting! Do we know why RISC OS only gives permission to send 17376 bytes? Can the number be changed? |
Steve Pampling (1551) 7904 posts |
Probably related to the MTU for the path. Test with ping 192.168.2.1 -f -l 1464 (or the router IP you have) and there’s a reply. Add 28 to that value for packet header overheads and you get 1492, however Linksys quote their routers as an MTU of 1500. Presumably not PPPoE there. So, we note that one of the factors of 17376 is 16 (16 * 1086 with 1086 barely in the ballpark of 1492 if you’re rich and have an Ethernet network and Internet connection.) However, back in the days of the Acorn stack (which we’ve still got) the router was not DSL but dial up and an MTU of 576 was common. So, quick check for bigger factor and lower MTU: Looks like a compromise value that works moderately OK for both Dial up and Ethernet but probably works best on the common connection of the day – dial up. For dial up, check the “Tradeoffs” section of the wiki link from above and note that “For example, a 1500-byte packet, the largest allowed by Ethernet at the network layer, ties up a 14.4k modem for about one second.” OK, I’ve been around the net a while, but I recall getting the fastest modem I could and that was 14k. In short, yes I dare say a modification of the values to deal with larger data blocks would probably work. Changing to a multiple of 1464 would probably make PPPoE more optimal at the expense of dial up operation. |
Timothy Baldwin (184) 242 posts |
I tried using setsockopt without success. RISC OS is equally slow when sending. Here is my test setup: http://tim.majoroak.me.uk/rpcemu-speedtest.tar.xz It requires Linux, pv, netcat and whatever rpcemu requires. Set the current directory of “rpcemu-speedtest” then run “script”. Unprivileged user namespaces need to be enabled so on Debian and derivatives you may need to run:
It constructs a virtual network with 2 routers connected by virtual Ethernet limited to 100Mbps with the test servers and clients connected to the routers by unrestricted virtual Ethernet.
|