Seems like a reasonable idea, but that would require that I have the client send its input state every tick rather than only sending changes when they happen. Do you think I should do that?
There is no difference, assuming all messages get delivered. If not all messages get delivered, then it is good to send the state of inputs in each packet.
let the ticks process as fast as possible
No, this is not what I'm saying. I'm saying that the global rate of tick progression happens on the server. The server has a clock that maps real time to tick numbers by simple division. Each time the server wakes up, it checks what the current "goal tick number" is, and if the last simulated tick number is less than that, it simulates ticks forward until it's caught up.
On the client, you need to get an estimate of what the server's clock is. The server will send packets saying "this was the state of things at tick X," which means that you know the current tick is at least X. You can then send your input, saying "this happened at tick X+1."
The server will get that input, and it will probably be late (unless you're sitting right next to the server.) The server will then include information saying "you were Y ticks late in the last message, and here is data for tick Z."
You can then adjust your server tick offset to Y (or, at least, bump it up one step) and send the next set of inputs for tick Z+Y.
If your inputs arrive way too early, so the server has to buffer more than one network packet worth of tick-timestamped data, then the server can send "you were early" information so the client can bump down its estimate of how early it needs to send the data.
- When the server sends tick adjustment data, the client will run physics faster than real time for that adjustment period (or slower/delayed, when adjusting backwards.)
- You need no round-trip estimate, because the server will simply tell you how much earlier (or later) you need to make your estimation. This means that asynchronous round trip times won't be a problem from a server clock estimate point of view.