I have two propretary NAS devices, running a sawn-off linux and NTP Ver. 
4.2.8p8.  I have access to the config files, but not the base software.

In both cases, the drift files go straight to -500.000.  Typing ntpq -p 
after "stabilisation", the servers listed have offsets in the order of 
-70 mS.

I seem to recall something about linux being able to adjust "tick length" 
to address cpu timing issues, but I can't find any reference to it.  
Would it help in this case - always supposing the linux implementation 
actually supports it?

Are there any "undocumented commands" within the NTP suite that might 
address the problem?  

Beyond the above, I am lost for ideas. Can anyone help?

Many thanks

Uncle Boris

On 2016-08-19, Uncle Boris <limit1509@cidercounty.org.uk> wrote:
> I have two propretary NAS devices, running a sawn-off linux and NTP Ver. 
> 4.2.8p8.  I have access to the config files, but not the base software.
>
> In both cases, the drift files go straight to -500.000.  Typing ntpq -p 
> after "stabilisation", the servers listed have offsets in the order of 
> -70 mS.

>
> I seem to recall something about linux being able to adjust "tick length" 
> to address cpu timing issues, but I can't find any reference to it.  
> Would it help in this case - always supposing the linux implementation 
> actually supports it?

man adjtimex
Or you could try chrony, which will do it for you (amongst other good
things).


>
> Are there any "undocumented commands" within the NTP suite that might 
> address the problem?  

adjtimex has nothing to do with ntp. It is a Linux command.

>
o
> Beyond the above, I am lost for ideas. Can anyone help?

At boot, linux is supposed to adjust the kernel tick rate to be very
close to one sec/sec. For a while the kenrels had trouble with this.
What kernel are you running?
(Not the more information you give the more likely you are to get good
advice. An unknown kernel on an unknown piece of hardware makes it
really hard to give good advice.


>
> Many thanks
>
> Uncle Boris
>

On Fri, 19 Aug 2016 22:53:32 +0000, William Unruh wrote:
 
> At boot, linux is supposed to adjust the kernel tick rate to be very
> close to one sec/sec. For a while the kenrels had trouble with this.
> What kernel are you running?
> (Not the more information you give the more likely you are to get good
> advice. An unknown kernel on an unknown piece of hardware makes it
> really hard to give good advice.

typing cat /proc/version gives me
Linux version 3.2.40 (root@build3) (gcc version 4.9.3 20150311 
(prerelease) (crosstool-NG 1.20.0) ) #7393 Thu Jun 2 19:48:42 CST 2016

And FWIW, one machine is a Synology DS214se and the other is a DS216se

On 2016-08-20, Uncle Boris <limit1509@cidercounty.org.uk> wrote:
> On Fri, 19 Aug 2016 22:53:32 +0000, William Unruh wrote:
>  
>> At boot, linux is supposed to adjust the kernel tick rate to be very
>> close to one sec/sec. For a while the kenrels had trouble with this.
>> What kernel are you running?
>> (Not the more information you give the more likely you are to get good
>> advice. An unknown kernel on an unknown piece of hardware makes it
>> really hard to give good advice.
>
> typing cat /proc/version gives me
> Linux version 3.2.40 (root@build3) (gcc version 4.9.3 20150311 
> (prerelease) (crosstool-NG 1.20.0) ) #7393 Thu Jun 2 19:48:42 CST 2016

So that should have the decent time setting. It may be that it has
trouble with the hardware.
Anyway, see if you have adjtimex on the machine-- if not compile it and
install it. With that you can adjust the rate of the clock to bring it
closer to one second per second, assuming the hardware supports it.

As I said, alternatively install chrony. It uses the adjtime subroutines
to adjust the rate and can handle rates much higher than 500pm .


>
> And FWIW, one machine is a Synology DS214se and the other is a DS216se
>