/cc @htuch

If the hi-res timers are used in the nighthawk for now, would it make sense to have this functionality just there?
Also would it make sense to make hi-res time enabled in the build files by default, instead of relying on users to remember to set on the command line during build?

@yanavlasov I think it's reasonable to add this to Envoy (I suggest this to @oschaaf). Why not make these the default though, rather than requiring specific enablement? Is there a performance or stability implication?

If the hi-res timers are used in the nighthawk for now, would it make sense to have this functionality just there?

So I thought this might be nice to have here as it seemed the change wouldn't add a significant maintenance burden; as the implementation can be shared across the regular and non-HR versions (at least today).. and potentially Envoy extensions might benefit from it?

Also would it make sense to make hi-res time enabled in the build files by default, instead of relying on users to remember to set on the command line during build?

Yes sure; alternatively this can also be set when initializing libevent instead of via setting an environment variable. But I was trying to minimize the change;

Why not make these the default though, rather than requiring specific enablement? Is there a performance or stability implication?

I was thinking that in Nighthawk this should be enabled by default but with an opt-out escape-latch for those who seek absolute highest throughput, as I remember there is a trade-off involved [1]. IMHO Envoy would probably better be off with an opt-in for those who run specific extensions with strict latency requirements..or maybe it would be nice to facilitate extensions that need it to enable the feature at server boot time automatically; e.g. a new interface call for extensions that Envoy can query as it starts to determine if any of those has strict latency requirements.

[1] From https://sourceforge.net/p/levent/mailman/message/29143607/

There are a bunch of backends that can give us a reasonably good
monotonic timer quickly, or a very precise monotonic timer less
quickly.  For example, Linux has CLOCK_MONOTONIC_COARSE (1msec
precision), which is over twice as fast as CLOCK_MONOTONIC.  Since
epoll only lets you wait with 1msec precision,
CLOCK_MONOTONIC_COARSE is a clear win.

@oschaaf this makes sense, but the implementation seems to be basically doing HR anyway for the regular timer case.

@htuch this makes sense, but the implementation seems to be basically doing HR anyway for the regular timer case.

correct, but imho consumers shouldn't care about how the two calls are implemented internally; from the outside my idea is that one of them is to express the desire for a reasonably precise but efficient timer, and the other one is to express the desire of favoring high precision.

(the doxygen comments might be a good place to clarify this in case we want to take this forward)

I was thinking that this distinction might some day be useful, perhaps knowledge about caller intent might be leveraged some day to optimize with coarse grained timer coalescing when favoring efficiency

@oschaaf yeah, that's reasonable. Can you add some tests for the new method?

@oschaaf yeah, that's reasonable. Can you add some tests for the new method?

I took a stab at that. 9f00ad8 explicitly shares some test code between enableTimer() and enableHRTimer().

Thanks.. one thing I'd be curious about is whether it's possible to use simulated time to actually capture the timing precision? Not sure how feasible that is, LGTM otherwise.

Nice, that works, and the new tests also functionally covers theoretical precision for the regular enableTimer() implementation: 2dca213