NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
System clock and spindown on NV+
Past February I enabled disk spindown on my NV+ (4.1.13, with 4 disks). This works nicely, but now I noticed that since then the system clock is very inaccurate. The system runs ntpdate every 4 hours,...
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:
so it loses 15s, then a bit later, another 7s. This is fairly repeatable.
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
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
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
