Many months since the last blog, been busy as usual. Did Christmas and stuff, nice as always to spend time with the family. Got engaged too, so adding wedding stuffs to the life-to-do list! Grabbed a bit of time to play around with the Korg Triton and tweaked the software that turns SoundTracker files into Tutka XML files; I like SoundTracker's interface, and almost detest Tutka's. Tutka (at least the version I have installed) suffers from inaccurate MIDI-sync sometimes. Works fine from a fresh start, which is just as well, since I'm only using it to output MIDI! Churned out some pretty prototype music (fred23-1.mp3), which isn't entirely well balanced, but sounds okay for a first go.
Still trying to get my head around how many threads will actually execute in parallel on NVIDIA's Tesla C1060; the documentation seems to be somewhat vague about how the internals work (or maybe it's just me not understanding!). After reading around a bit, I think it's 240, i.e. each core can execute just one thread instruction at a time. The way things are scheduled makes it complex, since 32 threads are grouped into a "warp", and 8 cores comprise one streaming multi-processor (MP), thus one MP can execute one instruction in all the threads of a warp in 4 clock cycles (32/8). However, each group of 3 MPs (or 24 cores) is managed by one thread scheduler. Thread schedulers schedule threads in blocks, and NVIDIA recommend 192 threads per block (or 6 warps) for the Tesla C1060, to hide internal latency of moving data in and out of core-local memory/registers (16k x 32-bit). In my mind, that means each block of 196 threads can all get one instruction executed in 8 cycles across 24 cores. With a 1296 MHz core (shader) clock, each core manages (obviously) 1,296 MIPS. 240 cores thus gives 311,040 MIPS. For a while I was wondering how NVIDIA got it's 933 GFLOPs figure for single-precision in their marketing stuff; answer is (not unsurprisingly) more than one FP-op per instruction. In theory, 3 single-precision operations per instruction, with a fused multiply-add as two of them, and some stuff for the special function block that lives on each MP (doing sin/cos/etc. and double-precision). Thus giving the 933 GFLOPs "theoretical" peak performance. Of course, this is unattainable for any practical computing application; for mortal programmers like me, we should probably be happy with around 200-300 GLOPs. At least now I'm happy in my head about how this stuff works :-); unfortunately the slightly cheap GeForce 6600 GT I've got in the home PC doesn't do CUDA. The GeForce 9800 GTX I've got shelved in the office does do CUDA (128 cores), so will probably drop that in the lab PC for a go!
Weather cooling down a bit, which is nice. Had another successful BBQ (second one so far!) on our "bricks and mortar plus two paving slabs" BBQ, which
came as part of the house pretty much. Couple of busy weekends with assorted parties and BBQs, this one was the first empty one in a while. Whilst
travelling around the country got stuck in several M25 traffic jams, including one where they stopped the traffic just ahead of me and closed the motorway
to spread some more sand around..
Put some more kit in the office rack, including fresh batteries in the existing UPS (as it was insisting on a battery change) and a new UPS to supply
the various new kit. New kit includes some Dell PowerEdge 1650 servers (one with dual processor and hardware RAID) and a
Sun Cobalt RAQ.
Spent some considerable time trying to get the fan speed down on the Dells as they make quite a racket, and gave up in the end. Seems that no-one has
managed to do this successfully yet. Foolishly tried disconnecting one of the (six) fans inside the box, but that just made it whinge about a broken
fan and sped the other ones up.. After managing to install the Dell server utilities (OpenManage) on Debian (thankfully someone
made some packages/documentation!) it just said that the fan-speed
feature wasn't supported anyhow. The noise isn't too horrid, but I'll do without for now! The RAQ is even more noisy..
One of the cooler pieces of kit added was a BayTech DS4-RPC which can
turn on/off four power sockets over ethernet (and has a bunch of RS232 links to connect to this stuff).
After re-arranging the office a bit, re-assembled the train set. Layout this time is a bit more straightforward — no closed loops to give
power issues, three switching points, 16 lights and a bunch of track sensors. Still using the same controller board over RS422, and still need to
write some pretty occam-pi software to drive it. Did at least get around to soldering up the RF transmitter device
and adding it to the tower (hopefully there's enough grounding in these boards to not screw up the RF signal too much!).
In the process of creating another RS422 device to control the level crossing (which was a present from Carl).
More specifically, a device to control a number of H-Bridges. One bridge will drive the
gates, and one the flashy red lights. Things here on hold whilst I wait for RS to deliver me some fast recovery rectifier
diodes (today hopefully). Also waiting for various other deliveries from Amazon and
Dabs. One of the RAID'd disks in my desktop PC is whinging, but not quite dead yet. Currently a 160 GB disk,
upgrading to 500 GB (for only a few pounds/pence extra!). Also had some other hardware failure — a fairly old PC mysteriously freezing up from
time to time. Not a huge problem except it was the internet gateway, DNS, Asterisk, UPS monitor, etc. Suspected motherboard failure so spent a good
few hours thisevening transplanting its disks into a new (old) PC. On the plus side, a slightly faster CPU. The machine also acts as my music/MIDI
interface, so getting it back up was moderately high priority (work has internet if all else fails..).
In the land of music, have been spending some time writing a bit of software to turn XM files (as I have generated by Soundtracker) into XML files for Tutka which can play them over MIDI into my Triton Rack. Experiments earlier today showed promise :-). Old songs sounding much richer (and potentially different). The slightly incomplete software takes selections of instruments from XM files and maps them to one or more MIDI channels (because of the way panning works in MIDI, can't do too much in one sitting). The plan is to play different instrument sets into the multitrack and lay them on top of each other. Unfortunately getting the MIDI sync right (generated by the multitrack) will require an extra MIDI input into the [newly fixed] PC, as I'd also like to be able to dump the "multi" settings from the Triton to avoid having to reprogram these all the time.. (it's interface is a little limited). Nothing committed to the multitrack yet, but musical emissions from the Triton were sounding promising.
Kittens and the cat also exercise their musical abilities by trampling over the keyboard(s) to reach their favourite perches..
Slowly settling into the summer, had a few hot days (by my standards, which would be 25 degrees or more!), now just warm and muggy with light drizzle. Worth noting that I moved house a couple of months ago, now own our own property :-). Downside is that we have to deal with all the house-owning stuff, like mortgage, insurance, gardening, tree-trimming, etc. Just about settled in though! Cat rejoined us from his sabbatical on the Isle-of-Wight, and has recently been joined by two little kittens (Rhubarb and Custard), who don't have their own webpages yet! Bob managed to get his new kitten on Facebook already; ours are still learning how to operate a keyboard properly, at the moment they just bounce over it and trash vim sessions. Yay for undo and subversion!
Spent a lot of time writing LEGO® Mindstorms NXT materials, and successfully delivered a couple of workshops using these (University's "Science Extravaganza" and a "Robot Challenge Day"). The latter worked like a mini FIRST LEGO League (UK, FIRST Hand Technology) and was overall very successful! (and many thanks to all the postgrads/staff who helped out to make it so :-)). Just one more event to go, for a residential summer-school, then some proper summer time. Along with this, usual admin things, plus some research (but not much). Recently been looking at generating LLVM code from NOCC, instead of going via Transputer code first (which given it's a 3-deep integer and FP stack machine makes things a little ugly in code-generation, plus the LLVM people and many others have already solved these problems several times over!). Also did some more poking around with the "Graphics3D" library in KRoC, attempting to add some more useful graphics primitives. Ongoing..
Had a mild disagreement with Matlab after Lucy bought a copy and installed it — activation failed to connect to the network. After going as far as strace'ing the binary, found it was trying to connect to an IPv4 address through an IPv6 socket. As we're not IPv6 enabled here, that obviously failed. After various failed attempts to setup IPv6 and IPv6-in-IPv4 routing (although learnt plenty about how IPv6 works!), even tried Miredo, which provides a simple way of providing IPv4 hosts behind NAT/firewall/etc. with routable IPv6 addresses via something in France (I think), eventually found "/sbin/sysctl net.ipv6.bindv6only=0" on a Matlab help forum (although completely unrelated to activation). Problem solved! Instead of falling back to IPv4 if IPv6 connectivity fails, it just gives up. Not the most helpful behaviour I've seen in software..! At least activation can be done off-line if required, which might have been simpler in some respects, but not to be beaten by a bit of code..
Just to follow up on the last post, an old student of mine pointed me at this Slashdot story (the unstoppable "tech support" scam). Sounds like it was that sort of thing. Luckily though, most of our phone calls are for wood-worm and dry-rot treatments, as BT handily gave us the number of someone who is listed in the yellow-pages etc. as doing this kind of work. Presumably they aren't trading anymore, or at least have changed their number, but it would be nice if BT gave numbers some cooling off period! We even get the occasional call requesting plastering services..
Five and a bit months on from the last blog entry (busy year!)..
Interesting phone call this morning (caller ID reports "unavailable"), approximately along the lines of:
Person: <Indian accent and busy call-centre background> hello, is that Mr. Bar-nes?
Me: yes, this is Mr. Barnes
Person: this is (unintelligable) from (unintelligable), our company has received several packets from your computer operating system which mean you may have spyware/malware on your computer.
Me: home or work computer?
Person: your home computer.
Me: I don't believe you.
Person: why not?
Me: I'm a computer scientist.
Person: well, when you're browsing websites your computer can get infected with malware and spyware.
Me: um, well, no, not really. Is this a Windows issue?
Person: yes, your browser in Windows has probably picked up some spyware which is sending out packets.
Me: well, we don't have any Windows PCs here.
Person: oh, really?
Me: yes.
Person: what operating system do you use?
Me: linux.
Phone hangs up quickly.
So who knows what this company was trying to do (or perhaps sell).. Besides, if my computers were sending out duff packets into the internet, I would expect my ISP to be contacting me, rather than some strange Indian call-centre. Another case of bluff-cold-calling.. Muppets.
Hello 2010! Successful Christmas and new-year had, with the family and suchlike. Got a new wooly hat, USB mug-warmer (within the initial 100mA power limit..?) and USB hoover, amongst other things. Spent a reasonable amount of time over the last week writing a Sound Blaster 16 driver for RMoX. Now have something that at least outputs audio samples correctly! Doesn't quite interface with the RMoX audio sub-system properly yet, but provides an alternative raw interface for just dumping bytes. Doing this also required a new 'lowmem' driver (for reserving DMA space in the low-memory area, which was also abused by the x86 multiprocessor driver), and various fixes to the DMA driver. Topped it off by having the LCARS graphical interface make appropriate beepy noises :-). More for proof of concept, rather than full implementation. The SB16 driver just uses single-shot mode at the moment — should really be auto-initialising, but modern CPUs should be able to reprogram the hardware and DMA controller fast enough. Not tried on real hardware yet, but have an ISA breakout for PC/104 and some old SB cards lurking around to give it a go at some point. Also got hold of some more Kontron and Eurotech embedded PC/104 mainboards to play with. Just this evening started work on an ICH AC'97 audio driver, looking promising, but doesn't do much — more work required on the general AC'97 interfacing mechanisms, some of which were already in place to access the UCB1400's touchscreen interface, sat behind a CS5535 AC'97 interface on some of the embedded boards we have. Need to context-switch into exam questions, coursework and other administrative fodder at some point.
Had a successful time at the
SOSP 2009 and
CPA 2009 conferences, back
into term-time and teaching at Kent.
This year's
Kent regional final of the
FIRST LEGO League
(Wikipedia page,
main site) went smoothly :-). The children seemed to have fun at
any rate, and produced assorted creative solutions to the robotics
challenges.
Did some more work on the LEGO train. Mostly finished putting together the
main train control circuitry — basically a 64-port digital I/O board
on which sits another board that breaks out to the various train-related
hardware. This currently consists of 3 "points" devices (for switching
tracks); 16 street-lights (though only 8 exist at the moment); and
16 magnetic reed-sensors attached to various bits of the track. There's
currently a bit of C code running on the PC that talks to this over the
RS422 bus (along with various other things).
Talking to the train is handled with a dedicated serial port at the moment
(soon to be condensed into an RS422-bus device, as it only does simple
things). Some RF650 modules from RF-solutions are used to transmit serial packets over 433 MHz to the train.
On the train is the insides of a LEGO infra-red serial tower, together with
some circuitry (and an Atmel AVR) that picks up radio messages for the train
and relays them to the RCX that is actually powering the train. The train's
RCX runs a very simple program that receives these messages then does
something (forwards, backwards, stop). If no new messages are received in
a fixed amount of time, the train stops dead (safety feature!). The RCX
is nearly redundant currently (similar control could be extracted from the
onboard Atmel AVR fairly easily), but it allows for extra things in the
future (other sensors and motors -- jobs for the train..?). The whole
train thing still gets its power from the rails, which saves on batteries.
Next step is to put together an RS422 device to relay train control
messages over radio directly (rather than using up another serial port),
followed by a software system (written in occam-pi) to drive the whole
thing (and a simulation of it on-screen).
Also found some time fairly recently to hack around with RMoX some more. I've got a final-year project group working on providing a harness for Linux device-drivers, file-systems and suchlike (easy code integration), and have nearly finished an IDE disk driver (works on QEMU, fails with VirtualBox).
Mostly busy with real work, including things leading up to
SOSP 2009 and
CPA 2009. Not had a lot
of time for
hacking just lately, but at least the exam marking is out of the way now
:-).
Finally getting around to spending some time on the
interactive train-set, which will be something for
open-days and school workshops,
essentially building bits of software to control it. Got some initial hardware
for the "street lights" and "points switching" sorted out, but still working on
how to control the train itself. Also poking around with a way of detecting
the position of the train on the track — leading solution is a magnet and
reed-switches.
Also includes an SR-latch, as the reed switch is likely to pulse faster
than the input polling. All of these things are wired into a multi I/O
board that the PC (and thus control software) can talk to. Once the
various component parts
work, this will be transferred to some proper prototyping board :-).
Controlling the train remains an
unsolved problem, particularly with the RCX brick. My current thinking is to
build a small ~433 MHz transceiver setup, using the RF650 from RF-solutions. This will simply
retransmit data into the 'modified' internals of a serial IR tower, and then
onto the RCX. The track has plenty of juice going through it, so no problems
there :-).
Have also managed to spend a
bit of time writing some code for RMoX. Now
have a mostly functional paint program :-). Not a sophisticated
application by any measure, but a good test of basic interactive graphics
handling. For some reason, the GD5446FB hardware cursor isn't working in
16-bit modes, so the current settings are for 24-bit modes. If I've got some
spare energy/time later, might look at spicing up the interface slightly by
animating some things.