[time-nuts] Beaglebone NTP server

[Dan Drown]

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  
for bursts.

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/
>> beaglebone-black-timer-capture-driver/
>>
>> 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/
>> interrupt-latency.png
>> 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/
>> mailman/listinfo/time-nuts
>> 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.
>