>> Which problem do you think we are discussing? > The bad reversion is what I am discussing. OK.
>> step_system works as you describe it. The problem is that it is >> being fed bad data. > Really? Can you detail your assertion? How about an example? System time is 1970. Server time is 2037, which gets truncated and turns into 1901 Subtract gives an offset of -69 > No. It thinks it does a pivot, but you never pivot an offset, only a > timestaamp. Get the currect system time. Add the offset. Now you have a timestamp for the new system time. Pivot that. Using the above example, the new time would be 1901 which is before the build date so add 136 years to get 2037, the server time that we want. > When you subtract one timestamp (with the implicit term > NTP_EPOCH) from another timestamp (with th eimplicit NTP_EPOCH) then you > have removed the term NTP_EPOCH. Right. But in the l_fp case, one or both of the timestamps may have been truncated. One truncation isn't fatal. Consider 2035 and 2037. After truncation, the 2037 is 1. When you do the subtract, there is an overflow which in this case adds the truncation back. The nasty cases are one truncation and no overflow or overflow with no truncation. That's assuming you do the subtract using 64 bit arithmetic. If you use something bigger, you don't get the overflows. That fixes one case but breaks one that used to work. > See above. No pivot needed. Subtracting one timestamp from another removes > any constant that is in both terms. Right. But it doesn't magically fix unmatched truncations or overflows in the subtract. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
