Fwd: Polluted time server causing issues with digital modes
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
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 AMSAT-BB@amsat.org. 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
Frank,
Since getting involved with FT8, I've been using the Meinberg Software on my computers to stay in sync with other stations worldwide. It has served me very well.
Bob K8BL
https://www.meinbergglobal.com/english/productinfo/time-server.htm ________________________________ From: Frank k6fw1@verizon.net To: amsat-bb@amsat.org Sent: Sunday, April 1, 2018 1:41 PM Subject: Re: [amsat-bb] Fwd: Polluted time server causing issues with digital modes
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 AMSAT-BB@amsat.org. 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
_______________________________________________ Sent via AMSAT-BB@amsat.org. 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
Just a reminder regarding my message: I am not criticizing or stating that Dimension4 or any other package that uses round-robin DNS is to fault. It is the one NTP server--rackety.udel.edu--that was causing the problem. Remove this from your configuration options, and avoid it all together, and your time sync package-of-choice will run fine. 73 Brad
On Sun, Apr 1, 2018 at 1:52 PM, R.T.Liddy k8bl@ameritech.net wrote:
Frank,
Since getting involved with FT8, I've been using the Meinberg Software on my computers to stay in sync with other stations worldwide. It has served me very well.
Bob K8BL
https://www.meinbergglobal.com/english/productinfo/time-server.htm ________________________________ From: Frank k6fw1@verizon.net To: amsat-bb@amsat.org Sent: Sunday, April 1, 2018 1:41 PM Subject: Re: [amsat-bb] Fwd: Polluted time server causing issues with digital modes
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 AMSAT-BB@amsat.org. 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
Sent via AMSAT-BB@amsat.org. 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 _______________________________________________ Sent via AMSAT-BB@amsat.org. 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
participants (4)
-
Brad Brooks -
Brad WF7T
-
Frank -
R.T.Liddy