XPost: alt.comp.os.windows-11   
   From: daniel47@somewhere.someplaceelse   
      
   On 9/09/2025 10:13 pm, Dan Purgert wrote:   
   > On 2025-09-09, Daniel70 wrote:   
   >> On 9/09/2025 12:43 am, Lew Pitcher wrote:   
   >>> On Tue, 09 Sep 2025 00:24:30 +1000, Daniel70 wrote:   
   >>>> On 8/09/2025 11:43 pm, Lew Pitcher wrote:   
   >>>>> On Mon, 08 Sep 2025 23:24:12 +1000, Daniel70 wrote:   
   >>>>>> On 8/09/2025 10:21 pm, Dan Purgert wrote:   
   >>>>>>> On 2025-09-08, Daniel70 wrote:   
   >>>>>>>> [...] Which got me thinking ..... How do "they" Speed-test   
   >>>>>>>> Internet Links?? .. particularly How do 'they' distinguish   
   >>>>>>>> the Up-link TIME from the Down-link TIME?? e.g. my current   
   >>>>>>>> speeds, using Speedtest [...]   
   >>>>>>>   
   >>>>>>> For the most part, a speedtest works by you downloading a   
   >>>>>>> file of known size (say 100 MiB), and then sending it back.   
   >>>>>>> Exact file size will vary by testing provider, but   
   >>>>>>> essentially it's just this:   
   >>>>>>>   
   >>>>>>> Download start = 0.00 Download end = [TIME]   
   >>>>>>>   
   >>>>>>> File size / TIME = X Mbit / sec   
   >>>>>>   
   >>>>>> But how does the distant end know when I have received the   
   >>>>>> entire file (i.e. Download end time)??   
   >>>>>>>   
   >>>>>>> Upload Start = 0.00 Upload end = [TIME]   
   >>>>>>>   
   >>>>>>> File size / TIME = Y Mbit / Sec   
   >>>>>>>   
   >>>>>> Similarly, how does the distant end know when my computer   
   >>>>>> started the Upload (Upload start time)??   
   >>>>>   
   >>>>> The transfers typically use TCP, and that protocol includes   
   >>>>> feedback from the receiving end as to whether or not it has   
   >>>>> received the data sent. Typically, this feedback is in small   
   >>>>> enough packets that transmission latency doesn't affect the   
   >>>>> overall throughput measurement enough to matter.   
   >>>>>   
   >>>>> In theory, only one end has to make the timing measurements; It   
   >>>>> can be the sending end, or the receiving end.   
   >>>>>   
   >>>>> For sending-end measurement, the sender - starts the clock -   
   >>>>> sends a known amount of data to the receiver, obeying the   
   >>>>> receiver's TCP flow-control requests - stops the clock at the TCP   
   >>>>> FIN/FIN-ACK end-of-data acknowledged - computes elapsed time -   
   >>>>> computes upload transfer rate (known amount of data / computed   
   >>>>> elapsed time)   
   >>>>   
   >>>> O.K., so my computer sends my Start time, then a certain amount of   
   >>>> Data (1kB, maybe), and then sends my computers End Time. So   
   >>>> including the clock times, totaling, maybe, 1.1kB.   
   >>>   
   >>> Nope. Your computer neither sends "Start time" nor "End time". It   
   >>> simply sends data via TCP to the other system.   
   >>>   
   >>> Your system opens a TCP connection to the OTHER SYSTEM, and when the   
   >>> OTHER SYSTEM receives that TCP connection request from your system,   
   >>> the OTHER SYSTEM notes the start time.   
   >>>   
   >>> As your system sends data, the OTHER SYSTEM receives it, and   
   >>> measures how much data it received.   
   >>>   
   >>> When your system finishes sending data, it closes the TCP   
   >>> connection, which sends a TCP "all done" control message to the OTHER   
   >>> SYSTEM. When the OTHER SYSTEM receives that "all done" control   
   >>> message, it records the "End time", computes the elapsed time and   
   >>> volume of data, and then computes the throughput.   
   >>   
   >> YEAP!! Undergerstumble!! But did my data travel via Undersea Co-ax or   
   >> via Low Earth orbit Satellite or via High Earth orbit Satellite ..... or   
   >> via one of those reflector Panels (supposedly) left on The Moon by the   
   >> Apollo Astronauts??   
   >>   
   >   
   > It doesn't matter - throughput is not latency.   
      
   But I'm not really interested in throughput OR latency but how long it   
   takes to get from A (my place) to B (test site) .... and then how long   
   it takes to get from B (test site) to A (my place).   
      
   > If I'm receiving from you:   
   > 1. I know I got the first packet at (UNIX TIME) 1757418187   
   > 2. I know I got the last packet at (UNIX TIME) 1757418287   
   > 3. I know the file size was 100 MB   
   > 4. Therefore I calculate the rate as   
   >      100MB / (1757418287 - 1757418187)   
   >      800Mbit / 100 sec = 8 mbit/sec   
   >   
   > Or if I'm sending to you   
   > 1. I know I sent the first packet at (UNIX TIME) 1757418187   
   > 2. I know I sent the last packet at (UNIX TIME) 1757418287   
   > 2.1 I got the last ACK 20 milliseconds later, and throw it away because   
   >      it doesn't matter.   
   > 3. I know the file size was 100MB   
   > 5. Therefore I calculate the rate as   
   >      100 MB / (1757418287 - 1757418187)   
   >      800 Mbit / 100 sec = 8 mbit / sec   
   >   
   >> [...]   
   >> Data transfer time. How loan AFTER I started sending did YOU start   
   >> receiving??   
   >   
   > For the most part, latency doesn't matter -- we're talking some tens of   
   > milliseconds for a full round trip against some tens or hundreds of   
   > seconds to transfer the test file.   
   >   
   >   
   >> Most likely .... How do "they" determine my 'Upload Speed' and then how   
   >> do "they" determine my "Download Speed"??   
   >   
   > We've told you a dozen times, you're just not listening.   
   >   
   >> [...]   
   >> How fast can I get from my Home to the Airport and then back Home?? ;-P   
   >   
   > That would be the RTT / Latency, and doesn't matter when you're asking   
   > "what's the best way to get me, my 10 closest friends, all our luggage,   
   > and two dogs to the airport?"   
   >   
   But that's NOT what I'm asking, Dan, in this instance, I want to know   
   How fast can I get from my Home to the Airport and then back Home?? i.e.   
   FULL CIRCLE.   
      
   The Speed Test Site seems to be testing how long it took to get to the   
   Airport, though. ............ And then how long for me to get Home.   
   --   
   Daniel70   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)