Hi Tom
We use the exact same procedure that you outline below to timestamp
our data and ran into the same problem. It turned out to be due to
integer rounding in Uboot's clock configuration. Please update your
uboot and kernel to the newest versions. I sent around an email on 01
December listing this as one of November's bugfixes. http://www.mail-archive.com/[email protected]/msg01058.html
Your Uboot header should look something like this. Note the speed of
the CPU is now correctly reported as 533.33MHz.
U-Boot 2008.10-svn2226 (Nov 13 2009 - 09:27:45)
CPU: AMCC PowerPC 440EPx Rev. A at 533.333 MHz (PLB=133, OPB=66,
EBC=66 MHz)
No Security/Kasumi support
Bootstrap Option C - Boot ROM Location EBC (16 bits)
32 kB I-Cache 32 kB D-Cache
This wiki page outlines the update procedure:
http://casper.berkeley.edu/wiki/ROACH_kernel_uboot_update
After updating, you should find the clock at least as accurate as most
onboard motherboard clocks, and is more than good enough to allow NTPd
to lock.
Jason
On 23 Dec 2009, at 03:40, Tom Downes wrote:
Hello:
I am new to the list and to ROACH boards so apologies in advance if
this question is misdirected. I am working at Caltech on using a
ROACH(1) board running BORPH via USB. Specifically debian/etch with
kernel 2.6.25-svn1867-dirty1.
Our application requires timestamping FFT data to precision of 10ms
- there is another set of 100Hz data from a separate source with
which we need to align. I imagine that this kind of thing is a
fairly common problem.
My intention is to use linux/BORPH+ntp to get the time-of-day
correct to within 500ms. Then use a 1 pulse-per-second signal
(rising edge guaranteed to be at borders between seconds of time-of-
day) to align the NTP time to the true time as reported by NIST or
GPS. This is, in broad strokes, how an NTP stratum 0 server works.
Getting BORPH right to 500ms is proving to be much harder than
anticipated. The stock installation runs ntpdate at boot and that
manages to get the clock right, but the drift from there is HUGE.
On the order of a second per minute. A standard motherboard clock
(without NTP) will drift by, at most, a few seconds per day.
So I installed the NTP daemon via apt-get. ntpd can't seem to sync
to servers here on campus (ntpq -p does not list a star next to ntp-
XX.caltech.edu where XX=01,02). I have just tried deleting the
ntp.drift file to try to force ntpd to re-calibrate for clock drift,
but I think the drift is so huge, and probably fairly random, that
it will give up.
Is there a solution for keeping the ROACH/BORPH time-of-day accurate
over time scales longer than a few seconds? ntpdate is fine for
making sure the logs don't read 1969, but not much else. I can come
up with alternative schemes for my problem, but this seems preferable.
Tom
