John Hasler writes:
I wrote:
Would it be useful to offer an official minimal implementation
intended for embedded systems so that these people won't feel the need
to code their own? Maybe add minimal NTP support to Busybox?
Brian Inglis writes:
AIUI an updated v4 sntp client will be
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Jan Ceuleers jan.ceule...@computer.org wrote:
I recommend providing motivation for the undesired clients to stop using
the server, by the server sending a regular response indicating that it
is not synchronised or replying in some other way
On Mon, Jul 07, 2014 at 07:04:01PM +0200, Jan Ceuleers wrote:
I'm not sure why sending the requester's timestamp back to him is better
than an immutable timestamp.
The effect of the former is slow drift, the effect of the latter is (I
suspect) no lock at all due to the lack of passage of
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Jan Ceuleers jan.ceule...@computer.org wrote:
I recommend providing motivation for the undesired clients to stop using
the server, by the server sending a regular response indicating that it
is not synchronised or replying in
There are two obvious ways to go for an embedded client.
One way would be to use the sntp code as the base.
The other would be to either use the current NTP codebase and use the
configure options to disable all the refclocks and anything else you
didn't want, or wait until we're done with
Hi there
Paul wrote:
One normally uses a so-called GPIO pin to read PPS on systems that
lack a DCD line or a parallel port. E.g. BeagleBone or Raspberry Pi.
Obviously.
A lot of people however, by an embedded system, hook op a GPS receiver,
find that PPS doesn't work and then just give up.
I'd have to look this up but think board using Elan 486 used the
on chip high speed timer to timestamp the pps input at a gpio
port along with a custom ntpd on FreeBSD to obtain sub us offset.
You mean something like this? *grin*
http://www.rabel.org/pics/Net4501-2.jpg
Yes, that is one of
On 07/08/2014 12:11 PM, Jason Rabel wrote:
There are two obvious ways to go for an embedded client.
One way would be to use the sntp code as the base.
The other would be to either use the current NTP codebase and use the
configure options to disable all the refclocks and anything else you
On 08/07/2014 11:01, Rob van der Putten wrote:
Hi there
Paul wrote:
One normally uses a so-called GPIO pin to read PPS on systems that
lack a DCD line or a parallel port. E.g. BeagleBone or Raspberry Pi.
Obviously.
A lot of people however, by an embedded system, hook op a GPS receiver,
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Jan Ceuleers jan.ceule...@computer.org wrote:
I recommend providing motivation for the undesired clients to stop using
the server, by the server sending a regular response indicating that it
On Mon, Jul 7, 2014 at 4:38 PM, David Lord sn...@lordynet.org wrote:
I'd have to look this up but think board using Elan 486 used the
on chip high speed timer to timestamp the pps input at a gpio
port along with a custom ntpd on FreeBSD to obtain sub us offset.
Perhaps you're referring to
On Tue, Jul 8, 2014 at 6:01 AM, Rob van der Putten r...@sput.nl wrote:
A lot of people however, by an embedded system, hook op a GPS receiver, find
that PPS doesn't work and then just give up.
That's appropriate. If you don't know what you're doing and choose
not to do the work to learn then
Jason Rabel writes:
I do not know if this is the case with NTP, but quite often it takes
considerable hacking of sources to get code to compile on non-x86
embedded hardware (i.e. ARM MIPS)... It would probably help boost
usage if someone was assuring NTP sources compile on those platforms
Paul wrote:
On Mon, Jul 7, 2014 at 4:38 PM, David Lord sn...@lordynet.org wrote:
I'd have to look this up but think board using Elan 486 used the
on chip high speed timer to timestamp the pps input at a gpio
port along with a custom ntpd on FreeBSD to obtain sub us offset.
Perhaps you're
On 08/07/2014 14:37, Paul wrote:
[]
People looking for inexpensive, low overhead NTP appliances should be
supporting Partially Stapled's Laureline development.
I would have supported that, partially because I like the chap what he
does, but their server didn't support any of the standard NTP
Jason Rabel wrote:
I do not know if this is the case with NTP, but quite
often it takes considerable hacking of sources to get
code to compile on non-x86 embedded hardware (i.e. ARM MIPS)
... It would probably help boost usage if someone was
assuring NTP sources compile on those
On Tue, Jul 8, 2014 at 1:00 PM, David Taylor
david-tay...@blueyonder.co.uk.invalid wrote:
I would have supported that, partially because I like the chap what he
does, but their server didn't support any of the standard NTP management
commands last time I looked
I did talk to him about
Jason Rabel writes:
There are two obvious ways to go for an embedded client.
One way would be to use the sntp code as the base.
The other would be to either use the current NTP codebase and use the
configure options to disable all the refclocks and anything else you
didn't want, or
I bought one of these to see what it could do and wrote a review on the
Tindie site. One of the issues I raised was the volume and ad hoc format of
stats messages he puts out on port 514 for syslog . I just updated that review
with info on a log message filter I wrote, which makes loopstats
19 matches
Mail list logo
