Re: NTP (not SNTP) on the System i ?

NTP vs SNTP - it's more than this skewing issue, there are RFC documents that describe them both. At one time, these were separate documents. Now I think I just saw that SNTP is covered as a subset in the NTP RFC (request for comment, the mechanism used to get all manner of internet standards established and/or worked on - a very casual and probably skewed description of it all!!)

The last RFC that was only SNTP was 4330 - that has been obsoleted by 5905. http://tools.ietf.org/html/rfc5905 is a place to look at it.

So according to the latest RFC 5909, SNTP just doesn't have all the stuff that is in NTP - from 5909 we have this in the SNTP section -

Primary servers and clients complying with a subset of NTP,
called the Simple Network Time Protocol (SNTPv4) [RFC4330 <http://tools.ietf.org/html/rfc4330>],
do not need to implement the mitigation algorithms described
inSection 9 <http://tools.ietf.org/html/rfc5905#section-9> and following sections.

As I barely understand things, mitigation is working out time data from multiple servers - SNTP uses only 1 server as its time source.

The RFC, if I read it correctly, says that the only thing different is the mitigation - so skewing is certainly available to SNTP, as Chuck points out.

Anyhow, NTP on IBM i is SNTP according to RFC 2030, I think - a predecessor of 4330. Same with the AIX version. Not sure about any Java versions.

Later
Vern

On 5/20/2014 5:48 PM, CRPence wrote:

On 20-May-2014 14:23 -0500, Buck Calabro wrote:

<<SNIP>> NTP will speed up the clock (or slow it down) a bit until
the incoming packets match the system clock. In other words, the
clock will gradually slew onto the new time. With SNTP, the
algorithm is simple, and doesn't slew the clock, it makes up the
difference in one jump, so there's a lurch when SNTP needs to make a
change.

This is why the actual requirement matters. If the requirement is
to avoid large clock changes, you really need to be running an NTP
that can gradually slew the IBM i clock. <<SNIP>>

As I understood the SNTP client for IBM i, there are thresholds that can be set to decide if\how to adjust the time. And if the hardware supports the capability to slow-down or speed-up the system clock, then that throttle feature will be used [within specified thresholds] rather than resetting the time. Notably, for Change SNTP Attributes (CHGNTPA) is this old help-text\documentation for a particular parameter:

_Client adjustment threshold_ (ADJTHLD)
"Specifies the threshold which determines whether changing the clock will require setting or adjusting the clock.

• Setting the clock means replacing the current clock value with a new value. ...

• Adjusting the clock means to incrementally speed up or slow down
the clock so that time is gradually synchronized with the NTP or SNTP time server. Adjusting does not cause the large jumps in time that can be experienced with setting the clock. ...
..."