sunset

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 build.sh 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
kern.module.path=/stand/sgimips/7.0/modules
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 the DECStation 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 eventually failed,) 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.

Dumping peripherals

I had a volunteer project with my employer at a local non-profit recycler a couple years ago. our project was disassembling keyboards into component parts (plastic, circuit boards, cables), and while most of the keyboards were cheap, generic membrane-style, one of the volunteers had an LK201 keyboard. She pulled off the Do keycap and everyone had a chuckle while she debated if she was going to keep the “Do key”.

So here we are a few years later, and I’m cleaning out my basement, including a box of keyboards, mice, and audio peripherals. I kept the pieces to re-create workstation setups with the various systems I owned. I started with my Linux PC, went to a DECStation, an Alpha, then a SPARCStation. Ultimately I came full-circle back an x86.

After getting my own computer together in college, I had built a VGA to sync-on-green adapter so I could drive a surplus 19″ monitor from my 5×86 linux box. The monitor was salvaged from a Tektronix X terminal, which already had bad gamma due to aging. These were the days of shadow masks, and as the monitor warmed up, it got progressively blurrier.

I switched to a DEC-branded Hitachi monitor on my DECStation 5000/240 and things were suddenly much brighter and clearer. Most of the applications I needed were available on the DECStation, and I could remotely run Netscape from my Linux box when I needed it. The LK401 and puck mouse were perfectly usable.

After moving, I had a new desk, and set up both an Alpha 3000/400, and a SPARCStation. I ran X-to-X to link the two screens together. I mostly used the DEC head, not being much of a fan of the Sun type 5c keyboard. (I did like the optical mice, though.)

The setup only lasted a few months before it was painfully obvious that the graphics capabilities of an x86 with Xfree86 (later Xorg) completely outstripped the capabilities of decade+ old workstation hardware, and the peripherals got put away, never to be used again.

I saved a DEC LoFi box (and interface card), and a “Digital Ears” DSP box for my NeXT cube, as well as an LK400-series keyboard with a PS/2 interface. But more on those another time…