went on holiday, and…
Well, to be honest I think I’ve grown out of the blog. I was using it as kind of a aide memoir, but I’m now just writing everything down in my book and keeping it in my (falible) memory. Perhaps I should re-start doing it.
So as I was saying, I went on holiday, and since then never got back into the pattern of updating the site - so here we are 6 weeks later, a holiday down without snapping my legs, a group presentation, handing in my first paper - a speed PhD (!), new house, newly flooded house, building site of a house - later….
Here’s some musings anyway. See how far I’ve moved - I’m now back on a more medical theme - thinking about the audience for my proposed PhD work, who are more medical than CS people…
I now believe it feasible to use a low-overhead polling/alerting protocol, similar the management/agent system used by SNMP in packet switched networks to monitor and manage a multiprocessor machine (almost regardless of size #CPU/chips/cors. Our group to date have not really considered the management of our SpiNNaker machine, and the output directed to the users as the run of the neural network on the machine is underway. MMK has a Java system written that does health checking of the machine using a simple protocol that he has designed. He will be going through this with me w/e 13th March.
We looked at the MIB tree structure to store information and navigate it as a concept, and speculated we could use this for monitoring application data as well as system/network data. The SDRAM could be used to store results/intermediate data as there is just not the bandwidth to get everything in/out of the system on the max. 100Mb/s Ethernet links. (which also has to carry input data into the ANN).
My hypothesis is that this MIB/mgmt system could be used to get all traffic in and out of the machine for all purposes… loading code, taking stats, inputing stimulus.
I also outline to my supervisor a hierarchical approach to collection of data/diagnostics for management purposes - taking the 35,000ft (over)view, and then drilling deeper down into the machine to get more specific information, down from System level, to a Chip cluster (eg. 16*16 chip), super node (eg. 4×4 chip), chip level, then down to the processor and it’s registers/addressable memory… (down to the neuron!?)
We have a relevant metaphor: due to the limited exterior b/w getting information is like shining a flashlight around a very dark big black box - we can only see little bits at a time. I am looking to present information to the users in a number of hierarchical ‘views’ for example:
a) Diagnostics - health of the hardware
b) CPU Resources - How hard it’s being worked/stressed
c) Spiking activity - also tied into network activity/capacity (can we run probes within the ANN to examine performance?)
d) Locality - looking at the # local spikes vs remotely routed events etc.
It would be amazing to see a real-time glowing/modulating view of the machine in operation, similar to the way that fMRI can be used to peer into the human machine and look at activity centres - plus it would keep the medical people who are ‘customers’ - who have commissioned the simulations interested too - Can the patterns being viewed be related to the organic?… and they can change their viewpoint/zoom on demand to focus on anything they deem interesting…
Can we build an adaptation layer - to take information from our own light-weight protocol out of the system, and map this onto a higher level model, eg, TCP/IP <–> raw Ethernet frames, Physical Chip/Memory Locations <–> MIB tree mapping. ie. take the complexity out of the machine as far as possible - let it get on with the neural simulation, and leave it to external machines to do the interpretation?
That is all - whether I come back and type more - who knows! bye!