CA3LE

Maybe contact that developer. Easier to just use TestMy.net instead. Try the beta under My Settings.

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.

thank you! And thank you to those who've made anonymous BTC donations! Very unexpected. You guys rule.

I'll correct that, I didn't update the old My RT program with that mirror's information yet. Thanks for catching that. That mirror is slightly different than the rest, not built into My Latency by default... unless you select that mirror, then you'll see the option. It was donated by WaveX ISP in Kenya, I own all of the other servers. Donated, but it's a full TMN server I maintain... first one. -- it also doesn't appear in the legacy multithread test right now.

You live in a very interesting location in the world. When you search for the "western most part of Europe" in Google you find Cabo da Roca. But that's totally not true. This rock, just off your island is the real western most part of Europe. That rock, from what I can see... is the end of Europe. Google Maps The Westernmost Point of Europe I feel like you're getting extremely good speeds to that remote location.

Quotes from private messages

Wow! You resurrected a 20 year-old topic! Ahh the old days, when 4 Mbps was amazing.

It really does sound like you've checked all the boxes in your troubleshooting. Was this PC performing like the others until recently? I'd like to see how you perform on the beta, it may give us more clues. go to My Settings, toggle it ON then test as you normally do. Once enabled you can Tune ☆ and increase the max text size, enable multithread, etc. Run this on the PC with the issue and on a device that's known to be working correctly so we can compare.

Using DNS in Singapore doesn't really help for your latency to the server. Latency is like the time it takes for you to send a message to your friend and for them to respond. In the world of the internet, when you click on something or ask your computer to do something online, it sends a request to another computer far away. Latency is how long it takes for that request to reach the other computer and for you to get an answer back. If it takes a long time, everything online feels slow, like when you're waiting for someone to respond to a text. When you ask your computer to load a website, it sends a message to another computer far away called a server. That server holds the information for the website you want. The message travels through wires, cables, or even space (if it’s using satellites!), and when the server gets it, it sends the website information back to your computer the same way. The time it takes for the message to go to the server and back to your computer is what we call latency. The quicker it travels, the faster things load! You can't improve this unless you're able to take a shorter path to the server. The physical distance creates unavoidable latency... the speed of light is the limiting factor. What the Latency Test is showing you is that servers in Singapore will perform best for you. Amazon is hosted on a CDN (content delivery network) so when you request using that test it pulls from a server closer to you automatically. To improve latency over long distances, here’s how it works: Use servers closer to you: Imagine a game of telephone. The closer the person, the quicker the message gets to you. Using servers that are closer (like a local one instead of one far away) speeds things up. Optimize the route: Think of taking the quickest path home. By using smarter routes (like special internet paths called "content delivery networks"), the message travels faster, just like choosing a shortcut. Use faster connections: Just like a fast car on a highway, using better internet connections helps the message travel quicker, even over long distances!

Sorry this took so long. The upload and download now have separate X-axis with date/time that syncs and makes more sense. They also have separate y-axis and are independent of each other.

Alright, "Mixed Stress" is added, find it under Tune ☆. Toggle it on, adjust the ratio if you'd like, then run download tests as you normally do. Let me know what you think.

Very glad to hear that! I've found over the years, the most reliable indicator whether something can be trusted or not, ask the question, "is it at all related to Bill Gates?" Thank you for following up. Looking forward to it staying fixed for you.

oooohh, I got it working. Quickly. Almost like I planned it... oh wait. Need to style it differently, this isn't just a download test result. You can see where I run two combo tests, then one normal download test It's not like the upload portion is causing congestion in the browser, I'm testing it, calling upload 1/5. So for every 5 download packages received an upload package of equal size to 1 of the download packages is sent. The result is immediate degradation of the connection... exactly what we like to test here. I combined this with another device on the network and indeed found degraded performance. Meaning we're pushing to the limits. Stress test. Look at the gif, the 2nd combo test was larger (200MB) ... notice how the download was starting to fluctuate and flutter under this condition. The connection was like, "whhoooww, what!" Pretty cool. My phone's results are really interesting too. I'm going to keep playing around with the idea and get something packaged up for you nice and neat.

Don't know how I missed this topic. I read it when it came in but I never responded, sorry dude. I was thinking about the same thing as I was developing the beta... how it would be interesting to combine them together. So along the way I developed it with that in mind for the future. There are a couple of different ways I've imagined it can be done. I think I'll just have to experiment in the real-world. It's definitely coming. Whether people understand it, use it, want it or care about it... that's another story. But I think it would be a cool, unique tool... sounds like an interesting new benchmark. One that will be hard to score well on unless you're connection is awesome. I think the most interesting part to me is that it's unknown. I can kind of simulate what would happen but when it's actually a single process, I think it will yield interesting results. A test whose results can only be compared to itself. I'll let you know when it's ready to try.

I compiled chart.js into ES5 javascript and added a ResizeObserver polyfill (adding a newer JS feature to an older browser, filling the gap) and am able load the beta is Safari 13.1.2 now with no issues. 495.2 Mbps [61.9 MB/s] | Downloaded 200 MB Linear in 3.23 seconds Pre-Test: 520 Mbps [65 MB/s] | 106.7 MB in 1.64 seconds Download Graph: [560,552,544,512,488,496,432,480,488,504,504,512] Test Latency 44 ms Avg - 16 ms Min Latency Graph: [117,117,66,16,18,16,110,19,17,16,129,17,16,24,19,16,16] User: CA3LE | CompID: 6532027578876 | Host: Comcast Cable | Locale: co.testmy.net User Agent: Mozilla/5.0 Macintosh; Intel Mac OS X 10_13_6 AppleWebKit/605.1.15 KHTML, like Gecko Version/13.1.2 Safari/605.1.15 Graph & Validate: https://testmy.net/x/tmn?resultID=8IZxw75l0 40 Mbps [5 MB/s] | Uploaded 24.8 MB Linear in 4.96 seconds Pre-Test: 40 Mbps [5 MB/s] | 10 MB in 2 seconds Upload Graph: [44.8,40.8,44,42.4,43.2,41.6,40.8,41.6,40.8,41.6,41.6,42.4] Test Latency 39 ms Avg - 11 ms Min Latency Graph: [51,56,42,12,12,50,11,44,43,44,48,51] User: CA3LE | CompID: 6532027578876 | Host: Comcast Cable | Locale: co.testmy.net User Agent: Mozilla/5.0 Macintosh; Intel Mac OS X 10_13_6 AppleWebKit/605.1.15 KHTML, like Gecko Version/13.1.2 Safari/605.1.15 Graph & Validate: https://testmy.net/x/tmn?resultID=x69j8nxpt Hoststats and DB search charts also rely on this same resource. Charts are working across all pages on my iMac running a fresh install of High Sierra. My super old iPad, not so much. That's running Safari 10. I thought this would have worked... there may be another polyfill I need. But it's really hard to debug that one because I can't get it to connect in dev mode (so I can see what's really happening in the console). Maybe if I reset the device. But then I go to use the internet in general on that thing and pretty much all sites are broken in some way. May be time for that to retire. So this won't fix all cases but it should bridge the gap for many. It's basically been translated into language old browsers can understand. There are ways to polyfill the entire modern js framework... but how much of a payload do I want to send? Answer: As little as possible. It may not be worth it to make it work for every single browser. Especially since I have a legacy version of tests and charts that work in that scenario... I just need to give it instructions to serve that client a little different. Which isn't ideal but it will work. Please let me know if it's working for you now.

When I got back home I checked, 13.1.2 is the latest version of Safari for High Sierra unfortunately. BTW, why not run Chrome or Firefox instead?

Not too sure why it's showing the post 7 hours old on the forum index, I'll look into that. As for the beta not loading on v10.13.6 High Sierra. I've had to make special accommodations for older browsers with every beta release. I'll do some tests myself with Safari 13 and make the changes needed. It will probably just have to fail over to the previous version because the browser may not have capabilities needed. But if that's the case I'll have it show a notice to the client and disallow setting the beta. ...sometimes, I just need to call a method a little differently or reform some functions to make it work. My wife's laptop (2015 Macbook) isn't getting updates anymore, for a long time it was stuck on the old version of Safari... then all of a sudden it gave an update the other day. To 16.6.1 -- the version on my 2020 iMac is 17.5. Still searching for official word from Apple on this. See if you maybe have an update... long shot.

... and I'm aware that there's no way currently to filter the beta multithread results. You'll have this option soon. I'm doing it slightly different so that the multithread ID and server ID are both being stored, where before it was just identified as "multithread". Before you'd have to click details to see the server locale being tested. But now I need to resolve it in the search functions to give you the ability to filter for multithread. I think I'll end up with search options like multithread=>(include | exclude | only) and then you'll still have the identifier dropdown list that you can use in combination with that. Again, just a heads up, I'm aware that you can't search that way yet. I just wanted to take a few days to think about how I want to resolve that. ... you can filter them out of your results right now, by selecting a server locale identifier from the dropdown. For instance, if you've tested Dallas with both multithread and linear, selecting Dallas from the dropdown will only display the Linear results.

Looks like you found the Tune option and are enabling and disabling multithread now. I see yesterday and today your upload speed has improved. When comparing the beta and production version make sure you're comparing apples to apples. Multithread compared to multithread and Linear (single thread) compared to Linear. And keep in mind that only the beta has a multithread upload test and the beta multithread test also splits the file into more pieces than the current production version. (3X as many). This can make the beta multithread test stress a connection more than the current version... depending on the device being tested. Still, comparing apples to apples, it should be very similar between the beta and production. The method that the data is rendered can make a huge difference, this is why I offer these options. You're testing different aspects when you toggle multithread on and off.

Hummm... if you don't know what that item is, I would disable it. It's not under network extensions (like I was reading) may not have anything to do with the issue... but it might.

Another thing you might check is the login items. Search System Settings for Login Items & Network Extensions then click Network Extensions. One that's known to cause intermittent connection issues with Mac OS Sequoia 15.0 is Microsoft Defender network extension.

The search continues... Did you happen to notice if it's 2.4 or 5 GHz when this happens?

Glad to hear it's working better for you now. Sorry, I thought I responded after your post on Wednesday. It's not rotating the IP address, it's rotating the MAC address. A fixed address could be used to track or ID you between multiple networks. If you're concerned about that, when you leave your house turn the address to "rotating". When you're on a network you trust, like your home, turn it on fixed. Although, I'm trying to figure out how the MAC address changing would at all correlate with speed degradation. Why would that have any bearing on your speed? ... unless there are specific MAC based rules on the router that alter the speed limits for different addresses. Has the issue stayed resolved since changing the address to "Fixed" the other day?

Awesome