randbuff

I wonder why you're getting that error.  I've never seen or heard of that.  Does anyone else see that?  --- it's the same address you end up at when you do a download test... it's obviously not really missing.
 
The multithreading currently only works with the download test... I know, the upload results while you have that turned on say otherwise... I just haven't had a chance to fix that.  I'll be looking at rebuilding the upload test to allow multithreading soon.
 
Seems like bandwidth shaping is becoming common practice. Using the two testing methods can help users discover this about their connections.  I still believe that your true download speed is the speed rated by TMN's default, classic method... multithread is nice to know the capabilities of the connection but the linear load (as I guess I'm calling it) is a better judge of the real download speed you could expect to see in a normal transfer.  Many issues that slow users down are often masked by multithreading, so I plan on leaving the linear method as default.
 
... 85.5 Mbps down... very nice.  Here's what I just got with the same test.
 

 
And dude, my results with the upload test suck too. But unfortunately it's the truth.
 

 
I look at the activity monitor and see that I peaked twice as high as that number during the test.  But if you look at the entire transfer from start to finish... the number output by TMN is totally on the money.  It sucks, but you have to take the entire result into consideration.  I started at 200 kB/s, 600 kB/s, 800 kB/s, 1 MB/s, 2.2 MB/s .... that's just the numbers I saw come in on a 2 second polling... average them... I arrive at 960 kB/s.  Trust me, TestMy.net's calculation is much more precise that averaging the 2 second polling off my network controller.   ... I don't like the numbers it tells me sometimes either, but they're always accurate.
 
Sometimes I get better upload speed on this connection...
 

 
Realize that the end time of the test come before that /results address is executed.  By that time your score already calculated and about to be logged to the database... any lag will not effect the outcome.   Furthermore, the end time calculation is server-side.  As soon as the transfer is complete and that part of the program starts to execute... the calculation is actually done.  It might say calculating on your screen but trust me, once you see that... it's already done microseconds earlier and nothing can change the result.     ... in the past it was an issue, I rewrote it since.
 
My aim in the rebuild of the upload speed test is do bring the TiP system into the upload results and finally add a progress bar.  I think once you can see the details of how the data flowed during the test, the minimum speed, maximum and middle average... it will open some eyes as to why the scores here are so harsh.    ... it evaluates everyone the same... if there is a problem with it, me and other people wouldn't post some of the insane scores we do... also realize that the transfer file size maxes out at only 33MB, once that size is raised the accuracy for faster connections is raised.
 
... Many people hosting online video streaming use the upload test here because they say it's a quick and accurate gauge of the true maximum upload bandwidth potential in a video stream.  They take the number output by TMN and adjust their stream just below that and it works perfectly for them. That way they get the highest quality their connection can handle.  ... they tell me that other tests out there can't be relied upon.  So it must be doing something right.