<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Dan,<br>
        as you say bummer.  Any idea when commotion will be moving to 
    version 2 of OLSRd ?<br>
        Also is there a work around the current behavior to link to the
    nearest node? or do we just have to live with it 'till a switch to
    version 2?<br>
    thanks for the info.<br>
    john<br>
    <br>
    <br>
    <a class="moz-txt-link-abbreviated" href="mailto:commotion-discuss-request@lists.chambana.net">commotion-discuss-request@lists.chambana.net</a> wrote the following on
    5/28/2014 11:00 AM:<br>
    <span style="white-space: pre;">> <br>
      > Hi John,<br>
      > <br>
      > As it currently works, OLSRd (the routing program we use) has
      a <br>
      > SmartGateway plugin to distribute gateways to the mesh.<br>
      > Unfortunately, the way this plugin works is to tell a node to
      use the<br>
      > nearest gateway it can find, without regard to the capacity
      or<br>
      > latency of that gateway compared to others. So, if my node is
      1 hop<br>
      > away from a slow gateway and 2 hops away from a fast gateway,
      it will<br>
      > always choose the slow gateway (assuming link quality is
      relatively<br>
      > homogeneous). Bummer, I know.<br>
      > <br>
      > The good news is that, if I recall correctly, version 2 of
      OLSRd has<br>
      > a much smarter way of choosing gateways, that does in fact
      take into <br>
      > account gateway characteristics. So once we move to OSLRd
      version 2, <br>
      > that problem will hopefully be alleviated.<br>
      > <br>
      > But for now, we'll have to work around that limitation.<br>
      > <br>
      > hope that helps!<br>
      > <br>
      > Dan<br>
      > <br>
      > On 05/26/2014 10:27 AM, john coleman wrote:<br>
      >> Our neighborhood mesh is small but growing steadily.  We
      have <br>
      >> gateways on the mesh that vary by about 10 fold in
      speed.  Can<br>
      >> someone explain if and how the commotion mesh distributes
      load<br>
      >> between the gateways and if those linked to the wireless
      routers on<br>
      >> the slow gateways can expect any speed increase because
      of the<br>
      >> distributed load? Using common speed test websites<br>
      >> (<a class="moz-txt-link-abbreviated" href="http://www.speedtest.net">www.speedtest.net</a> and <a class="moz-txt-link-abbreviated" href="http://www.bandwidthplace.com">www.bandwidthplace.com</a>) I see no
      gain in<br>
      >> speed by being linked to the mesh. However, I am unsure
      if those<br>
      >> types of speed tests are appropriate for a mesh network.
      When a<br>
      >> gateway goes down, the attached node switches to another
      gateway to<br>
      >> access the internet, as it should. But I can't see
      evidence that<br>
      >> nodes attached to slow gateways receive speed benefits by
      having <br>
      >> fast gateways on the mesh.  Any insights or pointers to,
      not too <br>
      >> technical, documentation? </span><br>
    <span style="white-space: pre;">thanks, </span><br>
    <span style="white-space: pre;">john </span><br>
    <span style="white-space: pre;">p.s. using PicoStation<br>
      >> M2-HPs  running grumpy cat 1.1rc1<br>
      >> <br>
      >> _______________________________________________
      Commotion-discuss<br>
      >> mailing list <a class="moz-txt-link-abbreviated" href="mailto:Commotion-discuss@lists.chambana.net">Commotion-discuss@lists.chambana.net</a> <br>
      >>
      <a class="moz-txt-link-freetext" href="https://lists.chambana.net/mailman/listinfo/commotion-discuss">https://lists.chambana.net/mailman/listinfo/commotion-discuss</a><br>
      > </span><br>
    <br>
    <br>
    <br>
  </body>
</html>