Please bear the following in mind while considering why you are seeing
DT ≠ 0:
From Bill (G4WJS) a bit further back in this same thread...
"The DT figure is the measured difference between your PC clock and the
sync of a decoded signal. A positive DT implies that the signal clock
is behind yours. Positive components of the DT are the sender's clock
being slow, and propagation delay. Also contributing are latencies
including audio buffering and other processing delay which can be at
either of both ends of the link and like propagation delay can only
increase the DT, net clock difference can contribute a negative or a
positive DT component."
I would be most interested to hear if you tried pushing the limits of
how far out of sync you could push things and still manage decodes. The
guide indicates "A means for synchronizing the computer clock to UTC
within ±1 second". I wonder how far that boundary could be pushed and
what the DT readings would be for, say, someone up to 900ms off. Maybe
I should try it for myself...
Pardon my idle musings. I would be inclined to agree, even before the
testing, that this falls under the "tempest in a teapot" category.
Best,
AI4FU(Jim)
On Wednesday, December 5, 2018 at 6:48 PM, John Kludt
wrote:
Yeah, the one thing I have wondered about is all the the version to
version -X variance in protocols that are out there right now. How
does everyone know the decode failures are related to DT and not
72/75/77 bit issues? Checking against Time.Is my computer's are
always spot on and I almost never see a DT of zero. I also don't
seem to have decoding problems.
I use Net Time Sync on both Win 7 and Win 10 machines for both
terrestrial and EME FT8/JT65.
Anyway, following the thread with interest and hoping we do not
over,- engineer the solution when the cause is a bit unclear
John
Sent from my Verizon Motorola Smartphone
On Dec 5, 2018 6:30 PM, David Fisher wrote:
Since I apparently put the match to this issue, I’m going to run an
experiment.
I normally run my Win 10 Pro (homebuilt) computer with the Meinberg
NTP service. It has worked extremely well. But, it has also been
said that the Windows service may be fine. So, let’s find out.
I’ve disabled Meinberg on my computer and reenabled the WTS. I’ve
verified, and will continue to verify, that these setting stick
across reboots. They are. The hardware clock on this computer has
some miles on it and runs a bit slow, so whatever time service I
use, it has some work to do.
Before someone jumps on it – this is Windows 10 PRO, not Home. It’s
running 1809, and updates regularly as the patches come out. The
system runs will and is reliable.
I’ll keep an eye on “DT” readings and compare the system clock with
WWV from time to time. I’ll report what I find. Maybe this is a
tempest in a teapot.
Dave / NX6D
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
