Brian Utterback wrote:
>
>
> Garrett D'Amore wrote:
>> Sounds like this is a good way forward. I do have two questions though:
>>
>> 1) Synchronization with audio... you had told me at one point that
>> one of the time sources was an audio source that emitted a tone at
>> specific intervals -- such that accurate timing information was
>> critical for you. Have you tested with Boomer? Will this project
>> rely on, or make use of, the OSS API that is being integrated with
>> Boomer? (PSARC 2008/318)
>
> Since there are now over 40 hardware clocks available and I have
> access to only a couple, I have not tested many. Support for
> individual clocks will be done with community involvement as problems
> are reported. The audio clock has been reported to be less than
> stellar anyway, which is something I would like to address eventually.
> In the meantime, I expect to address hardware refclock problems as
> they are reported. I have sanity checked the ones I do have access to
> to ensure that the basic clock/ntpd/kernel interfaces work.
Ok, so I don't know what this means. Will the audio clock use OSS or
Sun audio? The Sun audio probably has a *lot* more jitter (perhaps
unacceptably large?) than the OSS API does. Since ntp *must* support
the OSS audio device (if it wants to work with FreeBSD at least, which I
believe it does), I'd like supporting Boomer to be a requirement for
this case going forward. (Put another way, I don't want to have to deal
with bugs from this project using the legacy Sun audio interfaces...)
>
>>
>> 2) Suspend/resume interaction. One of the problems that we've been
>> discussing lately is NTP getting out of sync on a resume event. How
>> well does the new NTP code deal with this? There is SIGTHAW
>> delivered on a resume, but you might not get it "right away" -- and
>> SIGFREEZE is useless because you might not get that until *after* the
>> system has resumed from a suspend cycle. Anyway, I'm interested to
>> know what work has been done here, and what needs still to be done.
>> I'm willing to help out, since I have similar issues for audio
>> drivers, and I think Randy is willing to help as well.
>
> I have not done any work on this. I only became aware of this issue
> this week. However, the problem exists in both the old and the new
> versions, so I don't view that as a problem for this case.
>
> Since you ask, it would seem that the best solution is to simply
> restart the ntp service. We can deal with this in the CR outside this
> case.
I'm not sure I agree that restart is the right thing -- rereading the
configuration file etc. might have unanticipated side effects. What is
necessary is to put the server into some kind of "get your clocks in
order quickly, because they are probably wrong" mode.
I agree that we can do this outside of the context of this case.
- -Garrett
>
>>
>> Thanks.
>>
>> -- Garrett
>>
>> Brian Utterback wrote:
>>> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
>>> This information is Copyright 2009 Sun Microsystems
>>> 1. Introduction
>>> 1.1. Project/Component Working Name:
>>> Upgrade NTP to Version 4
>>> 1.2. Name of Document Author/Supplier:
>>> Author: Brian Utterback
>>> 1.3 Date of This Document:
>>> 17 April, 2009
>>> 4. Technical Description
>>> Upgrade NTP to version 4.
>>>
>>>
>>> This project proposes to remove the current version 3.4 NTP
>>> deliverables and replace them with version 4.2.5. The current
>>> version in Solaris was released 11 years ago. The NTP project
>>> has continued to advance the code base for the entire time.
>>> This will be done by removing the current SUNWntpr and SUNWntpu
>>> packages from the ON consolidation and move them to the more
>>> appropriate SFW consolidation. In addition to the replacements
>>> for the current deliverables, the packages will include man pages
>>> and HTML documentation.
>>>
>>> While not 100% backwards compatible, the incompatibilities in the
>>> configuration file are mostly semantic in nature rather than
>>> syntatic, with the only major exceptions being in Sun added
>>> features, which we will not be adding. However, because of the
>>> popularity of
>>> the "slewalways" feature, the startup method will detect the
>>> presence of this Sun added keyword and configure the NTP daemon to
>>> use the NTP version 4 equivalent. The NTP community project, while
>>> not having an explicit requirement
>>> for backwards compatibility, in 11 years of development, including a
>>> full re-write of the configuration
>>> code, has had no major incompatibilities were introduced.
>>> The NTP community is very receptive to contributed code and
>>> integration of features needed by Solaris. I am a committer on
>>> the NTP project and I expect to work with the community to push all
>>> fixes and changes back into the community codebase.
>>>
>>> While the man pages are derived from the HTML documentation, they
>>> are specific to these deliverables and as far as possible complete and
>>> accurate regarding them. The HTML documenation, is delivered "as is"
>>> and may or may not reflect the deliverables. A notice to this effect is
>>> included in the man pages.
>>>
>>> This work is being sponsored by chris.armes at sun.com.
>>>
>>> This project seeks a minor release binding.
>>> This project supercedes PSARC 2001/162, which should considered
>>> withdrawn.
>>>
>>> 6. Resources and Schedule
>>> 6.4. Steering Committee requested information
>>> 6.4.1. Consolidation C-team Name:
>>> SFW
>>> 6.5. ARC review type: FastTrack
>>> 6.6. ARC Exposure: open
>>>
>>>
>>
>
