Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
ntp / frequency error exceeds tolerance 500 / Sun Blade 100
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo on Sparc
View previous topic :: View next topic  
Author Message
w.hill
Tux's lil' helper
Tux's lil' helper


Joined: 23 Jan 2005
Posts: 133
Location: Perth, Western Australia

PostPosted: Wed Nov 19, 2008 1:56 am    Post subject: ntp / frequency error exceeds tolerance 500 / Sun Blade 100 Reply with quote

Hi,

I'm running NTPD Ver. 4.2.4p5 on a Sun Blade 100 2.6.26.7

I'm getting a huge offset (see below) and a drift rate > than NTP can correct. 'frequency error 672 PPM exceeds tolerance 500'. It appears as though the error is bigger than NTPD can correct.

'Googling' about it would appear that there was a problem with the system clock of Sun Blade 100s and some other Sun boxes of the same era. Sun released a SOLARIS patch to fix the problem but I can't find a solution under LINUX.

Does anyone else have a Sun with the same problem? Have you found a fix?

TIA

atlas ~ # ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.6.2 121.94.159.255 2 u 40 64 377 0.332 45320.0 149.166
192.168.6.1 132.237.215.255 2 u 22 64 377 0.368 45122.0 182.936
+202.60.65.243 128.250.36.2 2 u 129 64 376 85.482 45291.5 123.218
+192.189.54.33 128.250.37.2 2 u 41 64 377 65.122 45230.7 104.509
+192.189.54.17 128.250.37.2 2 u 55 64 377 55.836 45138.0 151.887
*202.60.94.15 128.250.36.3 2 u 9 64 357 80.266 45290.7 131.936
Back to top
View user's profile Send private message
hvengel
Guru
Guru


Joined: 19 Sep 2004
Posts: 515

PostPosted: Sun Nov 23, 2008 11:19 pm    Post subject: Reply with quote

The max tolerance is set in <ntp-source-tree>/include/ntp_proto.h by

#define NTP_MAXFREQ 500e-6

One possible "fix" would be to change this to a higher values so that ntp does not panic on your system. You might consider changing this to:

#define NTP_MAXFREQ 700e-6

before building your ntp and this should allow ntp to work. The main reason for the 500PPM limit is more as a sanity check as ntpd will actually work with higher frequency offsets. The author of the ntp code would likely say something about the code possibly not being stable with larger frequency offsets but you are close to 500 PPM so it will likely be OK. It is is not stable you will know it soon enough.

Looking at your ntpq output I see some other things that might be issues. For example you jitter numbers are in the 100 to 180 milliseconds range. This is way too much and is an indication of a serious problems either with your network connection or your selected ntp servers. You should be seeing jitter numbers that are closer to 1 millisecond. Your offsets are also very high at around 45 seconds. It appears that you have two ntp servers on your local network (192.168.6.2 and 192.168.6.1). Do these servers also have high jitter and offset numbers?
Back to top
View user's profile Send private message
w.hill
Tux's lil' helper
Tux's lil' helper


Joined: 23 Jan 2005
Posts: 133
Location: Perth, Western Australia

PostPosted: Thu Nov 27, 2008 8:43 am    Post subject: Reply with quote

Hi,

I'm running the same version of ntpd on an Ultra 5 attached to the same switch so the network can't be a problem.

I suppose there could be a problem with the SunBlade's NIC driver

I recompile NTPD and see what happens.



athena ~ # ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*203.80.162.195 128.250.36.2 2 u 131 512 377 79.578 4.403 1.927
-202.81.208.37 203.109.252.32 3 u 109 512 377 17.309 -9.286 3.506
+203.161.84.63 128.250.36.2 2 u 81 512 377 71.656 5.902 0.267
+202.60.94.15 128.250.36.2 2 u 121 512 377 94.685 7.064 1.321
Back to top
View user's profile Send private message
hvengel
Guru
Guru


Joined: 19 Sep 2004
Posts: 515

PostPosted: Thu Nov 27, 2008 9:39 pm    Post subject: Reply with quote

Did you alter the NTP_MAXFREQ value?

Things are looking better with your current setup. All of your offsets are < 10 milliseconds which is not too bad but it might be possible to make some additional improvements. In addition your jitter numbers are much improved and are about as good as you can expect when using Internet time servers. Your delay numbers are a little high and you might get these down by selecting better servers. I currently use a local reference clock so I am used to seeing very low delay, offset and jitter numbers but back when I used Internet time servers I was able to locate a good set of them were my delay numbers were all < 20 milliseconds. This improved my offsets to the 1 to 3 millisecond range which is about as good as you can get using Internet based time servers.

You might also consider using one of your servers as your primary time server and have all of your other servers sync to it. This will reduce Internet traffic since only one server will be talking to the remote time servers (I am sure that the owners of those servers would rather that only one machine from you network was hitting them). Since your other servers would be talking to the single local master time server over local network connections they would still be nearly as accurate because of very low delay and jitter numbers.
Back to top
View user's profile Send private message
w.hill
Tux's lil' helper
Tux's lil' helper


Joined: 23 Jan 2005
Posts: 133
Location: Perth, Western Australia

PostPosted: Fri Nov 28, 2008 5:31 am    Post subject: Reply with quote

I did alter the NTP_MAXFREQ to 700e- as suggested.

I've modified /etc/ntp/conf to point only to local PCs. 192.168.6.2 and 192.168.6.1 are both gateway PCs (redundant links). 6.6 is the Ultra 5 host which also functions as a DNS server

The SunBlade 100 server requires constant adjustments by ntpd - approximately +0.7s / 15 minutes (see below). It is under no load (standby DNS)

Regards.

atlas ~ # ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.6.6 203.80.162.195 3 u 26 64 177 0.264 27.587 189.257
192.168.6.2 202.209.39.255 2 u 8 64 177 0.350 257.354 185.158
192.168.6.1 195.249.143.255 2 u 63 64 77 0.335 87.409 92.940

Nov 28 09:25:58 atlas ntpd[16472]: time reset +0.835382 s
Nov 28 09:41:12 atlas ntpd[16472]: time reset +0.706536 s
Nov 28 09:56:33 atlas ntpd[16472]: time reset +0.677025 s
Nov 28 10:12:16 atlas ntpd[16472]: time reset +0.711286 s
Nov 28 10:30:27 atlas ntpd[16472]: time reset +0.769547 s
Nov 28 10:46:58 atlas ntpd[16472]: time reset +0.717370 s
Nov 28 09:25:58 atlas ntpd[16472]: time reset +0.835382 s
Nov 28 09:41:12 atlas ntpd[16472]: time reset +0.706536 s
Nov 28 09:56:33 atlas ntpd[16472]: time reset +0.677025 s
Nov 28 10:12:16 atlas ntpd[16472]: time reset +0.711286 s
Nov 28 10:30:27 atlas ntpd[16472]: time reset +0.769547 s
Nov 28 10:46:58 atlas ntpd[16472]: time reset +0.717370 s
Nov 28 11:02:53 atlas ntpd[16472]: time reset +0.744804 s
Nov 28 11:18:03 atlas ntpd[16472]: time reset +0.679185 s
Nov 28 11:34:46 atlas ntpd[16472]: time reset +0.737159 s
Nov 28 11:51:24 atlas ntpd[16472]: time reset +0.724038 s
Nov 28 12:06:46 atlas ntpd[16472]: time reset +0.710266 s
Nov 28 12:22:04 atlas ntpd[16472]: time reset +0.699052 s
Nov 28 12:40:24 atlas ntpd[16472]: time reset +0.794090 s
Nov 28 12:57:52 atlas ntpd[16472]: time reset +0.747360 s
Nov 28 13:13:34 atlas ntpd[16472]: time reset +0.728311 s
Nov 28 13:31:51 atlas ntpd[16472]: time reset +0.793089 s
Nov 28 13:50:09 atlas ntpd[19872]: time reset +0.195444 s
Nov 28 14:06:39 atlas ntpd[19872]: time reset +0.728655 s
Nov 28 14:23:30 atlas ntpd[19872]: time reset +0.742949 s

Nov 28 11:02:53 atlas ntpd[16472]: time reset +0.744804 s
Nov 28 11:18:03 atlas ntpd[16472]: time reset +0.679185 s
Nov 28 11:34:46 atlas ntpd[16472]: time reset +0.737159 s
Nov 28 11:51:24 atlas ntpd[16472]: time reset +0.724038 s
Nov 28 12:06:46 atlas ntpd[16472]: time reset +0.710266 s
Nov 28 12:22:04 atlas ntpd[16472]: time reset +0.699052 s
Nov 28 12:40:24 atlas ntpd[16472]: time reset +0.794090 s
Nov 28 12:57:52 atlas ntpd[16472]: time reset +0.747360 s
Nov 28 13:13:34 atlas ntpd[16472]: time reset +0.728311 s
Nov 28 13:31:51 atlas ntpd[16472]: time reset +0.793089 s
Nov 28 13:50:09 atlas ntpd[19872]: time reset +0.195444 s
Nov 28 14:06:39 atlas ntpd[19872]: time reset +0.728655 s
Nov 28 14:23:30 atlas ntpd[19872]: time reset +0.742949 s
Back to top
View user's profile Send private message
hvengel
Guru
Guru


Joined: 19 Sep 2004
Posts: 515

PostPosted: Sat Nov 29, 2008 7:12 pm    Post subject: Reply with quote

It is better than it was but is still having major issues. ntp should only need to make a step adjustment when it first starts and the fact that it is doing this about every 15 minutes is an indication that something is very wrong. By default ntpd will make step adjustments when the time is off by more than 128 milliseconds. When you do an ntpq -c rv what is the frequency? I have a gut feeling that it will be 700PPM. If that is the case then you need to make a bigger adjustment to NTP_MAXFREQ but at best this "fix" is a hack. An error of 2.8 sec/hour (0.7 secs/ 15 minutes) is on the order of 900PPM and if ntp has an adjustment of 700PPM in place then uncorrected raw clock frequency is off by about 1600PPM (or more). Not good. Those who are "time nuts" try to find machines that will drift by less than 40PPM when free running (IE. no ntp) and preferably under 20PPM. Machines with higher levels of free running drift are generally not good time keepers and your machine is way outside of the normal range (Ie. almost all machines are <100PPM).

Have you checked the kernel bugzilla to see if there are any bugs open for this issue? Also I know that there has been lots of work on time/timing/timer code in the kernel over the past year or so and that there is lots of work in this area being done right now. For example 2.6.26 is the first Linux kernel to be a nanosecond kernel and there is a chance the the LinuxPPS patches will become part of 2.6.29. I don't know what version of the kernel you are running but perhaps a newer version would work better. If not perhaps you should open a bug report if there is not one already. Also if there is an open bug report for this there is a chance that you will be able to find a patch.

Also what clock source is being used by the system? Run these to find out which clock you are using and what clock sources are available.

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

If the current clock source is the tsc clock you might be having issues with power management messing with the clock. Since you mentioned that the machine is lightly loaded and the clock is running way too slow this is a very real possibility. No matter what clock source is being used you should try other clock sources to see if this improves things. In general these should be preferred in this order:

tsc - if you have an invariant tsc timer - newer processors or processors with no power management features.
hpet
acpi_pm
pit
jiffies

To change to the hpet timer you would do this:

echo -n "hpet" > /sys/devices/system/clocksource/clocksource0/current_clocksource

For some of these timers you might need to change your kernel configuration to make them available and you might also need to change your kernel boot parms. Only the tsc timer could be affected by power management all of the others should keep relatively constant time no matter what power mode the processor is in. The big advantages of the tsc timer is that it has higher resolution than the others (some have a resolution of less than 1 nanosecond) and has much lower (on the order of 1000 to 1) CPU overhead to read. But these advantages are only relevant if the timer is power state invariant. In some cases turning off power management features will make the tsc timer invariant.
Back to top
View user's profile Send private message
w.hill
Tux's lil' helper
Tux's lil' helper


Joined: 23 Jan 2005
Posts: 133
Location: Perth, Western Australia

PostPosted: Wed Dec 03, 2008 11:12 pm    Post subject: Reply with quote

Hi,

atlas ~ # ntpq -c rv
assID=0 status=c011 sync_alarm, sync_unspec, 1 event, event_restart,
version="ntpd 4.2.4p5@1.1541-o Thu Nov 27 08:58:00 UTC 2008 (1)",
processor="sparc64", system="Linux/2.6.26.7", leap=11, stratum=16,
precision=-19, rootdelay=0.000, rootdispersion=2.325, peer=0,
refid=INIT, reftime=00000000.00000000 Thu, Feb 7 2036 14:28:16.000,
poll=6, clock=cce18d0a.92da7aef Thu, Dec 4 2008 7:56:10.573, state=1,
offset=0.000, frequency=500.000, jitter=0.002, noise=0.002,
stability=0.000, tai=0

atlas ~ # uname -a
Linux atlas 2.6.26.7 #2 Wed Nov 19 16:09:46 WST 2008 sparc64 sun4u TI UltraSparc IIe (Hummingbird) GNU/Linux

atlas ~ # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hbtick

atlas ~ # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
hbtick jiffies

When I tried to change to 'jiffies' the server locked up & had to be powered down. I'll have to examine more closely the kernel settings for the various timers.

W.
Back to top
View user's profile Send private message
Weeve
Retired Dev
Retired Dev


Joined: 30 Oct 2002
Posts: 641

PostPosted: Mon Dec 15, 2008 6:04 pm    Post subject: Reply with quote

I've noticed that SPARC systems often are quite good at having time creep in this fashion (even with Solaris IIRC). To help combat this in the past, I've used ntp plus a daily cron job to change the time to match the NTP server's time, in case the creep has gotten too bad.
Back to top
View user's profile Send private message
hvengel
Guru
Guru


Joined: 19 Sep 2004
Posts: 515

PostPosted: Sun Dec 21, 2008 11:56 pm    Post subject: Reply with quote

Weeve wrote:
I've noticed that SPARC systems often are quite good at having time creep in this fashion (even with Solaris IIRC). To help combat this in the past, I've used ntp plus a daily cron job to change the time to match the NTP server's time, in case the creep has gotten too bad.


Doing this is a desperate action to take. This causes your system time to jump and if it jumps backwards it can cause processes that need the system time to be monotonic to have problems. You should be raising hell with the hardware vendor over this issue if it is in fact as wide spread as you say it is. FYI the correct term is drift not creep.

I notice that the OP is using kernel version 2.6.26.7. Starting with version 2.6.26 the linux kernel went from being a micro second kernel to being a nano second kernel. The issue is that glibc contains the time related headers that are used by ntp and glibc has not changed it's time related headers since linux was verion 2.2.something. So glibc is out of sync with these newer kernels. When ntp is built using the older timex.h headers from glibc with a newer kernel ntp will be trying to make adjustments that are off by 3 orders of magnitude. It may not have much affect on your issue but have you tried using a slightly older kernel (anything before the 2.6.26 series)?

I think that this problem could be adjusted in the kernel if you didn't mind hacking it. There was a long thread earlier this year on the kernel mailing list dealing with issues related to clock tick granularity and incorrect clock rates. The thread is long and contentious but it does have some patches that relate to this (perhaps indirectly) that may point you to the correct place to do what needs to be done. It can be located here:

http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-02/msg05432.html

You might also consider contacting one of those involved in the thread to see if perhaps they can help you patch up your kernel and perhaps also make those patches part of some future kernel release.
Back to top
View user's profile Send private message
Aiken
Tux's lil' helper
Tux's lil' helper


Joined: 22 Jan 2003
Posts: 141
Location: Toowoomba/Australia

PostPosted: Sun Jan 04, 2009 3:04 am    Post subject: Reply with quote

hvengel wrote:
When ntp is built using the older timex.h headers from glibc with a newer kernel ntp will be trying to make adjustments that are off by 3 orders of magnitude.


There is a flag that is used to tell the kernel if the offset being given is micro or nano. The kernel will scale the offset if need be. With the blade 100 it does not seem to be hard to find information saying they have bad clocks.

Code:

ntptiime -f 0; tickadj <desired-value>; ntpdate -b ntp-server; sleep 100; ntpdate -b ntp-server


Multitply the offset given by the 2nd ntpdate by 10000 and you have a rough estimate of the drift. Below are various values given to tickadj with the approximate drift rates I get on my blade 100. This is done with ntp not running.

Code:

10000  1179.51
10001  1080.96
10002  980.85
10003  880.97
10004  780.55
10005  680.78
10006  580.38
10007  480.07
10008  379.9
10009  280.06
10010  179.87
10011  79.77
10012  -19.97
10013  -120.1
10014  -220.19


I do "tickadj 10012" at boot time. Ntp is reporting a drift of -20.2. Currently using a 2.6.26-gentoo-r1 kernel.

edit: replaced ultra 100 with blade 100

edit2: Last night I put freebsd 7.1 on my blade 100. The drift was 398. Even if 2.6.26 adds a static component to the drift value as per the link hvengel gave, the clock is still border line with freebsd. My time server has a 2.6.24 kernel and it did have the static component in the drift value as per that thread.
_________________
Beware the grue.
Back to top
View user's profile Send private message
hvengel
Guru
Guru


Joined: 19 Sep 2004
Posts: 515

PostPosted: Fri Jan 09, 2009 9:26 pm    Post subject: Reply with quote

Aiken wrote:
hvengel wrote:
When ntp is built using the older timex.h headers from glibc with a newer kernel ntp will be trying to make adjustments that are off by 3 orders of magnitude.


There is a flag that is used to tell the kernel if the offset being given is micro or nano. The kernel will scale the offset if need be. With the blade 100 it does not seem to be hard to find information saying they have bad clocks.


Yes there is a flag that allows ntp and the kernel to agree if things are nano or micro. But at least with the current nanosecond linux kernels with a micro only ntp (IE. ntp build with an unpatched version of glibc) the clock is not very stable. The instability probably will not be apparent if you are using public Internet ntp servers as your time source since this will typically result in offsets that are significantly larger than the error introduced by this issue. But if you are using a high accuracy local reference clock like a GPS the problem is apparent and the time will swing back and forth across a zero offset by about 500 microseconds. With ntp compiled to work in nanosecond mode (IE. using a patched glibc) this is reduced to around +-20 microseconds max and it is usually less.

For the OP's server rootdispersion=2.325 which it typical when using public Internet time servers. Rootdispersion is a measure of the amount of variance or noise in the time source. This is caused by things like variable network latency, asymmetric network delays and other factors. In this case it is about 2.3 milliseconds. With a correctly setup local reference clock/glibc/ntp this will be closer to 0.35 most of the time. For example this is a machine running a LinuxPPS patched 2.6.26 kernel, a nano second patched glibc and using a Motorola Oncore UT+ reference clock:

Code:
# ntpq -c rv
associd=0 status=0455 leap_none, sync_uhf_radio, 5 events, clock_sync,
version="ntpd 4.2.5p135@1.1793-o Thu Nov 27 01:49:13 UTC 2008 (6)",
processor="x86_64", system="Linux/2.6.26-gentoo", leap=00, stratum=1,
precision=-22, rootdelay=0.000, rootdisp=0.348, refid=GPS,
reftime=cd123024.3930c40a  Fri, Jan  9 2009 12:20:52.223,
clock=cd12302b.5e251d64  Fri, Jan  9 2009 12:20:59.367, peer=33061,
tc=4, mintc=3, offset=0.005, frequency=-39.255, sys_jitter=0.007,
clk_jitter=0.002, clk_wander=0.000

# ntptime
ntp_gettime() returns code 0 (OK)
  time cd1230b7.667c3910  Fri, Jan  9 2009 12:23:19.400, (.400333067),
  maximum error 1742 us, estimated error 1 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -5.897 us, frequency -39.255 ppm, interval 1 s,
  maximum error 1742 us, estimated error 1 us,
  status 0x2001 (PLL,NANO),
  time constant 4, precision 0.001 us, tolerance 500 ppm,


As you can see the offset in the above ntp querys is less than 6 microseconds and rootdispersion is close to 0.35. This system is close to the bleeding edge as far as time keeping on Linux is concerned. In this case rootdispersion mainly reflects things like variable latencies in the PPS interrupt handler and temperature fluctuations that affect the quartz oscillator on the computer motherboard which is probably the biggest factor affecting this. The reference clock PPS pulses are +-50 nanoseconds of the UTC seconds epoch which is almost two orders of magnitude below the other factors that affect rootdispersion.

I have run this same basic system with both a stock glibc and a nanosecond patched glibc and this is where I am getting my +-500 microsecond offset number from. Most of those using the LinuxPPS patchs have seen similar results and the general consensus is that these newer kernels need a nano second patched glibc and an ntp built against this version to give optimum timekeeping results.

Aiken wrote:

Code:

ntptiime -f 0; tickadj <desired-value>; ntpdate -b ntp-server; sleep 100; ntpdate -b ntp-server


Multitply the offset given by the 2nd ntpdate by 10000 and you have a rough estimate of the drift. Below are various values given to tickadj with the approximate drift rates I get on my blade 100. This is done with ntp not running.

Code:

10000  1179.51
10001  1080.96
10002  980.85
10003  880.97
10004  780.55
10005  680.78
10006  580.38
10007  480.07
10008  379.9
10009  280.06
10010  179.87
10011  79.77
10012  -19.97
10013  -120.1
10014  -220.19


This is good to know.
Back to top
View user's profile Send private message
Aiken
Tux's lil' helper
Tux's lil' helper


Joined: 22 Jan 2003
Posts: 141
Location: Toowoomba/Australia

PostPosted: Sun Jan 11, 2009 3:22 pm    Post subject: Reply with quote

hvengel wrote:

Yes there is a flag that allows ntp and the kernel to agree if things are nano or micro. But at least with the current nanosecond linux kernels with a micro only ntp (IE. ntp build with an unpatched version of glibc) the clock is not very stable. The instability probably will not be apparent if you are using public Internet ntp servers as your time source since this will typically result in offsets that are significantly larger than the error introduced by this issue. But if you are using a high accuracy local reference clock like a GPS the problem is apparent and the time will swing back and forth across a zero offset by about 500 microseconds. With ntp compiled to work in nanosecond mode (IE. using a patched glibc) this is reduced to around +-20 microseconds max and it is usually less.


It is not just current kernels and a micro ntp. The slow convergence goes back to 2.6.18 and the offsets you are complaining about were not uncommon. Great for dialup but I really disliked it when using pps. 2.6.17 and earlier could react quite quickly.

If your offset is 2345 and STA_NANO is set then 2345 is used. If STA_NANO is not set then 2 * NSEC_USEC (ie 2000) will be used. I don't see that making a lot of difference. All I can think of at this late hour is ntp gives the kernel different time constants to use depending on nano (time constant unmodified) or micro (ntp time constant - 4). For micro the kernel then adds 4. With micro the kernel is not using the time constant that ntp is telling it. The time I modified the kernel so that it used the time constant it was given with micro I found convergence was much better.

As for a glibc patch I did not do much for nano support in ntp. All I did was add STA_NANO and friends the the glibc sys/timex.h. This is with a garmin gps25, unpatched (except for timex.h) glibc 2.6.1 and a 2.6.24 kernel + linuxpps + other mods.

Code:

assID=0 status=2154 leap_none, sync_atomic/PPS, 5 events, event_peer/strat_chg,
version="ntpd 4.2.4p5@1.1541-o Wed Dec  3 06:34:39 UTC 2008 (1)",
processor="i686", system="Linux/2.6.24-dirty", leap=00, stratum=1,
precision=-20, rootdelay=0.000, rootdispersion=0.306, peer=38437,
refid=PPS, reftime=cd145d48.d5674fab  Sun, Jan 11 2009 21:58:00.833,
poll=10, clock=cd145d4d.ca02d337  Sun, Jan 11 2009 21:58:05.789,
state=4, offset=0.001, frequency=-0.921, jitter=0.001, noise=0.001,
stability=0.000, tai=0

ntp_gettime() returns code 0 (OK)
  time cd145d4d.0033e790  Sun, Jan 11 2009 21:58:05.000, (.000792568),
  maximum error 3058 us, estimated error 0 us
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 0.566 us, frequency -0.921 ppm, interval 1 s,
  maximum error 3058 us, estimated error 0 us,
  status 0x2001 (PLL,NANO),
  time constant 2, precision 0.001 us, tolerance 512 ppm,


Back onto the original topic. My blade is being put back into use and I am watching the stability of the clock after using tickadj. The only thing I have seen so far is the effects of it being in a room that changes by 10 - 15C during the day. Based on the tickadj data I have previously posted for my blade I used tickadj 10012.

hvengel, where that thread you linked to really bit me was with my alpha. Drift was 210ppm or so and when that problem was introduced it changed to high 490s' A hot day would have it hitting the limit of what ntp could handle.
_________________
Beware the grue.
Back to top
View user's profile Send private message
w.hill
Tux's lil' helper
Tux's lil' helper


Joined: 23 Jan 2005
Posts: 133
Location: Perth, Western Australia

PostPosted: Fri Dec 04, 2009 6:44 am    Post subject: Reply with quote

Hi,

Thanks to everyone for all the help above. After much experimentation I arrived at: tick = 10007 -- (Somewhere between 10007 and 10008)

on: Linux atlas 2.6.30-gentoo-r8 #3 Mon Nov 30 11:25:20 WST 2009 sparc64 sun4u TI UltraSparc IIe (Hummingbird) GNU/Linux

Using: ntpd 4.2.4p7@1.1607-o

What should I do to ensure that the tick time is persistent between reboots? Not that they occur that often. Is there a kernel header file I can alter || can it be done at boot time?

Thanks.
Back to top
View user's profile Send private message
Aiken
Tux's lil' helper
Tux's lil' helper


Joined: 22 Jan 2003
Posts: 141
Location: Toowoomba/Australia

PostPosted: Fri Dec 04, 2009 8:15 am    Post subject: Reply with quote

One thought is add it /etc/conf.d/local.start

Seems to be a place to add programs you want run at start up.
_________________
Beware the grue.
Back to top
View user's profile Send private message
w.hill
Tux's lil' helper
Tux's lil' helper


Joined: 23 Jan 2005
Posts: 133
Location: Perth, Western Australia

PostPosted: Sat Dec 05, 2009 3:55 am    Post subject: Reply with quote

That worked.

Thanks.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on Sparc All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum