Chrome can be both a CPU and memory hog. I do not use it on my ham radio computer. It has a tool called Software Reporter Tool that runs now and then and chews-up CPU and memory resources. Thus it can stall the ham radio software, time updates, whatever.
In Windows 10, you can disable the Software Reporter Tool by disabling its inheritance. That way no application can use it. Below shows the path on my Windows 10 computer. My account is Joe, so you would need to change the account to your account name. The 90.260.200 in my case won't match yours, so that will also need to be changed. I suggest just printing this email and then using the file folders, just walk down the string manually per your configuration. C:\Users\Joe\AppData\Local\Google\Chrome\User Data\SwReporter\90.260.200\Software_Reporter_Tool.exe Select via a right click Software_Reporter_Tool.exe then Parameters, Security, Advanced and Disable Inheritance for Software_Reporter_Tool.exe and then save it. I also find that when Windows 10 goes to sleep, sometimes when my computer is woken-up, it is not connected to my Wi-Fi, so I restart the Wi-Fi and I also have to restart Meinberg to get the exact time back. Just a few thoughts. Joe, K1YOW _____ From: Rich - K1HTV [mailto:[email protected]] Sent: Thursday, April 22, 2021 10:39 AM To: WSJT Subject: Re: [wsjt-devel] Few FT8 decodes on Even cycles Bill - G4WJS, OK on the suggestion of switching to Meinberg NTP instead of D4.EXE, which I have been using successfully for years. Today, the problem of poor odd cycle and almost no even cycle FT8 decodes started again. I checked and found the Windows Internet Time Sync tool was disabled. One would think that if D4.EXE was the cause of the problem, disabling it would stop the anomaly, so I shut down D4.EXE, but the poor decode problem continued. Note that after a week of not leaving Chrome running, I started it again yesterday and left it running. When the poor decode problem started again today, I checked Task Manager and found that Chrome's memory use had increased to over 1.3 GB. That is still a small fraction of the 16GB of available RAM. What might cause this poor and asymmetrical number of decoded FT8 stations with the number of odd cycle decodes being greater than the almost zero number of even cycle decodes? Is it possible that some of the JT9.exe decoder code in RAM is getting contaminated? I'm in the process of bringing a 4 core computer online, replacing the dual core computer now in use for WSJT-X. It will use Meinberg NTP. Hopefully the poor decode problem will go away.with the new box. 73, Rich - K1HTV = = - From: Bill Somerville <[email protected]> To: [email protected] Cc: Bcc: Date: Mon, 19 Apr 2021 18:07:49 +0100 Subject: Re: [wsjt-devel] Few FT8 decodes on Even cycles Hi Rich, you describe symptoms that could be explained by your time synchronization application making step changes, that is sure to cause discontinuities in the audio streams which in turn are very likely to disrupt decoding of all signals in periods where that happens. One cause of this could be multiple time sync applications running simultaneously, e.g. not disabling the Windows Internet Time Sync tool if you are running another 3rd party time sync tool. Note also that we no longer recommend SNTP time sync tools as they are prone to this sort of time stepping on systems that keep poor time when unsynchronized. On MS Windows the Meinberg NTP Client is a proper NTP implementation and only steps the time during initialization, if configured to do so, to get a fast synchronization. There are other time sync tools that implement NTP rather than SNTP, if Meinberg is not to your liking. On other platforms the default network time sync tool will be a full NTP implementation like the *nix ntpd or more modern chronyd, so there just enabling the system network time synchronization is sufficient. 73 Bill G4WJS.
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
