peteg's blog

/noise/beach/2009-2010 | Link

Thinking that it had been more than a day since the last rain, and trying to get in ahead of the forecast shower, I went for an early-afternoon paddle at Gordons Bay. The surf was quite rough even in the bay, due to an apparently 2.5 to 3.5 metre swell, and there was a fair bit of leaf litter, seaweed and garbage in the water. The wind was quite stiff, resulting in a lot of whitewater. A bloke was trying to fish near my hop-in rocks, but quit while I was in the water.

John Brunner: No Future In It

/noise/books | Link

I read this one over many months, dipping into it when there was nothing better on offer. As a collection of short stories from the early 60s and late 50s it is not bad, but Brunner really only got going about a decade later. There are some cute ideas but nothing scintillating, and the prose is a bit workman-like, as if he's in it just to pay for those drugs.

Some of the stories are structurally similar to his later work -- mysteries with a late twist, narrative sliced up with extraneous noise.

Scraping the nixie clock software together.

/hacking/nixie_clock | Link

I spent the evening polishing a root filesystem for the ts7250. The flash is quite fat (128Mb) so I gave up on some of the buggy busybox applets (udhcpc in particular) in favour of their real counterparts from the Debian distro. This approach put dropbear back onto its branch, and as the board can reliably connect to the WiFi router I can now SSH into it almost always after boot. It displays the time now, and synchronises with ntp, and the built-in real-time clock works too, albeit with some hefty drift.

Unfortunately the system still does not schedule my program very satisfactorily: any perturbation in CPU load results in flicker, and it struggles to play an mp3 without skipping. This is with a low-latency Linux kernel (2.6.32.3). I get the impression that later kernels in that series are easy to get going on the ts7250, so I might try one, but apparently there will not be a full RT patch for 2.6.32. Bleeding edge it may have to be.

Part of the reason is that my program naively uses the kernel scheduler for all delays, not just the larger ones. Thus when there is contention for the CPU the system overhead spikes, taking roughly as much time as user code. The sirq (presumably clock interrupt) load is circa 10%. I can feel some busy waiting coming on.