[hpsdr] Observations on the new HPSDR firmware/PowerSDR
Bill Tracey
bill at ewjt.com
Sun May 31 21:44:31 PDT 2009
Hi Dan,
Interesting observations -- will have to look
into it. How long does it take it to degrade to
where you're hearing bands and pops? I've had
mine running listening to a tone for the last 30
mins or so and haven't heard it glitch. I'm on
a Quad Core on Vista so have a bit different setup than you do.
A time oriented degradation leads me to the
perhaps garbage collection issues, but I did not
think any of our main path (audio buffers) stuff
relied on garbage collection.
How are grabbing the call stacks - Process Explorer?
Looks like it might be time to learn a bit on .NET profiling.
Cheers
Bill (kd5tfd)
At 04:52 PM 5/30/2009, Dan Quigley wrote:
>***** High Performance Software Defined Radio Discussion List *****
>
>
>Content-Type: multipart/alternative;
> boundary="----=_NextPart_000_0006_01C9E136.326233F0"
>Content-Language: en-us
>
>I hope this helps
>
>On my WinXP box running on an Intel 2.1Ghz duo
>core with 3GB of ram, PowerSDR works fine (read
>great!) for a while then the receive function
>gradually starts degrading (drop outs/pops etc)
>until audio eventually stops. CPU also rises
>with the incidence of popping/drop outs. How
>long it takes to degrade appears to be related
>to audio buffer size and sample rate
>settings. The higher the sample rate the less
>amount of time it takes for performance to
>degrade. Transmitting also appears to
>accelerate the time it takes to degrade.
>
>Good performance returns when you restart
>PowerSDR (first waiting for the previous
>instance to unload, which can take a while.
>
>When running fine (e.g. no drop outs) , the
>thread that consumes most of the CPU cycles in
>the PowerSDR.exe process has this call
>stack (or one very similar), at 192K bandwidth.
>
>Thread 5-11% cpu
>ntkrnlpa.exe!NtBuildNumber+0x43
>ntkrnlpa.exe!MmIsDriverVerifying+0xbb0
>ntkrnlpa.exe!MmIsDriverVerifying+0x1492
>ntkrnlpa.exe!PoShutdownBugCheck+0x39e9
>ntkrnlpa.exe!KeSynchronizeExecution+0x30c
>ntdll.dll!KiFastSystemCallRet
>KERNEL32.dll!WaitForMultipleObjects+0x18
>pthreadVC.dll!pthread_exit+0x111
>
>Once performance degrades and drop outs begin to
>occur frequently. This thread and call stack
>floats quickly to the top of the sorted by cpu
>list. Then stays at the top. This thread jumps
>to 50% cpu when you close PowerSDR and stays
>there for a minute or so. When it eventually
>terminates, PowerSDR is unloaded from memory:
>
>Thread 34% cpu
>Stack:
>ntkrnlpa.exe!NtBuildNumber+0x43
>ntkrnlpa.exe!MmIsDriverVerifying+0xbb0
>hal.dll!HalClearSoftwareInterrupt+0x342
>DttSP.dll!SetKeyerSampleRate+0x27c8
>DttSP.dll!PolyPhaseFIRF+0x28ca
>
>When the system has totally degraded this thread stays at 15% cpu
>Thread 15% cpu
>Stack:
>ntkrnlpa.exe!NtBuildNumber+0x43
>ntkrnlpa.exe!MmIsDriverVerifying+0xbb0
>ntkrnlpa.exe!MmIsDriverVerifying+0x1492
>ntkrnlpa.exe!PoShutdownBugCheck+0x3702
>ntkrnlpa.exe!KeSynchronizeExecution+0x30c
>ntdll.dll!KiFastSystemCallRet
>KERNEL32.dll!WaitForSingleObject+0x12
>libusb0.dll!usb_set_debug+0x266
>libusb0.dll!usb_reap_async+0xf
>libusb0.dll!usb_bulk_write+0x1e
>JanusAudio.dll!OzyBulkWrite+0x21
1243831471.0
More information about the Hpsdr
mailing list