steemd should not be an ntp client

[sneak]

steemd should not be an ntp client. several reasons:

1. the way it uses pool.ntp.org is against their ToS.
2. a single NTP server's replies can be spoofed easily. this is the job of ntpd.
3. there is already a proper implementation of an ntp client, ntpd, which competent admins run on the requisite systems, frequently with lower latency to proper clocks than pool.ntp.org.

This should be removed from steemd and the system clock relied upon, and the docs updated to require ntpd on all nodes. (This is already best practice.)

From http://www.pool.ntp.org/vendors.html :

You must absolutely not use the default pool.ntp.org zone names as the default configuration in your application or appliance.

[abitmore]

I guess it's there due to lack of ntp client on Windows.

BTW #462 is related.

[bytemaster]

In order to remove NTP from steemd we need to have detailed (and simple) instructions for configuring ntpd. In my experience ntpd is does not work sufficiently on OS X or Linux due to drift.

In particular an Idle OS X machine will see its clock drift by several seconds between NTP syncs. This is not tolerable for a network that depends upon 3 second blocks.

On Linux we have the problem of Virtual Machine time drifting in unpredictable ways, especially when using services such as Amazon or Digital Ocean.

If there are simple instructions on how to run and configure ntpd on the various platforms, then we should do that.

[bytemaster]

http://www.chiark.greenend.org.uk/~cjwatson/blog/ntp-synchronisation-problems.html

OS X built in NTP also seems to fight with "pace maker".

The systems only seem to sync when first connecting to a network.

It is clear there are issues with defaults on many platforms.

[abitmore]

Just FYI all my nodes (Ubuntu 14.04 LTS) haven't had any issue with NTP so far. AWS and Linode and my own hardware. I simply did sudo apt-get install ntp, then wait for it to sync, then start the node.

[sneak]

It is my belief that any modern (that article is from 2010) linux distro (so, ubuntu 14.x 15.x 16.x et c) will work with a simple sudo apt-get install -y ntp. This will set the time once on boot and also keep ntpd running (and in continuous communication with >=3 diverse ntp servers) to prevent any significant drift from accumulating.

As for osx - nobody's running witnesses on OSX. Block consumers can drift a few seconds without issue.

[Gandalf-the-Grey]

There might be some issues in certain scenarios, like OpenVZ containers, etc. but I think we should jutr treat that (reliable time source) as a minimal requirement like any other.

Some use cases (like mine) might find desirable to explicitly forbid steemd to act as ntp client anyway (limiting connections at firewall).
It is also redundant in scenarios when you run multiple steemd instances across your infrastructure.

[sneak]

It only really matters for block producers (witnesses), they can't tolerate more than 100-150ms drift. For block consumers, they can be off 1000ms+.

@bytemaster has determined the right fix is to disable the builtin ntp code for all but witnesses, and even then make it a command line flag (that defaults to off) so that they can re-enable it in the event that there are still problems with using the kernel/ntpd as an accurate time source.

[bytemaster]

We can move this code into a plugin that can be enabled / disabled like other plugins.

[mvandeberg]

The immediate problem has been addressed by disabling the built-in NTP client by default. It will be removed permanently at a later date.

The branch has been merged.

[sneak]

don't forget to update the docs, and I will send out an email on the witness mailing list about requiring NTP.