rns.recipes

This release focuses on dataplane control, memory bounding and transport throughput, with adaptive ingress and egress control for interfaces, a new (and very efficient) zero-copy coalescing transmit buffer, an optimized HDLC deframer, and a range of other improvements to the inbound packet processing paths. It also introduces support for live profiling, and various new diagnostics output in rnstatus, along with a number of bug fixes and general improvements.

Changes

• Added adaptive dataplane egress control
• Added adaptive dataplane ingress control
• Added zero-copy coalescing transmit buffers to interfaces using the BackboneInterface backend
• Added early protocol violation checks for invalid frames
• Added transport implementation name and version to discovery information requirements
• Added full live profiling to the built-in Profiler primitive, by K8
• Added the @RNS.Profiler.profile decorator, by K8
• Added support for indefinitely running, reentrant profilers with bounded capture, by K8
• Added live profiling results output to rnstatus, by K8
• Added PPS statistics to rnstatus
• Added interface MTU display to rnstatus
• Added interface TX drop statistics to rnstatus
• Added interface TX buffer size output to rnstatus
• Added throughput benchmarker to the test suite
• Added support for natively compiled module builds, and the ability to load compiled modules when available
• Added module compilation status reporting from in-wheel build information
• Added parity tests for HDLC, IFAC and HKDF against the legacy implementations
• Added shared medium hints to interfaces
• Improved memory and CPU consumption under high traffic loads
• Improved traffic class handling
• Optimized HKDF to ~5.7x performance, if this worries you, good; then see the full parity and standard vector test suite and read the code
• Optimized inbound and outbound IFAC handling to ~90x performance on large frames
• Optimized inbound packet processing by reducing lock acquisitions and path table contention
• Optimized lookups for pending and active links using hash maps for lookup operations
• Optimized announce validation by caching signature validation results, significantly lowering announce storm CPU load
• Optimized the HDLC deframer
• Reduced redundant packet hashing in inbound processing
• Tuned default inbound queue lengths and announce queuing
• Tuned automatic interface MTU configuration
• Fixed Resource transfers failing when initialized from stream-based data sources that fell outside MAX_EFFICIENT_SIZE
• Fixed an invalid prefix stripping bug in the rngit page server (.something files not viewable)
• Fixed RSSI/SNR reporting regression
• Fixed keepalive handling on non-epoll backends
• Fixed a bug in rngit page navigation content initialization order
• Fixed the rngit page node not being able to serve in-tree downloads for large files
• Fixed rnstatus blocked IP listing including IPs that were actually not yet blocked
• Fixed rnstatus traffic totals counting the local shared instance inter-app transit in totals
• Fixed various minor bugs in rnsh, rnir, identity handling
• Fixed a latent bug in the AES module, where an exception would not resolve it's exception description correctly, and instead raise another exception.
• Removed dead Python 2 code from umsgpack

This time around, there's immediate updates for Sideband as well, including the RNS 1.5.1. Nomadnet has also been updated with new pinned versions and a few minor bugfixes, so not much new in the actual programs, but especially Sideband on Android, and the appimage builds will benefit from this update.

Seeing really high CPU usage after the upgrade, rnsd at 80 to 95% cpu usage across all cores.

Anything I should poke to see what's happening? There isn't anything odd looking as best as I can tell.

Attached strace and I see a lot of:

futex(0x7fd446c0b000, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY) = -1 EAGAIN (Resource temporarily unavailable)

That's very interesting qbit. On Linux or BSD? Looks like full kernel bufs maybe (being attempted written to repeatedly), but BackboneInterface should handle that... Hmm, or have I inadvertently created a busy loop under that condition somehow...? Are you seeing this on multiple machines or just one? What kind of interface setup is it? Really interested to know some more details, caus across the 9 different machines I've been testing on, I haven't seen anything like that.

Also the fact that it has high CPU usage across multiple cores is quite astonishing, unless you've been cheeky and pre-emptively started running RNS in free-threaded mode with t-build of Python.

(don't get any ideas, it's not quite ready yet, and several things need handling before that is possible)

And forgot to ask, does it happen or startup, or after some time? Any trigger conditions?

Seems to just be this one Linux machine. Here is a breakdown of the interfaces it has:

      1  AutoInterface
     15  BackboneInterface
      1  I2PInterface
      6  I2PInterfacePeer
      2  LocalInterface
      6  TCPInterface
      1  TCPServerInterface

Wondering if it's the I2P stuff.. I am now seeing a lot of: [2026-08-28 12:36:02] [Debug] Protocol violation on I2PInterfacePeer[Connected peer on ShutUpAndHack I2P]: Insufficient packet size for IFAC processing now... though maybe that's legit bad traffic..

qbit wrote:

Seems to just be this one Linux machine. Here is a breakdown of the interfaces it has:

      1  AutoInterface
     15  BackboneInterface
      1  I2PInterface
      6  I2PInterfacePeer
      2  LocalInterface
      6  TCPInterface
      1  TCPServerInterface

Wondering if it's the I2P stuff.. I am now seeing a lot of: [2026-08-28 12:36:02] [Debug] Protocol violation on I2PInterfacePeer[Connected peer on ShutUpAndHack I2P]: Insufficient packet size for IFAC processing now... though maybe that's legit bad traffic..

this is the I2P bug I just literally reported in this stream and proposed a fix for.

Sorry Mark, doesn't seem like all the messages were loaded when I responded - It happens after a few minutes of uptime.

Could you do a quick edit and add if not data: return in I2PInterface.py's process_incoming method, so it looks like:

def process_incoming(self, data):
    if not data: return
    self.rxb += len(data)
    if hasattr(self, "parent_interface") and self.parent_interface != None and self.parent_count:
        self.parent_interface.rxb += len(data)
    self.owner.inbound(data, self)

And tell me if it solves both the protocol violations and the CPU usage, or just the protocol violations, or nothing?

Hey, wait a sec... You're running discovery with pretty high stamp value on your public interfaces, right? So if the CPU usage across all cores starts at around 60 seconds uptime, it's just the stamp generation! At the value you're using it could take a couple of minutes to finish that unless you have some Threadripper show going on or something :)

ope :D - I think that was for sure part of it - but things never settled even after an hour and a half or so.. After the above change things have settled.

I'm pushing out a fixed release in a moment, there was some other issues as well.

Mark, I saw the note you have on Aleph about scraping nodes being blackholed. Can you expand on what you view as scraping? Don't want to accidentally trigger something.

Could you instead explain what it is you intend to do? And maybe post it in its own thread?

RNS 1.5.2 is out as well btw, with the fixes for the bugs discussed earlier here @qbit