Re: Garbage in Refid field - peers
- From: mayer@xxxxxxx (Danny Mayer)
- Date: Fri, 18 Nov 2005 03:54:08 GMT
TJ Horlacher wrote:
> "Danny Mayer" <mayer@xxxxxxx> wrote in message
> news:437D3865.9050408@xxxxxxxxxx
>
>>TJ Horlacher wrote:
>>
>>>When doing a ntpq -p, I am getting garbage in the refid column from
>>>Windows
>>>servers. Happens when running ntpq from Linux or Windows, but if garbage
>>>is
>>>there, than it is always coming from a Windows ntp server.
>>>
>>> sv1.time.com 204.17.42.199 11 u 15 64 377 0.001
>>>242.768 4.142
>>> sv2.time.com .Ñ 16 u 25 512 0
>>>0.000
>>>0.000 4000.00
>>>
>>>Linux servers running ntp v4.2.0.a.20040617-8
>>>Windows servers running ntp v4.2.0b@20051016
>>>
>>>Any advise, outside of don't run ntp on windows...
>>>
>>
>>On the contrary, upgrade ntp on Linux. This bug was fixed a long time
>>ago in the development stream.
>>
>>Danny
>>
>
>
> Danny thanks for the reply,
>
> I may try that, but this is also happening when running ntpq from windows
> server console as well. Stating that, also keep in mind the gabage in the
> refid field is only coming from windows server peers. I would think if it is
> an ntp issue on linux, then I would only beeing seeing this problem when
> running ntpq on linux consoles.
>
> I had previously reviewed ntp.org bug list, and you are correct - there is a
> listing that is new for Solaris and regarding 4.2.0b. However, I was hoping
> someone may have found a root cause or workaround.
>
> https://ntp.isc.org/bugs/show_bug.cgi?id=221
>
Oh that one. Yes, I haven't had time to look at it. Debugging it is ugly
and reproducing it may be harder.
> In addition, 4.2.0 is production release, while 4.0.2a is point release and
> is supported by Redhat updates. Version 4.0.2b is not currenly supported
> since it is still development. As such, moving to 4.0.2b for linux would
> require us to move away from update mangement, related to ntp, to our redhat
> timeservers throughout our organization. This is not a serious problem - but
> does cause additional and hopefully unnecessary work down the road.
>
Sorry, we can do anything about Redhat or what they do.
Danny
> TJ Horlacher
>
>
>>>thanks
>>>
>>>
>>>_______________________________________________
>>>questions mailing list
>>>questions@xxxxxxxxxxxxxxxxx
>>>https://lists.ntp.isc.org/mailman/listinfo/questions
>>>
>>
>>_______________________________________________
>>questions mailing list
>>questions@xxxxxxxxxxxxxxxxx
>>https://lists.ntp.isc.org/mailman/listinfo/questions
>>
>
>
>
> _______________________________________________
> questions mailing list
> questions@xxxxxxxxxxxxxxxxx
> https://lists.ntp.isc.org/mailman/listinfo/questions
>
_______________________________________________
questions mailing list
questions@xxxxxxxxxxxxxxxxx
https://lists.ntp.isc.org/mailman/listinfo/questions
.
- Follow-Ups:
- Re: Garbage in Refid field - peers
- From: TJ Horlacher
- Re: Garbage in Refid field - peers
- References:
- Garbage in Refid field - peers
- From: TJ Horlacher
- Re: Garbage in Refid field - peers
- From: Danny Mayer
- Re: Garbage in Refid field - peers
- From: TJ Horlacher
- Garbage in Refid field - peers
- Prev by Date: win32 undisciplined local clock sync time
- Next by Date: Re: win32 undisciplined local clock sync time
- Previous by thread: Re: Garbage in Refid field - peers
- Next by thread: Re: Garbage in Refid field - peers
- Index(es):
Relevant Pages
|
