[ntp] disable ntp time jump

[yxieca]

- What I did
This change is added to address the supervisord issue with clock setting back.

• removing -g to disable jump when time difference is greater than 1000s
• add -x to disable initial jump

- How to verify it
Set a dut with some clock difference with NTP and sync to CMOS. Then boot up an image with the fix. Confirming that the initial jump didn't happen when ntpd starts with a few reboots and ntpd restarts. And leave the system up and watch the clock slowly drift back towards the correct NTP time (ntpstats).

[jleveque]

I wonder if it is more explicit and easier to track if rather than removing the ntp-config timer-related stuff here, we instead open a separate PR to revert #2494.

[yxieca]

Joe, I agree with you. Reverting the original PR is a cleaner way of managing git history.

[nikos-github]

@yxieca @lguohan Please explain the issue in detail.

[yxieca]

@nikos-github the problem is that when ntpd is running without -x option, it is allowed to make a clock adjustment when it first connected to a NTP server. Which could result in dialing back the clock by x amount of time. If supervisord is starting a process when this happens, supervisord would barf. -g allows ntpd to dial clock back/forth when the difference is greater than 1000 seconds. We thought that could cause same supervisord issue.

[nikos-github]

@yxieca @lguohan This is like the 4th PR to change something else in order to address the supervisord shortcomings with the clock adjusting. Not allowing the clock to jump, means that the clock is not synchronized for a large period of time. I really don't understand how it is an acceptable solution to have the clock drift like that especially since it can take hours or even days to catch up. This isn't the right way to address the issue at supervisord and we discussed this before. And yet here we are 4 PRs later.

[yxieca]

@nikos-github Acknowledge. I agree that we are trying to work-around known issues with these changes. We would like to see supervisord bug get fixed too. But until then, we would rather like not triggering the issue :-)

[nikos-github]

@yxieca Have you tested with your changes to see how long it takes for the clock to synchronize if the difference is 1000s of seconds?

[yxieca]

@nikos-github from what I observed, the clock fixing rate is about 70 seconds every 24 hours.

[nikos-github]

@yxieca @lguohan So we're taking many many days. How is that ok? I can tell you right now this will be a deployment blocker for any of our sonic customers.

[yxieca]

Made to 201811 branch on 2/21/2019