I haven't tried it on the ROACH, but we've had great results (i.e. much better than 1 ms) with the IEEE Precision Time Protocol (using ptpd, from ptpd.sourceforge.net). You might want to give that a try before you resort to fancier solutions.
--Andy On Tue, Dec 22, 2009 at 8:40 PM, Tom Downes <tpdow...@caltech.edu> 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
