Hi Ummm…. errrrr….. I think you slipped a decimal point...
On Mar 15, 2013, at 8:49 PM, folkert <[email protected]> wrote: > Hi, > > Now that my two servers have a garmin 18x lvc connected to them, their > time keeping is nice. > > E.g. this one: > > remote refid st t when poll reach delay offset jitter > o127.127.20.0 .GPS. 0 l 6 16 377 0.000 -0.006 0.003 > [ other clocks skipped for brievety ] > > They can be reached from the internet at: > - clock1.trustedtimestamping.com ipv4 & ipv6 > - clock2.trustedtimestamping.com ipv6 only <- I had to restart ntpd on > that system 10 minutes ago because I confused ntpd by opening the > serial via which the gps is connected accidently with an other > program, so it has to settle > > Both systems run Linux. Clock1 kernel 3.2 and clock2 runs 2.6.38. > > Without ntpd + gps it looses minutes per day (altough when I checked > minutes ago the drift was only 13.637 ppm?!). > > I used to also have an MSF receiver but a couple of years the radio > transmitter in England was replaced by a weaker one so I receive mostly > noise now. > > Now that it works, it is somewhat boring. > So I got my DCF77 clock from the attic and decided to use it different > then how I'm supposed to use it: as a PPS source! I figured (inspired by > http://remco.org/index.php/2008/06/09/dcf77-pps-experiments-with-a-dcf77-radio-module-using-ntpd/ > ). > As a quick test I hacked the testdcf.c to show the number of > milliseconds the clock was at when it had received a bit. If I remember > correctly DCF77 sends 60 bits per minute so each bit should be at a > second edge. I expected either a small constant difference or values > that would be over the whole -0.5s ... 0.5s band. > The result was neither! From visual inspection it looked as if only 3 or > 4 different offsets were registered. So I ran 3 tests where I took 120 > offset-samples, masked of the microseconds and checked how often each > offset occured: > > test run 1: > 1 251 > 17 255 > 38 259 > 37 263 > 22 267 > 5 271 > > test run 2: > 1 251 > 10 255 > 1 257 > 43 259 > 1 261 > 44 263 > 17 267 > 3 271 > > test run 3: > 2 255 > 18 259 > 60 263 > 32 267 > 8 271 > > Column 1: number of occurences, column 2: the offset. > > So my guestimate is that 259 and 263 are the values to look for and I > should ignore the others so that I don't confuse ntpd. > > What do you guys think? > > > (Regarding the 250+ ms offset: the distance of my house to Mainflingen > in Germany (where the DCF77 atomic clock is located) is +/- 374.766km (I Last time I checked the speed of light was right around 300,000 KM / second (299,792.xxx). More or less it should take DCF77 a bit over 1 milliseconds (not 1 second) to get to you. > live in Gouda, the Netherlands), so that is an offset of +/- 1.25012s.) > > > Folkert van Heusden > > -- > ---------------------------------------------------------------------- > Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. Bob _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
