Evidence:
1 Linux time is always correct and advances monotonically.
2 Restarting WSJT-X for WSPR fixes the problem.
3 No one has mentioned this about WSJT-X running, for example, FT8. (?)
4 But does this happen on machines that run different motherboards and
or processors (i.e. Intel vs AMD vs ARM)? At least we know that it
happens with different flavors of Linux.Conclusions:
1 Inside the WSPR code there is a (let's call it) "register" that has
been informed of Linux time at the start of WSJT-X execution.
2 Guess: Perhaps the register does not contain enough bits for holding
Linux time and when the register reaches maximum count it overflows and
resets to 000000... (But time jumping ahead does not agree with
this prediction because a reset would be backwards.)
3 The delta of 6 seconds is a clue to how many counts are missed at the
least significant bits end of the register.
4 In the code someone left out a CONST declaration. Etc.
5 It's a fixable bug.
6 WSPR code was at least partially written by someone different from the
other code(s) so that declarations of variables are different.
7 Or it's caused by some other "bug". A family tree of possible bugs
is larger than what I am imagining. See 5.
8 I am probably be wrong again. :)I could subscribe to the Digest. But maybe I don't want that much email.
--Glenn, AF8C
On 5/24/2025 5:26 PM, Paul Simon via wsjt-devel wrote:
> On 5/23/2025 9:16 AM, Josh Rovero via wsjt-devel wrote:
>> I see similar behavior about every 72 hours or so on Fedora Core 41,
>> 64-bit.
>>
>> Restarting wsjtx seems to cure it for another 72 hours ..
>>
>> Josh Rovero
>> KK1D
>>
>
> ------------------------------------------
>>
>> I have been running wspr 24/7 using the linux version of wsjtx.
>> After
>> about two days, dt seems to increase by 6 seconds, in a single jump,
>> not
>> gradually. This does not happen on Windows.
>>
>> 1. The same happens on two different machines running Ubuntu and
>> Mageia,v 2.61 and v 2.7.0-rc8.
>>
>> 2. Computer clock is correct: checked vs. time.is <http://time.is>,
>> NIST controlled
>> clock, etc. Time measured manually is within one second.
>>
>> 3. Closing and reopening wsjtx immediately results in correct dt.
>>
>> 4. Running wsjtx under WINE gives same result.
>>
>> 5. Waterfall timing is correct and can see the six second early
>> start of
>> sequence.
>>
>> 6. Only happens if transmit box is ticked.
>>
>> Could someone please confirm and/or suggest possible solutions?
>>
>> Paul W6EXT
>>
>
> ---------------
> Well, good luck Josh. No response from anyone else. No developers
> either. Some of the links on the SourceForge pages are dead. One of the
> SourceForge pages states that WSPR is of historical interest.
>
>
> "So Long, and Thanks for All the Fish"
>
> Paul, w6...@arrl.net
>
>
>
>
>
>
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel--
This email has been checked for viruses by Avast antivirus software.
www.avast.com_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
