bridges to past peripherals

I’ve been slowly bringing up a dual Xeon E5472 system from circa 2008 as a storage server. It has a single PCI-X slot, with the rest PCIe x4. The PCI-X slot is occupied by a 3ware escalade variant, so I have no other PCI slots available. I originally intended to run Joyent SmartOS on it for use as a dedicated storage server, possibly migrating some VMs to containers. The SmartOS kernel (nee OpenSolaris) unfortunately doesn’t support the 3ware card, even in JBOD mode, and I already deal with ZFS with Linux at work, so I figured I’d try FreeBSD. I was able to get it installed on a ZFS mirror of mismatched drives after running through a manual gauntlet, but spare SATA drives are in short supply in my basement datacentre, so I figured I’d see what else I could connect to it. (I’m holding out hope for a PCIe SCSI controller to keep some SCA drives in service.)

For kicks, I purchased a PCIe to PCI bridge, so I could install a PATA controller, and try running ZFS mirrors on some new-old-stock PATA drives. I expected the PATA controller to be minimally functional, but I’m pleasantly surprised at how well it works. Benchmark performance is comparable to within a couple percent (2% worse, in some cases 10% better) than a mirror assembled from my mismatched SATA drives. I suppose this isn’t surprising since the drives I’m testing are contemporaries, just with different interfaces. (I also expect that as I add more spindles to the PCI-X SATA controller it will continue to scale bandwidth, which ye olde IDE controller can’t physically do.)

My computing conscience pointed out that a far better use of this newly acquired SATA connectivity would be to buy some large SATA drives and copy images and/or data from the smaller obsolete drives I have been collecting for data retention purposes, and then get rid of them. Going through a few drives so far, the storage space is trivial, since all the drives of interest are < 100GB. After optionally transferring contents of and clearing a few drives, I ended up with a pile to take to the local recycler. While I was there, I picked up three 500GB WD blues to assemble into a ~1TB RAIDZ. I'm getting roughly 100MByte read and write benchmark speeds, which seems plenty fast for my purposes. The only benchmarks I have which beat it are SSDs or a (very) large (now waterfalled) fibrechannel disk array. Seems like adding a few more disks for a 6-disk RAIDZ2 could make sense, but I also have a couple 3TB drives I plan on shuffling into the array as part of my grand migration scheme.

raspi is not the ARM I’m looking for

I got a raspberry pi a couple years ago as a christmas present from my brother-in-law. I like the idea. A cheap computer with roughly the same horsepower of my workstations of yesteryear, in a power-sipping small form factor. I want to believe, but the experience is disappointing.

First disappointment was that the accouterments for the pi (power supply, SD card, functional case, wifi adapter) cost as much as the base unit. The 1541 disk drive also cost more than a c64, so this isn’t a horrible shock, but the $40 pi price is not all-inclusive.

I christened my pi “bunnypi,” and originally had it mounted on the back of a dedicated monitor with a LaRu bunny sticker on it. My original plan was to introduce my son to old-school DOS games via DOSBox on it. This was marginally successful, since DOSBox runs only at roughly the 286-12 level, with noticeable performance glitches. This hasn’t stopped my son from playing with “the guys” in Ultima VI, or matching words in reader rabbit, but an actual 386 is more performant. ScummVM seems to run reasonably well with older titles, but is not frequently updated from upstream, so some of my favorite games remain unsupported on the pi.

Bunnypi not terribly reliable. It seems prone to overheating. A few times a year the raspbian updater seems to corrupt its own bootloader, leaving me with having to manually perform firmware and loader fixups. Part of the unreliability is just cheap hardware — the “official” power supply I received mine seems to have lost capacity over time, and plugging in the WiFi adapter caused the system to reset. It would hang at boot if the WiFi was left plugged in. I replaced the power supply with a beefier unit from my now-broken tablet, (which can source extra current needed for charging,) and it seems to be working better, although I’m still seeing periodic USB disconnect / reconnect cycles. As for the linux updates / upgrades, screwing up the boot process somehow seems par for the linux distro course. (Take distro of your choice, find the earliest version that will install on your target hardware or VM, and walk it through updates / upgrades to the latest version, and see if it makes it…)

The on-board audio of bunnypi is noisy PWM, limiting its utility for music playing. The noise is signal-correlated, so adding some noise-shaped dither might be able to help, but setting up the audio output chain is quite fiddly. Add-on boards with discrete DACs are available, or maybe a cheap $5 USB adapter would be good enough?

Bunnypi can drive my 1080 TV over HDMI, and the kids do love the screensavers, but the accelerated graphics support seems nonexistent. A little reading indicates the graphics acceleration supported on the pi is OpenGL ES, not standard OpenGL. Youtube videos of ES demos on the pi show it is capable of high-framerate graphics, but apparently doing a translation of OpenGL to OpenGL ES to get standard X screensavers either hasn’t been done yet, or is technically prohibitive. (Impossible? This is open source, right?)

USB is the only I/O available beyond GPIO and SD, so I don’t honestly know how people develop for this unless there is a cross-compile environment, emulator, or binary-compatible bigger brother that I’m not aware of. (Do people really put in giant SD cards to do raspi development? Or use USB hard-drives?)

The web browser is awkwardly slow. I installed a supposedly optimized webkit-based browser, but it wasn’t noticeably faster. And of course no flash or HTML5 video support, so no youtube.

The core use of bunnypi remains a dedicated screensaver generator.

Where are the grown-up ARM systems? Something with real I/O (PCIe, SATA, 100M+ ethernet) and ECC memory?

continuity of self-bootstrapping

I’ve been collecting build times for over a decade now, in an effort to grok how much faster newer hardware is, how much larger software is getting, and to normalize expectations between my various pieces of hardware. I use the NetBSD world as a microcosm for this, since it is fairly self-contained, and since NetBSD-2, the build process does a full bootstrap including building a (cross-)compiler. A modern Intel Romley or Grantley platform can build the NetBSD-7 amd64 world in less than 20 minutes, and is completely I/O bound. (Of course, I’m not sure when compilation has ever not been I/O bound…)

Self-hosted builds are in some sense “alive” — they beget the next version, they reproduce, and they propagate changes and grow over time. I don’t believe anybody bootstraps from complete scratch anymore these days, with hand-written hand-assembled machine code toggled directly into CPU memory into an environment that supports a macro assembler, which generates an environment that can host a rudimentary C compiler, etc. While there is a base case, it is an inductive process: developers use OS to create OS+1, or cross-compile from OS/foocpu to OS/barcpu. How far back could I go and walk this path? Could I do it across architectures? (Historically, how did things jump from PDP11 to VAX to i386?)

As I’ve been saying goodbye to my oldest hardware, I’ve been trying to get a sense of continuity from those early machines to my latest ones, and wanted to see if I could bootstrap the world on one of my oldest and slowest systems, and compare it with doing the same thing on one of my more modern systems. Modern is relative, of course. I’ve been pitting a circa 1990 12.5MHz MIPS R2000 DECStation (pmin) with 24MiB of RAM against a VM instance running on a circa 2010 3GHz AMD Phenom xII 545, both building the NetBSD 1.4.3A world. AMD (PVHVM) does a full build in 11 minutes. The same process on the pmin takes almost four days. This isn’t a direct apples-to-apples comparison, since the pmin is building NetBSD/pmax and the AMD is building NetBSD/i386, but it gives a good order-of-magnitude scale. (I should throw a 25MHz 80486 into the mix as a point for architectural normalization…)

Now for the continuity. I started running NetBSD on the pmax with 1.2, but I only ran it on DECStations until 1.4, and new architectures were always installed with binary distributions. Could I do it through source? As far as I can tell, the distributions were all compiled natively for 1.4.3. (The cross-compile setup wasn’t standardized until NetBSD-2.) Even following a native (rather than cross-compiled) source update path, there were some serious hiccups along the way: 1.4.3 (not 1.4.3A) doesn’t even compile natively for pmax, for instance. On i386, the jump from 1.4.3 to 1.5 is fiddly due to the switch from a.out to ELF formats. I spent a few evenings over winter break successfully fiddling this out on my i386 VM, recalling that a couple decades ago I was unsuccessful in making a similar jump from a.out to ELF with my Slackware Linux install. (I eventually capitulated back then and installed RedHat from binary.)

So far, I’ve gotten a 1.4.3 pmax to bootstrap 1.4.3A, and gone through the gyrations to get an 1.4.3 a.out i386 to bootstrap 1.5.3 ELF. Next step is doing 1.4.3A -> 1.5.3 on the pmax. We should then be able to do a direct comparison with 1.5.3 -> 1.6 matrix of native vs cross-compiled on both systems, and that will give me crossover continuity, since I could potentially run an i386 that has been bootstrapped from source on the pmin.

I’m also interested in the compile time scaling from 1.4.3 -> 1.4.3A -> 1.5 -> 1.5.3 -> 1.6 across multiple architectures. Is it the same for both pmin and i386? When does 24MiB start hurting? (the pmin didn’t seem overly swappy when building 1.4.3A.) Can I bring other systems (m68k, vax, alpha, sparc) to the party, too?

Some people walk a labyrinth for solace… I compile the world.

modems added to the ice floe

I added a couple telebit trailblazers to the ice floe a couple days ago, and tonight my US Robotics courier HST.

My father purchased a Kyocera 1200 bps modem for our family’s Leading Edge model D, with the hope that my mom could use it for her transcription and word-processing business. I used it to call BBSes. It took at least a year before I figured out how to get file transfers working with the included Microsoft Access comm program. (Not Microsoft Access the database — Access the comm program!) I downloaded Procomm with the Xmodem-checksum protocol, then later Telix (with Zmodem).

I saved my paper route money to buy a 2400bps modem. I did ANSI. I ran a BBS. I saved more paper route money and got at 14.4k courier HST through a local sysop of a large multi-line BBS. In the early 90s it was cheaper for me to call across the country in the middle of the night with a budget long-distance provider than to call to the more remote areas of my own area code, but that’s the subject of another post…

When I arrived in college, the sysadmin there knew I had run a BBS, beckoned me to the the sub-basement, and handed me a Xylogics terminal server. “You can make this work, right?” I first configured it to replace the old Cisco STS-10, providing direct text logins for students and alums. I opened up PPP connections a couple months later, and wrote an awk script to parse the log files and identify freeloaders. As a staff member, I of course never showed up on the freeloader list, even though I left my connection up 24/7, phone line connection permitting.

During a year break from college, I was employed at a large regional ISP as a system operator, junior to the sysadmins. I did the grunt-work of hard-resetting (yanking and re-seating) failing modems from the 800+ lines in our local POP, and directing our field guy to busy-out or replace modems that appeared to be broken at the frame-relay-connected remote POPs.

A couple years later I replaced my nailed-up V34 modem with a DSL connection, first CAP and later DMT. When the telco started interfering with their own DSL connections and the combination of video streaming and work-related VPN needs started outstripping DSL, I moved to a cablemodem.

I originally kept my modems with the intent of setting up a backup UUCP connection for my email, as I had provided others in college. Since moving jobs to corpoland, I no longer have control over a remote PSTN line, so can’t set up my own out-of-band UUCP connection. I no longer have a POTS line at home. I suspect that modems over VOIP do not fare well, although V.MOIP is supposed to address this. In any case, the sunset on modems designed to work over the PSTN has long since passed, and so it’s time to say goodbye.

I don’t even have another HST modem to dial in order to capture handshake audio, and a cursory search on the internet doesn’t reveal any such recordings. My HST has spent over a decade in a box, and the last time I fired it up, the NVRAM was completely shot, and it’s not like I have anywhere to dial anymore.

The option of simulating old tyme internet over a serial connection is always available by using a null modem cable. Latency will obviously be better, but it’s just a simulation. screeching handshake not included.

the kids have met spinning media

My children have met spinning media. I play games with them on my c64, so they know what floppy drives are. I play vinyl records for them. They have a small DVD collection of movies. Tonight we took apart a couple hard drives so I could show them the insides. They enjoy using screwdrivers.

First up was a full-height 1.6GB Seagate PA4E1B 5.25″ drive. We weren’t able to get the lid off, but they could see the drive arms and all the platters. Ten of them. Eighteen heads on the arm. (Later, with a hammer and screwdriver, I was able to get the lid off.)

We then moved to a 3.5″ 52MB Quantum Prodrive 52S. When the top of the drive came off, my daughter recognized the configuration of the head and arm over the platter. “It looks like a record,” she said. Two heads, and an optical detector for the tracks, rather than using servo tracks. I now wish I had fired it up and listened to it before disassembly, as I suspect it may have had a unique sound.

The largest drives I have now in my home datacenter are 3TB. MicroSD cards sold at the checkout lanes at my local supermarket can hold more data than the drives we disassembled in a fraction of the physical space, with orders of magnitude less power consumption. SSDs are catching up to spinning rust in capacity, and Intel’s recently announced non-volatile memory pushes densities even higher. It’s possible my kids will never have to delete data in their adult lives — data would get marked as trash, but would still technically available for retrieval “just in case” because the cost savings of actually reclaiming the space used by data will be negligible.

I had a Xerox 820-II CP/M machine with 8″ floppies that stored close to 1MB of data. My family had a PC with a 30MB hard drive, and I remember being in awe in the early 90s thinking about 1GB hard drives that cost around $1k. I bought a 179MB drive in high school with stipend money, and scrounged drives of various sizes throughout college. I don’t remember the first drive > 1GB that I owned — very few have survived. I vaguely recall a jump from hundreds of MB to tens of GB that happened in the early 2000s. All spinning media.

All slowly succumbing to mechanical wear-out, or more simply, obsolescence.


The first of three sun V20zs was decommissioned tonight. These were all surplus, and they sat for probably a year until I actually got around to dispositioning them. I think the machine failures of my sparc sun hardware were lining up. The sparc 2 I had been using as my gateway router failed due to bad cache, and I had replaced it with an ultra 5. The dual 50MHz sparc 20 was already long in the tooth, and a drive was starting to fail. I needed some place to land a new mail server, and I figured I’d create a virtual one, so I could collapse it to another VM host when the time came.

It served well while I got faster and more capable machines online. I even ran Xen on it for a time until I got newer x2200m2s online. Although the Opteron 250s in the v20z were 64-bit with a whopping 8GB of RAM, they didn’t support hardware virtualization, so I was paravirtualized only.

I recall the I/O under Xen PV being decent, with times comparable between bare metal and a DomU. Build times for NetBSD-6.0 were a little over 2hrs on bare metal, and under 2hrs on a Linux DomU running under NetBSD Dom0. Obviously I/O bound, and some help from Linux’ FS caching subsystem doing a better job than NetBSD. πŸ™‚

The service processor (remote management module) on the v20z was an embedded PPC running Linux, with an oddball CLI on it. I still had to deal with stupid PCisms like having to attach to the console and go to BIOS to change settings, but it was definitely an improvement over run-of-the-mill PC hardware.

One of the two remaining V20zs is running Joyent’s SmartOS system, primarily for fiddling with ZFS on a pile of SCA drives. The other V20z is unpowered and will be examined before being added to the stack later this week to see if it has any 2GB DIMMs to donate to the SmartOS cause. (and maybe get a dmesg and openssl benchmark.)

The V20z was an example of PC architecture taking a step up into serverhood, with the first generation Opteron kicking Intel while it was floundering with the Pentium 4. These machines still seem to be plenty fast to me, and one of the reasons I’m ditching them is that I’m finally getting a handle on just how much more CPU power newer systems have, not to mention power efficiency gains. I/O continues to be a sore point, and these are still SCA systems, so they are not trivially upgraded to SSDs. My kill-a-watt measurements showed 230W idle, and 275W while active.

Heh. The second system on the kill-list has only four 512M DIMMs. It will head onto the ice floe tomorrow after a disk yank and SP reset. But not before yanking 4GB of RAM from the first system to put into the remaining V20z. πŸ™‚

bye SGIs

last weekend I dropped off a stack of SGI challenges and an indy to my local recycler. there’s only so much that can be done with a 200MHz R4400 CPU these days. there’s also still some pmap bugs in NetBSD, so I never could complete a build of the world, although I did get some openssl numbers.

I never had these systems in production use, so there’s not a lot of emotional attachment. just the lost potential.

MIPS seems to be bare-bones these days. not even parity memory. I don’t get it. it was a serious workstation- and server-level CPU, and now it’s used for networking gear and more disturbingly for NAS boxes. (seriously, who would ever trust data to a storage subsystem that isn’t at least performing parity checks? yet most MIPS-based NAS boxes don’t have parity or ECC memory!?) MIPS was server-level in the early 90s. no longer.

here’s some dmesg and openssl benchmarks… photos later after I get them exported from raw.

I still like the SGI speckle finish and design. I’ll remember the indy’s fanfare when it was powered up. the electropaint screensaver that inspired xscreensaver’s stonerview. playing mp3 layer 2 files from an early music site… (can’t recall the name this late.) the lp account with no password. the awkwardness of IRIX. OK stopping before the bad memories surface.

here’s some dmesg.

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 7.0 (GENERIC32_IP2x.201510122130Z)
total memory = 128 MB
(768 KB reserved for ARCS)
avail memory = 119 MB
timecounter: Timecounters tick every 10.000 msec
mainbus0 (root): SGI-IP22 [SGI, 690a313e], 1 processor
cpu0 at mainbus0: MIPS R4400 CPU (0x460) Rev. 6.0 with MIPS R4010 FPC Rev. 0.0
cpu0: 48 TLB entries, 16MB max page size
cpu0: 16KB/16B direct-mapped L1 instruction cache
cpu0: 16KB/16B direct-mapped write-back L1 data cache
cpu0: 1024KB/128B direct-mapped write-back L2 unified cache
int0 at mainbus0 addr 0x1fbd9880
int0: bus 100MHz, CPU 200MHz
imc0 at mainbus0 addr 0x1fa00000: revision 3
gio0 at imc0
newport0 at gio0: SGI NG1 (board revision 4, cmap revision 5, xmap revision 5, vc2 revision 0), depth 8
wsdisplay0 at newport0 kbdmux 1
wsmux1: connecting to wsdisplay0
hpc0 at gio0: SGI HPC3 (onboard)
zsc0 at hpc0 offset 0x59830
zstty0 at zsc0 channel 1 (console i/o)
zstty1 at zsc0 channel 0
pckbc0 at hpc0 offset 0x59840
sq0 at hpc0 offset 0x54000: SGI Seeq 80c03
sq0: Ethernet address 08:00:69:0a:31:3e
wdsc0 at hpc0 offset 0x44000: WD33C93B (20.0 MHz clock, BURST DMA, SCSI ID 0)
wdsc0: microcode revision 0x0d, Fast SCSI
scsibus0 at wdsc0: 8 targets, 8 luns per target
haltwo0 at hpc0 offset 0x58000: HAL2 revision 4.1.0
audio0 at haltwo0: half duplex, playback, capture
pi1ppc0 at hpc0 offset 0x59800
pi1ppc0: capabilities=0x8
ppbus0 at pi1ppc0
ppbus0: No IEEE1284 device found.
lpt0 at ppbus0: port mode = 0x1
panel0 at hpc0 offset 0x59850
dsclock0 at mainbus0 addr 0x1fbe0000
ioc0 at mainbus0 addr 0x1fbd9800: rev 0, machine Indy (Guinness), board rev 0
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
timecounter: Timecounter "mips3_cp0_counter" frequency 100000000 Hz quality 100
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 1 lun 0:  disk fixed
sd0: 17518 MB, 10042 cyl, 12 head, 297 sec, 512 bytes/sect x 35877972 sectors
sd0: sync (100.00ns offset 12), 8-bit (10.000MB/s) transfers, tagged queueing
boot device: sd0
root on sd0a dumps on sd0b

and some openssl results:

OpenSSL 1.0.1p 9 Jul 2015
NetBSD 7.0
options:bn(32,32) md2(int) rc4(ptr,int) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr)
gcc version 4.8.4 (NetBSD nb2 20150115)
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md2                 78.66k      178.98k      257.45k      290.53k      303.10k
mdc2               145.06k      218.49k      252.84k      263.22k      265.83k
md4                272.68k     1020.27k     3510.04k     8881.49k    15989.37k
md5                221.69k      829.48k     2735.18k     6375.68k    10435.90k
hmac(md5)          432.03k     1521.22k     4359.31k     8265.54k    11164.68k
sha1               226.51k      804.40k     2370.03k     4631.29k     6387.03k
rmd160             157.18k      555.69k     1615.45k     3064.52k     4192.54k
rc4               7713.16k     8239.91k     7964.19k     7774.18k     8311.75k
des cbc           1339.39k     1451.10k     1482.15k     1495.11k     1388.01k
des ede3           442.20k      453.40k      452.86k      452.21k      503.50k
idea cbc          1772.67k     1894.70k     1922.57k     1920.86k     1916.00k
seed cbc          1880.76k     2062.38k     2107.36k     2091.69k     2102.61k
rc2 cbc           1549.19k     1627.91k     1639.00k     1637.72k     1641.15k
rc5-32/12 cbc        0.00         0.00         0.00         0.00         0.00
blowfish cbc      3121.18k     3362.69k     3491.58k     3559.60k     3588.10k
cast cbc          2230.75k     2412.86k     2450.63k     2468.83k     2454.86k
aes-128 cbc       2528.06k     2744.85k     2819.34k     2849.51k     2852.23k
aes-192 cbc       2141.74k     2331.49k     2441.50k     2459.99k     2460.35k
aes-256 cbc       1906.51k     2058.35k     2139.82k     2156.59k     2155.50k
camellia-128 cbc     1649.84k     2178.77k     2367.96k     2438.76k     2427.26k
camellia-192 cbc     1389.08k     1737.42k     1857.25k     1886.21k     1884.98k
camellia-256 cbc     1375.05k     1733.15k     1853.87k     1892.86k     1887.72k
sha256             357.50k      866.70k     1587.03k     2004.45k     2181.78k
sha512             140.38k      561.43k      904.85k     1298.90k     1482.75k
whirlpool          109.76k      224.54k      365.65k      435.29k      459.95k
aes-128 ige       2238.29k     2535.68k     2638.35k     2672.33k     2672.61k
aes-192 ige       1964.70k     2209.11k     2280.95k     2303.49k     2335.83k
aes-256 ige       1848.34k     1985.61k     2037.47k     2040.78k     2056.19k
ghash             2965.22k     3198.88k     3252.14k     3205.57k     3271.32k
                  sign    verify    sign/s verify/s
rsa  512 bits 0.054054s 0.004529s     18.5    220.8
rsa 1024 bits 0.291429s 0.014821s      3.4     67.5
rsa 2048 bits 1.931667s 0.053209s      0.5     18.8
rsa 4096 bits 12.870000s 0.198824s      0.1      5.0
                  sign    verify    sign/s verify/s
dsa  512 bits 0.045571s 0.055414s     21.9     18.0
dsa 1024 bits 0.149552s 0.175088s      6.7      5.7
dsa 2048 bits 0.525263s 0.648750s      1.9      1.5
                              sign    verify    sign/s verify/s
 160 bit ecdsa (secp160r1)   0.0152s   0.0746s     65.8     13.4
 192 bit ecdsa (nistp192)   0.0157s   0.0758s     63.7     13.2
 224 bit ecdsa (nistp224)   0.0216s   0.1059s     46.2      9.4
 256 bit ecdsa (nistp256)   0.0325s   0.1772s     30.7      5.6
 384 bit ecdsa (nistp384)   0.0693s   0.3858s     14.4      2.6
 521 bit ecdsa (nistp521)   0.1998s   1.0970s      5.0      0.9
 163 bit ecdsa (nistk163)   0.0176s   0.0755s     56.9     13.2
 233 bit ecdsa (nistk233)   0.0373s   0.1507s     26.8      6.6
 283 bit ecdsa (nistk283)   0.0567s   0.2668s     17.6      3.7
 409 bit ecdsa (nistk409)   0.2597s   0.6200s      3.8      1.6
 571 bit ecdsa (nistk571)   0.3654s   1.4271s      2.7      0.7
 163 bit ecdsa (nistb163)   0.0172s   0.0820s     58.1     12.2
 233 bit ecdsa (nistb233)   0.0368s   0.1602s     27.2      6.2
 283 bit ecdsa (nistb283)   0.0566s   0.2976s     17.7      3.4
 409 bit ecdsa (nistb409)   0.1548s   0.7013s      6.5      1.4
 571 bit ecdsa (nistb571)   0.4786s   1.6467s      2.1      0.6
                              op      op/s
 160 bit ecdh (secp160r1)   0.0637s     15.7
 192 bit ecdh (nistp192)   0.0640s     15.6
 224 bit ecdh (nistp224)   0.0917s     10.9
 256 bit ecdh (nistp256)   0.1524s      6.6
 384 bit ecdh (nistp384)   0.3209s      3.1
 521 bit ecdh (nistp521)   0.9000s      1.1
 163 bit ecdh (nistk163)   0.0366s     27.3
 233 bit ecdh (nistk233)   0.0709s     14.1
 283 bit ecdh (nistk283)   0.1320s      7.6
 409 bit ecdh (nistk409)   0.3094s      3.2
 571 bit ecdh (nistk571)   0.7113s      1.4
 163 bit ecdh (nistb163)   0.0411s     24.3
 233 bit ecdh (nistb233)   0.0795s     12.6
 283 bit ecdh (nistb283)   0.1469s      6.8
 409 bit ecdh (nistb409)   0.3514s      2.8
 571 bit ecdh (nistb571)   0.8185s      1.2

ham nets still active

An email from my kid’s school carried a suggestion from a parent that a satellite phone would be helpful in a natural disaster. It might be fine for contacting people outside of the affected area, but within the affected area, you are dependent on the local phone infrastructure, which has a strong likelihood of being out of commission. A handheld ham-radio doesn’t rely on anything external for communications, although it can optionally make use of repeaters.

Interleaved with kid-tending today, I fired up my Yaesu HT and listened to a local 2M repeater which was supporting the local marathon, complete with a net controller and tactical callsigns. After dinner, the repeater nets started coming alive, (first Sunday of the month is apparently a thing,) with checkins from all over the state and part of the neighboring state. I even heard there is an upcoming exercise that is attempting to simulate traffic flows generated from a 9.0 earthquake under field-day (no grid power) conditions. (I’d participate, but I need to get my license back first.)

As in my youth, all hams still seem to be at least a couple decades older than me, but maybe the demographics change in the digital modes, which I have yet to explore.

Or perhaps this is just another iteration on a passing hobby that my eye has currently focused on?

a pang for a DECstation

Tonight I revisited a longstanding question of mine: what does Ubuntu bring to the table over Debian? This of course leads me to look at hardware support for each, especially non-amd64 support. Mix this with current efforts to get my SGI systems running again, and I wonder what the state of Linux is for such platforms.

Linux doesn’t even seem to try to support older platforms anymore. Debian 8 doesn’t support sparc anymore, and mips is limited to malta, octeon, and loongson. No sgimips, no decstation, no alpha, no vax, and no hp300. ARM is the hot thing, but slapping a raspberry pi in a rack doesn’t make it server-class, and actual server-class ARM hardware hasn’t made its way to my basement datacentre… yet.

NetBSD at least still tries to keep running on older hardware. NetBSD-7 boots on my dusted-off sgimips Indy, although it seems to have some issues with cache management, which might be kernel bugs, or might be bad hardware. I don’t know enough about page table fault handling on MIPS to know for sure.

The MIPS action of course made me think of and miss my DECStations. One DECStation, in particular. It was a DECStation 5000/240, and ran almost nonstop from 1999ish to 2013. It was the main brain of my home network, handling DNS, DHCP, YP, HTTP, SMTP, and NFS on my home network for most of its life. I moved SMTP off to a dedicated dual CPU sparc 20 when spam filtering became a pain point. HTTP and home directories were moved to an alpha, although I can’t recall if they moved before or after SMTP.

The 5000/240 never let me down. Drives failed, and I had to stop running local backups onto QIC tape at some point due to lockups, (I suspect to a dodgy power supply in the expansion unit which did eventually fail,) but the machine itself kept on working until I was <ahem> prompted to clear some things out of the basement in late 2011. I had been trickling the moving of services over to newer active systems since 2011, but it still made me sad to shut it down. Attempting to build the NetBSD world on a 5000/200 and never being successful due to a failing disk (after a couple days of running) really drove the point home of how far software has outstripped the hardware.

Luckily a (now ex-) co-worker was interested in collecting my 5000/240, and it avoided the recycler. I still miss it.

ham radios

I just closed some web tabs containing renewal information about my expired ham radio license which have been festering for over a month now. When my license expiration date came around, I was led to believe that renewal could not be done directly through the FCC, and had to be done through a VEC. I figured if I really wanted to keep my ham license, I should meet up with a local group. It never happened, and my license expired.

I have radio machines. A tube heathkit HW-101, a sandbox HF icom, and a modern tri-band yaesu HT.

The HW-101 was given to me in high school, and barely worked when I got it. In college a ham I met on usenet sent me the full schematics and service manual, and I was able to tune it up a bit, but I could tell that some of the tubes needed replacement. After college, I had a co-worker who got into the surplus tube sorting business with his sister, and was able to get me a few replacements. Since owning a house, I’ve never put up an antenna, and haven’t fired it up. I should get rid of it, as the icom likely bests it in all metrics except for heat production. and sound. and smell. the tube rig has a satisfying hum when it fires up, and smells like toasted dust when it warms up. the filaments glow. the feel can’t be emulated.

the HF icom was pieced together from two friends, one who had the radio, and the other had the power supply. I don’t know how the two components got separated, but they were reunited for me. even without plugging in an antenna I can easily pick up WWV. digital display, all bands, multiple modes. not as tactile as the HW-101, but a lot more practical.

The yaesu HT was purchased when I realized that modern radios usually had receive-only capability over more than just the amateur bands, and I wanted to see if I could listen to local railroad traffic. indeed I could, and the radio was amazingly just slightly over $100. probably the most useful radio in an emergency situation.

I fondly recall a yaesu FT-208R I received as a hand-me-down from a neighbor when I was in high school. I used it to talk on my club’s repeater, and even participate in some club net exercises. it stopped working in college, and I figured I might be able to fix it, but never did. I don’t think I got rid of it until I got the newer HT. the tone encoder was third-party, and had to be manually switched to change the tones. good times.

Only tonight after knuckling down to fill out a paper license renewal form did I take a closer look my license expiration date and realized that the date I had been looking at was a cancellation date, not an expiration date, which meant that my license had no grace period left, and had already been cancelled. So if I want a new license, I get to start from scratch. I’m getting 80% correct walking through the tech question pool doing it totally cold, so maybe not such a big deal… but I do have to track down a local VEC.