K 10 svn:author V 3 phk K 8 svn:date V 27 1999-12-29T14:39:24.000000Z K 7 svn:log V 989 Don't use time_offset as a leaky bucket variable in hardpps(), this resulted in vastly optimistic offset values reported to userland (typically a factor 40+ too small). Apart from that, the code had two sign-bugs. Apply the hardpps() phase with the right sign with a simply scaling by integration interval. (This may be too stiff at long integration intervals, see below). Allow pps_shiftmax to be reduced again. Before this, the phase lock in hardpps() were broken, but due to two bugs mostly cancelling out, it would end up basically working with a large stochastic component. Now it behaves as one would expect: smooth and quiet. It seems that pps_shiftmax above 7..9 somewhere makes the phaselock too weak to hold onto random walk phase errors from a HP-105 OCXO, which basically means that it is too weak for real-life use with such integration times. This is yet to be resolved. Submitted to: Prof. Dave "NTP" Mills. Tested by: Terje Mathisen END