Need Time Help
For the group. This ham is trying to work EME. Earth-Moon-Earth propagation
path. Aka, "moonbounce."
He is trying to time synchronize a system, where the other station he is
communicating
with can be any other place on the Earth that can also see the Moon.
So the system time sync is for a little bit tougher case than a local area
network.
--- Graham
==
On Wed, Oct 5, 2016 at 6:14 AM, Bob Camp kb8tq@n1k.org wrote:
Hi
If you buy a GPS receiver and get it set up for timing …. just use it.
Then there is no
need for NTP at all….
Bob
On Oct 5, 2016, at 12:33 AM, Chris Albertson albertson.chris@gmail.com
wrote:
On Tue, Oct 4, 2016 at 6:52 PM, Bob Camp kb8tq@n1k.org wrote:
Hi
If:
- You are a typical Ham in a home environment
- All the servers are “out there” on the internet
- You have any of the normal modems feeding your home
You have a very basic issue in terms of path delay. All the servers you
can access
have the same asymmetric delay. In that case, no matter how many
servers
you
add to the ensemble, the situation never gets better. You are always
stuck
with the
(likely unknown) uplink / downlink delay difference of your modem.
Exactly
what
that number is depends a lot on the modern and the system feeding the
modem.
It is very possible to see static delay asymmetry well beyond the 5 ms
that the OP is after.
On most systems there is also a dynamic asymmetry that is related to
loading. That
just makes things harder to work out …..
But this is easy to measure, you buy a GPS receiver and use that as an
8th
or 6th reference clock along with the 5 or 7 Internet servers then you
look
at the difference between GPS and the Internet servers. The Internet
servers do much better than you'd think. Not as good as GPS but really
good. Why?
Because NTP normally never actually sets you clock to match a server's
clock. It adjusts the RATE of your clock so the it cruises on the
middle
of the pack of vetted servers. It adjusts your clock over a long period
to
it has the benefit of averaging out lots of random behavior. The result
is that you can keep within a few milliseconds of the GPS even with tens
of
millisecond of delay in the communication path.
For people new to NTP, the algorithm has it's hands the system clocks
"fast/Slow? lever and never normally moves the clocks hands directly
And all those Internet servers do NOT have the same asymmetric delay.
Well
they might but that would be a pathological case. Typically delays
really
are more symmetric than not (one way trip really is 1/2 the round trip)
The clocks that don't meet this assumption are found and removed from the
pool. It works because the dells are NOT the same but random Ans like
I
said, it is easy enough to measure. You can see that peer offsets are
all
over the map
Also your modem is likely not causing an asymmetric delay. That modern
wetter is is the old phone kind or a fiber optic system only takes you to
the fist router. The modern likely has the same time of flight in both
directions. The delay is cause by a queue some place of packets that
are
aggregated from many users. These are random but sort of predictable.
A
packet going across a continent or will see more of this then going to a
nearby server
wrote:
The problem, I think with your Internet sync's NTP servers is you are
only
using one server S. The most common practice is to use 3 to 5 with 5
being
about the right number. If you get Ntp enough Internet servers to
work
with it can detect problem like asymmetric path lengths which I'm sure
is
you problem.
NTP solved the problem that stumped a few people back in the 1970's of
how
to sync two clocks when there is a long delay and not constant in there
communications path. (Of course the problem is simple if the delay is
known and well measured) But the solution required the the average
path
delay is the same going in each direction. worse no software can't
know
there is an asymmetric delay. Well not unless it is using a few
servers.
NTP basically finds then ignores the "problem servers".
PTP solves the problem by requiring that all the network hardware has
special time stamp ability that is designed to work with PTP. This
hardware is rare unless the user provides it. So PTP can't really work
on
the public Internet.
You CAN do very well, to just a few Millisecond using NTP sync'ing to
Internet servers, but pick 5 of them or even 7. and make sure they are
dispersed and not all at the same place.
On Tue, Oct 4, 2016 at 2:34 PM, Attila Kinali attila@kinali.ch
wrote:
On Tue, 4 Oct 2016 15:41:58 +1100
Larry Hower hower@hower.net wrote:
Ultimately we want sub-millisecond accuracy.
If you want to go that way, you will have to leave windows as
this operating system does not offer the facilities to get down
to such a low level....Unless you calibrate the whole path by
injecting
a time pulse into the signal path like Jim Lux and TvB suggested
With linux you can get systems synchronized to better than 1ms by
using a PTP server in the local network or by directly using PPS.
This should get you in the order of better than 100µs probaly 20-30µs.
BTW: A word of advice against using NTP servers over the internet
for accurate time distribution. I recently set-up two NTP servers
to be used as stratum 2 servers (server A and B). Both synchronize
to the same stratum 1 server (server S), but are at different ISPs
and thus use different paths. NTP on both A and B reports the
following
values (current snapshot, values are representative):
Link delay offset jitter
A-S 4.205 0.020 0.081
B-S 2.112 0.039 0.079
A-B 0.606 -0.877 3.192 (as reported by A)
I.e. even though A and B use the same server S as reference, the
time difference between both servers is 800-900µs. I am not sure
where this path asymmetry comes from, but my guess would be on
the connectivity of A (there are two groups of stratum 2 it syncs
to and one of them shows the same ~900µs offset). I also do not
know why the jitter between A and B is so large even though the
delay is pretty low (seems to be a weirdness at a router inbetween).
Attila Kinali
--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
I must admit to being rather puzzled at the sub microsecond timing
requirement as I use ntp to set the W7 clock in my computer and have not
had any issues. In fact less than one second is OK for the usual two
minute periods that are required to allow for the Faraday rotation.
Although I use a GPSDO for a frequency reference I find JT software
reasonably tolerant of frequency. As I may be missing something I would
welcome observations on how important the period timing requirement is,
you never know I might get more contacts.
Regards
Peter
On 05/10/2016 12:50, Graham / KE9H wrote:
For the group. This ham is trying to work EME. Earth-Moon-Earth propagation
path. Aka, "moonbounce."
He is trying to time synchronize a system, where the other station he is
communicating
with can be any other place on the Earth that can also see the Moon.
So the system time sync is for a little bit tougher case than a local area
network.
--- Graham
Yes I'd be curious in knowing more about this as well. I've often observed time differences from other stations of several tenths of a second when running the JT modes on HF. Although I am beginner at EME I have made a couple of EME (earth moon earth) JT65 contacts on VHF without taking any special measures to sync the time on a Windows XP machine beyond using the built in features of the operating system to sync to my own local time server which was in turned synced to the 1 pps output of a GPS timing receiver.
I've also made FSK441 contacts (another related form of amateur radio digital communications) in the field without any time reference besides the free running clock in my Windows xp laptop. If there is a significant performance improvement to be had with these modes by having time nuts levels of timing precision on my computers I'd be very interested to know more.
All the best
Mark S
Sent from my iPhone
On Oct 5, 2016, at 6:18 AM, Peter Torry via time-nuts time-nuts@febo.com wrote:
I must admit to being rather puzzled at the sub microsecond timing requirement as I use ntp to set the W7 clock in my computer and have not had any issues. In fact less than one second is OK for the usual two minute periods that are required to allow for the Faraday rotation. Although I use a GPSDO for a frequency reference I find JT software reasonably tolerant of frequency. As I may be missing something I would welcome observations on how important the period timing requirement is, you never know I might get more contacts.
Regards
Peter
On 05/10/2016 12:50, Graham / KE9H wrote:
For the group. This ham is trying to work EME. Earth-Moon-Earth propagation
path. Aka, "moonbounce."
He is trying to time synchronize a system, where the other station he is
communicating
with can be any other place on the Earth that can also see the Moon.
So the system time sync is for a little bit tougher case than a local area
network.
--- Graham
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
On Wed, October 5, 2016 6:14 am, Bob Camp wrote:
If you buy a GPS receiver and get it set up for timing, just use it.
Then there is no need for NTP at all.
Is there another way to get computer system time set from a GPS receiver
other than NTP?
In the case that the system clock is controlled by GPSDO and the seconds
delineated by PPS, there should be no need for the NTP clock discipline
code, but I am not aware of any way to inform the NTP daemon that no
disciplining is needed. Presumably the code should determine that
eventually.
In the case that the system clock is free running, the clock discipline is
still needed, but I found a note in one of the NTP documents (that I can
no longer locate at the moment) that stated something to the effect that
NTP did not run well as it could with a single reference, which would seem
to directly affect the case where a GPS receiver is the only reference.
That document had only that short note, no details on why or specifics of
behavior.
--
Chris Caudle
If you are working "real" EME where you, and not a computer plus lookup table,
are coping the signals, none of these precise timing issues exist.
Wes N7WS
On 10/5/2016 6:18 AM, Peter Torry via time-nuts wrote:
I must admit to being rather puzzled at the sub microsecond timing requirement
as I use ntp to set the W7 clock in my computer and have not had any issues.
In fact less than one second is OK for the usual two minute periods that are
required to allow for the Faraday rotation. Although I use a GPSDO for a
frequency reference I find JT software reasonably tolerant of frequency. As I
may be missing something I would welcome observations on how important the
period timing requirement is, you never know I might get more contacts.
Regards
Peter
On 05/10/2016 12:50, Graham / KE9H wrote:
For the group. This ham is trying to work EME. Earth-Moon-Earth propagation
path. Aka, "moonbounce."
He is trying to time synchronize a system, where the other station he is
communicating
with can be any other place on the Earth that can also see the Moon.
So the system time sync is for a little bit tougher case than a local area
network.
--- Graham
In practice I'm not convinced the timing requirements for the JT modes in question are even more than a single order of magnitude more severe than the when I have been timing 15 second sequences on my wrist watch during manual non computer aided weak signal operations. To recap if some one has data or direct personal experience to make the case that extreme levels of timing accuracy will help I'd be interested in seeing this.
That being said I do believe it makes sense to fully use what ever timing resources one has access to.
All the best
Mark S
Sent from my iPhone
On Oct 5, 2016, at 9:47 AM, Wes wes@triconet.org wrote:
If you are working "real" EME where you, and not a computer plus lookup table, are coping the signals, none of these precise timing issues exist.
Wes N7WS
On 10/5/2016 6:18 AM, Peter Torry via time-nuts wrote:
I must admit to being rather puzzled at the sub microsecond timing requirement as I use ntp to set the W7 clock in my computer and have not had any issues. In fact less than one second is OK for the usual two minute periods that are required to allow for the Faraday rotation. Although I use a GPSDO for a frequency reference I find JT software reasonably tolerant of frequency. As I may be missing something I would welcome observations on how important the period timing requirement is, you never know I might get more contacts.
Regards
Peter
On 05/10/2016 12:50, Graham / KE9H wrote:
For the group. This ham is trying to work EME. Earth-Moon-Earth propagation
path. Aka, "moonbounce."
He is trying to time synchronize a system, where the other station he is
communicating
with can be any other place on the Earth that can also see the Moon.
So the system time sync is for a little bit tougher case than a local area
network.
--- Graham
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Yo Chris!
On Wed, 5 Oct 2016 10:19:10 -0500
"Chris Caudle" chris@chriscaudle.org wrote:
On Wed, October 5, 2016 6:14 am, Bob Camp wrote:
If you buy a GPS receiver and get it set up for timing, just use it.
Then there is no need for NTP at all.
Is there another way to get computer system time set from a GPS
receiver other than NTP?
gpsd.
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Yo Bob!
On Wed, 5 Oct 2016 07:14:30 -0400
Bob Camp kb8tq@n1k.org wrote:
If you buy a GPS receiver and get it set up for timing …. just use
it. Then there is no need for NTP at all….
Assuming your GPS never farts and always has a good lock. A pretty
good assumption, but not a perfect one.
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
I agree that the built in Microsoft tools are SNTP only and will not work
at the 15ms level.
I have had excellent success with Windows PC's of many vintages, from XP
through Windows 10, using Meinberg NTPD and the "pool.ntp.org" timeservers.
Tim N3QE
On Tue, Oct 4, 2016 at 12:41 AM, Larry Hower hower@hower.net wrote:
Hello to the List:
After a long and bitter struggle with XP and WIN 10, I am writing to ask
for some help in solving some problems we have been having in our attempt
to establish a very accurate time reference for use in EME activities.
We are hoping to achieve less than 5ms deviation, although anything below
15ms will be adequate for now.
Specifically, we want to use a universal reference that will enable amateur
radio operators in different parts of the world to start and stop their
transmissions within a few milliseconds of a specific time. For example, I
transmit at 12:00:00 for 1.75 minutes and “Joe” listens. Then “Joe”
transmits at 12:02:00 for 1.75 minutes. Repeat until QSO happens.
We are using WSJT-X software. We use standard receivers plus we have tried
a few SDRs.
Sorry for the oversimplified example but I want to make sure we are all on
the same page.
As background:
-
We are using desktops and laptops in separate locations running XP or
Win 10. -
We have used MS clock tools, including use of Boulder time servers,
tried both host name and IP address, without reaching the goal. -
We have set up some Serial GPS units with PPS and some USB GPS receivers
(no PPS) and can get to about 0.2 sec but it is not trusted or close
enough. -
We have set up a network time server with similar results.
-
Deviation is measured using WSJT-X
Standard Receivers
ICOMs (910/9100 and others – non-SDR). Locked to 10MHz external osc
reference. We have frequency accuracy of 1 to 2 Hertz at 10GHz.
SDRs
We believe that SDR processing can insert a delay of varying length,
depending on the software, bandwidth, etc. Our SDR tests seem to have a
delay of as much as 0.5 sec. And with sometimes variable results. We will
see how SDRs can be used after we resolve the current issues.
Some time related hardware details
1. Global Star 4 USB and Serial Connections
http://usglobalsat.com/p-688-bu-353-s4.aspx#images/product/large/688.jpg
We have 4 of these. Two are older models with serial connections. We have
serial ports on some computers (XP and a new high-end laptop running WIN
10) so we are able to activate the PPS option. Two of the GStar are newer
models with USB connections which are not able to use the PPS option.
We have tried NEMATime and NEMATime 2 software on this hardware without
reaching our goal of <15ms. Range of deviation is from 0.0 to about 0.3
sec. Drifts. Deviation is measured using WSJT-X.
2. TimeNet NTP Device
http://www.veracityglobal.com/products/networked-video-integ
ration-devices/timenet.aspx
We have one of these TimNet units and it has been set up at 2 different
locations on differing computers according to user instructions. We are
using the TimNet software as DL'd recently from their web site. We get GPS
“lock” and Time “lock” shown in the user panel but we do not have faith
that this is carried into the system clock. Occasionally the "lock"
indicators go blank but the time seems to be updated when the software is
strted again (the updated is operation is show at the correct time. We
think the app needs some work. Deviation is measured using WSJT-X. See
later details.
Setup
The G Star units have been installed at 2 separate locations, tested using
WSJT-X QRA 64 and WSPR-2 signals on 10.137MHz.
Similar tests with a TimeNet unit at one end and G Stars at the other end.
G Star units were installed on the XP laptops with the PPS option enabled
and running WSJT-X. These XP units seem to have their time “in sync”. See
following.
WSJT-X
We are not sure what, if any, internal delays there are attributable to
this software. We have been using the same version/build at both ends for
the tests. The software displays in 0.1 sec increments but will show 0.0sec
when things appear to be working well. We do not know the actual level of
precision of the WSJT-X software time measurements. I undersand that WSJT-X
“reads” the system clock at the start of a period (TX or RX) and displays
what it finds as the time deviation from the local system clock.
WIN XP
There are 2 laptops running XP. They seem to match each other re time using
WSJT-X, both are “out” usually by less than 0.1ms or 0.2ms. We are fairly
sure that they are working properly but they need to be more accurate
(<15ms).
WIN 10
Installed on a number of desktop and laptop computers. Many efforts were
made to make these system clocks reference the GPS devices.
We became aware that the WIN Time/Date GUI was not always driving the
setting down into the system clock. We became aware also that the Registry
entries needed to be confirmed as far as NTP or local reference and the
sync cycle needed definition because of the same unreliable GUI actions.
We found that we needed to start the Time Services and deal with some other
factors. We have found that in WIN 10 the time/date clock does not show
the update when it happens automatically according to the setting in the
directly. It does how the correct time of sync when we do it manually or
restart the GUI.
The end result is that we don't trust WIN 10 and and we are not sure how to
fix the problem. Linux not allowed for now.
Status
Our conclusion is that the external gear should be able to provide a more
accurate reference than we are able to obtain presently. We think "it is
in there somewhere" but we can't get it out.
We have a feeling that the WIN system clocks are not being updated
correctly or at least in a repeatable manner. We don't know if the problem
is hardwaare or software or our setup / configurations.
I ask for advice on how we can use the above gear or other gear or other
software to have our setup deliver better than 15ms accuracy.
Ultimately we want sub-millisecond accuracy.
Any help will be very much appreciated. Thanks in advance for anything you
can advise.
73,
Larry Hower
VK7WLH
W0LH
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
Hi
Given that this is for intermittent EME use, it’s not a system that has uber
reliability as a requirement. Once you get the antenna up in a reasonable location
a GPS is going to be pretty stable and reliable. If you have an EME array
running, adding a GPS antenna to it probably not a big deal.
If it is a big deal, run a GPSDO and then it’s no longer a problem. The KS
boxes still seem to be out there for < $100 ….
Bob
On Oct 5, 2016, at 2:32 PM, Gary E. Miller gem@rellim.com wrote:
Yo Bob!
On Wed, 5 Oct 2016 07:14:30 -0400
Bob Camp kb8tq@n1k.org wrote:
If you buy a GPS receiver and get it set up for timing …. just use
it. Then there is no need for NTP at all….
Assuming your GPS never farts and always has a good lock. A pretty
good assumption, but not a perfect one.
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.