Hi Everyone
I am hoping one of you may be able to help with a specific problem?
Some time ago, I purchased the excellent LeoNTP time server available here:-
https://store.uputronics.com/index.php?route=product/product=60_70_id=92
It serves network time via NTP over Ethernet primarily but it
> Le 28 mai 2019 à 16:38, Eric Scace a écrit :
>
> Hi fellow time nuts —
>
> I’m looking for a sanity check or alternative suggestions for the problem
> and tentative solution described below.
You have a situation where the application in any one system is unaware of the
validity of the
> Le 27 mai 2019 à 11:13, Dave B via time-nuts a
> écrit :
>
> Hi.
>
> This from the recent ShortWave Radiogram broadcast, may be of interest.
>
> ~ ~ ~
>
> (Snipped stuff about other SI units undergoing a revamp...)
>
> Scientists now have their sights set on updating the unit of
> time:
On Sunday, May 26, 2019, 7:24:31 AM PDT, Attila Kinali
wrote:
As you state that you are familiar with PLL design, I guess your confusion
comes from having a 1Hz signal and trying to use that for a "normal" phase
detector. While this is possible and can be done, it leads imediatly to
the
Hi Eric,
> 2. Date/time stamps in the data shall be rounded to the nearest EVEN
second by the system instances
That's a clever way to both mask accuracy & uncertainty and to avoid
leap seconds. Still, it smells like a hack, unfit for the 21st century.
But I feel your pain.
BTW, this is
Here is the exact output from my XLi. There are extra lines for F18 and F72
but not F73.
>F18
F18 BOOTLOADER 192-8000
SOFTWARE192-8001
FILE SYSTEM 192-8002V2.0
PROJ REV # 2.0
FPGA # 184-8000V64
>F72
F72 CLOCK PLL LOCKED
CLOCK STATUS
Something to think about. Leap seconds.
But that said I suspect the reason for the reasonable time is that many
publishers wouldn't have access to a solid time source like GPS or some
other universal reference.
Really agree with Mike on the litigation aspect and the need for accurate
time. How do
If the data collected by your system could potentially be used in
litigation , I would reconsider your accuracy requirement, especially
the OKness of simultaneous transactions.
I assume that all nodes can write to the blockchain; how do you sanity
check if one node's clock is wildly off?
Hi fellow time nuts —
I’m looking for a sanity check or alternative suggestions for the problem
and tentative solution described below.
Thanks for your thoughts.
— Eric
Problem:
In one of my day jobs, I am designing a global network of systems (using
open-source software) that
On 5/28/19 2:12 AM, Attila Kinali wrote:
On Tue, 28 May 2019 03:06:12 +0100
Another way to look at it is, before you reach the point where the
redefinition of the kg change becomes visible, other errors like
buoyancy of air will introduce errors that are orders of magnitude
largers
I would broaden your experiment to try many different remote servers.
Maybe using different chunks of the global NTP pool
(https://www.ntppool.org/en/use.html)
It could be traffic shaping on your ISP , an ISP in the middle, or one
on the remote end.
It could be traffic prioritization
On Tue, 28 May 2019 03:06:12 +0100
"Dr. David Kirkby" wrote:
> I notice a lot of 1 kg weights on eBay, so perhaps the same will happen
> with Cs clocks!
This is rather unlikely. For one, Cs beam standards have a very limited
life span. For an other I am pretty sure that the surge of kg weight
12 matches
Mail list logo
