From: Hal Murray
On the Raspberry Pi, the Ethernet is on USB so there is another source of
timing error. It's full speed USB rather than low speed USB so the timing
noise isn't as bad as it could be - 1/8 ms vs 1 ms. (I could be off on the
numbers or names, but the general idea is correct.)
strom...@nexgo.de said:
> Over wired Ethernet you can expect to synchronize a bunch of systems to
> within a ~200µs envelope of absolute time and maybe a factor of 2x-3x lower
> if you can control certain things more tightly than usual if you run those
> system on a single hop switched LAN
Charles Wyble wrote:
I built a dedicated server room in my house, with it's own air
conditioner. I've been working on overall instrumentation , especially
temperature.
If the rasPi is a dedicated system and does not serve extra tasks, just
record its CPU temperature, no extra sensor needed.
Charles Wyble wrote:
> I’m using a raspberry pi with gps hat for my master time source.
> Shortly I’ll be having a total of three systems (two using the same
> hat, one using the adafruit hat and being a pi2). I’ve got some
> interest in multiple way comparison and will follow this thread
>
Hi
There also are a lot of papers going back a ways by Jim Barnes and
David Alan (sometimes together and sometimes separately) related
to multiple clocks driving a single “estimate” of what time it actually is.
Bob
> On Dec 27, 2018, at 2:34 PM, Steve Allen wrote:
>
> On Wed
It looks like the image I sent got trimmed off. Did I do something wrong?
Regards,
Jerry
> On Dec 26, 2018, at 4:21 PM, Jerry Hancock wrote:
>
> The other issue is application priority in windows. Here’s an example. I
> have a timer running at .75 seconds in Visual Basic. To the left is
The other issue is application priority in windows. Here’s an example. I have
a timer running at .75 seconds in Visual Basic. To the left is normal priority
and to the right I set the application to real time priority in device manager.
I then calculated the time between timer interrupts. I
t...@leapsecond.com said:
> But most people have only one counter (one internal or external timebase
> reference) and one clock to be measured. So the measurements are one-to-one.
> If you have more references or more clocks, you're welcome to combine 2, or
> 3, or as many as you want. It gets
Thanks!
No, I don't really have a specific use case.
And your reply is very helpful in my continuing education!
I had wondered how to do something like this.
I always got stuck on how to know which signal came from which clock.
But it came up again in my mind when I was watching a waterfall
> I see the different forms of deviation measurements and they are all
> one-to-one comparisons.
Not all. But, yes, often. UTC itself is a wonderful example of making mutual
measurements of several hundred atomic clocks and establishing a superior
"paper" clock out of them collectively.
But
Hi
One simple answer is that it’s not always 1:1 comparisons. The “three corner
hat”
approach is indeed used to compare three devices at one time. There are some
issues with doing that. There are *lots* of papers on where the limits come
from
and what you need to do ( = pick fairly similar
Relatively good resolution. Relative to what? :)
Deviation requires you have something to measure against. A “source of truth”.
So what are you measuring deviation from?
From a system administration perspective , I want all my systems to be
consistent. I’ll say that
right == consistently
I see the different forms of deviation measurements and they are all
one-to-one comparisons.
Is there anything to be learned from doing mass data gathering?
For example, if I had a device of relatively good resolution that would
let me
timestamp the events from 100 different clocks, then
13 matches
Mail list logo
