Thanks, everyone, for your repoorts.
This morning I went to restart my computer after some Windows updates, and
"bang", Skimmer was back up to using 70 percent of resources on an
almost-empty band. After a lot of parameter switching and program stopping
and starting, with no discernible magic pattern, I finally got it to settle
down. Currently, with 92 out of 453 decoders running across 14000-14096
KHz bandwidth, and Skimmer minimized, Skimmer is using a total of 17
percent of my 2.66 GHz Celeron. With Skimmer full-screen, utilization
jumps to ~40 percent across the two processes, and Skimmer reports 41
percent; if the abnormally high CPU utilization were present, the task
manager CPU value Would have been 85-100 percent.
What does this say? To me it clearly indicates the presence of a subtle
and darned difficult-to-find bug in the initialization process somewhere,
that can affect you adversely any time the Skimmer is running on a PC with
other applications. Until that is found and fixed, I'd recommend the
following to minimize impact on other programs, such as loggers, running at
the same time:
* keep Skimmer minimized whenever possible, or at least keep it as small as
possible. Use Skimmer's Telnet command function to control band changes
from inside your logging program, or use WD5EAE's script-based control
program to do that for you.
* keep your Scan Rate as low as possible - don't use 192 unless you are
running Skimmer on a dedicated machine. 96 is plenty - you can set the
Skimmer frequency 38 KHz above the bottom band edge and cover 000-096,
which is all you need.
* if it comes up in a condition where the task manager says that CPU usage
is significantly higher than Skimmer itself reports, try changing the
Sample rate, Switching to SoftRock and back to SDR-IQ, or vice versa,
stopping and starting the waterfall, and stopping and starting
Skimmer. Try doing parameter changes both with the waterfall running and
after pausing it.1 After each activity check the task manager and see if
the CPU utilization has reverted to being less than what Skimmer
reports. Be sure to wait a few seconds each time for Skimmer to settle
down before you reach a conclusion. Eventually, if it reverts to normal,
don't stop and restart Skimmer. Set your Sampling rate back to what you
want, if it isn't already, and hopefully it won't go nuts again.
* Adjust your choice of bandplans on the Misc tab, as necessary edit your
band plans in the bandplan.ini file, and be sure that you have "Decode only
in CW Segments" checked. If you look in the bandplan.ini file, you'll see
ways to improve on the number of spurious decoders that Skimmer attempts to
deploy on RTTY and SSB signals.
This is important because a large share of Skimmer's CPU demand is due to
efforts to determine whether each candidate decoder that is deployed is
actually seeing anything that is decode-able. For example, I edited my CW
Contest bandplan to stop 40 CW at 7040 and 20 CW at 14070. With that
limitation, under essentially the same conditions as reported above,
Skimmer is displaying 94 of 94 decoders, reporting its own utilization as
36-38 percent, and task manager reports it as only 11-16 percent. Sure
does make my other programs run better!
73, Pete N4ZR
the World Contest Station Database is back...