Leaderboard

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!

Hi Ca3le I take some reviews using the the multithread and "single" test, and the single test is much better that multithreat, I am thinking on that, becouse have more servers saturating a connection must be the best option, but like satellite options using dynamic assignemt like tdma or fdma for upload and is a shared media looks that could be that Starlink protect itself for multitrhead delivery to protect his backbone. I test in other enviroments using a multiflows froma single source and give better results that using a single one, but I think the winner aproach is as you mention have a warm period, in other solution even delimite the measure time to try to only measure in the peak rate, like out a pause time of 10 second and meause only for 20 seconds. I will continue doing more test at leats for the next 3 weeks. Thanks

Thanks What a bunch of improvements, you are a rock star... How I can to donwnload a report of all test, with the min and max values? is posible? Thanks

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.