<div dir="ltr"><div><div>It's strange that the third stream pushed the SIIT further when the NAT64 was already at 100% it the second stream. I'd have expected the load to be the same  since the NAT64 could not, in theory, send the SIIT any more packets. Or am I misunderstanding something?<br><br></div>Also, I'm really stumped that you managed to peak using only two streams. This should render all database lookups practically instantaneous. If this is the case then... yeah. I guess there's not much I will be able to do from code.<br><br></div><div>But we'll see.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 15, 2017 at 12:18 PM, Alan Whinery <span dir="ltr"><<a href="mailto:whinery@hawaii.edu" target="_blank">whinery@hawaii.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <br>
    Sort of a digression, but since Alberto referred to Linux router
    performance -- <br>
    <p>After I got the Jool/Jool v6-only NAT64/bitw-464CLAT scenario
      working, I tried some file transfers at 100 Mbps to v4-numeric
      addresses, so it was hitting both boxes (VMs, actually).  Watching
      the software interrupt load with top, I was getting around 10%
      load on the first 100 Mbps stream and a second stream pushed NAT64
      to 100% load on SI, while CLAT was only doing about  30%, third
      stream 100% NAT64, 90% CLAT. <br>
    </p>
    <p>Attached PDF is what I wrote when I still remembered, about
      increasing cores and spreading CPU affinity to mitigate. <br>
    </p>
    <p>The point being that there are things to be understood about
      Linux router performance, in tandem with NAT64/SIIT performance.
      For one, rolling in the right off-loading, coalescence, etc, as
      well as CPU affinity to tune the box like a router, rather than as
      a host. This stuff is might be a problem well before you get to
      the network scale that has been tested with TRex.<br>
    </p><div><div class="h5">
    <br>
    <div class="m_1196453893782140520moz-cite-prefix">On 9/15/2017 5:49 AM, Alberto Leiva
      wrote:<br>
    </div>
    </div></div><blockquote type="cite"><div><div class="h5">
      <div dir="ltr">
        <div>
          <div>
            <div>Thank you!<br>
            </div>
            <div><br>
              > One thing I have been wondering about is if the TRex
              side gets confused and Jool is actually ok. If that is the
              case then I apologise!<br>
              <br>
            </div>
            <div>Well, who knows. I'm thinking that, if a normal Linux
              router would pass a similar test but a NAT64 Linux with
              Jool doesn't, then there should in theory be something
              that can be done.<br>
            </div>
            <div><br>
              > What would be the best way to check that? Massive
              pcaps?<br>
              <br>
            </div>
            I will compile a version with a bunch of timestamp tracking
            and see if we can get some conclusions out of it.<br>
            <br>
          </div>
        </div>
        Working...<br>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Fri, Sep 15, 2017 at 5:24 AM, Sander
          Steffann <span dir="ltr"><<a href="mailto:sander@steffann.nl" target="_blank">sander@steffann.nl</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
            <span><br>
              > Okay, guys. Prototype ready. I didn't test a
              gazillion connections, but as far as basic functionality
              goes, it looks stable. Don't quote me on that, though.<br>
              ><br>
              > Experimental branch in fake-nat64, in case anyone
              wants to try it out: <a href="https://github.com/NICMx/Jool/tree/fake-nat64" rel="noreferrer" target="_blank">https://github.com/NICMx/Jool/<wbr>tree/fake-nat64</a><br>
              <br>
            </span>Sorry, it still collapses :(<br>
            <br>
            I recorded a small test here: <a href="http://www.steffann.nl/sander/Fake%20NAT64%20collapse.mov" rel="noreferrer" target="_blank">http://www.steffann.nl/sander/<wbr>Fake%20NAT64%20collapse.mov</a><br>
            <br>
            The behaviour is really strange. One thing I have been
            wondering about is if the TRex side gets confused and Jool
            is actually ok. If that is the case then I apologise! What
            would be the best way to check that? Massive pcaps?<br>
            <br>
            Cheers,<br>
            Sander<br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="m_1196453893782140520mimeAttachmentHeader"></fieldset>
      <br>
      </div></div><span class=""><pre>______________________________<wbr>_________________
Jool-list mailing list
<a class="m_1196453893782140520moz-txt-link-abbreviated" href="mailto:Jool-list@nic.mx" target="_blank">Jool-list@nic.mx</a>
<a class="m_1196453893782140520moz-txt-link-freetext" href="https://mail-lists.nic.mx/listas/listinfo/jool-list" target="_blank">https://mail-lists.nic.mx/<wbr>listas/listinfo/jool-list</a>
</pre>
    </span></blockquote>
    <br>
  </div>

<br>______________________________<wbr>_________________<br>
Jool-list mailing list<br>
<a href="mailto:Jool-list@nic.mx">Jool-list@nic.mx</a><br>
<a href="https://mail-lists.nic.mx/listas/listinfo/jool-list" rel="noreferrer" target="_blank">https://mail-lists.nic.mx/<wbr>listas/listinfo/jool-list</a><br>
<br></blockquote></div><br></div>