Broadband Related > ISPs

AA speedtester UI

(1/2) > >>

Weaver:
One weird thing about the UI layout of the the AA speedtester web app: on my iPad Pro 12" under Safari the appearance of it is most confusing because the go-for-it button is just off the bottom of the screen. When you fire it up there is just this useless display initially, showing meters for a speed test that hasn't happened yet! And there is nothing to tell you what to do, so it all just looks completely broken.

The entire thing is drawn way too large so that it does not fit on the display vertically. I am hoping that it could be fixed, by rescaling everything to be on the basis of 100% = main viewport size?
This would mean taking the x and y sizes of the actual viewport and obtaining the ratios of those with the x and y size of the box that bounds the proposed image to be drawn, and then rescaling down according to the lesser scaling factor whether the display is not wide enough or not tall enough, while of course maintaining aspect ratio. So in my case it would be the height that determines the scaling factor and the meters would have to occupy rather less than the total width of the viewport.

chenks:
it's probably not designed with an ipad in mind, as you wouldn't (or shoulnd't) be doing speedtest over WIFI anyway.

Weaver:
Well, they don't know in advance what size of display some random user has, iPad or not, and it makes no sense drawing images that are simply too large. My iPad Pro has far more pixels than any desktop display that I have ever used, don't know what the numbers are but they are fairly mind blowing. It would perhaps have been ok in portrait mode. It is just good intelligent design vs laziness and the use of random magic constants. If the designers had been my underlings at work, they would have just been educated in fluid layout and required to rework the code. :-)

And since my wireless LAN is 250-300Mbps but my DSL link is only about 8 Mbps, then I am not too worried.

burakkucat:
I tried it some weeks ago and found the UI not that U-friendly.  :no:

I tried all of the operational modes for the test and each & everyone of them returned a throughput greater than my synchronisation speed. As a result, it was kicked into the far corner of my "litter-tray" . . .  ::)  ;)

Weaver:
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.

Navigation

[0] Message Index

[#] Next page