Subject: Efficiency of caller/toss

From: John Goerzen <[email-masked]>
Date: Wed, 18 Aug 2021 08:56:41 -0500

Hi,

So while looking into the question of "how could I have the 
quickest delivery and execution of packets between machines on a 
LAN", I started looking at nncp-caller and nncp-toss under strace.

I observed:

1) With nncp-toss, or nncp-caller with autotoss, each cycle 
involves opening directories, creating a lock file, and removing 
the lock file.  It also stats hdr files, of which I seem to have 
several thousand laying about for some reason.

2) nncp-caller seems to be doing frequent calls to nanosleep, 
futex, clock_gettime, and epoll while it has a connection to a 
remote.  (very quiet when it doesn't).  I'm going to assume that 
nncp-daemon does also, but I haven't checked that yet.  Although 
this looks bad-ish in strace, as a practical matter, it's about 
number 10-20 in my top list.  Firefox is far more expensive in 
background than it is.  So this may not be a huge deal, at least 
for one persistent connection.

The broad question is: what is the most efficient way to do fast 
data exchange?  (Efficient in terms of both SSD life and battery 
life on a laptop)

I have been using persistent connections (very high onlinedeadline 
and maxonlinetime) with nncp-caller, even when that's not strictly 
necessary, reasoning that there is no particular overhead for 
establishing a new connection periodically and all the logging 
associated with that.  However, if nncp-caller is using CPU 
time/battery power to maintain that, then perhaps I'm a bit off 
there.  (Though it does seem to be negligible)

The bigger question is around tossing.  Does autotoss do something 
more restrictive than nncp-toss (perhaps only toss from a 
particular machine)?  Is there a way, since autotoss is in-process 
with nncp-caller, to only trigger the toss algorithm when a new 
packet has been received, rather than by cycle interval?

One other concern about a very short cycle interval is that a 
failing packet can cause a large number of log entries.  (86,400 
per day with the default 1-second interval).  That failing packet 
could be, eg, sending a file to a box that won't accept it, using 
the wrong name for nncp-exec, or just a failure in what nncp-exec 
starts up.  For that reason, I have often used a higher cycle 
count.  If autotoss could only run after new packets, that would 
be helpful to reduce this.

A final question about when-tx-exists being true.  I am a bit 
unclear how that interacts with cron.  Is it:

1) Calls are made both when cron says to, AND when a new packet is 
queued (when-tx-exists triggers MORE calls than cron alone);

or

2) Called are made only when cron says to, but only if an outgoing 
packet exists.  (when-tx-exists causes FEWER calls than cron 
alone)

I'm guessing it's #2 but I'm not certain.

Thanks again!

- John