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?
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. But we'll see. On Fri, Sep 15, 2017 at 12:18 PM, Alan Whinery <[email protected]> wrote: > > Sort of a digression, but since Alberto referred to Linux router > performance -- > > 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. > > Attached PDF is what I wrote when I still remembered, about increasing > cores and spreading CPU affinity to mitigate. > > 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. > > On 9/15/2017 5:49 AM, Alberto Leiva wrote: > > Thank you! > > > 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! > > 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. > > > What would be the best way to check that? Massive pcaps? > > I will compile a version with a bunch of timestamp tracking and see if we > can get some conclusions out of it. > > Working... > > On Fri, Sep 15, 2017 at 5:24 AM, Sander Steffann <[email protected]> > wrote: > >> Hi, >> >> > 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. >> > >> > Experimental branch in fake-nat64, in case anyone wants to try it out: >> https://github.com/NICMx/Jool/tree/fake-nat64 >> >> Sorry, it still collapses :( >> >> I recorded a small test here: http://www.steffann.nl/sander/ >> Fake%20NAT64%20collapse.mov >> >> 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? >> >> Cheers, >> Sander >> >> > > > _______________________________________________ > Jool-list mailing > [email protected]https://mail-lists.nic.mx/listas/listinfo/jool-list > > > > _______________________________________________ > Jool-list mailing list > [email protected] > https://mail-lists.nic.mx/listas/listinfo/jool-list > >
_______________________________________________ Jool-list mailing list [email protected] https://mail-lists.nic.mx/listas/listinfo/jool-list
