Hi Lewis, Here is a sample data-point related to processor load, on the RPI 2. Stepping from Idle to full load on 4 cores resulted in a temp rise near the XO of approximately 14 degC, and correspondingly the XO shifted 3.6 PPM.
On Sat, Dec 3, 2016 at 10:29 AM, MLewis <[email protected]> wrote: > So much to absorb and learn from what people have responded with. > > Thanks all! > > On 01/12/2016 12:01 PM, Chris Albertson wrote: > >> OK, now I know what you need. Millisecond level time on the data >> processing machine. ... Let's assume you were able to set up a local NTP >> server that runs off it's >> own GPS reference clock. ... about 100x better then you >> need. ... Ethernet is not perfect but good enough for what you want. >> > That's the take I have on it. > > I really doubt varying processing load is an issue with NTP. ... What >> happens is >> the PPS causes an interrupt and inside the handler the nanosecond clock is >> sampled and copied to memory. The handler has something like 8 lines of >> code and runs very fast. >> > That's good to know about PPS, 'cause the computer's load while polling > hosts over the internet is getting me horrible variance in offsets. > > The other thing you might look at is NOT using NTP but using PTP. >> > Looks like fun, but way better than I need. More than I can afford too. > > I don't think your measurements are measuring correctly. ... Any offset is >> perfectly fine, that is simple the communications delay and is accounted >> for by NTP. ... If you were looking at >> offset, just don't do that. >> > O.K.. I'm pretty sure I don't understand that, but the issue I found was > not that different hosts offsets varied from one another, but that the > offset reported by "a" host would jump around. And when the load on the > computer was changing, low-to-high or high-to-low, several hosts', > sometimes all hosts, offsets jump around, with that multi-host variance > continuing for some minutes after the computer was running at the new load. > This settled down a little when I turned core parking off, but only a > little. I've attached a sample of the offsets I'm getting to show this > variance. Oddly, a sustained higher load would often settle the variance > and give the most consistent results: one such period is between poll 6 & > 10 on the "test run N24" attachment, and the graph shows the offset slope > and hosts' offset variances as the load moves from heavy to medium and then > light. > > After giving up on SMAs to tame individual host's offsets, to get a usable > offset from the reported offsets I implemented a cascade of filters: > applying factors on standard deviation to implement truncation means to > remove outliers, then winsorizing means, with independent bias factors > applied to selection and winsorization. This all worked rather well once I > tuned the filters' parameters. Then the variance got worse, so I added some > increasing attenuation on increasing corrected offset values and that made > my corrected offset usable within the tolerance I needed, until from a > certain date the reported offsets went all over the map. > > But we shouldn't go down this road, other than curiosity (and I wish I had > the time to explore the why), as going to a separate machine as an NTP host > removes all of those types of issues. And I don't have to grow my own > code... > > I think your only problem is finding a GPS with PPS output that works at >> your location. Don't worry much more. If it works and has PPS it is >> good >> enough >> > Exactly. > Any module that can get a usable GPS signal can discipline time and be > delivered over my local Ethernet to better than I need. > > You might have a "Plan B", ... >> > Thanks for those. Good to know. > > > > I believe the location issues narrows it down to the MAX-M8Q or the > NEO-M8T. > > Both have great sensitivity, but their firmware varies to address intent. > The M8Q can be explicitly set to Dynamic-Mode-Stationary (as it should go > to automatically with an unmoving antenna) and the M8T will set there as it > moves to focusing on a better time solution after establishing a location > fix. In comparing their product descriptions, the M8T seems the better > choice while sitting still for obtaining usable results in questionable > locations, but - speculating - that wording may be marketing wording in > response to prior issues with earlier T series modules. And so far, I've > not found any accounts of first hand experience with a M8T. > > The other issue is what breakout board the modules are available on. > - With the M8Q, there's hats or boards that can connect direct to a Pi or > such, but lack protection with supply voltage or outputs if I want to feed > them to another computer. > - And the M8T is available on a board that provides power regulation and > some protection, so that should be able to feed NEMA & PPS to any suitable > computer without risk. > - And I found a board that accepts GPS modules-on-breakout, protects them, > and can feed any computer, but the breakout boards with M8Q or M8T have > pins don't match the header. A small custom cable would fix that. > > But without trying them, I can't Know which will be best by my location. > Or if my location means one will work and the other won't... > > (waiting to do that GPS sat test at my location...) > > > _______________________________________________ > 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.
