Indeed, I found just the same: the results are literally impossible. It urgently needs to be retired and out back into beta. Maybe it has some fudge factor in it to attempt to convert from TCP payload rate to IP PDU rate but the designer got that way wrong.
-Musing- If I were writing a speed tester then I certainly would not use TCP! Just complicates matters and means that you are not in control. I would aim a stream of UDP packets at the destination and then ramp up the speed slowly whilst observing the end to end transit time with the use of time stamps in the packets having synchronised clocks at the two ends. I would check for rising packet loss as well. And I would also check for anomalous variations in the transit time in order to pick up the presence of any alien traffic on various parts of the path.
MWould also need to check for cyclic variation in the transit time, in order to detect an unequal multi-path link, like mine, although my links are fortunately pretty close especially in downstream. Could do this probably either by putting transit times into bins or maybe by performing fourier analysis, whichever, something applied to the arrival times designed to detect a cycle that should be a staircase function with a small number of discrete levels plus some noise. Doing it right is not that easy. The reason for doing that would be so that the algorithm would not get fooled into thinking there is alien traffic because the arrival time keeps varying, when in fact it is due to the presence of an unequal multi path link.