Efficiency of caller/toss

John Goerzen
2021-08-18T13:57:54Z

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