I’ve loaded Debian 8.2 Jessie onto my Beaglebone Black.
What’s the default NTP service that’s packaged with the firmware image?
I’m finding that the time is about 5 seconds in front of real time. My timezone is set to London GMT.
I’ve been reading the Debian website concerning NTP which advises to install the package aptitude install ntp. I’m concerned that if I install this package I will have a conflict of NTP services.
Thank you for your time.
Robert H, if by some chance you do not use systemd, that the package name “ntpdate” is the package you want.
I’ve amended the config file with the following UK servers, however the date time still seems to be running too fast even after rebooting.
Servers=0.uk.pool.ntp.org 1.uk.pool.ntp.org 2.uk.pool.ntp.org 3.uk.pool.ntp.org
Really appreciate you pointing out the default serive. There a nice little website with further details at https://wiki.archlinux.org/index.php/systemd-timesyncd
Thanks William. I will see how I get on with the default systemd service that comes with the BBB Debian 8.2 image. If I continue to struggle obtaining an accurate time when polling the UK servers with systemd then I will likely change to another NTP service.
I will keep this post update with my findings.
Robert Nelson, what did you do for updating time on the latest Wheezy images. Starting around 7.8 I guess. They seemed to work mostly seamlessly, without slowing down the boot process too much. rc.d ?
With wheezy it was just ntpdate... It's biggest issue, it doesn't know when
the network is up.. So if you look in the log, you'll see it try and give
up on bootup.. Usually have to call it manually... While systemd-timesyncd
handles that situation.
With wheezy it was just ntpdate… It’s biggest issue, it doesn’t know when the network is up… So if you look in the log, you’ll see it try and give up on bootup… Usually have to call it manually… While systemd-timesyncd handles that situation.
Well that was a problem for me when I was making my custom images. Not sure if you read my 2 year old blog post on setting up ntpdate at boot, but that’s exactly how I used to to it. Those image would also take very noticeably longer to boot too. Your images though, never seemed to have that issue.
Now days, I’d probably use a combination of fake-hwclock, and ntpdate that is fired off through rc.d or perhaps cron a few seconds after the board is known booted. Unless there is another option I’m not currently aware of, and just havent found it yet since I’ve not researched it at all . . .
It looks like the time is actually correct since I update the time servers. I was comparing it to the clock on my Windows 10 PC which appears to be 5 seconds too slow! This clock, if accurate, is matching the time on my BBB, http://www.timeanddate.com/worldclock/uk/london
Never trust windows time, you can do really funny things on a windows
network. At work, they use to purposely set our laptop clocks back
5mins.. Along with disabling our ability to change the time dns server
thru the normal admin panel.. a few reg hacks later we had it fixed..
Well windows only updates it’s time off the internet once every day, or perhaps even once a week.
Never trust windows time, you can do really funny things on a windows network. At work, they use to purposely set our laptop clocks back 5mins… Along with disabling our ability to change the time dns server thru the normal admin panel… a few reg hacks later we had it fixed…
Heh they had to been doing that through a third party app, or by using Windows instrumentation( netsh or whatever ). You can’t just change time on one network system and have it effect the whole network. Unless that one system just so happens to be the system all the networks systems update their time from.
I’ve written third party applications myself that would “prevent” time tampering. Unless the person attempting the tampering knows Windows from the command line fairly well. Then all bets are off. Except, that can still be remotely logged, and monitored.
On Tue, 12 Jan 2016 18:05:11 -0800 (PST), Robert Hurd
<email@example.com> declaimed the following:
It looks like the time is actually correct since I update the time servers.
I was comparing it to the clock on my Windows 10 PC which appears to be 5
seconds too slow! This clock, if accurate, is matching the time on my BBB,
If W10 is like earlier versions -- it only synchronizes via NTP once a