[time-nuts] Beaglebone NTP server
dan-timenuts at drown.org
Thu Dec 11 10:27:51 EST 2014
As a test of load, I sent around 650 ntp queries per second (give or
take 20 q/s) to the BBB. CPU usage was around 87% idle. There were
no dropped packets for the 108,000 sent. Round-trip time was between
287us and 199us. Traffic was around 470kbit/s.
Assuming clients have a query rate of 1 per 256s on average, that rate
is good for around 150k clients. That also leaves plenty of CPU free
NTP isn't exactly a heavy protocol :)
Is this better or worse than other NTP server platforms? I haven't
tested them, so I have no idea.
Quoting Chris Albertson <albertson.chris at gmail.com>:
> Those sub 1 u-second numbers are very good. They argue for using the BBB
> as an NTP server but I wonder if it really is the best. I think the
> numbers that matter are measures of the close on the computers who use your
> BBB as a server. In other words the goal is to synchronize a set of
> computers. Can The little BBB push accurate time out to a set of user
> computers and keep then in sync better then some other NTP server platform?
> On Wed, Dec 10, 2014 at 5:58 PM, Dan Drown <dan-timenuts at drown.org> wrote:
>> Quoting Paul <tic-toc at bodosom.net>:
>>> Using a PRU seems like overkill if all you want from the BBB is NTP. The
>>> standard pps-gpio should move the system clock precision below
>>> system/network jitter (.5 to 1 microsecond). The next step is using a
>>> timer (TIMER4) which should get you into .1 microsecond offsets.
>> As a note to people wanting to use the timer hardware on the BBB - I have
>> a driver for it at https://github.com/ddrown/pps-gmtimer
>> I wrote up the results in using it at http://blog.dan.drown.org/
>> The summary of it is:
>> pps-gpio - 50% of the time local clock offset within +/- 0.07us, 98%
>> within +/- 0.61us
>> pps-gmtimer - 50% of the time local clock offset within +/- 0.04us, 98%
>> within +/- 0.43us
>> Also, if you're using pps-gpio, you might want to disable cpufreq and
>> force your processor to 1GHz. It'll help with interrupt latency and jitter.
>> cpufreq ondemand, 300MHz-1GHz - http://dan.drown.org/bbb/run9/
>> 98% of interrupts handled 12.92us-23.21us after the event happened.
>> cpufreq forced 1GHz - http://dan.drown.org/bbb/run8/interrupt-latency.png
>> 98% of interrupts handled 6.04us-8.58us after the event happened.
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/
>> and follow the instructions there.
> Chris Albertson
> Redondo Beach, California
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
More information about the time-nuts