Customers hope they can control the sync action, and trigger it in midnight. They have some concern that a time sync action during production will cause potential trouble to their transactions, as it's time sensitive.
Then any way to make time screw only in midnight? the dataontap version is 8.0.2 p6/p4.
8 REPLIES 8
I haven't heard that objection from a customer before, but can understand the concern...surprised it hasn't come up before. Bill gave the right answer to meet the concern, and I would also add that they might want to look at the skew setting since if the time exceeds the skew it won't update, and with 24 hours between updates it could be further off than if updated hourly for example.
I was going to give the same warning on the skew limites, but the man page says the man and min skew options are obsoleted in ONTAP 8. It does not, however, say whether the default 30 minute max is still enforced or not...
I find bellow links to explain when client triggers poll in NTP v4,
I wanna know if time sync with ntp v4 only have slew action, so the time update within 128ms ,
and it won't influence the time stamp of file.
You need to be careful trying to apply documentation like this to ONTAP, which often does it's own implementation of public software (like NTP). So while this document describes an ntp.org client implementation, it may not necessarily properly describe an ONTAP client implementation.
Yes, it seemed do have sth different.
After check the documents, it shows
Ontap default to ntp v3 after 8.0.2.
and a common ntp client will refuse to work when the time gap is over long.
the gap smaller than 2 minutes can be synced without burst update
but it should sync even with a 30 minutes gap with burst time update which seemed not acceptable
by most of customers.
Not sure what you mean by "burst update". A well running NTP environment will have a skew of much less than a second, so no timestamp issues should be seen when the time is adjusted. If the controller has drifted 2 minutes from the NTP server, something is wrong. If it's drifted 30 minutes, something is very wrong.
I would agree that a 30 minute time adjustment should be unacceptable. However, I have never seen a skew anywhere near that big except is outage situations.