Hi. >From the title, you might (maybe) guess this is about the Raspberry Pi, and NTP.
I've only had the thing a few days, but been experimenting (playing) with the default NTP behaviour as seen with ntpq -p on the command line. The Fedora remix distro' is a bit of a disaster, unless I've screwed up creating the SD card, as it drifts all over the shop, to many 1000's of (whatever units) the delay and jitter are listed in. If left to it's own devices for a few hours, several 10's of 1000's of units jitter at times were listed. There again, that OS would pause and stutter anyway about every 10 to 15 seconds, while it's local console output (video monitor) reported timer timout errors at irregular intervals. Googling the issue, I see other's also see much the same symptoms. (The timer errors.) Trying another option of Debian, it's much better. This is prety typical, and similar to what a more powerful machine would see under the same circumstances, from past experience. pi@raspberrypi:~$ ntpq -p remote refid st t when poll reach delay offset jitter ======================================================================== *ntp.websters-co 193.67.79.202 2 u 11 128 377 37.918 -7.068 20.879 +ns1.luns.net.uk 33.117.170.50 2 u 65 128 377 34.099 -5.716 197.916 +ns0.luns.net.uk 157.44.176.4 2 u 64 128 377 33.914 -6.204 181.881 -time.xilo.net 130.88.212.143 3 u 101 128 377 25.476 -29.662 4.126 (A little bit of reformatting to fit here has been done) All I've done so far, is edit ntp.conf so that it uses 4 servers from uk.pool.ntp.org And the above is as it's seen looking out from my desk at work, via our very thin bit of internet damp string. That was all done over a SSH remote session. Our ADSL here is slow and creaky, and does suffer from buffer bloat. As determined by running netalyzr. http://netalyzr.icsi.berkeley.edu/ (Quite how accurate that is, running on US servers, from the UK, I dont know, but...) From anecdotal experience, whenever anyone is "doing anything" significant with the 'net, then we all suffer. Now... The RasPi: It has (it is said) a UART on board, and some uncommitted I/O, so what thoughts from the assembled estemed collective, re the possibility of "doing it by GPS" with PPS etc. This is found within dmesg's output, after boot... Serial: AMBA PL011 UART driver dev:f1: ttyAMA0 at MMIO 0x20201000 (irq = 83) is a PL011 rev3 console [ttyAMA0] enabled And there's always the option of a USB<>RS232 device, for the NMEA data at least. I'm not asking about how to sort the hardware out, I can handle that I think. Just the opinion from anyone who knows more about Linux(Debian or??) on the ARM cpu, and it's ability in this respect. It's said, that the RasPi, has about the same cpu "grunt" as a 300MHz Pentium, but I have no way to qualify that statement. I do realise some software cookery is needed, in particular to get use of the UART and one of the uncommitted I/O pins for the PPS to raise an interrupt of course. At present, this is all at the "it'd be good if it could be done" state. As if I don't have too many other projects on the go at this time. Comments, brickbats, bouquet's etc. Regards. Dave B (G0WBX) _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
