Loading ...
Sorry, an error occurred while loading the content.

More on Skimmer CPU Utilization

Expand Messages
  • Pete Smith
    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
    Message 1 of 1 , Nov 13, 2008
    View Source
    • 0 Attachment
      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...
      www.conteststations.com
    Your message has been successfully submitted and would be delivered to recipients shortly.