After playing around with things a bit, I find that I am able to run the clock forward at 8x speed (125ms/tick), but only able to do so reliably in reverse at 4x speed (250ms/tick).
So here is the "torture test" I have devised. It fastforwards the clock for 60 ticks, then reverse the direction for another 60 ticks. At the end of it, the second hand should return to the original position. By running this in a loop for many hours, I can confirm that there is no slippage for a given set of parameters.The parameters for this particular clock (another $2 clock I picked up from KMart after I accidentally stepped on and broke the Ikea one) are:
- Forward : 32ms pulse (9ms on, 1ms off)
- Reverse : 12ms pulse, 12ms wait, 28ms pulse
The high-level code to implement the above looks like this:
It is actually OK for the reverse tick to run slower because if you are trying to catch up to a certain time by running in reverse, the clock is still ticking ahead. So say if it's 3am now and I am trying to reverse back to 2am, that's 60 minutes worth of path to backtrace. At 4x speed, it will take me 60/4 = 15 minutes to do so. But in that 15 minutes, the clock has also moved ahead 15 minutes, so that's actually more like 45 minutes worth of time to backtrace.
Whereas if it's 2am and I am trying to fastforward to 3pm, again that's 60 minutes worth of time to traverse. At 8x speed, it will take me 60/8 = 7.5 minutes. But in that time, the clock has also moved ahead 7.5 minutes, so it will take me more than 7.5 minutes to catch up with the clock.
I need to come out with a function to calculate given the current and target time, how much time it will take me to fastforward or reverse to the desired position. Then it will provide an objective measure for the optimal route to take when the clock needs to catch up with the actual time.