Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers

2015-03-26 Thread David J Taylor

From: Hal Murray

david-tay...@blueyonder.co.uk said:

Perhaps because NTP sees the offset in both send and receive packets and
therefore, like any other network delay, it is subtracted out.


The description of the change was to remove a delay on the receive side.
There was no mention of a change on the send side.  So I was expecting a
change in the symmetry.  (I don't know if it would make things better or
worse, but something should change.)
==

Yes, I see what you mean.  I will be updating the report in the next few 
days so we can see what the change is.  At the moment, it seems that the 
mean offset has changed from +0.044 ms to  -0.037 ms.


Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk 


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers

2015-03-26 Thread Paul
On Thu, Mar 26, 2015 at 4:10 AM, David J Taylor 
david-tay...@blueyonder.co.uk wrote:


 Yes, I see what you mean.


I haven't parsed the driver but asymmetry inverts the sign of the offset as
viewed from each end (when each end is S1) so it's usually obvious.  I'm
not seeing it.  I've always used smsc95xx.turbo_mode=N so I don't have a
ready source to compare.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers

2015-03-25 Thread Hal Murray

david-tay...@blueyonder.co.uk said:
 I was really interested to see how much effect the extra Ethernet latency of
  the Raspberry Pi added in a real-world scenario.  Thanks to Philip
 Gladstone, I have now discovered a way of significantly reducing that
 latency, so that the delay reported by NTP is reduced from ~0.51 to ~0.35
 milliseconds.

   http://www.satsignal.eu/ntp/RaspberryPi-notes.html#EthernetLatency 

Thanks for the tip.  I did that to my R Pi and I see the same improvement in 
round trip time.

What I don't understand is why the time offset as measured by an outside 
system didn't change.  ??


-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers

2015-03-25 Thread David J Taylor

From: Hal Murray


  http://www.satsignal.eu/ntp/RaspberryPi-notes.html#EthernetLatency


Thanks for the tip.  I did that to my R Pi and I see the same improvement in
round trip time.

What I don't understand is why the time offset as measured by an outside
system didn't change.  ??


Perhaps because NTP sees the offset in both send and receive packets and 
therefore, like any other network delay, it is subtracted out.


Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk 


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers

2015-03-25 Thread Chris Albertson
On Wed, Mar 25, 2015 at 3:22 AM, Hal Murray hmur...@megapathdsl.net wrote:


 What I don't understand is why the time offset as measured by an outside
 system didn't change.  ??


NTP always and continuously measures the round trip time over the network
and assumes the one-way time is 1/2 the round trip time.  Reducing the
latency reduces the round trip time that NTP has to compensate for.

So if NTP always compensates for network delay why do you get improved
performance with less delay?  That is because what messes up NTP is
uncertainly in the delay and likely it's the case that reducing the delay
also reduces the standard deviation of the delay.   The other thing the
messes up NTP is its assumption that the delay is symmetric (that the
one-way delay = one half the round trip delay)  I think reducing the round
trip time also reduces error in this assumption.

NTP is not magic and uses the same algorithm you would use if you lived 200
years ago and were told to synchronize two grandfather clocks in two houses
that were 1 mile apart and you have to walk between the two houses and you
had no third clack you could cary.  What is the optimal solution to this
problem:  I think your first step would be to walk the distance many times
to build up a statistical database for travel times to get a solid mean and
sigma.  Then you would walk back and forth, 24x7 and try to compute the
differed in rates of the two clocks and adjust the pendulum of your clock.
Setting the absolute time would not work to converge the error to zero
setting the rate would. Of course the best thing would be to buy small
clock you could take with you but NTP was designed to run on a dump
network that only moves data without timing it.

-- 

Chris Albertson
Redondo Beach, California
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers

2015-03-25 Thread Attila Kinali
On Wed, 25 Mar 2015 09:46:05 -0700
Chris Albertson albertson.ch...@gmail.com wrote:

 So if NTP always compensates for network delay why do you get improved
 performance with less delay?  That is because what messes up NTP is
 uncertainly in the delay and likely it's the case that reducing the delay
 also reduces the standard deviation of the delay.   The other thing the
 messes up NTP is its assumption that the delay is symmetric (that the
 one-way delay = one half the round trip delay)  I think reducing the round
 trip time also reduces error in this assumption.

There is another assumption, that most people (especially engineers)
do (and NTP is forced to do), which does not always hold true: that
measurement noise is mean-free and uncorrelated. Especially in this
case, USB delay is definitly not mean-free if you queue up packages
(i would go so far as to say, that USB induced delay is never mean-free)
and has a non-zero auto- and cross-correlation, mediated trough
the USB clock, which is synced to the system clock's source (they
are derived from the same crystal).

AFAIK, and without checking, I think that NTP also makes the assumption,
that the noise is ergodic and time-invariant during measurement.
Again, in the case of USB (and to some extend all network based
communication systems), this does not hold true.


Attila Kinali
-- 
 _av500_ phd is easy
 _av500_ getting dsl is hard
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers

2015-03-25 Thread Hal Murray

 What I don't understand is why the time offset as measured by an
 outside system didn't change.  ??

david-tay...@blueyonder.co.uk said:
 Perhaps because NTP sees the offset in both send and receive packets and
 therefore, like any other network delay, it is subtracted out. 

The description of the change was to remove a delay on the receive side.  
There was no mention of a change on the send side.  So I was expecting a 
change in the symmetry.  (I don't know if it would make things better or 
worse, but something should change.)


-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers

2015-03-24 Thread David J Taylor

From: Neil Schroeder

The other key key key item is make sure you hand build yourself a 3.14 or
.16 kernel.

NS
=

Thanks, Neil.  I'm afraid I have neither the expertise nor the patience to 
do that, and to an extent this was intended to be an out-of-the-box 
comparison.  Doubtless adding a TCXO would improve performance as well, but 
I will leave that to someone else to try.


I was really interested to see how much effect the extra Ethernet latency of 
the Raspberry Pi added in a real-world scenario.  Thanks to Philip 
Gladstone, I have now discovered a way of significantly reducing that 
latency, so that the delay reported by NTP is reduced from ~0.51 to ~0.35 
milliseconds.


 http://www.satsignal.eu/ntp/RaspberryPi-notes.html#EthernetLatency

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk 


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers

2015-03-23 Thread David J Taylor

Folks,

Many thanks for all your comments.  I am now undertaking tests with the 
stripped-down Console build of the OS.  With both the RPi and the BBB I 
started with what the typical user might install rather than any special 
version (indeed, it's built into the BBB).  It seems that while many 
services are enabled and run by default on the BBB, this is not so on the 
RPi, and hence the great difference in CPU load.  Early results are that 
this does not make a lot of difference to what NTP on the card reports, but 
it does significantly affect the view from outside, i.e. what an NTP client 
might see from an NTP server.


Specific replies:

Graham:
The other thing that will help is getting rid of the cape-manager system you 
are using, that is file i/o based.  There is a lot of file scanning going on 
that is not useful in time critical applications.


Yes, but I have no idea how to do that.  There seems to be a peculiarity in 
that with the full OS gpsd works as expected, but it doesn't start 
automatically with the console OS.  It does run when started by hand, and I 
have used dpkg-reconfigure to try and make it auto-start.  For the moment, I 
will leave that as one of the BBB's unexplained mysteries!


Attila, Mike:
You will see that I have taken your advice and used the console OS.  Likely 
I will not use the BBB for much else as the RPi 2 is more powerful and has a 
much wider support base.


Attila:
Thanks for the pointer to the pre-built buildroot images, but they note: 
Since that time, BBB support was merged upstream, so this is really, really 
old. Please, please, don't use this in new projects.  I'm really only 
interested in what they typical user might download or find pre-installed.


Chris:
Yes, the two  /etc/ntp.conf  are identical, with the possible exception of a 
leapsecond file not yet being configured for the BBB.


Paul:
The patch antenna on the Adafruit does work here much of the time, but it is 
smaller than the patch in the magnetic mount antenna I ended up using. 
Compared to the naked Adafruit module, a ublox M8Q module and mag mount 
antenna is noticeably better for indoor use here, and on RPi cards other 
than the one in this test I've switched to these units:


 
http://ava.upuaut.net/store/index.php?route=product/productpath=59_60product_id=117

Paul:
I agree that the table could be improved, but rather than remove information 
I have emboldened that for the two servers which the client is testing.  The 
table is due for a full update once today's running is completed without 
interruption.


Wolfgang:
I agree with your comments, but I am comparing more out-of-the-box rather 
than special builds etc.  To show how things changed between the two OS 
versions I added a comparison here:


 http://www.satsignal.eu/ntp/BBB-vs-RPi.html#OS-comparison

Many thanks all for your help.  Tomorrow I will update the table, and I'm 
sure that the BBB will win out under both measures.


Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk 


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers

2015-03-22 Thread Mike George

David:

On this page:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.2FBBB_.28All_Revs.29

they list an alternative console only image:

https://rcn-ee.com/rootfs/bb.org/release/2015-03-01/console/bone-debian-7.8-console-armhf-2015-03-01-2gb.img.xz

It might be easier starting with that if you don't intend to use graphics.

Mike

On 3/22/2015 03:46, David J Taylor wrote:

David:
On the BBB, were you running the fully loaded release, or the minimum
console version of the OS?
Which specific version of the OS?

Thanks,
--- Graham
=

Graham,

The download was:

 bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz (547,024,548 bytes)

which was from the Recommended Debian Images from: 
http://beagleboard.org/latest-images.  Perhaps there are some services 
or background tasks I can disable to reduce the CPU steady load from 
its present 16% average level?


73,
David GM8ARV


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers

2015-03-22 Thread David J Taylor

David:
On the BBB, were you running the fully loaded release, or the minimum
console version of the OS?
Which specific version of the OS?

Thanks,
--- Graham
=

Graham,

The download was:

 bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz  (547,024,548 bytes)

which was from the Recommended Debian Images from: 
http://beagleboard.org/latest-images.  Perhaps there are some services or 
background tasks I can disable to reduce the CPU steady load from its 
present 16% average level?


73,
David GM8ARV
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk 


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers

2015-03-22 Thread David J Taylor

David:

On this page:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.2FBBB_.28All_Revs.29

they list an alternative console only image:

https://rcn-ee.com/rootfs/bb.org/release/2015-03-01/console/bone-debian-7.8-console-armhf-2015-03-01-2gb.img.xz

It might be easier starting with that if you don't intend to use graphics.

Mike


Thanks for that, Mike.  It takes quite some time to set up the BBB so if 
possible I would prefer to disable unnecessary programs and services.


Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk 


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers

2015-03-22 Thread Attila Kinali
On Sun, 22 Mar 2015 09:29:56 -0400
Mike George mgeo...@tuffmail.us wrote:

 On this page:
 
 http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.2FBBB_.28All_Revs.29
 
 they list an alternative console only image:
 
 https://rcn-ee.com/rootfs/bb.org/release/2015-03-01/console/bone-debian-7.8-console-armhf-2015-03-01-2gb.img.xz
 
 It might be easier starting with that if you don't intend to use graphics.


Alternatively, use an embedded buildsystem (e.g. buildroot[1]) so that the
image contains only what is really required, and nothing else. There
are also several, preconfigured buildroot forks for the BBB (e.g. [2]).

If you need help with that, send me an email off-list.

Attila Kinali



[1] http://buildroot.net
[2] https://github.com/fhunleth/buildroot-bbb

-- 
 _av500_ phd is easy
 _av500_ getting dsl is hard
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers

2015-03-22 Thread Neil Schroeder
I can confirm similar issues with each of my BBBs.  They just can't seem to
get the jitter down.

I've tried a variety of combinations of Debian and Ubuntu, and even
replaced the clock on one with an Si5338.

On Sun, Mar 22, 2015 at 6:29 AM, Mike George mgeo...@tuffmail.us wrote:

 David:

 On this page:

 http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.
 2FBBB_.28All_Revs.29

 they list an alternative console only image:

 https://rcn-ee.com/rootfs/bb.org/release/2015-03-01/
 console/bone-debian-7.8-console-armhf-2015-03-01-2gb.img.xz

 It might be easier starting with that if you don't intend to use graphics.

 Mike

 On 3/22/2015 03:46, David J Taylor wrote:

 David:
 On the BBB, were you running the fully loaded release, or the minimum
 console version of the OS?
 Which specific version of the OS?

 Thanks,
 --- Graham
 =

 Graham,

 The download was:

  bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz (547,024,548 bytes)

 which was from the Recommended Debian Images from:
 http://beagleboard.org/latest-images.  Perhaps there are some services
 or background tasks I can disable to reduce the CPU steady load from its
 present 16% average level?

 73,
 David GM8ARV


 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/
 mailman/listinfo/time-nuts
 and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers

2015-03-22 Thread Graham / KE9H
David:

If you are running headless, that is, not using the on board
video-graphics system,
all interaction with the unit is via the console, local or SSH.

In this case, I would use the console version as described above.  It is
about
one tenth the size of the version you are using.

You will need to install ntp, and disable whatever time system is already
present.
As well as any time and logging services that you do not use, that you can
find.

Debian is in transition from using a services management system called
init to
a new system called systemd or system daemon.  Debian 7.8 you are using
is a mixture of both.  By Debian 8 (jessie) the transition will be complete
and
is an almost pure systemd environment that will give you a centralized
location
and command set to view and turn on/off all services, including the
recurring
time-based ones.

Jessie is in test currently, and should be released in the next few months.
It is the OS for the new Beaglebone X-15 due out mid-year.  They have not
yet released a console version, but it real close.

The other thing that will help is getting rid of the cape-manager system you
are using, that is file i/o based.  There is a lot of file scanning going
on that
is not useful in time critical applications.

--- Graham

==



On Sun, Mar 22, 2015 at 8:29 AM, Mike George mgeo...@tuffmail.us wrote:

 David:

 On this page:

 http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.
 2FBBB_.28All_Revs.29

 they list an alternative console only image:

 https://rcn-ee.com/rootfs/bb.org/release/2015-03-01/
 console/bone-debian-7.8-console-armhf-2015-03-01-2gb.img.xz

 It might be easier starting with that if you don't intend to use graphics.

 Mike

 On 3/22/2015 03:46, David J Taylor wrote:

 David:
 On the BBB, were you running the fully loaded release, or the minimum
 console version of the OS?
 Which specific version of the OS?

 Thanks,
 --- Graham
 =

 Graham,

 The download was:

  bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz (547,024,548 bytes)

 which was from the Recommended Debian Images from:
 http://beagleboard.org/latest-images.  Perhaps there are some services
 or background tasks I can disable to reduce the CPU steady load from its
 present 16% average level?

 73,
 David GM8ARV


 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/
 mailman/listinfo/time-nuts
 and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers

2015-03-22 Thread David J Taylor

David:

On this page:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.2FBBB_.28All_Revs.29

they list an alternative console only image:

https://rcn-ee.com/rootfs/bb.org/release/2015-03-01/console/bone-debian-7.8-console-armhf-2015-03-01-2gb.img.xz

It might be easier starting with that if you don't intend to use graphics.

Mike


On reflection, Mike  Attila, even though it may be more effort, I will give 
that a try.


Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk 


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers

2015-03-22 Thread Wolfgang Wallner

What kernel do you use? And what scheduling configuration?

As it is a timing application, and sensible to jitter, I would suggest
to use a real-time kernel (e.g. Preempt RT) [1].

Usually one can find pre-built kernels with PreempRT-support for boards
like the RPi etc. on the internet.

If you use a real-time kernel, and have it configured that your
application of choice (in this case ntp) has real-time priority, the 16%
cpu usage won't be a problem any more. Other workloads like IRQs or task
scheduling may have much worse effects on application jitter (even on
real-time systems).

Interestingly, more CPU usage can even be better for jitter-sensitive
applications: low cpu usage might enable power-saving functions, which
in turn might lead to longer reaction times once an application needs to
be handled.

regards, Wolfgang

[1] https://www.osadl.org/Realtime-Linux.projects-realtime-linux.0.html

On 03/22/2015 08:46 AM, David J Taylor wrote:
 David:
 On the BBB, were you running the fully loaded release, or the minimum
 console version of the OS?
 Which specific version of the OS?
 
 Thanks,
 --- Graham
 =
 
 Graham,
 
 The download was:
 
  bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz  (547,024,548 bytes)
 
 which was from the Recommended Debian Images from:
 http://beagleboard.org/latest-images.  Perhaps there are some services
 or background tasks I can disable to reduce the CPU steady load from its
 present 16% average level?
 
 73,
 David GM8ARV
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.