but what I'm saying is that every second will still hit. It's just that that second will only last for 0.8s. So to the code above the OS and even the shell level system calls, there is no difference. The difference is very lo level - interrupts come in every micro-second or so from the CPU and the OS just turns over the clock a little faster. I've seen systems brought up to speed by days using NTP without problem - it just takes a number of hours for the system to get where it needs to. And if your system had been bleeding time, no files are post-dated... they are all dated to something slightly behind the real time.
On Sat, Mar 12, 2016 at 3:35 PM, John Wong <gokoproj...@gmail.com> wrote: > I believe K is asking whether he can sync up the clock now because he's > concerned about losing data, as 30-40 seconds is pretty bad. > > On Sat, Mar 12, 2016 at 8:57 AM, Spencer Brown <lilspe...@gmail.com> > wrote: > >> NTP gradually speeds or slows the clock to arrive at actual time. So the >> clock still hits every second but 1s may really be 0.8s or 1.2s. In your >> case, it will sync up within a day. NTP is very clever so you never have >> newer files back-dated to be older than older files or vice versa. >> >> Spencer >> >> On Thu, Mar 10, 2016 at 2:45 PM, Robert Coli <rc...@eventbrite.com> >> wrote: >> >>> On Wed, Mar 9, 2016 at 9:03 AM, K F <kf200...@yahoo.com> wrote: >>> >>>> the clock is about 30 to 40 seconds behind. >>>> >>> >>> If you don't want to get ntp working there, why not just... manually... >>> set the clocks? >>> >>> =Rob >>> >> >> >
