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 <[email protected]>:
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 <[email protected]> wrote:
Quoting Paul <[email protected]>:
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 -- [email protected]
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 -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
