I messed around with something similar and actually got more interested in time keeping in the end. In short the best thing to do would be to get a GPS which provides a PPS signal (pulse per second) or better and discipline the linux clock off of it, as has been mentioned already.
The linux system clock is not reliable for anything. It has to be counting _something_ and on many machines there are no reliable clock sources. The rate is simply not constant and this is why NTP is needed to keep the time from drifting off. In some cases you will see the clock running at half or double rate on some combinations of hardware/software. The resolution of the system clock is limited by the resolution of the clock source. Depending on the platform and the hardware linux finds, it will choose a clock source which can be overridden with the clock=<source> command line option. The common types you find on x86 PCs these days are pit, acpi, hpet and tsc. HPET is supposed to be specifically for timing, as is the power management/ACPI timer but these both have low precision. The best thing you can usually get is the TSC (RDTSC instruction) but this was not intended to be used for timing for multi processor and dynamically clocked systems.. the rate the TSC runs at varies constantly. Some of the recent intel processors have a feature called constant TSC or invariant TSC. If this feature is present, then the TSC is a good choice for the linux system clock, otherwise HPET.. the other options provide very poor resolution.
Still, the processor is cycling thermally, the power is not constant and clean, and so TSC is still not constant enough.. through the magic of cesium clocks on GPS sats and some fancy logic built into these GPS receivers, you can get a significantly more constant time source and hook it to a GPIO pin. Linux even has support built in for this..
I don't know if the Raspberry Pi will have any type of 'constant' timer that is high precision.. so it may not be possible to do use it. You can check the precision of the clock by running ntpd and querying like this: ntpdc -c kerninfo
I ended up using an Intel Atom based mini board for my project, since it had serial ports and a constant TSC to provide the higher level of precision I wanted. I used this GPS which is known to provide a PPS signal accurate to within 1 microsecond of UTC. It is also very sensitive and works in a window without a full sky view.
Garmin GPS 18x LVC - http://www.newegg.com/Product/.....6858998157
Here are some pictures of my crappy rigging job when I was testing:
And here's the rig that I ended up using for it:
You can check the current clock source linux is using in /sys/devices/system/clocksource/clocksource0/current_clocksource
I have no idea what clock sources the RPi has but I wouldn't expect them to be constant enough for what you want to do.
The GPS is _almost_ as good as your own cesium clock, which, depending on your budget, may be even better:
HP/Agilent 5071A - http://www.testequipmentconnec.....ucts/30797
Even with the GPS or cesium standard disciplining the system clock you will see some variation from temperature changes throughout the day. What you _really_ need to go with your atomic clock is what is called a 'temperature compensated crystal oscillator' =)