Older blog entries for ingvar (starting at number 227)

Things have been a bit... tense the last week and a bit. There are reasons for this, but I shan't expand on that here.

I have done almost no coding as a result of this (well, a partial unpacker for PCAP files, but that doesn't count). This might change, but as of now, I wouldn't expect any immediate changes, it's stressing and fretting rather than relaxed coding for me. I might (possibly) squeeze out an NTAR reader, because it's close enough to the PCAP reader (and should have a lot of code in common, once you're down at "ethernet frame" level, you should be able to go from there).

Oh, thought... It might be handy to have a writer, too.

Look forward to a new release of Gamelib soon.

Primary reason? It's hard to actually judge what needs and needs not be exposed from a library unless one actually tries USING the library. Yes, I'm writing a new game, this time it's 3D and navigating through a labyrinth (16x16x16 rooms, guaranteed minimum one solution, requires joystick).

At some point, I probably should look at Windows portability and/or OpenGL, shouldn't I? Ah, well, not today.

Gamelib 0.4 released. The only change is the addition of (linux-only) is joystick support (and a small stick-using demo application).

Pardon, I posted a URL with a spelling error yesterday, instead of http://src.hexapodia.net/openid.tar.gz, I managed to write http://src.exapodia.net/ openid.tar.gz.

Anyway, trouble sleeping and some playing around with my linux box made me write some limited joystick support for Gamelib (currently not packaged up, so CVS-only). I can only say witrh certainty that the support is limited to Linux and may well work well only under SBCL (due to "I want it in CL only" stubbornnes and a slight unavailability of a portable select(2) interface, at least that I could find in the early hours). Actually, it will only work really well under SBCL, because the user-friendliest version of the interface relies on spawning one native thread per joystick to deal with the event-handling.

Nonetheless, surpisingly small amount of code was then needed to make a simple "display X, Y, throttle and twist axes and the button state".

I aim at having it packaged up for a new release of Gamelib, erm, later (Friday? New year's Eve? something like that).

OK, the OpenID consumer library is finished and seems to work.

This library uses Drakma (for the Consumer/provider association) and Ironclad (for verifying the signed fields).

As said before, this would probably have been written faster if I had any actual use for the code, rather than pure intellectual curiosity. Nonetheless, I hope someone will find it useful.

Festive yule, you who actually partake of this particular holiday.

As usual, not much progress with Noctool (the service/ network-element monitoring tool that has been mumbled about). I do have an almost-finished library for an OpenID "Consumer" and I hope it should be done by the end of the day or possibly tomorrow.

As to "why", I guess it's because I saw a potential need (not an actual need, if so, it would've been done, already) and a slight urge to do something at least peripherally web- related.

Finished off base code for "turn monitor persistent" (it only handles base equipment with (so far) disk monitoring, but the framework is in place and it sort-of makes sense, so I have something to work from). [though see below]

This was speeded up by the need to actually reload the package. It's not a happy place when parts of your lisp implementation changes on disk, but not in the memory image (note to all who run Debian-provided lisps, if you run an upgrade, you MAY have to restart the lisp image).

Even more fun, you MAY have had SLIME upgraded behind your back. Luckily, this can be worked around by simply loading the SLIEM code again (it seems).

Of course, with all this "image restarting" and "emacs restarting, I noticed one weakness... I save one set of disk graph data per device (node, server, what have you). I actually need to save one set of data per disk, per device. And I do, in a way, I just saved them using the same name.

If this seems a bit disjointed, it is. I started typing it 24h ago and forgot to post it...

About one week of NOT working actively on noctool (it seemed time, what wit hthe run-up to christmas and assorted old non-programming projects making themselves noticed).

Some looking and tuning this morning, nothing exciting I'm afraid. Slight tuning of the load monitor alert mechanism. Now, keeps silent until a low-water mark has been reached, then ramps from "yellow" to "red". Previously, it multiplied the load by a fixed (per-monitor) value to give a direct reading. Previous method, more elegant, but harder to tune. New method, ugly as an ugly thing, but conceptually simple.

Also re-tooled (some of) the monitor-saving code (for persistent state; shame such a thing should be needed, eh). Next up, memory and swap monitors. Shortly after that, a demo main loop.

Graph-drawing is progressing. I now have a grid with units (and SI multipliers) on the Y axis and time on the X axis. Now comes the fun of stable storage. Not TOO much of a hassle, as long as it doesn't need to be efficient.

The graphing I do is more to provide a trend for human on- lookers than for the monitoring itself. I have just found it extremely useful, having a quantity that is alarming plotted against time, when keeping systems running. "Machine foo is creeping slowly upwards on /, better have a look at that" or "No, the fact that machine bar is now alarming for less than 10% free space isn't an acute problem, it's been within an inch of that for a week, I should look at machine gazonk first."

At the moment, I aim at having score-based warning thresholds, informed by cut-off values (at the moment, I set yellow (warning) to 30 and red (alarm) to 70; I also use a dampening mechanism to slow the time it takes for an alarm to drop; this will have to be balanced by a manual "reset alert-level" for quick checks). Saying that, I have received some interesting ideas via mail (essentially building a model of expected behaviour and alert if anything falls outside that; I expect that the deviation can tie in nicely to advise the alert-level).

Next comes a bit more monitors (ping and disk are done; will need load and memory for hosts and go looking for SNMP libraries again for router/switch interfaces). Then comes the "tie multiple monitoring hosts" protocol implementation and "monitoring UI" code.

OK, I now have (some) live data in one set of monitor- objects (disk usage for a machine I help admin). I have a proto-graph (there are lines and some explanatory text). I don't have QUITE as good graphs as I want, though (I want a frame around the "graph area", I want quantity marked off with eth right units on the Y axis and I want time, of some sort, marked off on the X axis).

Graphing time-dependent data is slightly trickier than I thought. Not only do you need to collect the data in some fashion (with possible aggregation to older "generations", to keep strorage costs down), you need to know how frequently you collect data and you need to know when you last collected data. Dealing with wildly varying value ranges is also interesting. The lowest measurement I expect seeing is in the range 0.1-0.5 ms, the highest I expect is on the order of 100 GB. I want one (and only one) "graph grid drawing" function. I deal with graphing data spanning "a day" to "a year". Again, I only want a single "graph grid drawing" function.

That seems to be mostly in place, though still woefully undertested. What has been tested is "drawing text" (now no longed fixed width, because it was terribly ugly; going to variable-width makes it "only" ugly).