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
