3D, I'll parse it out for you, as far as I understood it amidst the general personal attacks, because he finally explained it clearly in another thread: he says that pings are order of magnitude slower than you think, therefore your result in the "Japan experiment" probably pinged somewhere way closer to you than in Japan.
I absolutely agree that ping times will always be SLOWER than the speed of light. Over short distances (hundreds of miles) the delays through routers and switches dominates the ping time - so the results aren't much use. But over intercontinental distances, the times are dominated by the speed of light delays through the cables connecting us.
This means that the ping time can (and always IS) longer than the speed of light round trip. I do not deny that.
What is not "getting through" is that under no circumstances can it be FASTER than the round trip light-speed. So we can't use this technique to say "The distance between X and Y is Z kilometers" - but we can say "The distance between X and Y cannot be LONGER than Z kilometers". That may not be a particularly useful statement, but it is undoubtedly true...and that's what I claim.
Since all known FE maps drastically increase distances across oceans (mostly in the Southern Hemisphere) compared to RE maps - we may say: "The FE map says the distance between X and Y is N kilometers - but our 'ping' test proves that the distance must be less than Z kilometers. If N is greater than Z, then the Earth isn't flat.
Now, admittedly, the FE'ers do not claim to HAVE a map of the Earth - but we can say (definitively) that the ping times between Silicon Valley and Tokyo disprove both the unipolar and bipolar maps that have been shown here.
We can also use this tool to test whether future FE maps are at least superficially valid.
The idea that a computer somewhere between Silicon Valley and Tokyo actually returned my ping is ludicrous.
The entire purpose of having "ping" packets is to time the packet. The Internet protocol uses two special packet types - this protocol is also used for the "traceroute" tool - which allows you to figure out which computers are forwarding the ping messages to their destination.
I can use 'traceroute' to verify my ping distance...
1 ip-66-33-208-1.dreamhost.com (66.33.208.1) 2.282 ms 2.328 ms 2.359 ms
2 ip-208-113-156-13.dreamhost.com (208.113.156.13) 2.153 ms 2.186 ms 2.220 ms
3 ae1-0-bdr1-iad1.dreamhost.com (208.113.156.5) 0.207 ms ip-208-113-156-9.dreamhost.com (208.113.156.9) 0.169 ms ae1-0-bdr1-iad1.dreamhost.com (208.113.156.5) 0.178 ms
4 xe-2-1-0.er5.iad10.us.above.net (208.185.23.133) 0.307 ms ae-65.a03.asbnva02.us.bb.gin.ntt.net (129.250.196.241) 0.667 ms xe-2-1-0.er5.iad10.us.above.net (208.185.23.133) 0.465 ms
5 ae-70.r05.asbnva02.us.bb.gin.ntt.net (129.250.5.195) 38.457 ms 38.258 ms ae16.er4.iad10.us.zip.zayo.com (64.125.31.78) 0.802 ms
6 zayo-ntt.iad10.us.zip.zayo.com (64.125.14.70) 6.457 ms ae-10.r22.asbnva02.us.bb.gin.ntt.net (129.250.2.21) 0.875 ms ae-2.r22.asbnva02.us.bb.gin.ntt.net (129.250.2.120) 1.025 ms
7 ae-69.r06.asbnva02.us.bb.gin.ntt.net (129.250.5.193) 35.608 ms 35.821 ms ae-69.r05.asbnva02.us.bb.gin.ntt.net (129.250.5.191) 37.130 ms
8 ae-2.r22.asbnva02.us.bb.gin.ntt.net (129.250.2.120) 0.593 ms ae-2.r10.dllstx09.us.bb.gin.ntt.net (129.250.4.82) 38.641 ms ae-10.r22.asbnva02.us.bb.gin.ntt.net (129.250.2.21) 0.529 ms
9 ae-0.a00.dllstx04.us.bb.gin.ntt.net (129.250.4.170) 42.566 ms ae-1.a00.dllstx04.us.bb.gin.ntt.net (129.250.4.202) 42.497 ms ae-6.r22.dllstx09.us.bb.gin.ntt.net (129.250.5.12) 38.267 ms
10 192.80.16.162 (192.80.16.162) 36.848 ms 36.984 ms 40.931 ms
11 * ae-0.a00.dllstx04.us.bb.gin.ntt.net (129.250.4.170) 36.889 ms ae-1.a00.dllstx04.us.bb.gin.ntt.net (129.250.4.202) 36.864 ms
12 192.80.16.162 (192.80.16.162) 35.483 ms * *
Notice that the last few computers are xxxx.ntt.net - "NTT" is "Nippon Telegraph and Telephone Public Corporation"...which clearly shows that my traceroute definitely made it to Japanese soil - and the time between the last US node and the first NTT site is the one where the ping time jumps from 6-ish milliseconds up to 36-ish milliseconds.
This is CLEAR evidence that my packet really did cover no less than the distance claimed.
Short-circuiting a 'ping' (eg by having some intermediate computer return the ping ahead of the final destination) would break a whole lot of the Internet's most important parts. It categorically does not happen...and traceroute shows that it didn't happen in this case.
I agree that timing (say) an HTTP request and response wouldn't prove a darned thing - because all manner of intermediate computers might choose to cache the result and return it to you quicker than the destination computer might have done. But ping message types are sacrosanct. NOBODY screws with those!
Read:
https://tools.ietf.org/html/rfc1122(The bottom of page 41 and on into 42).