System clock and spindown on NV+

That would explain why your offsets are always very similar.

I've just checked on my Pro6 - very different machine of course. I can't see the issue, unless an increase of +0.004 was relevant! :)
Sounds like the Kernel clock is stopping while the HDDs are not accessible, how bizarre!

It is bizarre, but I am wondering if the power draw is creating the problem - and that the battery change would ensure that the cmos clock is getting enough power. Just an idea though.

Not a massive expert here, but CMOS clock and Kernel clock should be two different things? The Kernel clock is usually generated by CPU cycles, but it really depends on the system and if alternative timers are provided by the MB. On my Pro 6 "hwclock" (BIOS clock) was still on year 2002, I have synced with the system time (hwclock --systohc), let the HDD spin down, access the NAS again and checked again. No change, both clocks are still ok.

As Stephen says, I'd change that battery anyway. If that does not fix, I'd search the internet for a similar problem with Debian 4

The kernel clock is driven by some real-time clock interrupt. I don't know what the source of that interrupt is on the NV+. Time loss means either that interrupts are being missed (or ignored), or are not generated in the first place.

I agree that the battery change is speculative, but it is an inexpensive thing to try.

I just changed the battery. Unfortunately this did not solve the problem. It still loses 14-22 seconds during each spinup. I noticed that the hwclock is actually correct after a spinup, it is only the system time that gets messed up.

Roman

I've run out of ideas here.
Can you check the system time (date) several times while the HDDs spin up and confirm it's stuck?

Assuming you have this folder, what do you have in

/sys/devices/system/clocksource/clocksource0/available_clocksource
and what do you have in
/sys/devices/system/clocksource/clocksource0/current_clocksource

And no, I'm definitely not a linux expert, so what I say here may be rubbish! :)

If hwclock is correct, you could try resetting the system clock via "hwclock -s" in a frequently run chron job.

I've analyzed the spin-up process some more. I issue these commands repeatedly:
date; ntpdate -q <my good ntp server>
first while disks are idle. I then access the exported share from my pc which triggers a spinup. In the terminal window I hit the up arrow to bring back this command. It takes about 10s for the cmd to be echoed. I do this several times in succession. Here is the output:

server 192.168.100.8, stratum 1, offset 0.144709, delay 0.02582
24 Apr 17:33:00 ntpdate[3678]: adjust time server 192.168.100.8 offset 0.144709 sec
rn601:/var/log# date; ntpdate -q 192.168.100.8
Thu Apr 24 17:33:16 CEST 2014
server 192.168.100.8, stratum 1, offset 15.014825, delay 0.02577
24 Apr 17:33:16 ntpdate[3682]: step time server 192.168.100.8 offset 15.014825 sec
rn601:/var/log# date; ntpdate -q 192.168.100.8
Thu Apr 24 17:33:17 CEST 2014
...
server 192.168.100.8, stratum 1, offset 15.014838, delay 0.02582
24 Apr 17:33:21 ntpdate[3689]: step time server 192.168.100.8 offset 15.014838 sec
rn601:/var/log# date; ntpdate -q 192.168.100.8
Thu Apr 24 17:33:23 CEST 2014
server 192.168.100.8, stratum 1, offset 22.364863, delay 0.02580
24 Apr 17:33:24 ntpdate[3691]: step time server 192.168.100.8 offset 22.364863 sec

so it loses 15s, then a bit later, another 7s. This is fairly repeatable.

/sys/devices/system/clocksource/clocksource0/available_clocksource and what do you have in /sys/devices/system/clocksource/clocksource0/current_clocksource

sysfs is mounted, but /sys/devices/system does not contain a clocksource subdirectory, only an empty cpu directory.
If there is a hook into the spinup process (just as there is with ACPI operations on modern systems) i could put an ntpdate command in there, but otherwise I should probably just go back to no spindown. The reason I considered it is that this NAS is now only used for storing backups and rarely used items. I had hoped to prolong the life of its disks (one already failed, another one has 5 pending sectors), but spindown probably doesn't help here.

I would like to thank all of you for the interest you took in my case and the time spent helping me.

Roman

Turning off spindown is probably the practical solution.

The impact on disk life is a bit hard to assess, as there clearly is more stress on bearings when the drives are spun up. Spinning up 16 times a day might have been too much anyway.

AFAIK, spindown wouldn't help with bad sectors, though I don't really understand the mechanisms that create bad sectors very well. Physical damage is often cited as the cause, but I haven't seen any data on whether spindown reduces the risk of that damage or if it puts the drive more at risk.

rmaeder wrote:
I've analyzed the spin-up process some more....this NAS is now only used for storing backups and rarely used items.

Roman I spent a ridiculous amount of time and effort trying to use spindown on my NV+, never succeeding to avoid unexpected spinups, and especially spinups IMMEDIATELY FOLLOWING spindowns which I'm quite certain are not good for hard drives.

I gave-up. I think the "spinup" issue is an underlying Linux issue and not one Netgear has cared to fiddle with. Instead I decided to schedule my NV+ to power On for two hours every day, during which time I have my various PCs scheduled to perform their backups, which in my case are SyncBack Free backups of files, to MTWTFSS and Monthly folders in the ReadyNAS. Every Monday (today!) I let the NV+ run longer, because I do a manual (front pushbutton) backup to a USB drive using Rsync.

On rare occasions that I need the NV+ to be on for whatever reason ie. to retrieve a lost file or something, I turn it on with its Power pb and then return it to Sleep mode with a special Frontview button provided by member WhoCares (I think) here.