XPost: alt.comp.os.windows-11   
   From: robin_listas@es.invalid   
      
   On 2025-09-09 14:13, 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.   
   >   
   > 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.   
      
   You are not listening either, he does want the latency time. That's his   
   question.   
      
   >   
   >> [...]   
   >> 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?"   
   >   
      
      
   --   
   Cheers, Carlos.   
   ES🇪🇸, EU🇪🇺;   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)