Not sure if this is a red herring but maybe another piece of data for you guys: I was just running Linux Mint and the latest Wsjtx and after my phone died, which had a hotspot the laptop was using, my Rx seemed to get really bad. I couldn't see many signals and couldn't make any more QSOs. Then an operator from Arizona wrote to me and said my clock was off by 2 seconds (or more?). Never had that happen before, at least, no one has ever told me my clock was off.
Note, it was an old laptop, and an old ICOM 706, and the battery was almost dead on the laptop also. Probably just one of those battery related issues or something, but the clock being off seemed atypical, empirically speaking. HTH, 73 Doug KC1UUH On Sun, May 25, 2025, 3:01 PM Nic Sears via wsjt-devel < wsjt-devel@lists.sourceforge.net> wrote: > Could it be a memory leak type of problem? > > Nic G3YEG - ex comms programmer/ debug specialist > > On 25 May 2025 13:23, Glenn Williams via wsjt-devel < > wsjt-devel@lists.sourceforge.net> 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...@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 >
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
