Re: [wsjt-devel] wsjt-devel Digest, Vol 135, Issue 32

[Glenn W. <af...@al...>]

I was inspired to "get with the program"  (pun intended) to ask for
opinions on the 6-second jump problem. The way I did that was to
ask

https://grok.com/    (Artificial Intelligence)

some questions about system time and WSJT-X. In one of the requests
I accidentally hit the Enter key too soon but what Grok came back
with was many pages of good critique.  Not bad by itself.

All three critiques are in

https://hamfaqs.com/wsjtx/

to prevent having that much email here.  Non-programmers will
be happy about that.

-Glenn, AF8C

On 5/25/2025 8:23 AM, Glenn Williams via wsjt-devel wrote:
> 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...@ar...
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> wsjt-devel mailing list
>> wsj...@li...
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> 


-- 
This email has been checked for viruses by Avast antivirus software.
www.avast.com