Different issues here, assuming the trick is to isolate the latency factors relating (or un-relating in this case) to a particular beam: 1. User location: The use of geoip to determine user's location from the IP, doesn't work at all on satellite internet. Conversely, if the device being tested has fairly good gps and signal you might be ok for that. I know the gps on my iPhone is a lot more accurate than the one in my MacBook Pro - could be a problem if you're on the edge of a beam footprint. There may be some outliers in their database in that regard, so this is kind of a minimal risk. 2. Gateway provider: Have noticed that a certain provider (CenturyLink) randomly inserts 1-2 minute gaps in service on a national scale. Such an inconsistency would significantly vary the results for a particular beam that always routes to a gateway. 3. TestMy server location: Different locations are going to create different paths from the gateway. Assuming the CL gaps aren't there, you'd have to create a standard where certain beam/gateway combinations would use a specific TestMy server. For example, beam 68/SDO gateway (San Diego) would need to use the closest server in LA, not the default one in Dallas, because it would generate fewer hops. Depending upon the backbone (again, thinking about CL, which services most of the country now) fewer hops would reduce the risk of anything corrupting the test. 4. Time: Congestion varies over time and you'd have to compare with others doing the test within the same timeframe. It's not a safe bet that you'll get enough people doing tests from the same beam in the same timeframe, unless it's pre-coordinated. If you can safely isolate these four things, the only thing left is latency due to beam congestion. Can be done, but it's just not real probable. Edit: Almost forgot another real important one: Latency tests over TestMy aren't that accurate to begin with, so don't know if you could trust it for a viable comparison.
... View more