The way that I dealt with this is to maintain a server side estimate of client RTT, and use that for clock estimation on the server (e.g tick_cli = tick_srv - tick_rate * RTT/2)

This meant I didn't explictly deal with the client clock for any timestamping information, and used an incrementing event number to ensure events were inserted into the event queue on time.

In short, I didn't manage the clock on the client, as I saw complications - you suddenly lose the guarantee of contiguous time, which I am not comfortable with.

The only reason for this clock variation is to ensure that the server itself receives events when it expects them, whereby it compares the tick values between server and client. Providing that you can guarantee a fixed tick rate, you aren't actually moving forward /back in time, however, it is just the network conditions changing. This is why I approached this with - build an event queue server side of N events, where N might be the uncertainty in the client-server time * tick rate. This simply ensures the server has enough events that it never "runs out" of events to process to move the client forward in time. The RTT estimate that the server maintains is then used to resolve things like "was i shot, according to lag compensation".

Otherwise, you could likely use some kind of sliding window smoothing, or

You don't need to know the RTT for this.
Simply keep an offset between your local computer clock and "virtual game start time."
The "current game time" equals "current clock minus game start time."

If you are to "speed up" then move the game start time backwards (subtract from it.)
If you are to "slow down" then move the game start time forwards (add to it.)
Note that you want some interval/window where you don't adjust at all. For example, if the data arrives within 200 milliseconds ahead of being used, don't adjust.
(Another rule is to use number of packets; if a packet arrives and there are 0 or 1 unprocessed packets in the incoming queue, you're good; if there are more, you need to slow down.)

I think we're looking at this slightly differently - The reason I mention using the RTT is to approximate the time difference. In practice however, the RTT varies with network conditions and is going to deviate by several ticks at times.

I consider there to be several problems:

1. As the network conditions evolve, the client will move further into the future or past relative to the server.
2. The server needs at least (1+N) network tick interval's worth of events to account for changing latency in the connection (N>0)
3. The time at which events were generated is useful so that the client can move forward / back in time

Point 3. can be resolved by sending the current "server tick" that corresponds to the world state tick at time T of generating events, which does trust the client, but this happens with any method (using RTT, clock nudging), and just requires some sanity conditions on the server.

Point 1. and 2. are related, and the server will occasionally need to stop and recover in the event that it runs out of inputs. One of the finer points is differentiating between latency variations and network tick intervals, which are intentional delays. In the case of clock nudging, it is important that the accepted lead time is significantly larger than the network tick interval.

I never felt comfortable with how clock adjusting was discussed - It seems vulnerable to panicking when network conditions change sufficiently, and will vary with the network (obviously). I prefer to have the client running in the future, but with no explicit notion of "aiming to arrive on time", given that this really is just an estimate. Having the clock vary according to the network wasn't something I liked particularly. I realise that I've just moved the "problem" around, of course.

This probably makes no sense. It's late.

Thus, having the server always respond with a packet as soon as a packet is received (in some real-time thread) and measure the round-trip time of that (using a real-time receving thread on client, too) will show what gamers want to think of as their "ping."

For example, if server tells me it received my input for tick 10 at tick 7(3 ticks early), then I need to slow down 3 ticks worth of time. How should I go about doing this?