On May 21, 2018, at 11:19, Gary E. Miller wrote:
> Now, how to I tell the Linux kernel to apply that correction?
I honestly don’t understand how this would be used in a meaningful way via the
Linux kernel. The nanoseconds of correction for the PPS signal seems a small
nit
Have you considered asking Leo? In my experience, he is very helpful.
Denny
> On May 17, 2018, at 19:19, Clay Autery wrote:
>
> Anyone who is using one (or both) of these, and/or folks who have a logical
> opinion:
>
> *"GPSDO"* - Once configured, unit can run on an
The 6-7us of latency in this discussion does not involve the network path. In
this regard network latency is fairly well addressed with hardware
timestamping, although trying to get readings across the clock domains looses
dozens of nanos of precision. In this discussion, the 6-7us of latency
[I hate finding unsent email in my folder :-]
Others may disagree, but I doubt that the type of small temperature variation
you are referring to has any meaningful effect on tracking. While the datasheet
for the M8T says that there can be "significant impact" to the specifications
at “extreme
> On Nov 01, 2017, at 05:39, Attila Kinali wrote:
>
> 6-10µs is the interrupt latency of linux on ARM SoC. I guess, to get
> below that you'd have to tweak the kernel a bit. Which should not
> be that difficult. Definitly simpler than writing your own IP and NTP
> stack from
Depends upon the results you are trying to achieve. Using Linux pretty much
guarantees that your server clock will be off by 6-10us, with substantial
variance. Even with a good nic that supports hardware timestamping, the
variance will increase substantially as you go off box (spread spectrum
Back to back with 100Mb is good, particularly for latency tests, but you’ll
need a switch for general testing. FWIW, an otherwise idle switch generally has
very consistent latency, and if both ports are at 100Mb, it is symmetric. Also,
with any kind of managed switch you can easily monitor
See the -b and -n options to gpsctl. Also the -b option to gpsd.
> On Oct 28, 2017, at 15:12, jimlux wrote:
>
> Some emit NMEA sentences, others binary (ublox?) strings?
___
time-nuts mailing list -- time-nuts@febo.com
To
> On Oct 26, 2017, at 19:29, Chris Caudle <ch...@chriscaudle.org> wrote:
>
> On Thu, October 26, 2017 7:38 pm, Denny Page wrote:
>> If you are going to do PTP with ptp4l, or NTP with Chrony, you are going
>> to want hardware timestamping support on the et
If you are going to do PTP with ptp4l, or NTP with Chrony, you are going to
want hardware timestamping support on the ethernet phy. I would view this as
one of the principal concerns in choosing a system.
I’m not sufficiently familiar with Beagles… do any of them support hardware
timestamping?
As noted, the device clock’s offset from the current best estimate of correct
time is on the second line at the far right. The line that begins with “24”,
“AM” or “PM.”
If you tap on the offset, it will trigger a re-sync of NTP time. The offset can
be based on a single NTP server, so it may
If your Ethernet chipset (mac or phy) has timestamping capabilities, you can
use Chrony which has hardware timestamp support. This greatly improves
accuracy, and generally eliminates the CPU loading issue.
Denny
___
time-nuts mailing list --
> On Feb 14, 2017, at 15:14, J. Grizzard wrote:
>
> I really recommend the PC Engines apu2c hardware. Just a touch over $100,
> schematics available, hardware serial port, GPIO, 1588-capable PHY, CPU
> crystal accessible if you want to try a clockblock-type hack,
> On Feb 13, 2017, at 23:47, Hal Murray wrote:
>
> There is a whole class of low power mother boards targeted at the embedded
> market. A few of them have multiple Ethernets - goof for building firewalls.
> I haven't found any low cost ones.
This one might be of
It’s a little more complicated than that. A switch’s main cpu is like a host
with rx coalesce set to 100. And there are a surprising number of things that
trigger the main cpu beyond management functions. Multicast is a good example.
The amount of load on the main cpu can be quite variable, and
> On Jan 13, 2017, at 09:40, Bob Camp wrote:
>
> Just for reference, I happen to be running a ping over my local WiFi to one
> of the switches
> on the LAN. The ping response is anywhere from 2 ms out to 400 ms. Most of
> the time it’s
> in the 3 to 9 ms range. Simply taking
16 matches
Mail list logo