You have probably seen my earlier posts tracking down the cause of lost decode cycles, or more often, decoding just completely stops on a new HP laptop when CPU utilization is < 10%. Above that all is fine. This is on a new 8th gen Core i5 8265U, Intel UHD620 GPU, 8GB RAM, 256GB SSD, and 1366x720 display. USB audio and internal Realtek sound devices. Laptop lid open or closed, no matter.
The final solution here was to set the Display timeout to Never. I normally only RDP to this machine and the lid is always closed, so the display would normally shut off for that reason. Never thought a timer setting would still matter, but it does. After many long hours (over 5 weeks' worth) of testing and experimenting with every setting and program combination you could imagine, debug builds, changing C states, latency analysis, I noticed a loose correlation with decoding usually working the first several minutes after a reboot before coming to an end and a display setting. The "Turn Off Display after XX minutes" option in the Advanced Power Options menu. I am thinking that the display (and external graphics HDMI connector) is always forced on after a reboot, or attempts to at least. Setting it to "Never" did the trick after a reboot. To repro the failure, turn it to 10 minutes and wait, decoding will start seeing audio delays. No reboot required to force the failure. Each sample from the audio buffer (50/per 15 seconds for FT8) should take roughly 280uS. I start seeing several samples in each group of 50 take between 400-700uS. As a result not all 50 required audio samples are collected in the time allowed and the period is skipped and the .WAV file (if turned on) is not written out. If you turn on Save ALL and you see missing .WAV files in the directory, this is another symptom. LatencyMon will show all is good. Changing C states and Turbo Boost and any available such tweaks had no effect. Slide a random window around with the mouse fast for 10- 15 seconds to raise CPU above 10% for a decode period, or simply run any program that eats enough CPU cycles to get above 10%, all is good. I had resorted to running a Speedtest modern app and just letting it sit open on the desktop, tucked out of the way. Minimizing it dropped the CPU% too much. Its animated GO button was just enough to get me to 12%. I tried to repro this on a similar model HP laptop but with a Core i3 and 1080p display, otherwise same packaging, 4GB RAM and 128GB SSD, same Intel UHD620 GPU but it worked fine below 10%. Looked at its setting and it was 10 minutes, so this issue seems to be very particular. Here is the Advanced Power Options screen snapshot: [cid:[email protected]] I would like to thank Mike W9MDB for his many hours of assistance during this exercise, we now have the means/knowledge to easily spot such effects. Understanding the reason for them is still an art and likely case by case. * Mike K7MDL
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
