Re: [wsjt-devel] WSPR Crash on ARM, was : Re: WSPR crashes, error starting rx thread

2014-12-22 Thread Alan VK2ZIW 
Hi Bill and all,
ps -eLfu alanb  =
UID    PID     PPID   LWP  C NLWP STIME TTY  TIME CMD
alanb 3778  2254  3778  0    1 14:24 pts/0    00:00:00 /bin/sh 
/usr/local/bin/wspr40
alanb 3780  3778  3780  3    5 14:24 pts/0    00:01:52 python3 
/downloads/hamradio/digital/wsjt/4795wsprB/wspr/wspr.py
alanb 3780  3778  3781  0    5 14:24 pts/0    00:00:04 python3 
/downloads/hamradio/digital/wsjt/4795wsprB/wspr/wspr.py
alanb 3780  3778  3783  0    5 14:24 pts/0    00:00:03 python3 
/downloads/hamradio/digital/wsjt/4795wsprB/wspr/wspr.py
alanb 3780  3778  3875 99    5 15:17 pts/0    00:00:10 python3 
/downloads/hamradio/digital/wsjt/4795wsprB/wspr/wspr.py
alanb 3780  3778  3876  3    5 15:17 pts/0    00:00:00 python3 
/downloads/hamradio/digital/wsjt/4795wsprB/wspr/wspr.py

Why the 99?

Then on a 2nd ps -eLfu alanb, the 99 is back to 0. Another time, 80.

Puzzled, seems to jump in the Decode phase.
cat /proc/sys/kernel/threads-max 
13988
cat /proc/sys/vm/max_map_count
65530
ulimit -a
core file size  (blocks, -c) 0
data seg size   (kbytes, -d) unlimited
scheduling priority (-e) 0
file size   (blocks, -f) unlimited
pending signals (-i) 6994
max locked memory   (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files  (-n) 1024
pipe size    (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority  (-r) 0
stack size  (kbytes, -s) 8192
cpu time   (seconds, -t) unlimited
max user processes  (-u) 6994
virtual memory  (kbytes, -v) unlimited
file locks  (-x) unlimited

Alan VK2ZIW

On Sun, 21 Dec 2014 12:24:14 +, Bill Somerville wrote
 On 21/12/2014 11:01, Alan VK2ZIW wrote:
 Hi Greg and all, 
 Hi Alan,
  
 Can we please focus on the crash  problem? 
 
 WSPR runs perfectly fine for 10+ hours then crashes: 
 
 spawning new thread: Resourcetemporarily unavailable 
 Error starting rx thread    11 
 I don't know the WSPR code base apart from acursory skim through it but that 
 error sounds like the o/s has runout of process/thread slots. Clearly WSPR 
 doesn't spawn largenumbers of concurrent threads or processes so I would 
 guesssomething is starting threads or processes and they are notterminating 
 when they should. A simple 'ps' listing now and againwhile WSPR is running 
 should reveal the issue.
  
 
 snip
  Keep Smiling
 
 Alan VK2ZIW


Alan

Man's greatest waste of time: Worshipping the wrong God. 
Consider Jesus. 
--- 
Alan Beard               Unix Support Technician from 1984 to today 
70 Wedmore Rd.           Sun Solaris, AIX, HP/UX, Linux, SCO OpenServer 5.0.X 
Emu Heights N.S.W. 2750  Routers, terminal servers, printers, terminals etc.. 
+61 2 47353013 (h)       Support Programming, shell scripting, C, assembler 
0414 353013 (mobile)     After uni, electr
 
--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Possible Detection/Fix for KV Decoder Errors w/ Windows OS

2014-12-22 Thread Paul DU2/WA8UGN 
After extensive testing, and with the aid of Julian, VK4CMV, who confirmed 
the existence of the exact same errors occurring with his WSJT-X 
operations, I come to the conclusion that changes to Microsoft Windows via 
periodic Windows updates, may be a major player in error activity.

Testing was done on 3 different versions of WSJT-X (r3673, r4400,  r4633) 
in total isolation from the world, save on-air signal input.  Almost 
every permutation of disabling software, option settings, etc. were 
employed in a very large number of tests.  Each test was performed after a 
complete scrubbing of my laptop's hard drive, memory, and drivers.  No 
positive effects were observed during the tests.

I finally uninstalled every Windows update placed into service in Dec 2014, 
and re-tested.  Results were most encouraging, with long runs of each 
WSJT-X version before a hiccup.  Hiccups were cured by restarting WSJT-X 
(not the optimum resolution, but much better than others found to date).

Final confirmation of WSJT-X - Windows interaction having some relationship 
to the errors observed came when each Windows update was individually re-
installed.  No change to the much improved operation of WSJT-X versions was 
observed until two different updates were installed.  Each caused a slow-
down of decoding, increased errors, and frequent Decode lock-ups.

The offending Windows Updates are:

 KB3025390 - major offender
 KB2952664 - minor offender

With these two Windows updates uninstalled, and everything but the kitchen 
sink attached to the laptop and every bit of software normally used in weak 
signal operations here running, the results of testing were impressive.  
Fast decoding (I use Deepest decoding), and a noteworthy improvement in 
mean time between errors.  Best, only one decoder lock-up over 6+ hours of 
testing.  If a KV error occurs, with or without the pop-up error window, 
normal operation continues.  The pop-up error window can be closed when it 
appears - no observable deterioration in normal operations occur when that 
pop-up appears, nor when it is manually closed.

Any thoughts about this line of testing and its results?

Best 73,

Paul DU2/WA8UGN


--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel