DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=35746>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35746 ------- Additional Comments From [EMAIL PROTECTED] 2006-10-01 00:41 ------- While I agree with the general centiment that if an alternative algorithm works in more cases with no loss of performance that your idea maybe sound. But the following statement demonstrates your limited knowledge of what NTP goals are. (In reply to comment #4) > Whenever a user (or the ntp update agent/service/deamon) sets the date/time, > sessions may be lost. An NTP client does not reset the clock when it computes a variation. It makes the system clock tick faster or slower to narrow that variation over time. If its too far out NTP will not function and abort. Since TC is not a realtime application and runs largely on a multitaking OS a faster/slower clock is not ordinarly detectable by an appliction. Which is the point of running NTP. I'm a great believer that just as time never goes backwards that clock slew is not something that an application programmer has to deal with. This is one certainty of the universe for which computer concepts live within so as such its an underpins everything. If you want to change the time then do so in the BIOS before the operating system boots up, of the user changes the time force a device reboot. If the application of the device means you dont want this then you've going to have to look at NTP anyway. Some would argue that short sighted embeded device creators didn't provision an adequate mechanism to change the clock or keep it up-to-date. Since its a given that the accuracy of the clock source in the device while good isn't perfect (like most things) and the device's software relies heavily on absolute time to function. One question on your algorithm, is it written in the Java specification for the Thread.sleep() function that this has to be implmented in a way impervious to clock slew ? Or does that claim come from your experiments with a particular JVM implementation on the particular embeded device you have to hand ? It is no good building castles in the sand. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
