[ntp:questions] Support for "tickless" systems

2014-11-19 Thread David Taylor
In bug 2314, I reported that the jitter was always reported as 0 soon 
after NTP had started, and this was traced to the Linux in use on the 
Raspberry Pi being tickless.  Recompiling the kernel without the 
tickless option was a work-round, but is it possible to get jitter 
values with a tickless system?


I would like to re-open this bug if NTP can be made to report jitter 
correctly on a tickless Linux.

--
Cheers,
David
Web: http://www.satsignal.eu

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] Support for "tickless" systems

2014-11-19 Thread Miroslav Lichvar
On Wed, Nov 19, 2014 at 10:09:42AM +, David Taylor wrote:
> In bug 2314, I reported that the jitter was always reported as 0 soon after
> NTP had started, and this was traced to the Linux in use on the Raspberry Pi
> being tickless.  Recompiling the kernel without the tickless option was a
> work-round, but is it possible to get jitter values with a tickless system?

There was a problem with clock stability in the tickless mode on idle
systems, which should be fixed or at least significantly improved in
3.17. I'm not sure how it could cause the jitter to be reported as
zero though.

Can you try 3.17 or later and see if it's fixed? Also, it would be
interesting to know if adding nohz=off to the kernel command line
instead of recompiling works as a workaround too.

-- 
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] Support for "tickless" systems

2014-11-19 Thread Jack Ryan
3.17 what?

Miroslav Lichvar  wrote:

> On Wed, Nov 19, 2014 at 10:09:42AM +, David Taylor wrote:
> > In bug 2314, I reported that the jitter was always reported as 0 soon after
> > NTP had started, and this was traced to the Linux in use on the Raspberry Pi
> > being tickless.  Recompiling the kernel without the tickless option was a
> > work-round, but is it possible to get jitter values with a tickless system?
> 
> There was a problem with clock stability in the tickless mode on idle
> systems, which should be fixed or at least significantly improved in
> 3.17. I'm not sure how it could cause the jitter to be reported as
> zero though.
> 
> Can you try 3.17 or later and see if it's fixed? Also, it would be
> interesting to know if adding nohz=off to the kernel command line
> instead of recompiling works as a workaround too.
> 
> -- 
> Miroslav Lichvar

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] Support for "tickless" systems

2014-11-19 Thread David Taylor

On 19/11/2014 11:56, Miroslav Lichvar wrote:

On Wed, Nov 19, 2014 at 10:09:42AM +, David Taylor wrote:

In bug 2314, I reported that the jitter was always reported as 0 soon after
NTP had started, and this was traced to the Linux in use on the Raspberry Pi
being tickless.  Recompiling the kernel without the tickless option was a
work-round, but is it possible to get jitter values with a tickless system?


There was a problem with clock stability in the tickless mode on idle
systems, which should be fixed or at least significantly improved in
3.17. I'm not sure how it could cause the jitter to be reported as
zero though.

Can you try 3.17 or later and see if it's fixed? Also, it would be
interesting to know if adding nohz=off to the kernel command line
instead of recompiling works as a workaround too.


The latest Linux for the Raspberry Pi is 3.12.32+, I'm afraid.

Would the command-line you speak of be the one containing - for example 
- console=tty1 rootfstype=ext4

--
Thanks,
David
Web: http://www.satsignal.eu

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] Support for "tickless" systems

2014-11-19 Thread Rob
David Taylor  wrote:
> On 19/11/2014 11:56, Miroslav Lichvar wrote:
>> On Wed, Nov 19, 2014 at 10:09:42AM +, David Taylor wrote:
>>> In bug 2314, I reported that the jitter was always reported as 0 soon after
>>> NTP had started, and this was traced to the Linux in use on the Raspberry Pi
>>> being tickless.  Recompiling the kernel without the tickless option was a
>>> work-round, but is it possible to get jitter values with a tickless system?
>>
>> There was a problem with clock stability in the tickless mode on idle
>> systems, which should be fixed or at least significantly improved in
>> 3.17. I'm not sure how it could cause the jitter to be reported as
>> zero though.
>>
>> Can you try 3.17 or later and see if it's fixed? Also, it would be
>> interesting to know if adding nohz=off to the kernel command line
>> instead of recompiling works as a workaround too.
>
> The latest Linux for the Raspberry Pi is 3.12.32+, I'm afraid.
>
> Would the command-line you speak of be the one containing - for example 
> - console=tty1 rootfstype=ext4

Yes, but normally there are a lot more options than that.  You can edit
/boot/cmdline.txt and reboot.  But be careful that you don't put garbage
there and make the boot fail.  When that still happens you can put the
card in another system (laptop, PC via USB adapter) and edit it again.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] Support for "tickless" systems

2014-11-19 Thread David Taylor

On 19/11/2014 11:56, Miroslav Lichvar wrote:

On Wed, Nov 19, 2014 at 10:09:42AM +, David Taylor wrote:

In bug 2314, I reported that the jitter was always reported as 0 soon after
NTP had started, and this was traced to the Linux in use on the Raspberry Pi
being tickless.  Recompiling the kernel without the tickless option was a
work-round, but is it possible to get jitter values with a tickless system?


There was a problem with clock stability in the tickless mode on idle
systems, which should be fixed or at least significantly improved in
3.17. I'm not sure how it could cause the jitter to be reported as
zero though.

Can you try 3.17 or later and see if it's fixed? Also, it would be
interesting to know if adding nohz=off to the kernel command line
instead of recompiling works as a workaround too.


I found the right file (thanks, Rob, yes there are more options as you 
say) and tried setting nohz=off but it made no difference - jitter still 
reported as zero.


How would I tell whether the nohz=off was actually accepted or not, i.e. 
how to determine whether the kernel is tickless or not?  I found these 
diagnostics:


pi@raspberrypi ~ $ dmesg | grep -i nohz
[0.00] Kernel command line: dma.dmachans=0x7f35 
bcm2708_fb.fbwidth=592 bcm2708_fb.fbheight=448 bcm2708.boardrev=0x10 
bcm2708.serial=0x15e75d6b smsc95xx.macaddr=B8:27:EB:E7:5D:6B 
bcm2708_fb.fbswap=1 bcm2708.disk_led_gpio=47 
bcm2708.disk_led_active_low=0 sdhci-bcm2708.emmc_clock_freq=25000 
vc_mem.mem_base=0x1ec0 vc_mem.mem_size=0x2000 
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p6 rootfstype=ext4 
elevator=deadline rootwait bcm2708.pps_gpio_enable 
bcm2708.pps_gpio_pin=18  nohz=off


which just reflects the edit I made to cmdline.txt, and:

pi@raspberrypi ~ $ cat /proc/interrupts | grep -i time
  3:4351879   ARMCTRL  BCM2708 Timer Tick
pi@raspberrypi ~ $ sleep 10
pi@raspberrypi ~ $ cat /proc/interrupts | grep -i time
  3:4353699   ARMCTRL  BCM2708 Timer Tick
pi@raspberrypi ~ $

I don't know how to interpret the difference of 1820 in those two 
numbers.  The first two commands were typed by hand, by the way, the 
third with an up-arrow recall.


--
Thanks,
David
Web: http://www.satsignal.eu

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions