Okay all, I'm stumped here. We patched 6 5120's yesterday. 2 in our test environment and 4 in our production space. After patching the test systems with 136932-01, our offset dropped to .04, we then proceded to patch the production systems as an emergency outage. The result: 1 system is now accurate to .02 offset, the others have remained at 30-50ms offset with high levels of pll offset.
All servers are running ntp daemon 4.2.4p4. I have attached system info for the 4 servers in question. Servers 1,3, and 4 are still showing problems while server 2 is where I expect it to be. The layout of the file is: Control Domain info (kernel info, patch info, NTP info) Guest LDOM info (NTP.conf, xntpdc kerninfo, ntpq -c peers results). The only variant between the "working" system and the non working is that we are not running the ntp daemon on the control ldom on the working machine but I don't know that this would be a problem. Any guidance as to my next steps? Thanks, Greer On 4/14/08, Steffen Weiberle <Steffen.Weiberle at sun.com> wrote: > > Greer Reichow wrote: > > > Thanks for the help. Can anyone give me the firmware patch number to > > make sure I have the right one? > > > > For LDom 1.0.2, I am in the process of testing 136932-01 for the T5x20. > > I believe the T2000 one is 136927-01. The numbers are listed on the LDom > 1.0.2 download page. > > Note, these are 1.0.2 patches, not 1.0.1. I was running 1.0.2 with the > 1.0.1 patch, as 136932-01 had not been released yet. > > Steffen > > > > Thanks again, > > Greer > > > > On 4/13/08, *Kevin Rathbun* <Kevin.Rathbun at sun.com <mailto: > > Kevin.Rathbun at sun.com>> wrote: > > > > On Sun, Apr 13, 2008 at 03:05:49PM -0400, Steffen Weiberle wrote: > > > Greer Reichow wrote: > > > > All, > > > > I've come across aan interesting problem I'm hoping someone > > has seen > > > > > > > > I have the following in a development environment: > > > > 1)T2000 - 8 core, 32GB RAM > > > > 2)T5120 - 8 core, 32GB RAM > > > > 3)Symmetricom S250 GPS NTP Server > > > > > > > > Both the T2k & 5120 are built off the same jumpstart images > > (solaris 08/07) with ~ 4 ldoms each. Each LDOM is configured with > > 4CPUs and 2 GB RAM. We are running ntp client version 4.2.4 > > downloaded from sunfreeware.com <http://sunfreeware.com>. LDOM > > level is 1.0.1 currently > > > > > > > > Each LDOM on both machines is running the same ntp.conf file: > > > > server <ip> minpoll 4 maxpoll 4 prefer > > > > driftfile /var/ntp/ntp.drift > > > > > > > > While I know this wouldn't be ideal in a large deployment, the > > fact that I have a private DNS stratum 1 server and few clients > > allows me to set the time polling fairly tight. > > > > > > > > Here is the interesting part: > > > > Results of ntpq -c peers > > > > > > > > 5120: > > > > delay offset disp > > > > .061 37.037 0.12 > > > > > > > > T2000: > > > > delay offset disp > > > > .062 .04 0.14 > > > > > > > > Why am I getting such disparate results in offset? The project > > I'm developing this for has very strict timing requirements that the > > T2000 seems to meet (< 10ms accuracy) that the newer 5120 doesn't > > meet. Has anyone seen something similar? Right now this is > > pointing at a hardware issue, but I want to eliminate the ldom code > > as a problem > > > > > > There are clock drifts on the systems that are greater than what > > NTP can > > > handle. Came across this myself just last week. > > > > > > There are /etc/system settings described in Change Request > > 6630235 based > > > on CPU clock frequency. > > > > > > I am looking for a public document that describes these. > > > > > > Not sure about a public doc but here's other info. > > > > 6682970 Clock drift on N2 platforms (Glendale, Monza & Turgo) due to > > spread spectrum > > 6676309 Clock drift in Huron due to spread spectrum > > > > http://blogs.sun.com/blu/entry/spread_spectrum_emi_and_the > > > > kvn > > > > > > > > > > > > Steffen > > > > > > > Thanks, > > > > Greer > > > > -- > > > > This message was posted from opensolaris.org > > <http://opensolaris.org> > > > > _______________________________________________ > > > > ldoms-discuss mailing list > > > > ldoms-discuss at opensolaris.org > > <mailto:ldoms-discuss at opensolaris.org> > > > > http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss > > > > > > _______________________________________________ > > > ldoms-discuss mailing list > > > ldoms-discuss at opensolaris.org <mailto: > > ldoms-discuss at opensolaris.org> > > > http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > ldoms-discuss mailing list > > ldoms-discuss at opensolaris.org > > http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/ldoms-discuss/attachments/20080415/abd98e63/attachment.html> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 5120_server1_bad.txt URL: <http://mail.opensolaris.org/pipermail/ldoms-discuss/attachments/20080415/abd98e63/attachment.txt> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 5120_server2_good.txt URL: <http://mail.opensolaris.org/pipermail/ldoms-discuss/attachments/20080415/abd98e63/attachment-0001.txt> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 5120_server3_bad.txt URL: <http://mail.opensolaris.org/pipermail/ldoms-discuss/attachments/20080415/abd98e63/attachment-0002.txt> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 5120_server4_bad.txt URL: <http://mail.opensolaris.org/pipermail/ldoms-discuss/attachments/20080415/abd98e63/attachment-0003.txt>
