public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
From: John Goerzen <jgoerzen@complete•org>
To: nncp-devel@lists.cypherpunks.ru
Subject: Efficiency of caller/toss
Date: Wed, 18 Aug 2021 08:56:41 -0500 [thread overview]
Message-ID: <87v942zwiu.fsf@complete.org> (raw)
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
next reply other threads:[~2021-08-18 13:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-18 13:56 John Goerzen [this message]
2021-08-18 18:14 ` Efficiency of caller/toss Sergey Matveev
2021-08-18 19:20 ` John Goerzen
2021-08-18 19:29 ` Sergey Matveev
2021-08-20 2:24 ` John Goerzen
2021-08-20 10:28 ` Sergey Matveev
2021-08-20 19:19 ` John Goerzen
2021-08-21 18:38 ` Sergey Matveev
2021-08-23 14:10 ` Sergey Matveev
2021-09-02 9:06 ` Sergey Matveev
2021-09-02 13:07 ` John Goerzen
2021-09-02 13:34 ` Sergey Matveev
2021-08-20 10:23 ` Sergey Matveev