I didn't say there wasn't a problem, only that I didn't agree with the analysis, which is two different things.
On 01/08/2015 03:16 PM, Bill Somerville wrote: > On 08/01/2015 22:09, ki7mt wrote: >> Hi Alan, > Hi Alan & Greg, >> >> I'm not sure I agree with your analysis. > I do. >> >> Address space, re: virtual memory in the process list, doesn't cost the >> user anything, it is not real. What is real is the RSS column, that is >> resident memory usage. That's how much of your actual memory a process >> is occupying. > 88 Gbyte of memory used in a small program like WSPR is a sure sign of a > memory leak or some other resource leak like threads that are themselves > hanging onto large chunks of memory. > > The fact that physical memory is not currently being used is neither > here nor there, WSPR has no major long term memory requirements paged > into the working set or not. > > I would be very surprised if the virtual memory requirements of WSPR, > when working correctly, were to change by more than a few percent if at > all after a few periods of operating. >> >> It would be better if you could put the data in a file rather than >> pasting to an email, as it is mis-alinged badly. > Agreed, it is readable if HTML is turned on but like many I prefer not > to do that for e-mails. >> >> 73's >> Greg, KI7MT > 73 > Bill > G4WJS. >> >> >> On 01/08/2015 01:14 PM, Alan VK2ZIW wrote: >>> Hi Peter and all, >>> >>> We have a serious "threads" issue in WSJT 4 svn 4857, have a look at the >>> "top" >>> display >>> after running on Ubuntu 14.04 x86_64 for a week now: >>> >>> top - 05:34:32 up 31 days, 20:29, 5 users, load average: 0.23, 0.09, 0.07 >>> Tasks: 305 total, 1 running, 304 sleeping, 0 stopped, 0 zombie >>> %Cpu(s): 0.7 us, 0.6 sy, 0.0 ni, 98.8 id, 0.0 wa, 0.0 hi, 0.0 si, >>> 0.0 st >>> KiB Mem: 7875868 total, 7450088 used, 425780 free, 110280 buffers >>> KiB Swap: 10485756 total, 14080 used, 10471676 free. 4775268 cached Mem >>> >>> PID USER PR NI VIRT RES SHR S %CPU %MEM >>> TIME+ >>> COMMAND >>> 25106 alanb 20 0 87.969g 549256 12844 S 2.3 7.0 >>> 639:27.51 >>> python3 >>> 24049 alanb 20 0 33324 13324 3276 S 1.3 0.2 >>> 145:58.80 Xvnc >>> 6352 alanb 20 0 29260 1776 1156 R 1.0 0.0 >>> 0:00.35 top >>> 10 root 20 0 0 0 0 S 0.3 >>> 0.0 >>> 2:30.35 rcuos/2 >>> ---------------------------- >>> >>> WSPR is using 88Gb of Virtual Memory!!!! >>> >>> John Wiseman from the "pcrepeatercontroller" Yahoo group showed me 'the >>> way', >>> fixing my test code and showing, ARM systems are not at fault, in my blues >>> (previous emails). >>> But, you do have to get your "spawn thread", "detepch thread" and "exit >>> thread" >>> in the right order and timing. >>> >>> As I have mentioned before, I'm not a programmer. As an Engineering student, >>> I did Fortran in 1971 on an IBM 7040 (48k of 36bit words, ram, ferrite >>> cores) >>> In 1985 I started to 'fiddle' with "C". >>> >>> We DO have a problem. >>> >>> Alan VK2ZIW >>> >>> >>> >>> >>> >>> On Thu, 08 Jan 2015 10:24:04 -0700, ki7mt wrote >>> > Hi Peter, >>> > >>> > This should probably be re-classed as a sound card selection issue, >>> > rather than a sample-rate issue. As stated below, when your USB Audio >>> > CODEC is the default device, it does decode properly, which is good >>> > news. It is also good news that you have found a predictable way to make >>> > thing pass and fail. >>> > >>> > WSPR and WSJT are similar, insofaras, they both use portaudio, but sound >>> > selection and setup (F2) is done differently between the two apps. I've >>> > not dug into the WSJT code to see how things work there as opposed to >>> > WSPR. I'm Joe has his reasons as to why things are done differently, >>> > maybe he can comment on the difference between the two. >>> > >>> > WSJT and WSJT-X is comparing Apples to Oranges, as the sound sub-system >>> > is completely different using QT. >>> > >>> > 73's >>> > Greg, KI7MT >>> > >>> > On 01/08/2015 08:54 AM, Peter Frenning [OZ1PIF] wrote: >>> > > Testing WSJT 10 on Linux Mint Cinnamon 17.1 Rebecca, 32-bit >>> > > Sound device is a SignaLinkUSB (Burr-Brown 2904) aka "USB Audio CODEC" >>> > > >>> > > This problem deserves renewed attention, since the ".asoundrc"-based >>> resampling >>> > > no longer works in the latest releases of Ubuntu and Ubuntu-based >>> distributions. >>> >>> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
