As odd is even

Many times since I started programming I have had to write some sort of functionality to test if a number is odd.

It is odd that I woke up thinking about this and all the different ways I have implemented this test as my programming skill and understanding improved, so here's a whistle stop tour. I think its interesting to see the way thought processes change...

Ok, so when I was 15, my good friend Tim was pondering the same question, my answer was to use a float and an int.

Say that we want to test if '5' is even.

int a = 5;
float b = 5;
a = a / 2;
b = b / 2;
if(b!=a) // If they are not equivalent then the number is ODD!

As you can see, this is rather in efficient but at the time, it worked.

A little while later we learned about the % operator, so we can do something like this:

int a = 5;
int b = 5 % 2;
if(b>0) // If b is > 0 then the number is ODD!

Then I went to cern, worked for a while on some pretty high performance C and ended up writing this without thinking about it:

#define isEven(x) x&0x1

Learning is fun :-P

Bloody Hell, It works!

I worked late again last night, only till about 9pm but this time I was triumphant!

My distributed configuration application passed its first major test, grabbing the Front End Electronics configuration information from my central database, parsing it and rebuilding it and then pushing that data to two front end cards.

key: DCS:Detector Configuration System RCU:ReadOut Control Unit
Pre push latency:
2 seconds AFL start (Design constraint, I cant change this.)
0.5 seconds Database query. (This can be increased by a factor of 4 or 5 using prepared statements and 'views')
0.1 seconds Data parsing and rebuilding. (Taking data from the DCS Schema and putting into a useful state)
Push benchmarks
4.8 seconds to Push the 2096 (131 * 8 * 2) registers to the altros. (Via the RCU instruction memory)
8.9 seconds to Push the 2096 and perform 1 to 1 read write checks.

I think these figures can be greatly improved but based on these rough numbers I can estimate the time it will take to perform a whole Time Project Chamber configuration:
Presuming an average partition size of 18 Front End Cards per RCU that makes an altro push time of
4.8 * 9 = 43 seconds.
Due to the limitations of the Front End Cards and the power supply available at the pit the cards have to be stagger started sequentially, waiting 0.6 seconds per card:
0.6 * 18 = 10.8 seconds.
Total: 53.8seconds + unknown DB latency for multiple requests (est 3seconds);

In short, I think that we can confidently commit to having a full TPC configuration in less than 1 minute. The improvements to the RCU firmware should allow building of large instruction memory blocks for multiple register writes, this could improve the performance by a further 20-30% by my estimates.

In short, Woohoo!

Late night randomness

Yet again I find myself unable to sleep and sat in front of my computer at god-knows-what past midnight.

So, its late at night and I'm sat in front of my computer, logged into a screen session at work via ssh and editing code. *Why?*

I think I have a bit of an obsession, at least with this current project, The deadline for integration testing is mid-April yet here I am, editing code, making sleepy mistakes and updating my blog!

In Gentoo related news, I actually got some work done today, I lurked on bugzie for a while, answered a few user queries and requested that a couple of packages get stabilised.

Slowly but surely I'm becoming more active in Gentoo as a whole rather than just the security stuff.

Well, time to try and sleep again I guess.

Salut!

FEC2RORC Library

For those of you that are interested in what I have been doing at CERN, the documentation for my fec2rorc library is available on my webspace.

The reason for me uploading it to my website is that I get annoyed looking around the work servers for my documentation, particularly when I'm not at work! (Why I'm working from home, on a Saturday evening I have *no* idea).

Anyway....
http://www.brokenpipe.co.uk/fec2rorc.html