Sean

Having recently moved from a deteriorating 4G service to Starlink, I tried some experimenting to see if I could get some extra upload speed.  From what I've found out in this presentation, Starlink has significant uplink packet loss as well as varying latency as the satellites fly past, i.e. lowest latency directly overhead and highest when going out of view towards the horizon.
 
As the BBR congestion control does not use packet loss as a congestion indicator and adapts well to varying latency such as cellular networks, this should work well with Starlink uploads.  The Ookla Speedtest makes multiple simultaneous uploads, so it generally reports much faster upload speeds than uploading a large file, however, with the Linear test on TestMy (i.e. Multithread disabled) the difference from my testing is huge.  So far I had no l luck finding any way of configuring Windows 10 or 11 to use BBR, however, this is possible with Linux with Kernel 4.9 and higher, such as much recent Linux distros.  While Windows 11 supports the BBR2 congestion control, it seemed to have little to no effect on upload speeds.
 
With a Linux root terminal:
modprobe tcp_bbr  
Add the following lines to the end of /etc/sysctl.conf
net.ipv4.tcp_congestion_control = bbr net.core.default_qdisc = fq  
The following is a set of 5 upload tests across 5 different servers at varying distances from my location in Ireland, the final being Sydney at the other side of the globe.  I tried running a 50MB block in each, but after Germany, the CUBIC tests failed with a "Too Slow" message 😁, so used smaller blocks for those CUBIC tests.  Each upload test was run on the same Windows 10 PC (CUBIC congestion control) with Linux Mint running in a Hyper-V virtual machine configured for TCP BBR.
 

As the TCP BBR congestion control only affects uploading, for faster download speeds the remote server must use the BBR congestion control.  

how's that for symmetric? 😆
 
 

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.

You'll get this error if you run too many tests too quickly.  It should be there... but not unless you hit the test more than you did.
 
It shouldn't happen on your first re-test like that.  I was seeing it too, when combined test was used and re-test was quickly done.  I made an adjustment and it now passes properly under that scenario.
 
Thanks for the heads up.  

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.

Hi Sean,
 
I made some adjustments, when you enable "Linear Load" it will modify the Upload page to direct you to the legacy upload test.
 
This doesn't work with combined test, using combined test with linear load under the beta will still load the new version.
 
I hope to develop the linear upload test to work with the new graphs but I'm not sure if it's possible yet.  It's pretty tricky.  Porting the download test over was simple.  The problem has to do with a limitation of a certain browser API.  
 
The current version will remain available, I have no plans to get rid of that.  If I can't get it to work exactly the way I want... then I'll just integrate the old version, minus the extra graphing on the upload.

Based on how the Beta seems to function, I would think it would be a prime opportunity to add a "dual" test, which simultaneously runs both upload and download.
 
This would be nice for testing in enterprises that have their own data-centers and host VPN/Web/etc. traffic, as they can find out what types of bandwidth carving they should do. I.e., if my Buckeye 1-gig fiber supports a full-duplex 1-gig, then I don't have to worry as much about having a good upload speed when someone else is using my network. But if it's a half-duplex 1-gig, then it changes how I might want to carve out bandwidth.
 
Just a thought, would be an interesting metric to add. Could be a purple double-arrow in the results that indicates the combined speed as well, since it's not a pure upload/download, but a "dual" / "simultaneous" / "mixed" test.

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. 

 

With a slower upload speed or higher latency it interferes with the normal flow.  If the requests are lagged it will affect the result.
 
With 100+ smaller requests the connection has to negotiate each one.   The latency and upload can effect this.
 
This will be less pronounced with linear because we don't have to keep initiating requests over and over.  
 
I went around and around with this one, trying to get those connections to ramp up quicker.  Originally I was trying to make the test ramp up quicker by adjusting test parameters for that situation.  Then realized that it's only doing what it's supposed to do.  This happens when the connection is weak, it's only showing you what happened.  If something slows down the requests or the process... it affects the end result.
 
So keep in mind when you're using the beta, it's splitting the multithread process much more than my previous version.  100 elements for < 1MB tests and 200 elements beyond that, where the production multithread at 10MB you only open 12 threads and 200MB opens 30 threads.  Big difference.  The beta is more demanding.
 
The difference is before I adjusted the process to meet the connection.  Smaller tests were done with less elements.  I've decided going forward that TMN shouldn't scale based on the connection, rather measure every connection the same.  As the linear test does.  Remember I'm only talking about the multithread process.
 
The beta upload test works the same way, 100 and 200 elements.
 
A couple of things to can do.  Click [customize] and Enable Linear Boost or test linear on connections like that one.
 
 
I've seen that too, always on crappy connections.  I think you're right about it being due to packet loss.  I'm going to see about detecting when a thread gets stuck like that and then reinitiate that thread and report the event in the results.
 
It's all about how the data is being rendered.  The beta is an entirely new test with different variables.  These new variables seem to favor more modern connection types because they're better designed for this type of load.  A bunch of small requests may be harder to render in some cases than a few large ones.  But that's what we're here to test.

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.
 

 
 

I thought this was kinda funny, did a combined test and got the exact same 767.2Mbps on both upload and download. Had to giggle at this one.
 

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.

(2x100ft, 2x10ft) to Cat-8 blue shielded from Tinifiber (Hyperscale Data Center Cables) now Spectrum is my bitch 😂

I've got the Samsung s21 ultra;  work where im in the "5GUC" 
 
PS:  oh, and ookla showed over 500. 
 
 

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...

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. 

I almost always use Cat5e. I run 10 Gbps on Cat5e, all day every day — just short distances. And even for longer distances it will surprise you. In my testing using my existing Cat5e house wiring I was getting 5 Gbps on probably about 100 ft. Far from ideal but actually worked awesome. If you were told that 5 Gbps was all that was possible you'd never tell the difference. Not jittery or anything, just simply half the speed of ideal conditions... but still 5 Gbps.
 
In my experience Cat5e is also easier to work with if you're fitting your own connections.
 
In short, you probably don't actually need the extra shielding of Cat6. You're better off spending the extra money on better networking gear.   

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:
 

1:  I actually lol'd on this. XD  This was the general consensus of many....MANY people and Verizon pretty much said F.U. to all its unhappy customers; @ one point even trying to disgustingly blame Samsung for " Not implementing multi-bands of 5G from the factory".  The thing that really put the nail in the coffin for me was i just bought a Samsung Note 8 not even a year prior, ($899) and just brought it in for an issue i was having with media loading... than they were like " We've got a deal for you!!" 🙄
 
2: NGL, never imagined you having anything less than the newest of new mobile tech.... Glad to see you can still surprise us after all these moons, D

Ooooh man, I'd be pissed too. I would have left them too and ever since I'd be looking for the class action suit that I'm sure is in the works. If it isn't, maybe it should be.
 
Verizon carried that phone with 5G branding, if they ended up not using the tech in favor of something else --- well, then that's okay too (technology changes) but they need to reimburse the customers who thought they were future proofing themselves. You can't sell it branded as 5G then later say, "oh, it's 5G but not the kind we use." -- "WTF! I bought it from YOU!"        "I think they might use those bands in Malaysia or Cambodia, maybe think of moving."
 
I had something similar but different recently happen with Verizon. I have a pixel 2, which I still love. Came out October 2017. So a little over 4 years old now. Google stopped updates for it last year. But still, overall it's a great device. Fast, responsive, does what you tell it to do... and Verizon will have 4G for a long time, so this device should remain compatible, right?
 
WRONG! As they retire the 3G CDMA network they're also killing all 4G non-VoLTE (Voice over LTE) devices December 31st 2022. They gave a warning but nothing else. Even $300 off would have made me happy, come on - SOMETHING! Basically, I got "you'll be kicked off the network unless you upgrade."
 
In my case, I needed to upgrade. Was planning one soon anyway (really shouldn't have gone this long in the business I'm in but it's such an awesome device!). But for most people, my Pixel 2 is still a perfectly good device - great even. They could allow it to continue to use data... but no.
 
I ended up with the S22 Ultra but am still walking around my house with my Pixel 2... haha.
 

 
All of the best devices are always FORCED to die eventually. More planned, forced obsolescence is all we can expect in the future.

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:
 

Hey all. Just wanted to say a big thank you to the creators and maintainers of testmy.net.
 
I live in Jamaica and we don't have fast or quality internet service here unless you live in the more populated areas. Where I live there are no physical internet connections available so I've had to use fixed wireless options for years. I've been through every single one that's been available and your speed test has helped keep my sanity. Basically all of them have tried to send me to the sites that make them shine and make me look like the crazy unreasonable customer.
 
My current provider just upgraded my package after almost 15 years and wanted me to do daily speed tests to make sure everything was fine. They told me to use openspeedtest.com and I told them I would use testmy.net instead (been using you for years and loving it, THANK YOU again) but they said they wanted to measure jitter as well so I relented. Well, after a while I  noticed the connection was acting up and while testmy.net gave me the real world, openspeedtest.com was giving results saying I had full speed and nothing was wrong.
 
To cut a long story short, after 2 months of telling them something was wrong and trying to convince them to use testmy.net instead, they have finally relented and admitted there's a problem  on their network. So thank you again to each and every one of you who has and anything to do with this site. Please continue to do what you do and fight for the little guy.
 
Much appreciated.