Sean

I'm not sure if this is a bug or something intentional, but had the following large pop-up during a test. I ran a combined linear test, which completed successfully. I enabled multithread, clicked "Re-test", closed the full screen pop-up ad and the after the first stage of the upload test appeared, it displayed the following large count down and asked me if I want to continue with the test, which then completed successfully Edit: I ran a handful of further tests, including simultaneously on my mobile (different 4G connection), but didn't get this again.

I just noticed in the beta mode that there is no setting to toggle Linear Upload, which I think was there up until recently, i.e. the Customise Settings page currently just has a Linear Download toggle: Could you add a Linear Upload toggle? I can still run the linear upload by temporarily toggling off the Beta, but would rather not lose the linear upload capability once the beta becomes final. I mainly use linear testing on slower connections such as rural DSL and cellular connections.

I tried retesting with my router upload limited to 0.5Mbps up (to mimic my workplace DSL uplink) and the 10MB manual download block performs better giving about 7-8Mbps in Chrome after a few tests. With a 102MB manual block it gets around 50Mbps: With linear, it gives around the full download speed like when I do not have the upload throttled to 512Kbps. Going by your test results above, it appears you either did not limit the upload speed to 512Kbps on your gateway / router (to mimic a slow 512Kbps DSL upload) or it was measuring the 512Kbps upload limit as 39.2Mbps. The following shows the 512Kbps upload configured on my router to mimic the 512Kbps upload limit on my workplace's DSL connection. With MikroTik routers, FastTrack must be disabled (IP -> Firewall) for speed limits to take effect.

From my testing so far, the Beta appears to work well with my 4G based Internet connection at home. However, when I managed to give it a quick test run at my workplace, the beta kept delivering speeds under 1Mbps down in Chrome even though they have a 10Mbps DSL connection. From further testing at home and setting upload / download limits on my MikroTik router, I found that when I set the upload speed to 512Kbps to match the DSL uplink at my workplace, I am able to replicate the issue here and also uncovered a few other small issues. With my workplace DSL connection the following is the Beta test followed by the linear test in Chrome with the UK server: Retest with the German server. As I write this post, I see the up/down rows are swapped on the left. 🙃 I did one more test in Edge and although it performed better than Chrome, the upload and download was still around half the linear download test: Other observations: The Beta test does not mention it being a multithread test in the test result. For comparison, the non-beta multithread test mentions "Multithread": Download tests with a block size under 1MB incorrectly show the KB as MB in the test results page. For example, the following test result on the left shows a test block of 205kB, however in the test results page, it shows "205 MB": If the download or upload test is unable to fetch all the blocks, it gets stuck. This happened a few times, probably due to the small packet loss on my 4G connection, such as the following screenshot where it endlessly waited here for the final 2 kB block.

From looking through your test results, it looks like the intermittent dips could be your 4G router switching between 4G bands. This is particularly an issue with Cat 4 routers that only connect to a single 4G band, such as the TP-Link MR200/400/6400 series and the Huawei B593 and B3xx series. For example, Three uses 4G band 20 extensively in rural areas due to its ability to penetrate building material, vegetation, etc. better than 4G bands 1 and 3, however, however they only have 1/3 the bandwidth on band 20 compared to band 3 and it's more congested due to users in fringe areas only being able to pick up that band indoors. Speed drops after around 6pm is mainly due to traffic load on the mast as the bandwidth is shared between everyone connected to the mast, like a road. If you have a Huawei 4G router, you can try using LTE H-Monitor (link) to lock to individual bands (Configuration -> Radio). Choose a single Upload band and the matching download band (e.g. B3 1800MHz for both). Run a speed test, then repeat with a different band such as B1 and B28. If you get no signal, then that band is not in use. Three uses bands 1, 3, 20, 28 and 32 (download only). The TP-Link routers and most older Huawei routers lack support for bands 28 and 32. Higher end routers such as the Huawei B628 and B818 can connect to multiple bands simultaneously (i.e. carrier aggregation) and also have Gigabit Ethernet ports, so can potentially deliver much faster, possibly 200-300Mbps if band 32 is on the mast you're connected to.

While in a 3.6GHz 5G area today I tried some further testing, this time with a different browser. It turns out the Chrome browser is less CPU intensive than Firefox when it comes to handling high throughput, at least with SSL. This surprised me as it used to be the other way around. Unlike Firefox, the Chrome browser did not appear to freeze or stutter even when testing above 400Mbps: I'll need to retest whenever I'm back in the other town with the less congested 5G site to see if it can top 700Mbps. 😃

Both were run directly on my phone, however, I'd say it's more likely the browser's SSL overhead that's limiting the speed with browser based tests. For example, I don't think the Ookla App uses SSL for its tests, never mind using a non-standard TCP port. Indeed there's no way I could get Ookla's speed realistically with actual file downloads on my phone as they would face the same SSL bottleneck. For example, any streaming service that offers downloads will obviously use SSL or other encryption overhead for their DRM. Basically I need a faster phone. 😃 I'll probably upgrade to the Samsung S21 FE when there's a good sale on one. Not just for speed tests, but for even offloading video files from my phone and additional 5G bands in use that my current phone lacks. I don't get why manufacturers still put USB2 ports on phones just to save a few cents on manufacturing.

While in an area with good 5G coverage on the 3.6GHz band, not in a moving vehicle for once, I tried a few speed tests. It appears that ~370Mbps is about the max my Samsung A51 5G phone will get on TestMy and possibly any other browser based test. During the test, the web browser appears unresponsive during the download test, unusually with the figure jumping straight to 100% once the speed hits about 350Mbps. On the other hand, these are my fastest TestMy results to date on a phone: Although the Ookla App got faster (734Mb down), I have recently noticed a design flaw with most midrange 5G phones, including mine - There is no practical way to make use of 5G speed above about 350Mbps even with tethering. Most midrange phones have a USB2 port (USB2 maxes out about 350-380Mbps real world) and 802.11ac Wi-Fi that is not MIMO capable (SISO maxes about 300Mbps real world on an 80MHz channel), two major bottlenecks when tethering. So for my next phone, I need to make sure it has USB3 or Wi-Fi 6 with MIMO...

My preference would be Cat 5e for general cable runs and Cat 6a for long cable runs where PoE or 10Gbps is required. Both officially handle 1Gbps over a 100m run (328ft), but can usually handle up to 10Gbps over shorter runs. Cat 6a cable has thicker conductors than Cat 6 (without the 'a') and is rated to handle 10Gbps over a 100m run. I did the mistake of buying Cat 6a cable for our home wiring, only to spend a few hours troubleshooting and recrimping RJ45 plugs wondering why I could not get all 8 conductors to link. It turned out that the pack of "Cat 6 plugs" I bought where actually Cat 5 plugs falsely described as Cat 6 in the Amazon listing. This turned out to be the case with many listings I looked at based on the user reviews (sort by Newest first). Even when I got hold of proper Cat 6 plugs from a local trade supplier, getting the 8 colour coded wires aligned up is a lot more awkward than with Cat 5e as the thicker conductors are stiff. Basically, unless you need 2.5Gbps or faster over very long cable runs, I would choose Cat 5e for the ease of installation and termination and the high risk of buying Cat 5 plugs / wall plates falsely described as Cat 6 capable. In any case, Cat 5e will provide vastly improved throughput, latency and stability over any Wi-Fi or Homeplug based connection, particularly over longer indoor ranges.

Having heard the US 3G shutdown news from over here, I'm surprised they did not bother to create a workaround for unsupported smartphones. It would just have been a matter of Verizon creating a simple App to handle voice calls and text messages via 4G data to replace the default dialler App, which even the oldest smartphones would be capable of (I remember using VoIP apps back in 2012). Sure it would take a little getting used to using an App to dial out or for SMS, but better than losing voice/text services entirely until the user upgrades. It's not like the App would need to be anything special either like WhatsApp to handle multimedia, video calling, etc. With the budget network I'm with (48 Ireland), they only support 3G roaming at present, so I can imagine this will be an issue if I visit the USA after the 3G switch-off. European law will soon require mobile operators to offer like-home connectivity when roaming throughout the EU, so it's likely they will offer 4G roaming even outside the EU when that happens. While the 48 network only offers 4G in Ireland with its partner network Three, it occasionally switches to 5G:

Going by reneehere's ISP Hughes in the test results, unfortunately there is little that can be done to improve the speed. Hughes and other satellite based Internet providers (except Starlink) are heavily oversubscribed in many areas and barely fit for purpose despite their heavily exaggerated advertising. The only workaround would be to either change ISP (if out of contract) or schedule downloads such as overnight to use the following day, e.g. pick Netflix titles to download overnight, so they play the following day. If there is no wired ISP available (e.g. DSL, cable, etc), I suggest checking if 4G LTE is available. There a thread here where someone managed to switch from Huges to T-Mobile LTE. I wouldn't be too concerned about 5G as rural 5G often uses narrow long range bands that perform no better, if not worse than 4G. Starlink is another option worth considering if you can afford it. Starlink uses low earth orbit satellites, so has far fewer subscribers per cell (radius of about 15 miles) than other satellite ISPs where there may be thousands crammed into spot beams with a radius of about 80 miles.

If your upload speed is very stable, such as a DSL connection, you should be able to go close to your upload speed limit without any issue. For example, 1.5Mbps should be fine, possibly 1.6Mbps. If it's a wireless or cellular based ISP, you may need to drop further back than this. I suggest doing a trial run with a continuous ping in the background, such as to Google's DNS 8.8.8.8. If there is barely any increase in the ping times compared to 1000Kbps, then that bitrate is fine. If however, you see the pings regularly spiking up such as over 100ms, then try dropping back the bitrate by 0.1Mbps.

From my end, the latency spike shows up at a different IP, in this case hop #15 due to routing from Ireland. My connection doesn't appear to support reverse DNS resolution, probably due to being 4G based. Tracing route to dallas.testmy.net [45.32.203.96] over a maximum of 30 hops: 1 1 ms 1 ms 1 ms 192.168.5.1 2 * * * Request timed out. 3 31 ms 21 ms 29 ms 172.16.0.133 4 38 ms 29 ms 24 ms 172.24.194.174 5 35 ms 23 ms 19 ms 212.2.180.90 6 22 ms 22 ms 31 ms 212.2.180.89 7 25 ms 62 ms 19 ms 193.95.129.239 8 56 ms 24 ms 21 ms 193.95.129.185 9 35 ms 51 ms 23 ms 166.49.168.128 10 60 ms 75 ms 46 ms 166.49.208.170 11 34 ms 28 ms 32 ms 166.49.164.94 12 43 ms 59 ms 30 ms 212.119.4.140 13 76 ms 64 ms 38 ms 129.250.4.140 14 58 ms 35 ms 37 ms 129.250.2.183 15 114 ms * * 129.250.2.111 16 138 ms 138 ms 133 ms 129.250.5.12 17 195 ms 199 ms 137 ms 129.250.3.244 18 154 ms 131 ms 140 ms 128.241.219.54 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 177 ms 145 ms 138 ms 45.32.203.96 Trace complete. Edit: Sorry I should have checked. From further tests, it looks like the transatlantic hop latency from Ireland to US and then from there to Dallas at hop #16.

The first two tests (Ookla and nPerf) run their tests multi-threaded by default, i.e. they typically make around 8 simultaneous connections to the test server to try to saturate the connection. Ookla has a lot of test servers within the ISP networks, so there is a good chance your test traffic is not leaving their network unless you manually choose another server. To get a multithread test here on TestMy, click the "Multithread off" at the top-right to turn it on. Note that multithreaded tests don't realistically show what you would get streaming or downloading, which generally run over a single connection from the server. Google's built-in speed test is a single connection speed test (not multithreaded), but uses the new TCP BBR congestion protocol. The TCP BBR congestion protocol is excellent at handling packet loss up to about 5% before it suffers significant speed loss. As web servers don't have BBR enabled (or installed) by default, most websites use the legacy TCP CUBIC congestion protocol. For this reason, TestMy does not use TCP BBR, apart from the Colorado Springs server at this time. A few major web hosts such as Google and Microsoft and CDNs such as Cloudflare are TCP BBR enabled. As Google's speed test uses Measurement Lab's servers, you can see how your speed compares with the widely used TCP CUBIC congestion protocol that Measurement Lab uses on its own website test: https://speed.measurementlab.net/#/ If the "Retransmission" figure is not zero, there is a some packet loss on your connection. If the speed is close to the 80Mbps what you got on Google, then your ISP may have congestion on its peering with international links as TestMy does not have any test servers in Italy.

That's great having it up and running, hopefully the speed is holding up through the evening. ? I'm not sure what prevented the iPhone from connecting, unless there was a spelling error in the Wi-Fi password. For the GB remaining, you may need to set this up in the NetGear Mobile App: Go into the Netgear Mobile App, then touch "Data Usage" Change the "Data Limit Unit" to "GB" To the right of "Data Limit", touch the pen icon, enter 100 and touch 'Go'. Change the "Monthly cycle starts (day)" to the day of the month that you activated the plan. Touch the top-right back arrow to save the change and exit. When you cycle through the screens on the Netgear (briefly push its power button), it should show the GB used like this. I haven't used mine in a while, so it's showing 0 here: To check the signal reading on your Nighthawk M1 - Go into the Netgear Mobile App, then go into the menu -> Settings -> Network -> Advanced Info. The most important signal readings are the RSRP (signal strength) and the SINR (signal quality). The RSRP should be no more negative than -100dBm and the SINR should be above 10. If either is worse (e.g. RSRP of -110dBm, SINR of 5, etc.), then move the router to another location and wait a few seconds for the readings to update. Hughes sure is stingy with that hefty early termination fee, more like a fine for leaving them. No wonder they can get away with such poor service, as I'm sure there are some that can't afford that early termination fee. ?