I looked at my log since 2009, my copy of Dimension 4 has never used this time sever. The notes on this time server states closed and only for use by networks of 10 or more computers. Matter of fact my Dimension 4 has only connected to the same time server since 2009. I don't know what controls Dimension 4 and which time server it uses, but it does not seem to be random. I agree that if a station is using a time server that is not accurate then the modes that rely on precise time syncing will not work.
Frank K6FW
On 3/31/18 10:37 PM, Brad WF7T wrote:
I am forwarding this for anyone interested. I think my discovery is correct and invite additional review/scrutiny.
73 Brad WF7T
On Sunday, April 1, 2018 at 12:21:36 AM UTC-5, Brad WF7T wrote:
*I have discovered a polluted time server that is wreaking havoc with time-synced digital modes, and worse. For everyone using round-robin style time synchronization like Dimension 4, please remove the following time server: rackety.udel.edu http://rackety.udel.edu.* It is consistently sending time sync corrections that are between 10 and 41 seconds different than every other SNTP server in the world. This will cause your PC clocks to skip this amount and stay that way until another time sync occurs, e.g. 5 to 15 minutes later, causing another massive time correction by another accurate time NTP server. Please pass this information along to all digital-active hams.
While this amount of time is not of any consequence for RTTY, PSK and the like, this behavior is detrimental to WSJT and QRSS modes. Terrestrial WSJT modes like FT8, WSPR, Meteor scatter MSK144, and EME modes fail to decode and will cause out of sequence transmissions.
I also noticed a number of out-of-sequence FT8 tranmissions on 40M this afternoon (BTW, open early to EU), which clued me into the situation. This messed up time server could have been a contributor.
*Remove or disable the following server: rackety.udel.edu http://rackety.udel.edu.* Apparently it has been getting increasingly worse since 3/8/2018 or so. I only discovered this tonight while I was decoding WSPR on 474.2KHz (630M) and saw a huge time jump and lack of decodes of some fairly strong signals.
And yes, this is also an InfoSec problem. Time bases are important for MANY Information Security purposes, but beyond the scope of this discussion.
Excerpts of my Dimension4 time-base logs below. Please contact me with questions/comments.
73 Brad WF7T Nashville, TN
... First noted occurrence in my time-base logs
2018-03-07 10:36:44.461 -7.962988e+000 rackety.udel.edu SNTP <-- 7 second correction 2018-03-07 10:39:52.480 7.980464e+000 clock-1.cs.cmu.edu SNTP <-- fixed on next round-robin sync
... Persists for a second day, appearing to get worse
2018-03-08 09:17:25.217 -1.015543e+001 rackety.udel.edu SNTP <-- 10 second correction 2018-03-08 09:20:35.240 9.963055e+000 clock-1.cs.cmu.edu SNTP <-- Fixed on next round-robin sync
... Jump ahead a week; yup, getting worse
2018-03-15 05:34:10.880 -1.761963e+001 rackety.udel.edu SNTP <-- 17 second correction 2018-03-15 05:37:29.176 1.812267e+001 ntp.cais.rnp.br SNTP <-- Fixed on next round-robin sync
... Skipping ahead to tonight; SNAFU
2018-03-31 23:29:34.849 -4.165045e+001 rackety.udel.edu SNTP <-- 41.6 second correction! 2018-03-31 23:33:35.421 4.192192e+001 ntp2.kansas.net SNTP <-- fixed on next round-robin sync
Sent via [email protected]. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://www.amsat.org/mailman/listinfo/amsat-bb