DSM-G600, DNS-3xx and NSA-220 Hack Forum

With 9965, I get a drift around 300. I don't know the details, only that a perfect clock has 10000 ticks a day. If a positive drift means your clock is going too fast, you should try larger tick values to lengthen the day. Did you try 9965?

I was poking around at this myself, and this page has some useful info: (the man page for adjtimex)

http://gd.tuwien.ac.at/linuxcommand.org … imex8.html

I also found this comment interesting:

For a machine connected to the Internet, or equipped with a precision oscillator or radio clock, the best way is to regulate the system clock with ntpd.  The kernel will automatically update the hardware clock every eleven minutes.

Maybe it's not even worth fussing with adjtimex if you're running ntpd?

Here's some additional advice on choosing good adjtimex values:

If your system clock gained 8 seconds in 24 hours, you could set the tick to 9999, and then it would lose 0.64 seconds a day (that is, 1 tick unit = 8.64 seconds per day). To correct the rest of the error, you could set the frequency offset to (2^16)*0.64/.0864 = 485452. Thus, putting the following in rc.local would approximately correct the system clock:

Code:

adjtimex  --tick 9999  --freq 485452

I am using ntpd on both my DNS-323's and it does a pretty good job. No need for adjtimex.

The ntpd keeps record of the clock drift and also evaluates the variations in the drift. If the drift changes frequently then it connects at shorter intervals to the Internet time servers.

There is another issue related to the accuracy of the Stratum 2 clocks, in previous versions of ntpd the accuracy caused the clock to drift by up to 50ms, I think the algorithm has been improved and it is down to 5 ms now.

DNS-323 internal clock is unfortunately quite challenging for ntpd, it is both off the real time and drifting with temperature- I think that D-link did not bother to use temperature compensation.

Compare the following reports, first the master LAN clock server temperature compensated clock:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+87.232.1.41     195.177.253.180  3 u  205 1024  377   49.872   -8.228   3.901
+87.32.0.19      193.120.10.3     2 u  222 1024  377   47.413   -1.571   0.756
87.32.8.19      .INIT.          16 u    - 1024    0    0.000    0.000   0.000
127.127.1.0     .LOCL.          10 l   29   64  377    0.000    0.000   0.001
*134.226.81.3    .GPS.            1 u  279 1024  377   47.991   -3.741   0.052


Note the difference to the DNS-323- the offset is very high and also the jitter is double or even 4 times the reference LAN time server.

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.111.254 134.226.81.3     3 u  367 1024  377    0.156  105.980   6.824
127.127.1.0     .LOCL.          10 l   61   64  377    0.000    0.000   0.008

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.111.254 134.226.81.3     3 u  736 1024  377    0.152   77.342  15.791
127.127.1.0     .LOCL.          10 l   51   64  377    0.000    0.000   0.008


Edit: Just re-read you posts: ntpd uses clock skew do adjust the clock offset so it is incorrect that it fixes the time only at the time sync intervals.

Last edited by skydreamer (2008-10-16 11:35:10)

fonz wrote:

Without adjtimex, the drift hits the limit (+/- 500), resulting in periodic step adjustments (too much drift to compensate smoothly).

I would dare to disagree, there is no evidence from ntpq of that. Initially the ntpd may be wobbly before it checks out the host sytem clock but it settles down after a week and works fine from there on.

Then again I can only comment on my existing hardware there might be some misbehaving boxes out there plus I have modded mine in terms of cooling and this is probably the single biggest reason for clock variations.

Thanks for all the input... definitely a learning exercise.  I'm finding that ntpd on the DNS-323 is keeping the clock far better than the Windows client machines - which appear to only update clock from internet timeservers about once a week.

I can see the temperature fluctuations on the DNS very clearly.  I'm running ffp from USB disk now and the unit powers down disks during periods of inactivity (mostly night). I've got the fan control script shutting the fan off completely when temp drops below 100F. So the unit runs anywhere from about 95F (everything off) to 110F (disks spining and under heavy use).

Thanks...

I knew there was likely someplace in the registry to change the ntp behavior... Just hadn't gone the extra step to research it.

I appreciate you offering the info.

- Jim

Yes; I see the sync errors. However, I never see the "offset" messages; only "synchronized" messages.

Probably need to change logging options in the ntp.conf file?

Nov  5 14:34:38 NAS01 daemon.notice ntpd[1890]: kernel time sync error 0001
Nov  5 14:40:00 NAS01 cron.notice crond[1696]: USER root pid 20103 cmd /usr/sbin/getdhcp&
Nov  5 14:50:01 NAS01 cron.notice crond[1696]: USER root pid 20183 cmd /usr/sbin/getdhcp&
Nov  5 14:52:23 NAS01 daemon.info ntpd[1890]: synchronized to 64.202.112.65, stratum 2             <===== ***
Nov  5 15:00:01 NAS01 cron.notice crond[1696]: USER root pid 20249 cmd /usr/sbin/getdhcp&
Nov  5 15:10:00 NAS01 cron.notice crond[1696]: USER root pid 20331 cmd /usr/sbin/getdhcp&
Nov  5 15:20:01 NAS01 cron.notice crond[1696]: USER root pid 20401 cmd /usr/sbin/getdhcp&
Nov  5 15:30:01 NAS01 cron.notice crond[1696]: USER root pid 20467 cmd /usr/sbin/getdhcp&
Nov  5 15:40:01 NAS01 cron.notice crond[1696]: USER root pid 20544 cmd /usr/sbin/getdhcp&
Nov  5 15:42:03 NAS01 daemon.notice ntpd[1890]: kernel time sync error 0001
Nov  5 15:50:01 NAS01 cron.notice crond[1696]: USER root pid 20610 cmd /usr/sbin/getdhcp&

Last edited by jesbo (2008-11-06 01:04:25)

Thanks for the explanation.  Given that ntpd seems to be keeping the time adjusted correctly, I'm going to ignore the error for the time being and readdress it  when the next firmware release comes out.  Maybe Dlink will have upgraded the kernel.

True... I just haven't had time to set up a development environment on the DNS yet.  I'm waiting for a cold/rainy Saturday to tackle that project.

skydreamer wrote:

jesbo wrote:

....  I'm waiting for a cold/rainy Saturday to tackle that project.

Plenty of these on the West coast of Ireland- will I send you some? :-)

Yes... But you've got the Irish Whiskey and my fav... Guinness to make it more pleasant.