I had assumed that like FreeBSD and NetBSD, that desktop/graphics would not be supported. That assumption turned out to be incorrect. OpenBSD does support the Ultra 5's ATI graphics, and I was able to use this configuration file to run X windows.
As you can see, the default desktop environment is very bare-bones. It runs fvwm as the default windows manager, and Gnome and KDE aren't installed as part of the X11 distribution.
OpenBSD 3.4 SPARC64 Screenshot running default X11 configuration with fvwm
As you can see in the screenshot, top reports only 70 MB used in memory and no swap activity. It's easy to forget how small X11 by itself is when it's not running KDE or Gnome or some other fancy window manager. Compare this to when the system is running Solaris with Gnome, where the disk trashs from hitting swap when I so much as move the mouse.
Setting up the desktop environment wasn't trouble-free, however. After I installed from the serial console, I tried running startx from the serial console. I figured it'd die, but not only did it die, it actually crashed the system:
XFree86 Version 4data fault: pc=f0008fd0 addr=ffffffffffffe000
panic: kernel fault
kdb breakpoint at 129fec8
Stopped at. Debugger+0x4: nop
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
I switched from serial console to screen/keyboard and I didn't have that problem anymore.
OpenBSD comes with xf86cfg (an X-based X configuration utility) and xf86config (text-based X configuration utility). xf86cfg wouldn't run, and xf86config doesn't seem to have SPARC in mind, with its lack of a Sun keyboard or mouse option, among others. So I was left without a working XFree86 configuration file. However, Google provided an answer and I yoinked a config, and X started up fine.
There are pre-built packages of the various components of KDE/Gnome but I didn't install or configure any of them. I imagine that it would take some work to get it all working together. There are also various X11 apps available that are precompiled.
I was able to run 16-bit color (about 32,000 colors) at 1280x1024 with no problem. I also used SSH to tunnel a few remote X11 sessions, and ran apps such as Mozilla FireBird from my x86 Linux workstation.
As with NetBSD and FreeBSD, OpenBSD supports soft updates, which can greatly speed up disk operations. While FreeBSD lets you use tunefs, OpenBSD (like NetBSD) requires an edit to /etc/fstab and a reboot to enable soft updates. It isn't enabled by default, but I would highly recommend doing so. While not all disk operations may benefit significantly, simple operations like untarring a file can be dramatically sped up by soft updates.
/dev/wd0f /usr ffs rw,nodev,softdep 1 2
For instance, untarring the ports.tar file without soft updates took about 17 minutes. With soft updates enabled on that file system, it only took 3 minutes. That's a significant savings in time.
System performance-wise, OpenBSD (on x86 at least) didn't fare well in a widely publicized and much embattled benchmarking article. Unfortunately I was not able to get those benchmarks running on OpenBSD SPARC64, and generally those benchmarks don't seem to be 64-bit friendly (having compiled but died with a bus error for both FreeBSD and NetBSD on this same system). I spoke with the author, and unfortunately he doesn't have access to a 64-bit system to do trouble shooting.
I was all ready to rave about OpenBSD, when I hit a little snag with MySQL. While MySQL compiled from source without any complaints and initially ran fine (idle, at least), I ran into a strange problem when running sql-bench, the excellent SQL benchmarking tool I've been using thus far.
When sql-bench came to the create benchmark, it died with the following error:
Can't find file: './test/bench_60.frm' (errno: 9) at ./test-create line 137
The subsequent benchmarks after create died with similar errors. Initially I thought it may be some sort of permissions problem. The file it's referring to does exist, but when I checked the permissions, they were all correct. I even (in a very un-OpenBSD-esque manner) chmod'd MySQL's data directory to 777 just to make sure. Same problem, so permissions wasn't the problem.
I initially ran sql-bench against 4.0.17, so I upgraded to 4.0.18, which is the current release. Same issue. OpenBSD comes with GCC 2.95.3 by default, so I installed the pre-made GCC 3.2.3 package. Still the same issue.
I was only able to find a single case of someone having a similar issue with a Google search.
I tried playing around with some sysctl variables, thinking perhaps it was a limit on the number of open files (there's about 10,000 tables in the create benchmark), but kicking kern.maxfiles to 15,000 didn't help either. I made a post to the OpenBSD sparc port mailing list (they cover both SPARC and SPARC64) and the guy who had the issue wrote back, saying he still had the same problem.
Sean Brown responded to my post with some good suggestions, but they didn't work out either. As he suggested, I kicked kern.maxfiles up to 32,000 but still no resolution. I also made sure --tmpdir was on a large file system, and that didn't resolve the issue either.
Since the release of OpenBSD 3.5 is imminent (May 1st), I decided to try a snapshot of 3.5 to see if that would alleviate the issue. I pulled the 3.5 snapshot from the ftp site, and it was dated March 29th. Once it was loaded up, I ran MySQL and sql-bench and still had the same issue.
The sql-bench benchmarks has the ability to run against PostgreSQL as well, so I compiled PostgreSQL 7.4.2 from source (it compiled cleanly) and ran sql-bench against it. Unfortunately, most of the tests resulted in PostgreSQL dumping core:
Bus error (core dumped)
So there goes that. I tried using ports-compiled PostgreSQL but it also died with core dumps. Given the problems I had, and the problem at least one other had, it would seem OpenBSD SPARC64 isn't really an option for database systems at this time, even on a development/staging basis.