System clock and spindown on NV+

I am not seeing this behavior on my NV+ or my duo (both have spindown enabled). There are a couple of entries that reach 0.44 seconds, but the .0x range is what it usually is. Nothing in the 10s of seconds.

What drives are you using? I'm wondering how much power they draw during spinup.

I have 3 Seagate Barracuda 7200.10, and one WDC WD7502ABYS, each with 750GB.
On average, the disks spin up about 16 times daily.

Roman

About 10 amps of spin-up current, which doesn't seem like it should be a problem.

Are you seeing any other issues?

Amazingly, since yesterday I find entries about disk spinup/down in the daemon.log; none such appeared before. The only change I can recall is the installation of the ssh addon and a reboot.
Time error seems somewhat correlated with length of spindown:

Apr 19 11:11:04 rn601 noflushd[674]: Spinning down disks.
Apr 19 14:00:06 rn601 noflushd[674]: Disks spinning up after 169 minutes.
Apr 19 14:10:24 rn601 ntpdate[3890]: step time server 192.168.100.8 offset 22.299269 sec
Apr 19 14:20:55 rn601 noflushd[674]: Spinning down disks.
Apr 19 15:46:42 rn601 noflushd[674]: Disks spinning up after 85 minutes.
Apr 19 16:00:23 rn601 ntpdate[4306]: step time server 192.168.100.8 offset 22.271407 sec
Apr 19 16:07:06 rn601 noflushd[674]: Spinning down disks.
Apr 19 19:04:45 rn601 noflushd[674]: Disks spinning up after 177 minutes.
Apr 19 19:28:56 rn601 noflushd[674]: Spinning down disks.
Apr 20 00:00:41 rn601 noflushd[674]: Disks spinning up after 271 minutes.
Apr 20 00:10:47 rn601 ntpdate[6312]: step time server 192.168.100.8 offset 44.546045 sec
Apr 20 02:25:18 rn601 noflushd[674]: Spinning down disks.
Apr 20 02:25:29 rn601 noflushd[674]: Disks spinning up after 0 minutes.
Apr 20 02:45:30 rn601 noflushd[674]: Spinning down disks.
Apr 20 02:53:03 rn601 noflushd[674]: Disks spinning up after 7 minutes.
Apr 20 03:13:29 rn601 noflushd[674]: Spinning down disks.
Apr 20 04:00:12 rn601 noflushd[674]: Disks spinning up after 46 minutes.
Apr 20 04:10:16 rn601 ntpdate[6969]: step time server 192.168.100.8 offset 14.924754 sec
Apr 20 04:30:29 rn601 noflushd[674]: Spinning down disks.
Apr 20 06:25:10 rn601 noflushd[674]: Disks spinning up after 114 minutes.
Apr 20 06:34:51 rn601 ntpdate[7852]: step time server 192.168.100.8 offset 14.827573 sec
Apr 20 07:07:32 rn601 noflushd[674]: Spinning down disks.
Apr 20 10:20:17 rn601 noflushd[674]: Disks spinning up after 192 minutes.
Apr 20 10:30:02 rn601 ntpdate[8828]: step time server 192.168.100.8 offset 0.046450 sec

Except the last one; but this is always like that when the reason for the spinup is me logging in with ssh.
I thought about installing the ntpd addon and letting ntp run freely (without syncing the clock), so I could monitor the offset from outside, but the file
NTP-Server_4.2.4pl7-readynas-0.9.0.bin that is mentionen in a couple of places is longer in the places where Google tells me it should be.
Does anyone have a copy for me?

Roman

Correlation with the spindown period suggests that the clock is running slower when the disks are spun down. The longer the spindown, the more time it loses.

What hardware version is your NV+? It should be on the back label (v3 or some such). I can check mine as well - possibly mine is different, which might explain why I am not seeing it.

How much do you want spindown?

Perhaps one option is to contact Netgear support and buy a replacement PSU. That is speculative, but possibly might help.

If you disable disk spindown, does the clock go back to what it used to be?
Are you sure your NTP server is accurate and not freewheeling?

From the posting, I was assuming the the NAS clock was correct after the NTP corrections.

rmaeder - are you using the default netgear ntp servers? If so, I suspect they are accurate, otherwise my systems (and others) would also be seeing these signs.

ntpdate says it stepped the clock xx seconds. I believe ntpdate is considered 'obsolete' in the community. A proper ntp daemon will check the ntp server's consistency before trusting it. ntpdate just steps the time. If the server is inaccurate, the clock will be inaccurately stepped every time ntpdate is run.

Thanks for all the helpful suggestions and questions. Here's some more info about this case, which narrows down the problem.

1. I use my own ntp server which is very accurate and closely monitored. No chance that it could be the cause. After the corrections the clock is indeed correct.

2. After I wrote my last post I left myself accidentally logged into the unit, and when I returned about 4 hours later I found the disks idle. An "ntpdate -q" showed to my surprise that the clock was still accurate! I then did something which caused the disks to spin up (which introduces a delay of about 10s), and after they were running, the clock was suddenly 14 s late. Within 10 minutes the delayed cron job adjusted it as usual.

So it looks like the clock loses between 14 and 22 s during the actual spin up, but runs normally otherwise.
And if there are several spindown/up cycles before the next ntpdate, it loses several times that amount; this is also visible from the log file I posted. Could the timing system in the kernel be hanging during the spinup?

3. As for the h/w version, the back label doesn't have any "V" in it. The unit is from 2006, except for the power supply, which went up in smoke in 2009 (and took the UPS with it..).

EDIT:
I analyzed another spindown while logged in. Immediately after spin up the clock was still ok, but then within a few minutes it suddenly jumps those 14 seconds. The syslog has an entry:

Apr 20 15:13:54 rn601 kernel: :40000002|1

which seems correlated with the spinup events. What does this mean?

Roman

If it is a kernel thing, it must be limited to specific models, since I am not seeing it. Mine is v3 hardware.

There is a small battery (CR2032) on the system board for the clock - likely it is dead on your system. Not sure if it is related, but if you want to try replacing it there is some info here on removing the battery (ftp://downloads.netgear.com/files/RESET_TIMER.pdf). The link isn't really about replacing it, but once you get it out, you can certainly do that.

Another link is here:
viewtopic.php?f=7&t=35377