[Lowfer] WSPR-X (getting our Priority straight)

[Jim Davey]

Thanks JD for the insight.  I don’t want to disparage Joe’s software, just
understand how to be a responsible user.  That being said, I think this
community is the perfect place to discover issues and discuss work-arounds
or good housekeeping habits.
My WSPR has been frozen since Wednesday, so is not currently adding to the
overload.  I’ll check file sizes in this state before I try anything else.
 
And then while I am there to watch it, let it run for a few days while
watching file size growth and overall stability.  I’ll try the priority
suggestion if the situation persists after cleanup.  If I use something
like DUMeter, I may be able to capture the behavior of the upload process
as it works on my particular setup.
The XP laptop I am using is not running any other software except for a
time-sync application which has a 15 min sync.  Even with new CMOS
batteries, these old laptops keep horrible time.
On server overload, I just tried to load the database page at wsprnet.org,
and it took nearly 30 seconds for the page to even begin to load.

Jim






On 12/13/15, 5:19 PM, "Lowfer on behalf of JD"
<lowfer-bounces at mailman.qth.net on behalf of listread at lwca.org> wrote:

>>>> The WSPR program surely doesn¹t try to upload the entire ALL_WSPR.txt
>>>> file each time it updates, does it (as opposed to just new spots)?
>>>>.... 
>>>> I¹m wondering if my instance of WSPR is spending all its time doing
>>>> something besides decoding, or perhaps I am still uploading a big
>>>>file 
>>>> when the next occurrence comes along, causing crashes or freezes.
>
>If you do manual uploads (as I have to do because of no 'net access on
>the 
>farm), it certainly does upload the whole thing, and the database then
>has 
>to sort out what's new, and that causes problems when it grows too large.
>As for automatic uploads, I'm not sure how WSPR decides what to do with
>the 
>newer decodes, but keep in mind that it does have to load the whole file
>into memory and save it back to disk each time it performs an operation
>on 
>it, and that consumes time and other resources.
>
>For that reason, I do the same thing Garry does and rename my file each
>day 
>(if it contains anything I want to preserve) or else delete it entirely.
>It's a variation of the KISS principle...in this case, Keep It Small.
>
>As for long decode times, there may be a couple of things going on.  One
>I 
>discovered a couple years back (especially on WSPR-2 mode) is that
>too-strong signals force too much analysis, probably due to production of
>stray audio components that have to be accounted for.  That sometimes
>causes 
>decoding to overlap--and therefor miss--the next transmission window.
>
>Also, anything else the computer is doing takes away resources from WSPR.
>Don't let your antivirus do background scans at the same time, for
>instance, 
>and clear out your browser cache before a listening session.  (Seems
>bizarre, but recent versions of Windows waste resources keeping track of
>those files even when the browser isn't open.)  Do without "live tiles"
>if 
>you can, etc.
>
>Finally, my experience here Friday with WSPR X acting so flaky for a time
>got me hunting for other problems I hadn't experienced before and
>possible 
>solutions--and I found one today!  My unaccustomed difficulty Friday gave
>every indication of Windows taking too much time for its own housekeeping
>tasks and shortchanging the desired application, namely WSPR X.
>
>Well, imagine my delight today to read a tip by KE4PT on page 72 of the
>January 2016 QST, in which he describes a technique to use a batch file
>to 
>run WSJT-X in realtime priority mode on Windows 8.1.  The same technique
>applies to Windows XP, 7, and probably also 10.
>
>It's equivalent to opening Task Manager, selecting the Processes tab,
>right-clicking Set Priority, and then choosing a higher value than the
>default of Normal. (Except you don't have to go through all the mouse
>clicks...just run the .bat file to simultaneously start the program and
>set 
>its priority.)
>
>There are three greater levels of priority available, in increasing
>order: 
>Above Normal, High, and Realtime.  There are potential drawbacks, of
>course; 
>the higher priority you give to one running process, the more likely you
>are 
>to create instabilities in another one that may also be time-critical.
>For 
>that reason, I would (and will) try High first and see if it gave me the
>desired result first before going all the way to Realtime.
>
>Since WSPR, like WSJT, is so time sensitive, this may be a useful fix.
>
>John
>
>
>
>
>
>______________________________________________________________
>Lowfer mailing list
>Home: http://mailman.qth.net/mailman/listinfo/lowfer
>Help: http://mailman.qth.net/mmfaq.htm
>Post: mailto:Lowfer at mailman.qth.net
>Post must be less than 50KB total for message plus attachment!
>
>This list hosted by: http://www.qsl.net
>Please help support this email list: http://www.qsl.net/donate.html