A Slightly More Usable IRC Client

I’ve made a number of changes to snowflake in the last few days. Been trying to figure out why my network stack is fail, and I think it might be to do with sloppy interrupt handling or a poorly written rtl8139 driver. And then there is the upgrade to an svn snapshot of ocaml-3.12.0+dev, followed by a bunch of fixes to that change. And some cosmetic work like an updated IRC client.

I have a lame workaround for the network issues, which makes IRC work a bit better at the very least: a thread that constantly sends out ARP packets. Cheesy, but it suffices for the short-term. And means I can spend some time enjoying working on the IRC client.

Like all things I do, it is riddled with bugs! But it makes it slightly more tolerable to use. I also tried to see if my network hack would let DAAP work, but I’m afraid it’s too buggy and damaged for me to get that far.

Tracking Down Bottlenecks

My friend Taras does some really intriguing work on Firefox, and of late has been working hard to reduce cold startup time, which involves a lot of tracing. And anyone who reads this blog every now and then will realise I have serious issues with my network stack, which got me thinking.

One of Taras’ posts, “When in Trouble, Draw a Picture” could equally apply to my current problem. It’s pretty easy to use the rdtsc instruction to get relative timing information, and a pretty graph should be fairly easy to produce from timestamped debug messages.

As an indication of how disastrous my network stack is, I added a little bit of code in my IRC module to reply to CTCP pings. The result? Between 30-60s for a CTCP ping reply. Ridiculous!

Unfortunately, I can’t work on it right now as I managed to inadvertently forkbomb my unbuntu install and need to physically restart the machine. Easier said than done, as it requires a trip in to work to do. The fork() system call can be dangerous in the hands of the uninitiated, but lesson learned.