CA3LE

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

I see 1 results from today that was 140 Mbps... but very odd about the other ones. I've never personally seen that happen to that degree before. I'd really like to see how you run on the beta and what kind of charts it draws for your connection. Click "My Settings" then toggle the beta ON. Run a few combined tests. Then visit Tune ☆ and toggle multithread ON. Run a few more combined tests and hit me back so I can take a look.

Sorry for the inconvenience. I made a change to the code that should prevent that from happening again. Please let me know if you have any other questions. Happy Testing!

Working on the histogram... here's the return on some raw queries I'm forming. Histogram of your full history (download bin size 10 Mbps, upload bin size 2 Mbps) -> WHERE User_Name = 'wmertens' AND Test_Type = 'download' +-----------+-------+------+ | bin_floor | COUNT | bar | +-----------+-------+------+ | 0 | 14 | *** | | 10000 | 21 | *** | | 20000 | 16 | *** | | 30000 | 9 | ** | | 40000 | 11 | ** | | 50000 | 18 | *** | | 60000 | 2 | * | | 70000 | 2 | * | | 80000 | 3 | * | | 90000 | 9 | ** | | 100000 | 7 | ** | | 110000 | 3 | * | | 120000 | 1 | | | 130000 | 1 | | | 140000 | 1 | | | 150000 | 2 | * | | 210000 | 1 | | | 220000 | 1 | | | 250000 | 1 | | +-----------+-------+------+ 19 rows in set (0.002 sec) -> WHERE User_Name = 'wmertens' AND Test_Type = 'upload' +-----------+-------+------+ | bin_floor | COUNT | bar | +-----------+-------+------+ | 0 | 4 | * | | 2000 | 4 | * | | 4000 | 7 | ** | | 6000 | 8 | ** | | 8000 | 13 | *** | | 10000 | 9 | ** | | 12000 | 7 | ** | | 14000 | 8 | ** | | 16000 | 2 | * | | 18000 | 19 | *** | | 20000 | 6 | ** | | 24000 | 4 | * | | 26000 | 4 | * | | 28000 | 1 | | | 30000 | 2 | * | | 32000 | 2 | * | | 34000 | 4 | * | | 36000 | 4 | * | | 38000 | 1 | | | 40000 | 4 | * | | 60000 | 1 | | | 62000 | 1 | | +-----------+-------+------+ 22 rows in set (0.002 sec) My results, on Comcast, this year only... (download bin size 25 Mbps, upload bin size 2.5 Mbps) -> WHERE User_Name = 'CA3LE' AND Test_Type = 'upload' AND `Date` > '20240101000000' AND `User_Host` = 'comcast_cable' +-----------+-------+-------+ | bin_floor | COUNT | bar | +-----------+-------+-------+ | 0 | 12 | ** | | 2500 | 11 | ** | | 5000 | 1 | | | 7500 | 14 | *** | | 10000 | 3 | * | | 12500 | 4 | * | | 15000 | 6 | ** | | 17500 | 8 | ** | | 20000 | 14 | *** | | 22500 | 13 | *** | | 25000 | 13 | *** | | 27500 | 9 | ** | | 30000 | 14 | *** | | 32500 | 35 | **** | | 35000 | 61 | **** | | 37500 | 203 | ***** | | 40000 | 20 | *** | +-----------+-------+-------+ 17 rows in set (0.212 sec) -> WHERE User_Name = 'CA3LE' AND Test_Type = 'download' AND `Date` > '20240101000000' AND `User_Host` = 'comcast_cable' +-----------+-------+------+ | bin_floor | COUNT | bar | +-----------+-------+------+ | 0 | 48 | **** | | 25000 | 17 | *** | | 50000 | 7 | ** | | 75000 | 10 | ** | | 100000 | 26 | *** | | 125000 | 31 | *** | | 150000 | 35 | **** | | 175000 | 21 | *** | | 200000 | 25 | *** | | 225000 | 29 | *** | | 250000 | 22 | *** | | 275000 | 21 | *** | | 300000 | 24 | *** | | 325000 | 36 | **** | | 350000 | 35 | **** | | 375000 | 23 | *** | | 400000 | 18 | *** | | 425000 | 25 | *** | | 450000 | 33 | *** | | 475000 | 44 | **** | | 500000 | 22 | *** | | 525000 | 2 | * | | 550000 | 4 | * | | 575000 | 6 | ** | | 600000 | 9 | ** | | 625000 | 8 | ** | | 650000 | 10 | ** | | 675000 | 13 | *** | | 700000 | 15 | *** | | 725000 | 22 | *** | | 750000 | 9 | ** | | 775000 | 12 | ** | | 800000 | 20 | *** | | 825000 | 13 | *** | | 850000 | 3 | * | | 875000 | 1 | | +-----------+-------+------+ 36 rows in set (0.177 sec) Optimal bin size will vary case by case, I'll give you some control over all of that. "bar" is there just for visual reference in the query, the charts will be drawn from the count and be better represented in the final output to the client. These are just raw returned queries. Now I have to build it into something. But this shows how I can easily return a histogram, at the mysql level.

The latest update didn't have any changes to multithread so if you're seeing lower results there is another reason. Keep in mind, speedtest.net ≠ testmy.net. Compare with the beta on vs off. You should get very similar results comparing against similar variables using the new vs legacy tests.

Very nice. Expected, right in line with your results from the production version. If you'd like to use the previous behavior and test multithread you can always Tune ☆ and toggle the option.

You can but the system may disallow you or kick you out. I used to be more free with that stuff but it was too heavily abused. Originally I actually designed all the URLs to be driven by other's remote programs. I have another beta for a program you may be interested in. Called My Sensor, once enabled it gives you remote control over any computer that you visit TMN on. You can then just let it run, send remote test commands and get a constant stream of data on the connection. Uses almost no bandwidth (unless you tell it to test). --- it's been a very difficult project and I'm not ready to share it yet. I've personally been running it non-stop for over 4 years, works awesome really. Keeps getting better but it's still not ready for prime time yet. The linear upload is working in the beta now. As for your export options, I still need to build that out. Went on a tangent with the linear upload test. 🤣 🤪 I did notice that the columns that I'm saving those numbers to need to be altered. The pre-planned extra columns I used are int and I need them to be decimal. A problem because the numbers are in MB/s (saves a little space in the database being a smaller number). When it's saved in an int column it causes the number to be rounded. 5.49 MB/s may become 5 MB/s for example. An over 7 Mbps difference, which is unacceptable. So I need to alter that table. Your (high/low) results before I make that change will be rounded. Yes, I could just store that in Mbps on those columns and call it a day but that would bother me. Alter table is easy now in beta, much harder when it's live with millions of results. The beta has still only run less than 2 days worth of tests that the production version does. I'll get that table altered and then build out the functionality to go with it over the next few days.

I'll keep searching for a solution. When I try to run the command I would need to use, I get this... ca3le@Damons-2020-iMac js % sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport scan WARNING: The airport command line tool is deprecated and will be removed in a future release. For diagnosing Wi-Fi related issues, use the Wireless Diagnostics app or wdutil command line tool. The best solution would be to have the 2.4 and 5 GHz networks on separate SSIDs. Then just don't add the 2.4 GHz network to your laptop. But that's not always possible. Like with my Netgear Orbi. It's always dual band and gives me no control. Total garbage. But that's what we have to work with sometimes. There has to be a new solution! Let's make sure that's the case first. That just rang the bell as a possibility due to the symptoms.

This beta started as a request for a multithread upload test. Funny and ironic that the hardest part to implement in this version was the Linear (single thread) Upload. The "Linear" option has been removed and you'll now see a "Multithread" toggle under Tune ☆. Multithread and Linear now work with both test types. Hope you find this useful.

I'm looking at your results. Drops to a fairly consistent 200 Mbps level. Maybe... the newer software is for some reason connecting you to the 2.4 GHz wifi (intermittently) but then when you restart wifi or the computer you're getting connected to 5 GHz? Check the network details next time it's running weird. Hold [Option] + click the wifi icon and it will show you details.

ahhh, "My Average" is taking the last 25 results into consideration. That's a direct copy of how it's currently done. This also filters your results by identifier and host. So when you're on Spectrum you'll get an average of only those results, when you're on Verizon you'll get an average of your Verizon results. Same is true if you visit on a desktop, android or iOS. You'll only compare similar results. But that's only for "My Average" -- the ISP and location are taking into account all results and come from a continuous 15 minute average that runs for all databases. Those numbers constantly fluctuate with the current average user's performance.

The graph points are averaged with the previous two graph points. I explain this on the download and upload test pages, if you scroll down with the beta enabled. https://testmy.net/upload#test-info The current version plots each point without any averaging, the timing are more raw but it also makes it prone to more anomalies. In the beta, the 15% progress is actually an average of over a dozen data points... the next point at 30% then does the same calculation and then averages that result with the previous. At 45% it does the same thing except it includes the previous two points. The remaining points continue to average with the previous two points. Unfortunately this lowers the resolution but it draws better graphs consistent with what's happening. Better for a live graph in this situation in my opinion. The final result does not take any of that graph data into account, using only the start and stop times. True for all versions. Note: If you Tune ☆ "50th Percentile Result" the result will be calculated from the graph data.

Yes and no... for right now. For download it's enabled by default for upload it only works with multithread... until I push my next update. You may have already read this topic on it. I got it fully working just last night. As soon as the linear upload test is available in the beta, it will be the default option. When you toggle the multithread option it will affect both upload and download tests.

sweet. As soon as I posted my response to you on Wednesday I got into building the single thread upload test into the new version. That inconsistency has been driving me nuts, that it's missing that super important element. That's what makes TMN different. It's been insanely hard to work that into the new test. The new version was first built as a multithread test in proof of concept - @xs1 requested a multithread upload test. Adding the single thread download test to that was simple, bing-bang-boom. But the single thread upload test is at least 10 times as hard to program. Even though it's already built... working it into the new program has been a challenge for sure. Anyways, I did it. It works really good too, graphing the results. Stripped to the essential functions. Tested it up to 500 MB... works awesome. I'll publish the update soon. I'm stoked!

Thank you. Not possible yet, I need to rewrite the export program and modify the db_search tool for it to be able to read the data. You've run enough tests to give me some good data to work from. I need to think about it for a little bit and then I'll get crackin'. I see your upload speed on the beta is much higher. This is because it's multithreaded, opening concurrent connections. Look like Starlink favors that... but you should still periodically run tests with the current upload test. I'm working to make the single thread upload test work with the beta, it better represents what you can expect to get in a single stream or file download. Multithreading can be misleading... unless that's how you use your connection. A bunch of smaller, concurrent uploads and downloads... I do that sometimes, with torrents or just having a lot of devices... but most of the time, when I care, it's a single file I'm waiting on. Single threaded performance is always at the core most important, in all computing. You're seeing 20-30 Mbps multithreaded but only 5 Mbps in a single thread operation. I personally call that 5 Mbps, not 20. In other words, you need to open 4-6 multiple uploads to get up to speed. But if you wanted to stream video, you'd want to keep it under 5 Mbps (I'd say 3 Mbps to be safe)... because it won't be able to handle more than that. I want to give people the bigger number for bragging rights but that doesn't help anyone. The only way to improve is to know the truth. So if you're curious why the results are so much greater, it's because it's not the same test. The current beta is my first multithreaded upload test, completely different method and way that the data is uploaded. Gives your connection opportunity to stretch its legs a bit more. Both tests are valid and important information. Tested from different perspectives. Download has both single (linear) and multithreaded in both versions, toggle that setting under "Tune ☆".

Maximum column has also been added. The beta is now open to all members, just visit My Settings and toggle the button. I hope you like it.

Hi @Sencinet -- Welcome! I can see how this will be very helpful. It's not easily possible with the current version. But the beta has better database structure, more is possible. I've added a minimum column and it's saving that data with the result. After you've gathered some results with the beta I'll program some tricks to make it do what you're looking for. A new column needed to be added to do this most efficiently. I'll probably add a button that says "show minimum speeds" -- you'll then be able to use TMN's normal graphing functions and export to CSV. BTW, the beta version does a pre-test to warm up the connection, which is additionally beneficial in this instance. The minimum I'm saving is only taken from the final result, not pre-test.

Hi Rod, I'm happy to see that you're still visiting. I was optimizing the query structure of the database search. This presented a new problem because now certain calculations are done later in the process. Not really an issue, we can work with that, especially given the performance gains of dropping 2/3 of the queries... except I can't tell if there should or shouldn't be a graph displayed early enough in the process to generate the page structure the way I wanted. A problem easily solved if it was a single graph. Instead of just making it work... I rebuilt it into a single graph. Along the way I finally solved the x-axis / y-axis. There are two separate y-axis for speed and then two x-axis for date. The dates align with each other properly now on the x-axis no matter what the situation. This update also makes DB search query much faster for members like you with over 100,000 results. My testing saw no less than 2X increase in speed, some queries saw as much as 6X improvement. Once I thought of how it could be done (early yesterday) it was mostly a matter of reorganizing. Still a good 20-30 hours of programming, lol. Numerous other bug fixes, more complex queries are possible. Thank you @Pgoodwin1 for the suggestions, got the juices flowing. Thank you @rrr10 -- sorry it took >5 years to program your suggestion. It's a harder problem than I ever could have imagined. No examples to go off of, very little documentation of this very specific use case. I guess not very many people want to combine charts in this way... well, I like it. I can see how it will help people understand results better. I hope you like it too.