XPost: alt.comp.os.windows-11   
   From: dan@djph.net   
      
   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.   
      
   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?"   
      
   --   
   |_|O|_|   
   |_|_|O| Github: https://github.com/dpurgert   
   |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)