Hal Murray writes:
> Most CPU chips include a temperature sensor.
The temperature sensor for the CPU is close to useless unless you have
an SoC with the XO integrated. It tells you a lot about the average
load of the CPU, but not much else.
> For Linux PCs, you need the coretemp module loaded.
Dan Drown :
> Quoting "Eric S. Raymond" :
> >Is the CPU temp going to be a good approximation of what the clock sees,
> >though? I can think of several reasons to doubt it.
>
> It's better than nothing, but it does have two limitations:
>
> 1. the CPU heats itself at a different rate than the su
Quoting "Eric S. Raymond" :
Is the CPU temp going to be a good approximation of what the clock sees,
though? I can think of several reasons to doubt it.
It's better than nothing, but it does have two limitations:
1. the CPU heats itself at a different rate than the surrounding
board, so it
Hal Murray :
>
> e...@thyrsus.com said:
> > I have a USB thermometer on order, they're cheap. Might I suggest you get
> > one and repeat this experiment, actually plotting your temperature
> > variation?
>
> Most CPU chips include a temperature sensor.
>
> For Linux PCs, you need the coretemp
e...@thyrsus.com said:
> One of my agenda items for a while has been to develop a protocol for places
> that want to firewall out NTP for security reasons - that is, a set of
> practices and error estimates based on documented assumptions.
Background data is good. I think you will get into trou
e...@thyrsus.com said:
> I have a USB thermometer on order, they're cheap. Might I suggest you get
> one and repeat this experiment, actually plotting your temperature
> variation?
Most CPU chips include a temperature sensor.
For Linux PCs, you need the coretemp module loaded. The lm-sensors
>> That's from 2008.
>> Was there anything in there that you thought was particularly interesting
or
>> surprising?
> The actual numbers. I've seen the logic before.
That was a long time ago. Any numbers are likely to be misleading. Best to
collect your own. How about "Trust, but verify."
Eric S. Raymond writes:
> Achim Gratz :
>> Forget about GPS outages. If you want to connect these time servers to
>> the net, they should have some form of sanity checking that's
>> independent from their primary time source and take them off the net as
>> soon as something looks fishy.
>
> What k
Achim Gratz :
> Forget about GPS outages. If you want to connect these time servers to
> the net, they should have some form of sanity checking that's
> independent from their primary time source and take them off the net as
> soon as something looks fishy.
What kind of sanity checking do you rec
Eric S. Raymond writes:
> I shall now discuss three interlocking reasons this possibility does
> not loom as large in my mind as it does in Hal's.
[…]
> When I think about this, I consider 10ms total deviation from UTC as
> the target for WAN service. Let's say your local clock drifts by 3ms
> per
Dan Drown writes:
> The GPS module I'm using still outputs PPS even when it loses lock.
> That won't be true for every GPS module.
I also have a NavSpark mini attached at the moment and I was surprised
it kept outputting the PPS when losing 3D lock (it stops blinking the
LED). It seems semi-docum
Dan Drown :
> >We may already be at a technological place where GPS outages don't bust the
> >tolerable-error budget, even with cheap hardware. If we aren't, we'll
> >probably be there soon. One of my medium-term agenda items is to measure
> >and see.
>
> I had setup a test along these lines a we
Hal Murray :
> That's from 2008.
>
> Was there anything in there that you thought was particularly interesting or
> surprising?
The actual numbers. I've seen the logic before.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel m
Daniel Franke :
> On 8/25/16, Eric S. Raymond wrote:
> > (Remember that the user story assumes a big hardware budget.)
>
> A big hardware budget should have room for a rubidium GPSDO,
> in which case you can get away with freerunning for a lot longer.
Yes, that did occur to me. Or, a TCxO like
Quoting "Eric S. Raymond" :
:
Hal objected (off list) to me drawing a conclusion from today's
offset multiplot that check servers aren't necessary when you have
a local GPS - a Stratum 1 really can run autonomously. He said,
correctly of course, that the check servers aren't there to improve
time
On 8/25/16, Eric S. Raymond wrote:
> (Remember that the user story assumes a big hardware budget.)
A big hardware budget should have room for a rubidium GPSDO,
in which case you can get away with freerunning for a lot longer.
___
devel mailing list
deve
Hal Murray :
> It sounds like you are trying to rationalize running without any network
> servers.
One of my agenda items for a while has been to develop a protocol for
places that want to firewall out NTP for security reasons - that is, a
set of practices and error estimates based on documented
That's from 2008.
Was there anything in there that you thought was particularly interesting or
surprising?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
There is lots of good stuff there.
But...
It sounds like you are trying to rationalize running without any network
servers.
Even if you do collect lots of data, you can't extrapolate very far from a
sample of one.
There are many ways to screw up. Even if you get a lot of data, there will
b
ABSTRACT: Most computers have several high-resolution timing sources,
from the programmable interrupt timer to the cycle counter. Yet, even
at a precision of one cycle in ten millions, clocks may drift
significantly in a single second at a clock frequency of several
GHz. When tracing the low-level
20 matches
Mail list logo
