I noticed that message, but I thought you meant "ntpdate" instead of "ntpd" because you mentioned it in the context of boot-up. It sounds like just what we need.
I'll work out a plan with my co-workers for updating the board and contact you if I run into problems with ntpd. Thanks! And to others who offered help. Tom On Tue, Dec 22, 2009 at 9:56 PM, Jason Manley <[email protected]> wrote: > 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 >> > >
