oscar.hellstrom.st :: weblog

Today I received my Kinesis Contoured keyboard. Enough has already been written about the keyboard by others, but it is a programmable ergonomic keyboard, which is quite different to type on compared to “normal” keyboards. After having it for a day I’m starting to get a bit more used to typing on it, though I still feel very clumsy. A bummer is also that my specialized keyboard layout does not really work very well on this keyboard, so I will have to rework that some day in the future. Though I should probably be a bit more used to the keyboard before I can figure out where I want to put the keys. I’m also trying to come up with any good use for the macros on the keyboard, which can store up to 48 macros.
All in all it feels a bit like the first week with the Dvorak layout, with frustration and all. Learning to use the Contoured keyboard will probably not take me very long though.

After long enough, yet another developer has entered into BSD Land. This one took the way by FreeBSD. Right now I’m mostly benchmarking Erlang applications on FreeBSD, which so far is a bit disappointing, since kpoll is disabled for FreeBSD. Apparently FreeBSD has issues with kqueue and pipes, at least according to the OTP folks. I will try to compile the ERTS with kpoll support anyway, and see what happens. An interesting observation so far is that Ejabberd is spending much more time in kernel-space rather than user-space or this FreeBSD connection. The time spent in kernel-space could probably (?) be shortened with the support for kpoll.

UPDATE:
By hacking the configure script and forcing it to compile with kernel polling support on FreeBSD I noticed really nice performance, until the VM hung for quite some time. It seems that the combination of Erlang, FreeBSD and kqueue indeed have issues.

At the moment I’m running a lot of benchmarks with Tsung. The funny thing with this is that I’ve had more problems getting the client machines to cope with the pressure than the server. I’m running two clients, which are hitting a server, trying to get as many active concurrent connections an possible. Not knowing too much about the inner workings of the Linux TCP/IP stack, I’ve so far run in to ENFILE and EADDRINUSE. The first was kinda expected and is solved by bumping up the allowed file descriptors for the Erlang process. The second however, var rather unexpected, since the clients do not bind to any port. It however turned out that the range of local ports available for non-privileged processes were way to narrow. This magic range is however easily changed with sysctl (net.ipv4.ip_local_port_range) or /proc/sys/net/ipv4/ip_local_port_range.

The server has so far suffered from too few file descriptors, but keeps up rather good :)