<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 14/05/2023 6:55 pm, David Lang
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:728orr66-1432-751p-263q-sqopr12s20sq@ynat.uz">
      
      <br>
      I just discovered that someone is manufacturing an adapter so you
      no longer have <br>
      to cut the cable<br>
      <br>
      <a href="https://www.amazon.com/YAOSHENG-Rectangular-Adapter-Connect-Injector/dp/B0BYJTHX4P" moz-do-not-send="true">https://www.amazon.com/YAOSHENG-Rectangular-Adapter-Connect-Injector/dp/B0BYJTHX4P</a><br>
      <br>
    </blockquote>
    <p>I'll see whether I can get hold of one of these. Cutting a cable
      on a university IT asset as an academic is not allowed here,
      except if it doesn't meet electrical safety standards.</p>
    <p>Alternatively, has anyone tried the standard Starlink Ethernet
      adapter with a PoE injector instead of the WiFi box? The adapter
      above seems to be like the Starlink one (which also inserts into
      the cable between Dishy and router).</p>
    <blockquote type="cite" cite="mid:728orr66-1432-751p-263q-sqopr12s20sq@ynat.uz">
      > Put another way: If you have a protocol (TCP) that is
      designed to reasonably <br>
      > expect that its current cwnd is OK to use for now is put into
      a situation <br>
      > where there are relatively frequent, huge and lasting step
      changes in <br>
      > available BDP within subsecond periods, are your underlying
      assumptions still <br>
      > valid?<br>
      <br>
      I think that with interference from other APs, WIFI suffers at
      least as much <br>
      unpredictable changes to the available bandwidth.<br>
    </blockquote>
    Really? I'm thinking stuff like the sudden addition of packets from
    potentially dozens of TCP flows with large cwnd's?  <br>
    <blockquote type="cite" cite="mid:728orr66-1432-751p-263q-sqopr12s20sq@ynat.uz">
      <br>
      > I suspect they're handing over whole cells, not individual
      users, at a time.<br>
      <br>
      I would guess the same (remember, in spite of them having launched
      >4000 <br>
      satellites, this is still the early days, with the network
      changing as more are <br>
      launching)<br>
      <br>
      We've seen that it seems that there is only one satellite serving
      any cell at <br>
      one time. </blockquote>
    But the reverse is almost certainly not true: Each satellite must
    serve multiple cells.<br>
    <blockquote type="cite" cite="mid:728orr66-1432-751p-263q-sqopr12s20sq@ynat.uz">But
      remember that the system does know how much usage there is in the
      <br>
      cell before they do the handoff. It's unknown if they do anything
      with that, or <br>
      if they are just relaying based on geography. We also don't know
      what the <br>
      bandwidth to the ground stations is compared to the dishy.<br>
    </blockquote>
    Well, we do know for NZ, sort of, based on the licences Starlink has
    here. <br>
    <blockquote type="cite" cite="mid:728orr66-1432-751p-263q-sqopr12s20sq@ynat.uz">
      <br>
      And remember that for every cell that a satellite takes over, it's
      also giving <br>
      away one cell at the same time.<br>
    </blockquote>
    Yes, except that some cells may have no users in them and some of
    them have a lot (think of a satellite flying into range of
    California from the Pacific, dropping over-the-water cells and
    acquiring land-based ones).<br>
    <blockquote type="cite" cite="mid:728orr66-1432-751p-263q-sqopr12s20sq@ynat.uz">
      <br>
      I'm not saying that the problem is trivial, but just that it's not
      unique<br>
    </blockquote>
    What makes me suspicious here that it's not the usual bufferbloat
    problem is this: With conventional bufferbloat and FIFOs, you'd
    expect standing queues, right? With Starlink, we see the queues
    emptying relatively occasionally with RTTs in the low 20 ms, and in
    some cases under 20 ms even. With large ping packets (1500 bytes).<br>
    <blockquote type="cite" cite="mid:728orr66-1432-751p-263q-sqopr12s20sq@ynat.uz">
      <br>
      David Lang<br>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
<a class="moz-txt-link-abbreviated" href="mailto:u.speidel@auckland.ac.nz">u.speidel@auckland.ac.nz</a> 
<a class="moz-txt-link-freetext" href="http://www.cs.auckland.ac.nz/~ulrich/">http://www.cs.auckland.ac.nz/~ulrich/</a>
****************************************************************



</pre>
  </body>
</html>