public inbox for
Atom feed
* Efficiency of caller/toss
@ 2021-08-18 13:56 John Goerzen
  2021-08-18 18:14 ` Sergey Matveev
  0 siblings, 1 reply; 13+ messages in thread
From: John Goerzen @ 2021-08-18 13:56 UTC (permalink / raw)
  To: nncp-devel


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);


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

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

Thanks again!

- John

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2021-09-02 13:35 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-18 13:56 Efficiency of caller/toss John Goerzen
2021-08-18 18:14 ` 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