Blargh

Rustradio - SDR framework now also in the browser, with Wasm

Sat, 11 Apr 2026 00:00:00 +0000

I’ve previously blogged about RustRadio, my GNU Radio like framework for writing software defined radio applications in Rust. And now there’s more progress of an interesting kind.

Anything that tries to do something similar to GNU Radio needs a few things:

Core framework.
SDR components (filters, clock recovery, multipliers, etc).
A user interface.

In addition to these, GNU Radio also has the excellent GNU Radio Companion for interactive creation of flowgraphs, but I’m not tackling that yet.

I have a core framework, and some components (blocks). But the UI has been a bit lacking.

I’ve played around with TUI applications, but I always knew I also wanted to support having a UI in the browser. I’m not as interested in adding support for QT or Windows native UI. The browser will do fine.

There are two ways to get the UI in the browser:

Have the browser talk to a backend that’s running the actual DSP.
Running the DSP in the browser, with no need for a backend.

While I’ll want (1) eventually, and have some ideas about that, this post is about running everything in the browser, using Wasm.

I know that this is just scratching the surface on some aspects of this, but I hope I at least didn’t get anything wrong.

Wasm, in short

There have been various technologies to running code in the browser. ActiveX, VBScript, Java, and Flash come to mind. They’ve all gone away. Only Javascript remains. Typescript is a better Javascript, but it’s still basically Javascript.

Wasm allows you to compile programming languages that normally compile to native code, like C, C++, and Rust, to a portable binary that the browser can execute. This is better than compiling (transpiling) them to Javascript, because it doesn’t require the overhead of guaranteeing Javascript behavior while actually executing another language’s compiled code.

Great. I’m not a fan of Javascript, so this should mean I’ll be able to do web coding without writing even a single line of Javascript. Well, aside from the line that goes “load the Wasm”.

More importantly for this project, it means I’ll be able to run RustRadio in the browser.

Web workers

Javascript is single threaded. That’s not a problem in itself, since RustRadio is perfectly happy running single threaded. But if something get stuck in a loop then you’ll get the “Page is not responding” dialog, making you and your users unhappy. And even without that, while some heavy computation is happening in the main UI thread, the page will be unresponsive.

Javascript will likely never have threads in the traditional sense (some frameworks fake it, as I’ll get to).

So if you want to avoid locking up the main UI thread, then you need to spin off a “Worker”. This worker runs in its own thread, and has very limited access to the outside world, including other workers. In particular, it does not have access to the DOM (the web page). Only the main UI “thread” has access to that.

What you can do is post messages between the worker and the other worker or main thread that spawned it. You can also create a shared buffer, but I’ve not done that yet, so ignoring that for now.

Any heavy CPU work that’s expected to take a few milliseconds should be considered for offload to a Worker instead of running on the main UI thread. And keep in mind low end devices like phones, when estimating “a few milliseconds”.

The sandboxing of a Worker is also nice, in that if something runs in a worker, then you know that it can’t affect the DOM.

It’s apparently possible to run threads with Wasm in some setups, but it’s not been standardized, so it’s not something I’m going to build for. In particular, it doesn’t work on Apple phones, which is a big enough target that it’s a showstopper.

So for my purposes the only way to run a separate thread is to run a separate worker.

Computing and receiving messages on the same thread

A worker receives a message by having its onmessage handler called. But since the worker is just the one thread, it can’t interrupt whatever heavy computation was currently happening. It can’t even do something POSIX signal like, and redirect execution into a new stack. No, it just patiently waits until the worker finishes what it’s doing before calling that callback.

There are two ways of doing this. Either the worker snapshots its computation, and hopes it’ll get a message later, resuming it, or (technically equivalently) you use async functions. The latter seems better in my limited experience. Because async is just fancy syntax for returning a future, it’s not actually different from returning and resuming; It’s just automatic. It also means that having returned, any other onmessage handler for more messages have a chance to run.

async->sync->async

Sometimes async code needs to send a sync function to some API (e.g. register a sync callback). This handler is then called outside of async, and can’t await on any async. onmessage and button click handlers are sync, yet may need to await. This is part of that whole “what color is your function” thing.

It seems that the core library of Rust Wasm, wasm_bindgen, helpfully provides a function to register more futures for execution, with spawn_local(). This makes things easy. The handler then just registers the async call, and returns.

My example: An AX.25 1200bps decoder, in the browser

I’ve blogged about AX.25 before. For this post all you need to know is that it’s a data packet sent over radio, and that my example is able to find and decode the packet from a recording.

The live site is here if you want to try it. Or just enjoy this screenshot and video if you don’t. :-)

My first memory error in Rust

Rust is a memory safe language. JS is too. So how is this the first time I’ve managed to get memory corruption with Rust?

Notice in this screenshot how the vector has been corrupted, thinking it’s over a GB of data. It should be 64Ki.

Hopefully I’ll get this fixed, so for future reference this is when running the code in the ruwasm repo at commit 6088f711141fe566a8a02f9f40d5866ff6d8e82f.

Maybe it’s from some immature dependency. Maybe (more likely?) it’s a bug in my sloppily coded buffer handler. It does have a couple of unsafe.

github pages autodeploy

You may have noticed that the URL to the live demo is hosted on github.io.

Because there’s no active server component, I thought I’d try out continuous deployment of this Wasm application. It was simpler than I expected. Just enable github pages, set them to be sourced from github actions, and add a simple github action, and upon every git push, the latest version gets hosted “in the cloud”.

That’s it. Now whenever I push a new version to github, it’s live on that URL a minute later. Pretty cool.

Future work is to trigger another github action on tagging a release, creating a permanent location where this tagged version is deployed. That way it’ll be possible to bisect looking for a bug, without even compiling.

I’ll also want to have it trigger on pull requests, so that it can be tested prior to merge, without the need to download and build locally.

Wasm, the end of Javascript?

Of course this is Betteridge’s law of headlines, but this video is still interesting and relevant.

WebUSB should provide direct access to SDR hardware like RTLSDR and USRPs. There’s no reason it shouldn’t be possible to run a large complex interactive SDR application directly against hardware, all inside the browser with no server components.

The strange webserver hot potato — sending file descriptors

Sun, 26 Oct 2025 00:00:00 +0000

I’ve previously mentioned my io-uring webserver tarweb. I’ve now added another interesting aspect to it.

As you may or may not be aware, on Linux it’s possible to send a file descriptor from one process to another over a unix domain socket. That’s actually pretty magic if you think about it.

You can also send unix credentials and SELinux security contexts, but that’s a story for another day.

My goal

I want to run some domains using my webserver “tarweb”. But not all. And I want to host them on a single IP address, on the normal HTTPS port 443.

Simple, right? Just use nginx’s proxy_pass?

Ah, but I don’t want nginx to stay in the path. After SNI (read: “browser saying which domain it wants”) has been identified I want the TCP connection to go directly from the browser to the correct backend.

I’m sure somewhere on the internet there’s already an SNI router that does this, but all the ones I found stay in line with the request path, adding a hop.

Why?

A few reasons:

Having all bytes bounce on the SNI router triples the number of total file descriptors for the connection. (one on the backend, then one each on the router for upstream and downstream). There are limits per process and system wide, and the more you have the more you need to juggle them in code.
It also wastes CPU and RAM.
I want the backend to know the real client IP address, via getpeername() or similar, on the socket itself.
I don’t want restarting nginx to cut existing connections to backends.
I’d like to use TLS keys that the nginx user doesn’t have access to.
I used proxy_pass for livecount, and last time I got blog posts on HackerNews nginx ran out of file descriptors, and started serving 500 for it serving just plain old static files on disk. For now I’ve moved livecount to a different port, but in the long run I want it back on port 443, and yet isolated from nginx so that the latter keeps working even if livecount is overloaded.

Livecount has an open websocket to every open browser tab in the world reading a given page, so they add up. (no, it doesn’t log. It just keeps count)

What I built

I built a proof of concept SNI router. It is a frontline server receiving TCP connections, on which it then snoops the SNI from the TLS ClientHello, and routes the connection according to its given rules.

Anything it reads from the socket is sent along to the real backend along with the file descriptor. So the backend (in my use that’s tarweb) needs to have code cooperating to receive the new connection.

It’s not the cleanest code, but it works. I got ChatGPT to write the boring “parse the TLS record / ClientHello” parts. Rust is a memory safe language, so “how bad could it be?”. :-)

It seems to work for all the currently used TLS versions.

It’s not plug and play

As I said, it requires the backend to be ready to receive “hey, here’s a file descriptor, and here’s the first few hundred bytes you should treat as if you’ve read them from the client”.

File descriptors don’t have an operation to “unread”. If they did then this would be easier. Then it would “just” be a matter of giving a backend webserver a file descriptor. For some use cases that could mean starting a new webserver process that reads and writes from stdin/stdout.

Not super efficient to go back to the fork-exec-per-connection model from the previous century, but it would achieve the direct connection.

But the details are academic. We do need to pass along the snooped bytes somehow, or the TLS handshake won’t succeed. Which means it does need cooperation from the backend.

But it is privacy preserving

Because the SNI router never writes to the client, and therefore doesn’t perform a TLS handshake, it doesn’t need any private keys or certificates.

The SNI router has no secrets, and sees no secrets.

I also added a mode that proxies the TCP connection, if some SNI should be routed to a different server. But of course then it’s not possible to pass the file descriptor. So encrypted bytes will bounce on the SNI router for that kind of flow. But still the SNI router is not able to decrypt anything.

A downside is of course that bouncing the connection around the world will slow it down, add latency, and waste resources. So pass the file descriptor where possible.

The hot potato

So now my setup has the SNI router accept the connection, and then throw the very file descriptor over to tarweb, saying “you deal with this TCP connection”. Tarweb does the TLS handshake, and then throws the TLS session keys over to the kernel, saying “I can’t be bothered doing encryption, you do it”, and then actually handles the HTTP requests.

Well actually, there’s another strange indirection. When tarweb receives a file descriptor, it uses io-uring “registered files” to turn it into a “fixed file handle”, and closes the original file descriptor. On the kernel side there’s still a file descriptor of course, but there’s nothing in /proc/<pid>/fd/:

$ ls /proc/699874/fd -l
total 0
lrwx------ 1 thomas thomas 64 Oct 26 21:47 0 -> /dev/pts/5
lrwx------ 1 thomas thomas 64 Oct 26 21:47 1 -> /dev/pts/5
lrwx------ 1 thomas thomas 64 Oct 26 21:47 2 -> /dev/pts/5
lrwx------ 1 thomas thomas 64 Oct 26 21:47 3 -> anon_inode:[io_uring]

This improves performance a bit on the linux kernel side.

The SNI router does not use io-uring. At least not yet. The SNI router’s job is much smaller (doesn’t even do a TLS handshake), much more brief (it almost immediately passes the file descriptor to tarweb), and much less concurrency (because of the connections being so short lived as far as it’s concerned), that it may not be worth it.

In normal use the SNI router only needs these syscalls per connection:

accept() for the new connection,
read() a few hundred bytes of ClientHello,
sendmsg() of same size to pass it on,
close() to forget the file descriptor.

HTTP/3 can redirect connections

At the risk of going off on an unrelated tangent, HTTP/3 (QUIC-based) has an interesting way of telling a client to “go over there”. A built in load balancer inside the protocol, you could say, sparing the load balancer needing to proxy everything.

This opens up opportunities to steer not just on SNI, and is much more flexible than DNS, all without needing the “proxy” to be inline.

E.g. say a browser is in Sweden, and you have servers in Norway and Italy. And say you have measured, and find that it would be best if the browser connected to your Norway server. But due to peering agreements and other fun stuff, Italy will be preferred on any BGP anycasted address.

You then have a few possible options, and I do mean they’re all possible:

Have the browser connect to norway.example.com, with Norway-specific IP addresses. Not great. People will start bookmarking these URLs, and what happens when you move your Norway servers to Denmark? norway.example.com now goes to servers in Denmark?
Use DNS based load balancing, giving Swedish browsers the Norway unicast IPs. Yes… but this is WAY more work than you probably think. And WAY less reliable at giving the best experience for the long tail. And sometimes your most important customer is in that long tail.
Try to traffic engineer the whole Internet with BGP announcement tweaks. Good luck with that, for the medium to long tail.
Install servers in Sweden, and any other place you may have users. Then you can anycast your addresses from there, and have full control of how you proxy (or packet by packet traffic engineer over tunnels) them. Expensive if you have many locations you need to do this in. Some traffic will still go to the wrong anycast entry point, but pretty feasible though expensive.

The two DNS-based ones also have the valid concern that screwing up DNS can have bad consequences. If you can leave DNS alone that’s better.

Back to HTTP/3. If you’ve set up HTTP/3 it may be because you care about latency. It’s then easier to act on information you have about every single connection. On an individual connection basis you can tell the browser in Sweden that it should now talk to the servers in Norway. All without DNS or anycast.

Which is nice, because running a webserver is hard enough. Also running a dynamic DNS service or anycast has even more opportunities to blow up fantastically.

Where was I? Oh yeah, file descriptors

I should add that HTTP/3 doesn’t have the “running out of file descriptors” problem. Being based on UDP you can run your entire service with just a single file descriptor. Connections are identified by IDs, not 5-tuples.

So why didn’t I just use HTTP/3?

HTTP/3 is complex. You can build a weird io-uring kTLS based webserver on a weekend, and control everything (except TLS handshakes). Implementing HTTP/3 from scratch, and controlling everything, is a different beast.
HTTP/1 needs to still work. Not all clients support HTTP/3, and HTTP/1 or 2 is even used to bootstrap HTTP/3 via its Alt-Svc header.
Preferred address in HTTP/3 is just a suggestion. Browsers don’t have to actually move.

What about encrypted SNI (ESNI), or encrypted ClientHello (ECH)

No support for that (yet). From some skimming ESNI should “just work”, with just a minor decryption operation in the SNI router.

ECH seems harder. It should still be doable, but the SNI router will need to do the full handshake, or close to it. And after taking its routing decision it needs to transfer the encryption state to the backend, along with the file descriptor.

This is not impossible, of course. It’s similar to how tarweb passes the TLS session keys to the kernel. But it likely does mean that the SNI router needs to have access to both the TLS session keys and maybe even the domain TLS private keys.

But that’s a problem for another day.

tarweb was first written in C++.
livecount keeps long lived connection.
tarweb rewritten in Rust, and using io-uring.
You can redirect with Javascript, but this still has the norway.example.com problem.
I passed file descriptors between processes in injcode, but it was only ever a proof of concept that only worked on 32bit x86, and the code doesn’t look like it actually does it? Anyway I can’t expect to remember code from 17 years ago.

Ideal programming language

Sun, 07 Sep 2025 00:00:00 +0000

My last post about Go got some attention.

In fact, two of my posts got attention that day, which broke my nginx since I was running livecount behind nginx, making me run out of file descriptors when thousands of people had the page opened.

It’s a shame that I had to turn off livecount, since it’d be cool to see the stats. But I was out of the country, with unreliable access to both Internet and even electricity in hotels, so I couldn’t implement the real fix until I got back, when it had already mostly died down.

I knew this was a problem with livecount, of course, and I even allude to it in its blog post.

Anyway, back to programming languages.

The reactions to my post can be summarized as:

Oh yes, these things are definite flaws in the language.
What you’re saying is true, but it’s not a problem. Your post is pointless.
You’re dumb. You don’t understand Go. Here let me explain your own blog post to you […]

I respect the first two. The last one has to be from people who are too emotionally invested with their tools, and take articles like this like a personal attack of some sort. They go out of their way to be offended, and then start screaming “but I don’t fucking want guitar lessons!”. They want to counter attack against another programming language, thinking I would take it personally too. Maybe this heretic is a Java programmer, and that’s why he’s stupid? (bad guess).

It also reminded me of PHP programmers back in the PHP 3.x days who would die on the hill of defending PHP as an awesome language, while admitting that they knew literally no other language. What should they know of England who only England know?

I’m not offended. Those replies are not offensive; They’re boring. There’s nothing to learn from the comments, and probably not from the people making such comments in general, either.

Also it seems that somebody managed to get my whole Blog comment database deleted from disqus. Either disqus itself was hacked, or just my account with them. Or someone tricked disqus into deleting it. They managed to restore it, though.

Keeping this third type of commenter in mind, I got an email a few days later asking what programming languages are “closer to ideal”, and if I maybe have a blog post in me about that.

I don’t know who’s asking, so I replied the long version, while still taking the question at face value.

My reply (after minor edits)

Ideal… Well, this is getting into the space of “what is the best programming language”, which doesn’t have a perfect answer. To do what?

To make an Android app (something I’m not an expert in. I’ve just made one simple one), I think Kotlin seems nice. But I don’t know it very well.

For web development, something I also don’t do much, it’s probably Typescript.

For maximum portability for systems programming, C or C++ (depending on if all your target platforms (e.g. embedded stuff) support C++) is probably best.

But these are practical answers. Some people like Lisp. Others like Haskell. Rust strikes a good position between practical, low level control, safe, and a high level type system. If the Rust compiler supports your platform, then it’s pretty much as portable as C/C++.

I’ve written about the deficiencies of Java and Go because the ways they are deficient are interesting. I don’t find the ways C++ is deficient to be interesting. C++ is what it is. I happen to enjoy coding C++.

I also have thoughts about the trap of accidentally writing too much in bash.

I have a draft of things wrong with Rust. But so far I think they are all fixable. (e.g. no placement syntax has been defined yet)

But I have no interest in writing a blog post about the lack of memory safety of C++. It is what it is.

Java’s deficiencies are interesting because they are the best guesses of the future that 1990 had to offer. And those guesses were almost all wrong.

Go’s deficiencies are interesting/frustrating because it (almost entirely) is the best that the 1980s-early 1990s had to offer. And yet it launched in 2009.

Enjoyment

I don’t enjoy coding Javascript. So I’m experimenting writing frontend stuff in Rust and compile to WASM. So far it works for me, but is not something I’d recommend for anyone who wants to get anything done.

But no, I won’t be writing up which programming language is “ideal”, because it’s one of those “it depends”.

Go is still not good

Sat, 12 Jul 2025 00:00:00 +0000

Previous posts Why Go is not my favourite language and Go programs are not portable have me critiquing Go for over a decade.

These things about Go are bugging me more and more. Mostly because they’re so unnecessary. The world knew better, and yet Go was created the way it was.

For readers of previous posts you’ll find some things repeated here. Sorry about that.

Error variable scope is forced to be wrong

Here’s an example of the language forcing you to do the wrong thing. It’s very helpful for the reader of code (and code is read more often than it’s written), to minimize the scope of a variable. If by mere syntax you can tell the reader that a variable is just used in these two lines, then that’s a good thing.

Example:

if err := foo(); err != nil {
   return err
}

(enough has been said about this verbose repeated boilerplate that I don’t have to. I also don’t particularly care)

So that’s fine. The reader knows err is here and only here.

But then you encounter this:

bar, err := foo()
if err != nil {
  return err
}
if err = foo2(); err != nil {
  return err
}
[… a lot of code below …]

Wait, what? Why is err reused for foo2()? Is there’s something subtle I’m not seeing? Even if we change that to :=, we’re left to wonder why err is in scope for (potentially) the rest of the function. Why? Is it read later?

Especially when looking for bugs, an experienced coder will see these things and slow down, because here be dragons. Ok, now I’ve wasted a couple of seconds on the red herring of reusing err for foo2().

Is a bug perhaps that the function ends with this?

// Return foo99() error. (oops, that's not what we're doing)
foo99()
return err // This is `err` from way up there in the foo() call.

Why does the scope of err extend way beyond where it’s relevant?

The code would have been so much easier to read if only err’s scope had been smaller. But that’s not syntactically possible in Go.

This was not thought through. Deciding on this was not thinking, it was typing.

Two types of nil

Look at this nonsense:

package main
import "fmt"
type I interface{}
type S struct{}
func main() {
    var i I
    var s *S
    fmt.Println(s, i) // nil nil
    fmt.Println(s == nil, i == nil, s == i) // t,t,f: They're equal, but they're not.
    i = s
    fmt.Println(s, i) // nil nil
    fmt.Println(s == nil, i == nil, s == i) // t,f,t: They are not equal, but they are.
}

Go was not satisfied with one billion dollar mistake, so they decided to have two flavors of NULL.

“What color is your nil?” — The two billion dollar mistake.

The reason for the difference boils down to again, not thinking, just typing.

It’s not portable

Adding comment near the top of the file for conditional compilation must be the dumbest thing ever. Anybody who’s actually tried to maintain a portable program will tell you this will only cause suffering.

It’s an Aristotle way of the science of designing a language; lock yourself up in a room, and never test your hypotheses against reality.

The problem is that this is not year 350 BCE. We actually have experience that aside from air resistance, heavy and light objects actually fall at the same speed. And we have experience with portable programs, and would not do something this dumb.

If this had been the year 350 BCE, then this could be forgiven. Science as we know it hadn’t been invented yet. But this is after decades of very widely available experience in portability.

`append` with no defined ownership

What does this print?

package main
import "fmt"
func foo(a []string) {
    a = append(a, "NIGHTMARE")
}
func main() {
    a := []string{"hello", "world", "!"}
    foo(a[:1])
    fmt.Println(a)
}

Probably [hello NIGHTMARE !]. Who wants that? Nobody wants that.

Ok, how about this?

package main
import "fmt"
func foo(a []string) {
    a = append(a, "BACON", "THIS", "SHOULD", "WORK")
}
func main() {
    a := []string{"hello", "world", "!"}
    foo(a[:1])
    fmt.Println(a)
}

If you guessed [hello world !], then you know more than anybody should have to know about quirks of a stupid programming language.

`defer` is dumb

Even in a GC language, sometimes you just can’t wait to destroy a resource. It really does need to run as we leave the local code, be it by normal return, or via an exception (aka panic).

What we clearly want is RAII, or something like it.

Java has it:

try (MyResource r = new MyResource()) {
  /*
  work with resource r, which will be cleaned up when the scope ends via
  .close(), not merely when the GC feels like it.
  */
}

Python has it. Though Python is almost entirely refcounted, so one can pretty much rely on the __del__ finalizer being called. But if it’s important, then there’s the with syntax.

with MyResource() as res:
  # some code. At end of the block __exit__ will be called on res.

Go? Go makes you go read the manual and see if this particular resource needs to have a defer function called on it, and which one.

foo, err := myResource()
if err != nil {
  return err
}
defer foo.Close()

This is so dumb. Some resources need a defer destroy. Some don’t. Which ones? Good fucking luck.

And you also regularly end up with stuff like this monstrosity:

f, err := openFile()
if err != nil {
  return nil, err
}
defer f.Close()
if err := f.Write(something()); err != nil {
  return nil, err
}
if err := f.Close(); err != nil {
  return nil, err
}

Yes, this is what you NEED to do to safely write something to a file in Go.

What’s this, a second Close()? Oh yeah, of course that’s needed. Is it even safe to double-close, or does my defer need to check for that? It happens to be safe on os.File, but on other things: WHO KNOWS?!

The standard library swallows exceptions, so all hope is lost

(Largely a repeat of part of a previous post)

Go says it doesn’t have exceptions. Go makes it extremely awkward to use exceptions, because they want to punish programmers who use them.

Ok, fine so far.

But all Go programmers must still write exception safe code. Because while they don’t use exceptions, other code will. Things will panic.

So you need, not should, NEED, to write code like:

func (f *Foo) foo() {
    f.mutex.Lock()
    defer f.mutex.Unlock()
    f.bar()
}

What is this stupid middle endian system? That’s dumb just like putting the day in the middle of a date is dumb. MMDDYY, honestly? (separate rant)

But panic will terminate the program, they say, so why do you care if you unlock a mutex five milliseconds before it exits anyway?

Because what if something swallows that exception and carries on as normal, and you’re now stuck with a locked mutex?

But surely nobody would do that? Reasonable and strict coding standards would surely prevent it, under penalty of being fired?

The standard library does that. fmt.Print when calling .String(), and the standard library HTTP server does that, for exceptions in the HTTP handlers.

All hope is lost. You MUST write exception safe code. But you can’t use exceptions. You can only have the downsides of exceptions be thrust upon you.

Don’t let them gaslight you.

Sometimes things aren’t UTF-8

If you stuff random binary data into a string, Go just steams along, as described in this post.

Over the decades I have lost data to tools skipping non-UTF-8 filenames. I should not be blamed for having files that were named before UTF-8 existed.

Well… I had them. They’re gone now. They were silently skipped in a backup/restore.

Go wants you to continue losing data. Or at least, when you lose data, it’ll say “well, what (encoding) was the data wearing?”.

Or how about you just do something more thought through, when you design a language? How about doing the right thing, instead of the obviously wrong simple thing?

Memory use

Why do I care about memory use? RAM is cheap. Much cheaper than the time it takes to read this blog post. I care because my service runs on a cloud instance where you actually pay for RAM. Or you run containers, and you want to run a thousand of them on the same machine. Your data may fit in RAM, but it’s still expensive if you have to give your thousand containers 4TiB of RAM instead of 1TiB.

You can manually trigger a GC run with runtime.GC(), but “oh no don’t do that”, they say, “it’ll run when it has to, just trust it”.

Yeah, 90% of the time, that works every time. But then it doesn’t.

I rewrote some stuff in another language because over time the Go version would use more and more memory.

Another example of why memory matters is Android Studio. I basically cannot run it on my 32GiB laptop. 32GiB is not enough to run an IDE. If I run Android Studio and Chrome at the same time, then the OOM killer kicks in.

It didn’t have to be this way

We knew better. This was not the COBOL debate over whether to use symbols or English words.

And it’s not like when we didn’t know at the time that Java’s ideas were bad, because we did know Go’s ideas were bad.

We already knew better than Go, and yet now we’re stuck with bad Go codebases.

Other people’s posts

This post was discussed on HackerNews on 2025-08-22.

Setting clock source with GNU Radio

Sun, 22 Jun 2025 00:00:00 +0000

I bought a GPS Disciplined Oscillator (GPSDO), because I thought it’d be fun for various projects. Specifically I bought this one.

I started by calibrating my ICOM IC-9700. I made sure it got a GPS lock, and connected it to the 9700 10MHz reference port, with a 20dB attenuator inline, just in case. Ok, the receive frequency moved a bit, but how do I know it was improved? My D75 was still about 200Hz off frequency.

Segal’s law paraphrased: “Someone with one radio knows what frequency they’re on. Someone with two radios is never sure”.

Unless, of course, that person has two radios with disciplined oscillators. Which I do. I also have a USRP B200 with an added GPSDO accessory.

Sidenote: wow, that’s gotten expensive. Today I’d probably use the same GPSDO from DXPatrol instead (it has four outputs). Note that if you do have the GPSDO installed in the B200, then you cannot use an external 10MHz reference. It’s a known issue. Then again if you paid this much, why would you not use it?

Configuring GNU Radio to use the GPSDO

First I thought that surely the best reference would be the default, so I should be able to just send a tone, having configured only frequency and output gain:

But that doesn’t seem right. It was off by almost a kHz, compared to the 9700! That’s worse than the D75.

Let me try with the morse_beacon example in RustRadio, where I know I set the clock source.

cargo run -F soapysdr --example morse_beacon -- \
  --sample-rate 320k \
  --freq 436.6m \
  -d 'soapy=0,remote=tcp://my-soapysdr-server,remote:prot=tcp,driver=remote,remote:driver=uhd' \
  --ogain 0.8 \
  --clock-source gpsdo \
  'M0THC'

Yeah that’s perfect. So GNU Radio is not setting the clock source, but instead defaulting to the internal undisciplined clock source.

I looked all over the GNU Radio Companion, testing both Soapy Custom Sink and Soapy Sink (deprecated). I added various versions of clock=gpsdo to driver strings and parameters. No change.

Then I went to check the source. The block does have a clock_source parameter, but it’s hidden.

Looking further, it’s not only hidden, but also unused. I guess they kept it only to prevent old flowgraphs from having syntax errors.

But there is a way to set the clock source. By sending a message.

So I created this flowgraph, with the Message PMT being pmt.dict_add(pmt.make_dict(), pmt.intern("clock_src"), pmt.intern("gpsdo")):

It worked. You can clearly see where the strobe message told the Source block to stop being a silly goose. The internal clock can be seen being almost a kHz off, and the GPSDO is so perfect you can’t see any error, even with the waterfall zoomed in as much as it can be.

The ICOM IC-9700 can frequency lock now?

I expected the 9700 to only support a one-off calibration, but looks like it locks on to the external reference, and keeps tuning forever. And it has a button saying “Cancel Sync”. It even keeps it enabled across reboots. Nice.

Does this mean that this injection board is obsolete?

My understanding didn’t come out of nothing. Here’s a blog post that corroborates my memory.

I guess it was solved in a firmware update? My firmware version is 1.44. Oh I see, a comment from 2022 says that this has now been fixed. Which… corroborates what I’m seeing now.

So yeah. No need for an injection board. Just plug in a 10MHz reference to the reference port.

Software defined KISS modem

Sat, 21 Jun 2025 00:00:00 +0000

I’ve kept working on my SDR framework in Rust called RustRadio, that I’ve blogged about twice before. I’ve been adding a little bit here, a little bit there, with one of my goals being to control a whole AX.25 stack.

As seen in the diagram in this post, we need:

Applications, client and server — I’ve made those.
AX.25 connected mode stack (OSI layer 4, basically) — The kernel’s sucks, so I made that too.
A modem (OSI layer 1-2), turning digital packets into analog radio — The topic of this post.

The job of the modem

Applications talk in terms of streams. AX.25 implementation turns that into individual data frames. The most common protocol for sending and receiving frames is KISS.

I’ve not been happy with the existing KISS modems for a few reasons. The main one is that they just convert between packets and audio. I don’t want audio, I want I/Q signals suitable for SDRs.

On the transmit side it’s less of a problem for regular 1200bps AX.25, since either the radio will turn audio into a FM-modulated signal, or if using an SDR it’s trivial to add the audio-to-I/Q step.

On transmit you do have to trigger PTT, though. You can do VOX, but it’s not optimal.

But on the receive side it’s a completely different matter. Once it’s audio, the information about the RF signal strength is gone. It makes it impossible to work on more advanced reception strategies such as whole packet clock recovery, or soft decoding. Soft decoding would allow things like “CRC doesn’t match, but this one bit had a very low RF signal strength, so if flipping that bit fixes the CRC, then that’s probably correct.

Once you have a pluggable KISS modem you can also innovate on making the modem better. A simple example is to just run the same modem in multiple copies, thereby increasing the bandwidth (both in the Hz sense and the bps sense).

Since SDRs are not bound to audio as a communication medium, they can also be changed to use more efficient modulations. Wouldn’t it be cool to build a QAM modulation scheme, with LDPC and “real” soft decoding?

Yes, an SDR based modem does have two main challenges:

Power. SDRs don’t transmit at high power, so you need to get it through a power amplifier.
Duplex. Most TX-capable SDRs have two antenna ports. One for TX, one for RX. You’ll need to have two antennas, or figure out a safe way to transmit on the same antenna without destroying the RX port.

For the duplex problem, the cheap and simple solution is to use frequencies on different bands, and put a band pass filter on the receive port, thus blocking the transmitted power. SDR outputs are not clean, so you’ll need a filter on the transmit path too anyway. In other words, you can just use a diplexer.

It gets harder if RX and TX need to be on the same band, or worse, the same exact frequency. Repeaters tend to use cavity filters. But that’s a bit bulky for my use cases. And in any case don’t work if the frequency is exactly the same.

More likely a better use case here is to use half duplex, with a relay switching from RX to TX and back. But you need to synchronize it so that there’s no race condition that accidentally plows 10W into your receive port, even for a split second.

But that’s a problem for the future. For now I’m just using two antennas.

How to run the modem

I’ve implemented it. It works. It’s less that 250 lines of Rust, and the actual transmitter and receiver is really easy to follow. Well… to me at least.

In order to not introduce too many things at a time, here’s how to use the regular Linux kernel stack with my new bell202 modem. Bell202 is the standard and most used amateur radio data mode. Often just referred to as “1200bps packet”.

Build and start the modem:

$ git clone https://github.com/ThomasHabets/rustradio
[…]
$ cd rustradio
$ cargo build --release -F soapysdr,fast-math,nix --example bell202
[…]
$ ./target/release/examples/bell202 \
    -d 'driver=uhd' \
    --tty ./mydev.link \
    --freq 144.800m \
    --ogain 0.5

Create Linux AX.25 config:

$ sudo apt install libax25
$ echo 'radio1 M0XXX-1 9600 255 5 My test' | sudo tee -a /etc/ax25/axports

Attach the kernel to the modem:

$ sudo kissattach ./mydev.link radio1
AX.25 port radio1 bound to device ax0  
$ sudo kissparms -c 1 -p radio1

Now use it as normal:

$ axcall M0XXX-2
[…]

QO100 early success

Sun, 15 Jun 2025 00:00:00 +0000

I have heard and been heard via QO-100! As a licensed radio amateur I have sent signals via satellite as far away as Brazil.

What it is

QO-100 is the first geostationary satellite with an amateur radio payload. A “repeater”, if you will. Geostationary means that you just aim your antenna (dish) once, and you can use it forever.

This is amazing for tweaking and experimenting. Other amateur radio satellites are only visible in the sky for minutes at a time, requiring you to chase them across the sky to make a contact before it’s gone.

They also fly lower, meaning they can only see a small part of the world at a time. QO-100 has constant line-of-sight to all of Africa, Europe, India, and parts of Brazil.

Needs a bit more equipment, though

Other “birds” (satellites) can be accessed using a normal handheld FM radio and something like an arrow antenna. Well, you should actually have two radios, so that you can hear yourself on the downlink while transmitting.

There are also linear amateur radio satellites. For them you need SSB radios, which narrows down which radios you can use. And you still need to chase them across the sky.

For QO-100, though, you don’t just need another modulation, you need more complicated frequencies.

The uplink for QO-100 is 2.4GHz, and the downlink is 10.4895GHz. (I’m only looking at the narrowband transponder, for now).

My setup

There are many options. I chose mine because I want to do as much as possible with software defined radios, and I want my components to work for other experiments, if this one doesn’t work out.

Receive side

First I needed a dish. I bought a small 35cm dish from passion-radio, because of its portability. Small dishes are not as good at focusing the signal, but in return they are easier to aim, since they have a wider beam.

Basically nothing reasonable can receive a 10GHz directly, so the next thing I needed was an LNB. It takes a block of high frequencies, and “moves it down” to lower ones. I got the othernet Bullseye, since it has good specs and reviews. This converts the downlink signal down to a more manageable 759.5MHz. The LNB needs a bias-tee of 12V to power it. This is like a “power over ethernet injector”, for those of you who build networks.

This shifting of frequencies also has the benefit that lower frequencies have lower losses while going through coax.

I plugged this into a USRP B200 (if buying from ettus, you’ll need its enclosure too). There are cheaper options out there, but I bought this 10 years ago, so why not use it. I also tried a LimeSDR Mini. It worked very well too, but my B200 has a GPS disciplined oscillator, which reduces any unknowns about being on frequency.

After the investment of the dish and the LNB, I brought the receive setup to the top of a tall building, to see if it works.

It was harder than I expected to point the dish. It needs to be very precisely aimed. In theory you can just use this website and a compass, but compasses don’t like nearby metal (including the metal in the dish), so I found that it was more effective to eyeball it from google maps, and the alignment of nearby buildings, and hunt from there.

The second problem is wind. Wind will catch the dish, and tip it over. I recommend a better plan than to simply dedicate one hand to holding on to it.

Eventually I found the beacons where I expected them:

The best way I found to fine tune the direction was to output FT8 as audio, and maximize the apparent volume, while making very small adjustments.

Even though the B200 was GPS locked, and presumably bang on frequency, that’s not the case for the LNB. It’s not bad, but it looks like it’s a problem for very frequency sensitive modes like FT8.

I used pipewire virtual audio cards to get the signal from GNURadio into WSJT-X. There we see the problem clearly. Those yellow blocks at the bottom should be perfect rectangles, and not lean to the side. The fact that they all lean the same way tells me it’s a problem on my end, not with the person transmitting.

I have a plan for fixing this, but not today.

So in short: LNB in dish - bias-tee - USRP B200.

Transmit side

The transmit side has a different problem than the receive side. 2.4GHz is easy enough to generate using an SDR like the B200 (or LimeSDR). But the output of SDRs doesn’t have any power.

Before amplifying, though, it needs to be filtered. SDRs can generate any signal in a huge frequency range, but in the end any transmitter needs an analog filter. And analog filters are physical. They are band specific. I found some nice band pass filters on aliexpress, and bought a bunch for different bands. For this project we need a 2.4GHz band pass filter.

For power amplification I bought a 10W amplifier, but I’m still trying to make it work. In the mean time, I decided to use an analog devices CN0417. It’s only a 1W amplifier, but I was hoping that it could work for morse code or FT8.

In the past I’ve noticed that the USRP B200 has produced a pretty garbage signal (“nonlinearities”, the word may be) when it has its output gain set too high. I can set the gain lower, but the 1W power amplifier only amplifies by 20dB. So I added a 30dB LNA before the power amplifier.

I have only used LNAs on the receive side before, but turns out they work very well to amplify the low power of an SDR for transmit, too.

For the antenna, the best option seems to be to get a helix antenna, since it sits “around” the LNB, and bounces on the same dish.

In short: B200 - 30dB LNA - CN0417 - Helix antenna.

Converting to and from audio

At this point I have the uplink and downlink signal in the B200. As one does, I created a mess of a GNU Radio graph. It only uses standard blocks.

The transmit side takes audio and just sends it to the SDR. For transmit the SDR is mostly easily tuned directly. It just needs analog filtering and power amplification.

The receive side takes the whole narrowband downlink, and lets me tune around for what I want to decode. Or save the whole spectrum to disk.

To connect to WSJT-X I used the same virtual audio cables I’ve blogged about in the past. Some fighting in pavucontrol is needed to route the audio to the right loopback.

WSJT-X doesn’t need to trigger PTT, since this setup is full duplex.

The location

Sure, a bigger dish would help, as would putting the dish on the roof. But since I need to tweak it and have short cables for efficiency, putting it on the roof means a risk I’m not willing to take. So at least for now the setup is near ground level.

How did it go?

Reception works better than expected. Sure, not as clean as some other ground stations, but that’s to be expected.

For transmit, I first thought the small dish and weak amplifier was just not enough. I could not see the morse code beacons I send using RustRadio.

But then I saw and heard the beacons on websdr! So they do get there.

(sound)

What about FT8?

As mentioned above, FT8 decoding isn’t great. Some decode, but most (by far) don’t. They sound OK, but don’t decode. I tried switching to lower sideband, in case that’s how people transmitted, but that didn’t seem to help. I think it’s all due to needing to compensate for LNB frequency instability.

I was heard, though:

So yes, I can receive stronger signals, and I can be heard with my weaker signals. I just can’t hear my own weak signals.

Rooms for improvement

A bigger dish would help. I just need to figure out the best way to install it. Maybe this can wait until it’s all “perfect” and I can hire someone to install it on the roof.

More power. I need to get this 10W amplifier working. That should make me able to hear myself.

I need to figure out the downlink frequency stability. Either I can try to get an LNB with an external GPS discliplined clock, or I could use the satellite’s beacons — presumably stable — to lock on and fix the LNB instability in software. That’d be ideal. What can be done in software should be done in software.

The station

In use:

Mocked up:

io_uring, kTLS and Rust for zero syscall HTTPS server

Sun, 06 Apr 2025 00:00:00 +0000

Around the turn of the century we started to get a bigger need for high capacity web servers. For example there was the C10k problem paper.

At the time, the kinds of things done to reduce work done per request was pre-forking the web server. This means a request could be handled without an expensive process creation.

Because yes, creating a new process for every request used to be something perfectly normal.

Things did get better. People learned how to create threads, making things more light weight. Then they switched to using poll()/select(), in order to not just spare the process/thread creation, but the whole context switch.

I remember a comment on Kuro5hin from anakata, the creator of both The Pirate Bay and the web server that powered it, along the lines of “I am select() of borg, resistance is futile”, mocking someone for not understanding how to write a scalable web server.

But select()/poll() also doesn’t scale. If you have ten thousand connections, that’s an array of ten thousand integers that need to be sent to the kernel for every single iteration of your request handling loop.

Enter epoll (kqueue on other operating systems, but I’m focusing on Linux here). Now that’s better. The main loop is now:

  set_up_epoll()
  while True:
    new, read, write = epoll()
    epoll_add_connections(new)
    for con in read:
      process(con.read())
      if con.read_all_we_need:
        epoll_remove_read_op(con)
    for con in write:
      con.write_buffer()
      if con.buffer_empty:
        epoll_remove_write_op(con)

All the syscalls are pretty cheap. epoll() only deals in deltas, and it doesn’t have to be re-told the thousands of active connections.

But they’re not without cost. Once we’ve gotten this far, the cost of a syscall is actually a significant part of the total remaining cost.

We’re here going to ignore improvements like sendfile() and splice(), and instead jump to…

io_uring

Instead of performing a syscall for everything we want to do, commanding the kernel to do this or that, io_uring lets us just keep writing orders to a queue, and letting the kernel consume that queue asynchronously.

For example, we can put accept() into the queue. The kernel will pick that up, wait for an incoming connection, and when it arrives it’ll put a “completion” into the completion queue.

The web server can then check the completion queue. If there’s a completion there, it can act on it.

This way the web server can queue up all kinds of operations that were previously “expensive” syscalls by simply writing them to memory. That’s it. And then it’ll read the results from another part of memory. That’s it.

In order to avoid busy looping, both the kernel and the web server will only busy-loop checking the queue for a little bit (configurable, but think milliseconds), and if there’s nothing new, the web server will do a syscall to “go to sleep” until something gets added to the queue.

Similarly on the kernel side, the kernel will stop busy-looping if there’s nothing new, and needs a syscall to start busylooping again.

This sounds like it would be tricky to optimize, but it’s not. In the end the web server just puts stuff on the queue, and calls a library function that only does that syscall if the kernel actually has stopped busylooping.

This means that a busy web server can serve all of its queries without even once (after setup is done) needing to do a syscall. As long as queues keep getting added to, strace will show nothing.

One thread per core

Since CPUs today have many cores, ideally you want to run exactly one thread per core, bind it to that core, and not share any read-write data structure.

For NUMA hardware, you also want to make sure that a thread only accesses memory on the local NUMA node. This netflix talk has some interesting stuff on NUMA and high volume HTTP delivery.

The request load will still not be perfectly balanced between the threads (and therefore cores), but I guess fixing that would have to be the topic of a future post.

Memory allocations

We will still have memory allocations though, both on the kernel and web server side. Memory allocations in user space will eventually need syscalls.

For the web server side, you can pre-allocate a fixed chunk for every connection, and then have everything about that connection live there. That way new connections don’t need syscalls, memory doesn’t get fragmented, and you don’t run the risk of running out of memory.

On the kernel side each connection will still need buffers for incoming and outgoing bytes. This may be somewhat controllable via socket options, but again it’ll have to be the subject of a future post.

Try to not run out of RAM. Bad things tend to happen.

kTLS

kTLS is a feature of the Linux kernel where an application can hand off the job of encryption/decryption to the kernel. The application still has to perform the TLS handshake, but after that it can enable kTLS and pretend that it’s all sent in plaintext.

You may say that this doesn’t actually speed anything up, it just moves where encryption was done. But there are gains:

This means that sendfile() can be used, removing the need to copy a bunch of data between user space and kernel space.
If the network card has hardware support for it, the crypto operation may actually be offloaded from the CPU onto the network card, leaving the CPU to do better things.

Descriptorless files

Another optimization is to avoid passing file descriptors back and forth between user space and kernel space. The mapping between file descriptors and io_uring apparently has overhead.

So in comes descriptorless files via register_files.

Now the supposed file descriptor numbers that user space sees are just integers. They don’t show up in /proc/pid/fd, and can only be used with io_uring. They’re still capped by the ulimit file descriptor limit, though.

tarweb

In order to learn these technologies better, I built a web server incorporating all these things.

It’s named tarweb because it’s a web server that serves the content of a single tar file.

Rust, io_uring, and kTLS. Not exactly the most common combination. I found that io_uring and kTLS didn’t play super well together. Enabling kTLS requires three setsockopt() calls, and io_uring doesn’t support setsockopt (until they merge my PR, that is).

And the ktls crate, part of rustls, only allows you to call the synchronous setsockopt(), not export the needed struct for me to pass to my new io_uring setsockopt. Another pr sent.

So with those two PRs merged, it’s working great.

tarweb is far from perfect. The code needs a lot of work, and there’s no guarantee that the TLS library (rustls) doesn’t do memory allocations during handshakes. But it does serve https without even one syscall on a per request basis. And that’s pretty cool.

Benchmarks

I have not done any benchmarks yet. I want to clean the code up first.

io-uring and safety

One thing making io_uring more complex than synchronous syscalls is that any buffer needs to stay in memory until the operation is marked completed by showing up in the completion queue.

For example when submitting a write operation, the memory location of those bytes must not be deallocated or overwritten.

The io-uring crate doesn’t help much with this. The API doesn’t allow the borrow checker to protect you at compile time, and I don’t see it doing any runtime checks either.

I feel like I’m back in C++, where any mistake can blow your whole leg off. It’s a miracle that I’ve not seen a segfault.

Someone should make a safer-ring crate or similar, using the powers of pinning and/or borrows or something, to achieve Rust’s normal “if it compiles, then it’s correct”.

Edit: I’m not the first to point it out.

This post was discussed on HackerNews on 2025-08-22.

Exploring RISC-V vector instructions

Mon, 24 Mar 2025 00:00:00 +0000

It finally happened! A raspberry pi like device, with a RISC-V CPU supporting the v extension. Aka RVV. Aka vector instructions.

I bought one, and explored it a bit.

SIMD background

First some background on SIMD.

SIMD is a set of instructions allowing you to do the same operation to multiple independent pieces of data. As an example, say you had four 8 bit integers, and you wanted to multiply them all by 2, then add 1. You could do this with a single operation without any special instructions.

    # x86 example assembly.

    mov eax, [myvalues]  # load our four bytes.
    mov ebx, 2           # we want to multiply by two
    imul eax, ebx        # single operation, multiple data!
                         # After this, eax contains 0x02040608
    add eax, 0x01010101  # single operation, multiple data!
                         # After this, eax contains 0x03050709
    mov [myvalues], eax  # store back the new value.

section .data
  myvalues db 1,2,3,4

Success, right? No, of course not. This naive code doesn’t handle over/underflow, and doesn’t even remotely work for floating point data. For that, we need special SIMD instructions.

x86 and ARM have gone the way of fixed sized registers. In 1997 Intel introduced MMX, to great fanfare. The PR went all “it’s multimedia!”. “Multimedia” was a buzzword at the time. This first generation gave you a whopping 64 bit register size, that you could use for one 64-bit value, two 32-bit values, four 16-bit values, or 8 8-bit values.

A “batch size” of 64 bit, if you prefer.

These new registers got a new set of instructions, to do these SIMD operations. I’m not going to learn the original MMX instructions, but it should look something like this:

  movq mm0, [myvalues]  # load values
  movq mm1, [addconst]  # load our const addition values.
  paddb mm0, mm0        # add to itself means multiply by 2
  paddb mm0, mm1        # Add vector of ones.
  movq [myvalues], mm0  # store the updated value.
  emms                  # state reset.

section .data
  myvalues db 1,2,3,4
  addconst db 1,1,1,1

So far so good.

The problem with SIMD

The problem with SIMD is that it’s so rigid. With MMX, the registers are 64 bits. No more, no less. Intel followed up with SSE, adding floating point support and doubling the register size to 128 bits. That’s four 32-bit floats in one xmm register.

So now we have 64-bit mm registers, 128-bit xmm registers, and uncountably many instructions to work with these two sets of new registers.

Then we got SSE2, SSE3, SSE4. Then AVX, AVX2 (256 bit registers), and even AVX-512 (512 bit registers).

512 bit registers. Not bad. You can do 16 32-bit floating point operations per instruction with that.

But here’s the problem: Only if your code was written to be aware of these new registers and instructions! If your production environment uses the best of the best, with AVX-512, you still can’t use that, if your development/QA environment only has AVX2. Not without having separate binaries.

Or you could maintain 20 different compiled versions, and dynamically choose between them. That’s what volk does. Or you could compile with -march=native (gcc) or -Ctarget-cpu=native (Rust), and create binaries that only work on machines at least as new as the one you built on.

But none of these options allow you to build a binary that will automatically take advantage of future processor improvements.

Vector instructions do.

Vector instructions

Instead of working with fixed sized batches, vector instructions let you specify the size of the data, and the CPU will do as many at once as it can.

Here’s an example:

  # Before we enter the loop, input registers are set thusly:
  # a0: number of elements to process.
  # a1: pointer to input elements.
  # a2: pointer to output elements.

  # Load 2.0 once. We'll need it later.
  flw ft0, two
loop:
  # prepare the CPU to process a batch:
  # * a0: of *up to* a0 elements,
  # * e32: each element is 32 bits. The spec calls this SEW.
  # * m1: group registers in size of 1 (I'll get to this). LMUL in the spec.
  # * ta & ma: ignore these flags, they're deep details.
  #
  # t0 will be set to the number of elements in a "batch"
  vsetvli t0, a0, e32, m1, ta, ma

  # Set t1 to be the number of bytes per "batch".
  # t1 = t0 << 2
  slli t1, t0, 2

  # Load a batch.
  vle32.v v0, (a0)

  # Multiply them all by 2.0.
  vfmul.vf v0, v0, ft0

  # Store them in the output buffer.
  vse32.v v0, (a2)

  # Update pointers and element counters.
  add a1, a1, t1
  add a2, a2, t1
  sub a0, a0, t0

  # Loop until a0 is zero.
  bnez a0, loop

two:    .float 2.0

Write once, and when vector registers get bigger, your code will automatically perform more multiplies per batch. That’s great! You can use an old and slow RISC-V CPU for development, but then when you get your big beefy machine the code is ready to go full speed.

The RISC-V vector spec allows for vector registers up to 64Kib=8KiB, or 2048 32-bit floats. And with m8 (see below), that allows e.g. 16384 32-bit floats being multiplied by 16384 other floats, and then added added to yet more 16384 floats, in a single fused multiply-add instruction.

Even more batching

RISC-V has 32 vector registers. On a particular CPU, each register will be the same fixed size, called VLEN. But the instruction set allows us to group the registers, creating mega-registers. That’s what the m1 in setvli is about.

If we use m8 instead of m1, that gives you just four vector registers: v0, v8, v16, and v24. But in return they are 8 times as wide.

The spec calls this batching number LMUL.

Basically a pairwise floating point vector multiplication vfmul.vf v0, v0, v8 in m8 mode effectively represents:

   vfmul.vf v0, v0, v8
   vfmul.vf v1, v1, v9
   vfmul.vf v2, v2, v10
   vfmul.vf v3, v3, v11
   vfmul.vf v4, v4, v12
   vfmul.vf v5, v5, v13
   vfmul.vf v6, v6, v14
   vfmul.vf v7, v7, v15

Bigger batching, at the cost of fewer registers. I couldn’t come up with a nice way to multiply two complex numbers with only four registers. Maybe you can? If so, please send a PR adding a mul_cvec_asm_m8_segment function to my repo. Until then, the m4 version is the biggest batch. m8 may still not be faster, since the m2 version of mul_cvec_asm_mX_segment is a little bit faster than the m4 version in my test.

Like with SIMD, there are convenient vector instructions for loading and handling data. For example, if you have a vector of complex floats, then you probably have real and imaginary values alternating. vlseg2e32.v v0, a0 will then load the real values in v0, and the imaginary values in v1.

Or, if vsetvli was called with m4, the real values will be in v0 through v3, and imaginary values in v4 through v7.

Curiously a “stride” load (vlse32.v v0, (a0), t1), where you can do things like “load every second float”, seems to not have very good performance. Maybe this is specific to the CPU I’m using. I would have expected the L1 cache to make them fairly equal, but apparently not.

So yes, it’s not perfect. On a future CPU it may be cheap to load from L1 cache, so your code should be more wasteful about vector registers, to be optimal. Maybe on a future CPU the stride load is faster than the segmented load. There’s no way to know.

The Orange Pi RV2

It seems that the CPU, a Ky X1, isn’t known to llvm yet. So you have to manually enable the v extension when compiling. But that’s fine.

$ cat ~/.cargo/config.toml
[target.riscv64gc-unknown-linux-gnu]
rustflags = ["-Ctarget-cpu=native", "-Ctarget-feature=+v"]

I filed a bug with Rust about it, but it seems it may be a missing LLVM feature. It’s apparently not merely checking /proc/cpuinfo for the features in question, but needs the name of the CPU in code or something.

It seems that the vector registers (VLEN) on this hardware are 256 bit wide. This means that with m8 a single multiplication instruction can do 8*256/32=64 32-bit floating point operations. Multiplying two vector registers in one instructions multiplies half a kibibyte (256 bytes per aggregate register).

64 32bit operations is a lot. We started off in SIMD with just 2. And as I say above, when future hardware gets bigger vector registers, you won’t even have to recompile.

That’s not to say that the Orange Pi RV2 is some sort of supercomputer. It’s much faster than the VisionFive 2, but your laptop is much faster still.

So how much faster is it?

I started a Rust crate to test this out.

$ cargo +nightly bench --target  target-riscv64-no-vector.json -Zbuild-std
[…]
running 10 tests
test bench_mul_cvec_asm_m2_segment ... bench:       2,930.20 ns/iter (+/- 29.96)
test bench_mul_cvec_asm_m4_segment ... bench:       3,036.18 ns/iter (+/- 100.35)
test bench_mul_cvec_asm_m4_stride  ... bench:       4,713.20 ns/iter (+/- 55.09)
test bench_mul_cvec_asm_m8_stride  ... bench:       5,368.08 ns/iter (+/- 15.18)
test bench_mul_cvec_rust           ... bench:       9,957.66 ns/iter (+/- 76.39)
test bench_mul_cvec_rust_v         ... bench:       3,020.23 ns/iter (+/- 21.72)
test bench_mul_fvec_asm_m4         ... bench:         843.94 ns/iter (+/- 22.86)
test bench_mul_fvec_asm_m8         ... bench:         801.36 ns/iter (+/- 27.71)
test bench_mul_fvec_rust           ... bench:       4,097.09 ns/iter (+/- 29.77)
test bench_mul_fvec_rust_v         ... bench:       1,084.47 ns/iter (+/- 13.46)

The “rust” version is normal Rust code. The _v code is Rust code where the compiler is allowed to use vector instructions. As you can see, Rust (well, LLVM) is already pretty good. But my hand coded vector assembly is faster still.

As you can see, the answer for this small benchmark is “about 3-5 times faster”. That multiplier probably goes up the more operations that you do. These benchmarks just do a couple of multiplies.

Note that I’m cheating a bit with the manual assembly. It assumes that the input is an even multiple of the batch size.

Custom target with Rust

To experiment with target settings, I modified the target spec. This is not necessary for normal code (you can just force-enable the v extension, per above), but could be interesting to know. In my case I’m actually using it to turn vectorization off by default, since while Rust lets you enable a target feature per function, it doesn’t let you disable it per function.

rustup install nightly
rustup default nightly
rustc  -Zunstable-options \
  --print target-spec-json \
  --target=riscv64gc-unknown-linux-gnu \
  > mytarget.json
rustup default stable
# edit mytarget.json
rustup component add --toolchain nightly rust-src
cargo +nightly bench --target mytarget.json -Zbuild-std

Did anything not “just work”?

I have found that the documentation for the RISC-V vector instructions are a bit lacking, to say the least. I’m used to reading specs, but this one is a bit extreme.

vlseg2e32.v v0, (a0) fails with illegal instructions when in m8 mode. That’s strange. Works fine in m1 through m4.

Can we check the specs on the CPU? Doesn’t look like it. It’s a “Ky X1”. That’s all we’re told. Is it truly RVV 1.0? Don’t know. Who even makes it? Don’t know. I see guesses and assertions that it may be by SpacemiT, but they don’t list it on their website. Maybe it’s a variant of the K1? Could be. The English page doesn’t load, but the Chinese page seems to have similar marketing phrases as Orange Pi RV2 uses for its CPU.

Ah, maybe this is blocked by the spec:

The EMUL setting must be such that EMUL * NFIELDS ≤ 8, otherwise the instruction encoding is reserved. […] This constraint makes this total no larger than 1/4 of the architectural register file, and the same as for regular operations with EMUL=8.

So for some reason you can’t load half the register space in a single instruction. Oh well, I guess I have to settle for loading 256 bytes at a time.

It’s a strange requirement, though. The instruction encoding allows it, but it just doesn’t do the obvious thing.

ARM

ARM uses SIMD like Intel. I vaguely remember that it also has vector instructions (SVE?), but I’ve not looked into it.

Can I test this out without hardware?

Yes, qemu has both RISC-V support and support for its vector instructions. I didn’t make precise notes when I tried this out months ago, but this should get you started.

tl;dr

Vector instructions are great. I wasn’t aware of this register grouping, and I love it.

Rebuilding FRR with pim6d

Thu, 27 Feb 2025 00:00:00 +0000

Short post today.

Turns out that Debian, in its infinite wisdom, disables pim6d in frr. Here’s a short howto on how to build it fixed.

$ sudo apt build-dep frr
[…]
$ apt source frr
[…]
$ cd frr-8*
$ DEB_BUILD_PROFILES=pkg.frr.pim6d dpkg-buildpackage -us -uc -b
$ sudo dpkg -i ../frr_*.deb

Then you can enable pim6d in /etc/frr/daemons and restart frr.

Not that I managed to get IPv6 multicast routing to to work over wireguard interfaces anyway. Not sure what’s wrong. Though it didn’t fix it, here’s an interesting command that made stuff like ip -6 mroute look like it should work:

$ sudo smcroutectl  add LAN ff38:40:fd11:222:3333:44:0:1122 wg-foo