Re: Long running WSPR tx crashing WSJT; recreating issue and narrowing down parameters #wsjt-x-crashing #macOS


Starting next set of experiments to understand and characterize the WSJT long running tx failure.

Next set of experiments: 4a, b, c, d, e, f

Same configuration as Experiment 1 with the following exception:
* changed TX percentage (duty tx cycle) from 90% to 50%
* quit WSJTx and began non stop transmission
* will perform this exactly for 4a, b, c, d, e and f without any config changes
* will summarize experiment outcome results early next week


Results and observations from experiment 4a

* average number of wspr transmissions/hr = 14 using 50% tx duty cycle
* WSJT ran for 25 hours before failure
* The progress bar continued operating; hence part of the sw was operational; not a full P0 / Sev 0 (app fully down / locked / complete unresponsive) as documented in experiment 2 and 3 outcomes
* 349 WSPR contacts logged before failure
* WSJT RAM usage grew from 150.1 baseline starting point to 242 megs of RAM used by WSJT before failure


* Observation notes from experiment 4a:
** RAM utilization was materially higher (at 50% tx duty cycle) before failure relative to the 180 to 190 megs of RAM used by WSJT at 90% duty cycle before failure; delta approx 55 more megs of RAM WSPR tx log stored data before failure. Hence, more WSPR transmissions logged before failure. This is an important tell tale.
** The reduced TX percentage (from 90% to 50%) of course means that less Tx data being created and stored. One could rationalize that I was able to run longer hours before failure - mean time before failure - (25 hrs as opposed to 14 to 18 hrs) because WSJT at 50% duty cycle had less WSPR Tx log entries for the same time frame
** I was able to log 349 WSPR WSJT contacts at 50% duty cycle (experiment 4a) versus approx 280 to 330 WSPR WSJT (experiments 1 to 3) contacts at 90% duty cycle; not a big delta between these (so far). Yet I wonder if the program garbage collection algo and applied method is correct; will I get more contacts using 50% duty cycle for the same time because the program has latency doing garbage clean up? While it is to early to tell without more experiments, it is looking like if you don't quit WSJT and transmit up to a certain ceiling, call it 350 entries(for now) in the WSJT primary screen, you will get a tx failure.



Curious if other WSJT users who eventually have a crash/ failure, regardless of operating system, encounter a WSJT failure when they hit the 330 to 379 transmission entries AND without quitting WSJT. If you quit WSJT before 250 tx entries, you may not ever encounter this crash.

Join to automatically receive all group messages.