But I got something strange when I replaced time() in my original code with gettimeofday: exactly precise seconds (to 5 decimal places). I am not quite sure if that is actually correct–is that just calculated to be precise or it the measurement actually precise?

I'm not sure what you mean exactly, maybe you could show the code you're referring to that shows this effect? Note that Time::HiRes provides its own implementation of time, could that have something to do with it?

print gettimeofday, "\n";

soonix answered that one: in the list context of print, gettimeofday returns two values, and you're seeing the concatenation of the two. That's why I used sprintf("%d.%06d",gettimeofday) - using getttimeofday in scalar context returns a floating-point number; since I was using Math::BigFloat I didn't want any floating-point imprecisions, so I used a string instead.

Although, I use default settings of CentOS 7 for chrony–do I need to adjust something to use those smooth adjustments?

Sorry, it's been a while since I worked with it in detail, I'm certainly not an expert. But throughout its documentation you'll see references to it slewing the clock, so I believe its normal mode of operation is to change the system clock's frequency slightly to adjust the time, instead of adjusting the time itself, which would result in jumps. And just to make sure: You mean you're running chronyd on this machine, not just on your NTP server and using a regular NTP client on the local machine?

Update: Take a look at the makestep and perhaps maxslewrate directives in your configuration - and in general I'd suggest a thorough read of those docs. Update 2: From initstepslew:

In normal operation, chronyd slews the time when it needs to adjust the system clock. For example, to correct a system clock which is 1 second slow, chronyd slightly increases the amount by which the system clock is advanced on each clock interrupt, until the error is removed. Note that at no time does time run backwards with this method. On most Unix systems it is not desirable to step the system clock, because many programs rely on time advancing monotonically forwards.