Planefinder Client high CPU usage

[Janos Konya]

You can try a few more steps before my ideas are depleted.

1./ as I mentioned earlier, go to network adapter's properties and change RSS value to 2
You can find the menu by clicking on the button, close to the adapter name
(Reason: If all cores are occupied by networking tasks and the connection is delayed, you can experience a "virtual" problem somewhere else.)

Test the machine after altering the RSS settings. If CPU runs at a higher rate again, step to the 2nd point
----------
2./ Try to check Windows with another tool :
Run PowerShell with elevated rights and type in this command "Repair-WindowsImage -Online -ScanHealth"
It will not do the repair job but checks if your windows is damaged. Takes a few mins.

3./ In case your Windows is flagged as damaged:
Run PowerShell with elevated rights and type in this command: "Repair-WindowsImage -Online -RestoreHealth"
After the process is finished, restart the machine.

 

[Stealth]

I'll certainly check out your suggestions Janos and I appreciate your continuing interest. However, what is really puzzling me is why the problem is only manifesting in one process i.e. PF.
Planeplotter and VRS are running without any similar issues, as are all other processes on the system.
Rechecking the PF log I found numerous entries like the following, although I think this may be just a result of low traffic :
2021-02-01 12:07:40.917737 [-] Closed TCP connection: 192.168.1.9:30033
2021-02-01 12:07:40.917805 [-] Client restarted successfully
2021-02-01 12:07:40.918640 [-] TCP connection established: 192.168.1.9:30033
2021-02-01 12:07:41.42469 [V] Zero-byte response received, closing connection
2021-02-01 12:07:41.42707 [-] Closed TCP connection: 192.168.1.9:30033

 

[Janos Konya]

It is just like my guess. Connection has built up on hardware and (TCP) protocol layers but in receiving (time)window no data arrived. A delay like this in series may cause problems if configuration is not prepared to handle the case. Of course it is not a fact just a possible thing. On other hand, PF Client is able to handle zero air traffic - it is normally handled by a soft restart (as you can see)
- Is it your receiver on 192.168.1.9 IP address? Is this a wired connection? I feel that your networking chain suffers from delays somewhere...

In my set, VRS connects to the receiver alone, then forwards incoming data towards pf client and other softwares locally, and then to other targets on the network - using the "rebroadcast servers" option in settings. So, VRS is my redistribution center.

Pls try to apply #1 point in my last post and then lower the network speed to 100 Mbps full duplex instead Gigabit connection (auto negotiation).

Guys from Plane Finder might have some more ideas...

 

[Janos Konya]

2021-02-01 12:07:41.42469 [V] Zero-byte response received, closing connection

It might be the phenomenon of a possibly "sleeping" device at 192.168.1.9 address.
Network adapter shall be able to wake up the sleeping device, but power saving settings can overwrite this behaviour...
(just an idea)

If VRS connects there directly, you can send "keep alive packets" there by filling the checkbox in receiver settings.

 

[Stealth]

Yes, the .9 ip is the receiver address, fed by a 'Beast'. RSS doesn't appear to be configurable on the built in wireless adapter. However I did find that the sleep option was on, so that's off now. VRS is only installed to rebroadcast for an external client.
It's behaving itself at the moment.

 

[Janos Konya]

So, the Beast connects to a router by wifi. OK
I meant the RSS setting on PC's adapter. Keep it as a next point of testing if necessary.

Either sending keep alive packets from VRS or switching off the sleep option on the other end both can be the solution.
Let's see if it keeps running in a normal way... Fingers crossed.

 

[Stealth]

It took off again a half hour or so ago. I didn't reboot after changing the sleep setting, but I have now. Very consistent each time at 27-29% CPU.

 

[Janos Konya]

Seems to be a tricky one.
You might need Agatha Christie's help.

When 27% CPU usage appears again, check if there is some data-flow or it is stacked.

 

[Stealth]

Seems to be a tricky one.
You might need Agatha Christie's help.

When 27% CPU usage appears again, check if there is some data-flow or it is stacked.

I think a call to Hercule might be the answer.

"Repair-WindowsImage -Online -ScanHealth" came up as healthy

 

[Janos Konya]

"Repair-WindowsImage -Online -ScanHealth" came up as healthy

1 less of possible problems

 

[Stealth]

Just to close this off for now, no issues since my last post. Whether anything we did made a difference or just that the trigger for the event hasn't occurred since, I really don't know.

 

[Janos Konya]

I hope that the intermittent problem you have experienced has really been resolved.
There is no standard solution for this. We can at most go around and around the used functions and "grope" on an exclusionary basis hoping that we can find a kind of "solution".

 

[Stealth]

No re-occurrence of the problem since my post on the 9th of Feb. Interestingly a problem appeared with Planeplotter for a while that manifested as a 6 to 7 second freeze of data processing from the Beast receiver at intermittent times. That problem didn't last for more than a week or two, and no obvious cause was identified there either. Since then there have been a number of Windows updates, so its anybody's guess.