Re: [time-nuts] Comparing the BeagleBone Black & Raspberry Pi asNTP servers
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
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
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
On Sun, 22 Mar 2015 09:29:56 -0400 Mike George 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
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 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
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
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 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
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.
Re: [time-nuts] Comparing the BeagleBone Black & Raspberry Pi asNTP servers
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/product&path=59_60&product_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
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
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
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
On Wed, Mar 25, 2015 at 3:22 AM, Hal Murray 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
>> 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
On Wed, 25 Mar 2015 09:46:05 -0700 Chris Albertson 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
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
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.