> You could just sync it once a week. 2am everyday is also a fine choice. > Most RTCs can keep within a second a week, I think. It may seem like a > really good idea to have super-accurate time on a phone system, but > (IMHO) I can't see a need for better than one second accuracy. AND, > every time you set the time, you risk something going wrong with the > phone system. Seriously. The phone system was likely designed to have > it's time set once and then left alone and the manufacturer tested only > that condition. If you update the time frequently, there's a good chance > that sooner or later, it'll coincide with some other event, which will > cause someone to be kicked off the conference-call-of-a-lifetime.
An interesting theory and set of assumptions. Perhaps to replace said fear of risk with confidence in design I'd suggest that Joseph run his time setting program in a sort of time jitter test mode -- where for minutes at a time, or all day if necessary, he randomly, or rapidly, sets the time ahead or behind by seconds or fractions of a second. If no one reports any problems during this test period then we all sit back knowing that at least this system handles dynamic time setting robustly. Which brings up another hack to solve both Joseph's problem and Glenn's worry. Have your program just run in a tight loop: get PC time; set telephone time; and wait 10 seconds. This excessive update rate will not only guarantee the telephone stay in sync with the NTP PC to millisecond levels but if there are any bugs in the telephone system firmware they will show up in the first day instead of the conference-call-of-a-lifetime. /tvb _______________________________________________ time-nuts mailing list [email protected] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
