0

I don't have any mathematical background, so please excuse my language.

motivation

  • Two different computers running a clock which is being reset to the same value (integer, i.e 1464009526876).
  • There will be no communication between the two computers from this moment forth
  • Due to various reasons, the two clocks will eventually go out of sync
  • I'm only interested in functions that specifically call for data from the clock, due to potential differences between the machines, there might be a different call number between the two
  • I don't care about the value itself
  • I do care for it to be different on each call, and overall having the same value on both ends
  • I am willing to sacrifice a certain amount of time in which this value won't change

problem

Assuming two positive integers (a, b), which have a difference of no bigger than (d), which is a constant that can be decided upon beforehand.

The algorithm, accepting a single number(a|b) as an input, will output a new integer which is relative to both, hopefully placed somewhere between the two.

This integer will be the same for both, and basically all numbers within the defined range.

example

a = 1464009526876;

b = 1464009514876;

alg(a); // output: 1464009526800

alg(b); // output: 1464009526800

My overall challenge is to sync the two numbers, and try to generate values that are different, yet somewhat close to the initial reset value and/or the average/relative time passed.

Using NTP won't cut it due to its need to poll for the data (also, as mentioned before, I don't care about the value itself, just for it to be identical and relative to the original reset value).

Laurel
  • 5,965
  • 14
  • 31
  • 57
silicakes
  • 6,364
  • 3
  • 28
  • 39
  • To clarify, are you essentially trying to synchronize two clocks without having to poll the other clock (and without any other information about the clocks themselves other than they start on same value and don't have a sizable difference)? – FriedSaucePots May 23 '16 at 15:00
  • Yes, however I don't care about the value itself as I am more interested for it to be identical even if it means a certain shift on both ends – silicakes May 23 '16 at 15:04
  • Without polling and without knowing which computer is faster or slower, I'm pretty sure this problem is impossible. And if possible, I'd imagine it's incredibly fragile. `alg()` will need to determine which direction to adjust the time and without more info, that cannot be determined (the adjustment could just as easily increase the clock difference).. – FriedSaucePots May 23 '16 at 15:11
  • Interesting, and what if i do know which machine is faster? or better yet, what kind of information can I provide in order to get the solution? – silicakes May 23 '16 at 15:15
  • If you knew which machine was faster and you still had a maximum difference between clocks, I'd probably adjust the clock to the next highest / lowest value (depending on which machine is faster) that is divisible by the maximum difference. That will make it so both clocks will adjust to the same value. Note it's fragile in the sense that if that maximum difference is ever exceeded, then the clocks could start drifting wildly apart. – FriedSaucePots May 23 '16 at 15:30
  • This will only work, assuming there's no more than one occurrence of the sort between the two machines. In order to make sure of that, I can force one of the machines to add that certain limit to its clock. the slower machine (s) will then count up, where as the faster one (f) will count down, giving us: s-->n<--f where n is the only occurrence of modulus(0) division. however, this is prune to fail for every round following that since the time gap will become unknown quite fast – silicakes May 23 '16 at 15:47
  • Ah OK, I did not know that you wont be setting the clocks but just getting the value. You're right if you don't adjust the clocks themselves, then the time gap will become unknown fast and the rounding will not work reliably. I would guess this particular subject of non-polling clock synchronization can be an entire area of research on its own, though I'd guess results will be theoretical for now and NTP would still be favored over it ;) – FriedSaucePots May 23 '16 at 16:20
  • Perhaps, however NTP isn't a good solution for me (see the original post). Thanks for your help! – silicakes May 23 '16 at 16:34
  • @silicakes, what you are asking for is essentially the core `TrueTime` mechanism of the Spanner DB paper from google. The paper talks about it and there's a talk from one of the authors which goes into more details on it. Paper: http://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf Talk: https://www.youtube.com/watch?v=Q7pcMn0_tac – user1952500 May 23 '16 at 19:17

2 Answers2

0

There is no way to calculate this under real world conditions.

Even a simplified version, where you are just looking to know if the other clock is ahead or behind you is similarly impossible. You just aren't psychic.

You would essentially need to have a position equation (with quantum time being "time", and "position" being the time the computer thinks it is). And both sides would need to know it beforehand.

You might be able to get a good estimate of what each position graph looks like by gathering data and extrapolating.

If you had that, it would be simple to find a solution.

If it's X o'clock on your end, you can plug that value into your position equation to get the "quantum" time. And then you can use that value to find out what time it is on the other end.

And then you just have to solve the problem of creating another equation that you can plug both numbers into and get the value you want as the result of the algorithm. Without more information, it's hard to tell what it might look like.

Of course this is a high level explanation, but the math shouldn't be too hard to implement. Obviously, I'm not sure how well this will reflect the real world either.

Laurel
  • 5,965
  • 14
  • 31
  • 57
  • You're assuming I'd like to sync time for either position, however, I'm just looking for a third option, which isn't the time on either machines, but rather - a close approximate. For my example, I could easily go with casting the last 4 digits into zeroes, giving me a 'dead zone'(where time stops) for 1 second , and risking a time() function call on the specific millisecond of the second's shift. I can avoid such case, by adding a small amount of latency to the runtime by getting the original time from each of the machines. – silicakes May 23 '16 at 15:20
  • @silicakes Are you looking to calculate this on a third computer, which knows the time on either machine? – Laurel May 23 '16 at 15:26
  • afraid not: I'm looking to calculate this on both computers without them talking one to another. – silicakes May 23 '16 at 15:51
0

I'd suggest getting the current time and then rounding to the nearest second (millisecond, whatever).

In order for that to work, you need both systems to have their time nearly synchronized. You can probably safely assume that the clocks won't diverge by more than 1/2 second per day. So if every day your two systems called some NTP service to get the current time, you can probably assume that the two systems are within 1/2 second of each other.

Jim Mischel
  • 131,090
  • 20
  • 188
  • 351
  • That's assuming the entire clock syncing is a one time gig. I might not have mentioned that I need this for every new session engaging with my API. These sessions actively affect CPU and other resources, along with various code contingencies that might trigger a somewhat different behaviour that will eventually propagate towards applying the date/time value. NTP requires polling (as mentioned in my original question) which I'd like to avoid. – silicakes May 23 '16 at 16:38
  • @sillicakes: I was thinking of polling the NTP server once per day, to set the system clock. But if that won't work ... ? – Jim Mischel May 23 '16 at 17:20
  • I'm afraid it won't since my sync is outside the server itself and should sync various calls to various times simultaneously – silicakes May 24 '16 at 07:32