Kudu's transaction system "tag's" mutations with a timestamp that has a wall-time component.   Beyond powering distributed consistency semantics (i.e. in between different tablets, each running raft internally) these timestamps can be used to run point-in-time scans, if the system is setup appropriately. As part of the algorithm, server's send the timestamps to each other all the time, either directly or through clients, and then use those to update their own clocks.   If the server's clock's are out-of-sync by a lot, then the point-in-time scans lose meaning, but moreover, other weird things might happen like a server crashing and coming back with lower wall clock time.   We're working on an alternative that will avoid users having to deal with this problem, but in the mean time I'd suggest setting ntp properly.   One possible layout that we've seen work in the past is to have a couple of ntp time masters close or within the kudu cluster and then have the servers be ntp peers to each other.   ... View more