Ronny Egner wrote: This posting is broken because it has this header:
Content-Transfer-Encoding: quoted-printable but doesn't actually quoted-printable encode the body. That means that things go badly wrong whenever there is an "=" sign. I'll therefore quote the message source here, which means I'll have to put the quote marks in by hand. For the benefit of other people with MIME capable newsreaders, I won't trim the quoting in the way I normally would. (More at foot - theory about gateway bug.) > Steve Kostecke schrieb: > > On 2008-06-09, Ronny Egner <[EMAIL PROTECTED]> wrote: > >> The problem i am facing occur on all my new 6 servers > >> which are all equally configured (Red Hat AS 4 U4, 64-bit). > > > > Are they VMs? > No, physical machines. > >> server solaris-server > >> server windows-dc-serverA > >> server windows-dc-serverB > > > > You can reduce the initial sync time from ~ 5 minutes to ~15-20 > > seconds > > by appending 'iburst' to your server lines. > I will try that. > >> ntpq> peers > >> remote refid st t when poll reach delay offset jitter > >> ======================== ========================= ===================== > >> solaris-server 10.x.y.2 5 u 18 64 377 0.259 892.342 30.508 > >> windows-dc-serverA 10.x.v.1 4 u 17 64 377 0.214 847.816 50.335 > >> windows-dc-serverB 10.x.v.1 4 u 22 64 377 0.272 923.808 45.667 > > > > There is a signifiant diference in offsets between those remote time > > servers. And the jitter is quite high. Are all of these server on the > > same LAN? Are any at remote sites or reached over a VPN? > No they are not reacable over a VPN. They are routed through the network > (quite complicated; but there is no WAN part inbetween). > I dont know much about the windows servers. The customer told me i can > use them for time synchronization - so i did it because the network i > highly protected from the outside lan. > >> ntpq> rv 39492 > >> assID=39492 status=9014 reach, conf, 1 event, event_reach, > >> srcadr=solaris-server, srcport=123, dstadr=10.x.y.z, dstport=1 23, leap=00, > >> stratum=5, precision=-18, rootdelay=31.601, rootdispersion=103 16.483, > > > > The root dispersion suggests that this peer has not been synced to a > > real time source is quite a while. This needs to be fixed first. > > > Could you please post the solaris-server 'ntpq -p' billboard from (in a > > condensed format as shown above)? > This is from the solaris box: > ntpq> version > ntpq 3-5.93e Mon Sep 20 15:45:42 PDT 1999 (1) > (it is a Solaris 10) > ntpq> peer > remote refid st t when poll reach delay offset > disp ========================= ========================= ========================= === > #windows-dc-serverA 10.x.v.1 4 u 215 1024 377 0.31 0.888 3. > 42 > +windows-dc-serverB 10.x.v.1 4 u 509 1024 377 0.44 -1.445 2. > 61 > Both windows server seem to get ther ntp data from the host 10.x.v.1. > ntpq> as > ind assID status conf reach auth condition last_event cnt ========================= ========================= ========= > 1 29028 9514 yes yes none dist.peer reachable 1 Association 1 is being rejected because the root dispersion is too high. > 2 29029 9414 yes yes none synchr. reachable 1 > status=9514 reach, conf, sel_sys.peer, hi_dist, 1 event, event_reach Note the hi_dist flag. That's telling you that the rootdispersion is too high, and the server is therefore unacceptable. > srcadr=windows-dc-serverA, srcport=123, dstadr=10.x.y.4, > dstport=123, keyid=0, stratum=4, precision=-6, rootdelay=31.25, > rootdispersion=10120.09, refid=10.x.v.1, delay=0.31, offset=0.89, rootdispersion, and therefore root distance, is greater than the maximum allowed 1 second. > dispersion=3.42, reach=377, valid=8, hmode=3, pmode=4, hpoll= > 10, > ppoll=10, leap=00, flash=0x0<OK>, > status=9414 reach, conf, sel_sync, 1 event, event_reach > srcadr=windows-dc-serverB, srcport=123, dstadr=10.x.y.4, > dstport=123, keyid=0, stratum=4, precision=-6, rootdelay=31.25, > rootdispersion=10113.86, refid=10.x.v.1, delay=0.44, offset=-1.45 , This root dispersion is also more than 9 seconds greater than permitted. > dispersion=2.61, reach=377, valid=8, hmode=3, pmode=4, hpoll= > 10, > ppoll=10, leap=00, flash=0x0<OK>, Basically, you should never use W32Time to serve time to a real NTP client, although I still don't understand why Solaris isn't reporting stratum 16. Did you do anything to force the use of that server? In this context, W32Time reports a true root dispersion when unsychronised, including being "synchronised" to its local clock, whereas ntpd should go into alarm in the first case, and gives an extremely optimistic distance in the second case. > Thanks for your help. > -- > Mit freundlichen Grüßen > Ronny Egner > Diplom-Ingenieur (BA) > Systeme & Service > Oracle DBA > Telefon: +49 381 2524-422 > Telefax: +49 381 2524-399 > SIV.AG - Service für Informationsverarbeitung AG > Hauptsitz: Konrad-Zuse-Str. 1, 18184 Roggentin > Handelsregister: Amtsgericht Rostock, HRB 8677, Ust.-IdNr.: DE 137477226 > Vorstand: Jörg Sinnig (Vorsitzender), Andreas Lehmann, Arno Weichbrodt > Aufsichtsratsvorsitzender: Thomas Huth > ************************************************************************* > Aus Rechtsgründen ist die in dieser E-Mail gegebene Information nicht > rechtsverbindlich. Eine rechtsverbindliche Bestätigung reichen wir > Ihnen auf Anforderung in schriftlicher Form nach. Diese Nachricht ist > ausschließlich für den Adressaten oder dessen Vertreter bestimmt. > The information contained in this email is not legally binding. > At your request, we will provide you with a legally binding confirmation > in written form. This message is intended solely for the addressee, > entity to which the email is addressed or the authorised agent. The entity to which this is addressed, is, of course, the whole universe. > ************************************************************************* (The mail problem may well be with the gateway. This list isn't really a mailing list; it is really a newsgroup, and the gateway provides a convenience for accessing the newsgroup where firewalls on unenlightened ISPs make accessing the group difficult. On USENET discussion groups, binary attachments are strictly forbidden (they are abused to transmit large files, which often violate copyright), so, although cryptographic signatures are actually tolerated, the gateway has stripped the signature. It is possible that, in doing so, it has failed to copy the rest of the message in a fully transparent manner. I wonder if the reason that the original didn't make it onto USENET is related.) _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
