[hpsdr] Further test of DPC latency (was Re: Come and get it, code's ready!)
Steve Bunch
steveb_75 at ameritech.net
Thu Jun 4 08:17:44 PDT 2009
Thanks to Dan Quigley for pointing out the DPC tool (see his note sent
June 3). On my system described below, the tool was reporting a DPC
latency never less than about 1600-1700 us, occasionally bouncing up
to 27ms. I disabled drivers until the latency went down. The "IDT
High Definition Audio CODEC" was the culprit. After disabling it, the
latency went down to the 15-40us range. Thanks for the tip, Dan! Of
course, now I have no audio on the PC, but fortunately for this
experiment, Mercury outputs its own!
I've been watching the waterfall, Process Explorer, and DPC screens
for most of an hour, watching and listening to static on 10M to get a
nice noisy background where any smears would be obvious... (The only
change from the description below is that I am not using CPU affinity
now -- it didn't seem to make any difference anyway.) For several
minutes after a cold start of the system, I saw no problems. Then the
losses began occurring at pretty close to the level reported below --
maybe once per minute, on average, but with a high variance (high
enough that the smooth start may not be significant). The symptom
exhibits as a smear of maybe 20-30 rows of pixels of the same value
being drawn, with a blanking of audio (no filters are on, AGC
medium). Corresponding to this, there's a blip in the I/O Bytes
History in Process Explorer where in that 1-sec sampling interval, the
average I/O goes from 1.9MB down to around 2/3-3/4 of that. There is
no corresponding change in DPC latency, so that does not seem to be
the specific cause. On one blip, I thought I heard a relay click, but
I had the static turned up high enough that I'm not 100% sure.
The DPC program was the first thing I started running after a reboot
after I turned off the audio driver, and there was a DPC latency of
27ms again, once only and not (so far) repeated, so that's not the IDT
driver. The longest since, after tens of minutes, is 208us (oops,
just went up to 356).
I'll leave it running for the rest of the day in background to see if
anything changes.
Steve, K9SRB
On Jun 2, 2009, at 11:39 PM, Steve Bunch wrote:
> Spoke too soon. After the storms passed and I got in some long runs
> with clearer background noise, I do still see lost data with
> Mercury, though it doesn't cause big pops - usually just blips of no
> audio - and it's not as frequent. This shows itself visually as a
> multi-pixel vertical 'smear' of the PowerSDR waterfall, that is,
> same-pixel data repeated for multiple rows. The blip is coincident
> with a small downward blip in the otherwise very-constant I/O
> Bandwidth reported in Process Explorer -- saying that less data was
> read during that sampling period. This was when listening to CW on
> 17M, and the loss occurred about once per minute or so, though it
> wasn't consistent. It probably occurs under other conditions, this
> was just one spot I tried that had steady background noise at the
> time.
>
> So there is data loss still going on somewhere with the new
> firmware, at the highest data rate. I'm trying to dig deeper into
> it now.
>
> Steve, K9SRB
>
> On Jun 1, 2009, at 4:07 PM, Steve Bunch wrote:
>
>> ***** High Performance Software Defined Radio Discussion List *****
>>
>> Just updated Mercury and Penelope to 2.7, and it's working very
>> well for me. (Updated Janus but have not tried it yet.)
>>
>> I had previously been experiencing frequent pops/dropouts at 192K
>> (less often at 512 than with larger buffers), and less often but
>> still happening at 96K. Now running at 192K/2048 and 1024 w/o
>> problems other than occasional lightning-induced ADC overloads --
>> shutting down soon!
>>
>> Hardware here is a 2.4GHz Core 2 quad with 4GB RAM, intel DP35DP
>> motherboard, motherboard USB, separate graphics board, TAPR-built
>> HPSDR boards running from a PC power supply, board order randomly
>> chosen as Penny/Ozy/Mercury in J6 (closest to P/S)/J5/J4. Software
>> is WinXP SP3 32-bit, McAfee virus protection on, .NET 3.5 SP1, a
>> few other things running, but nothing big. Listening to AM radio
>> is taking a bit over 30% of one processor with 192K/2048 sampling,
>> CPU affinity set to CPU 3 only, scheduling RT, running a full-width
>> waterfall, no NR/NB/ANF -- a configuration that previously
>> generated lots of pops/dropouts. CPU Time is split a bit under 1/4
>> system time, 3/4 user (per Process Explorer). These same settings
>> used to pop at least once or twice per waterfall screen, so this is
>> a big improvement.
>>
>> Thanks to Kirk, Bill, and Phil for all the hard work on this!
>>
>> 73,
>> Steve, K9SRB
>>
>> On May 28, 2009, at 11:39 PM, Bill Tracey wrote:
>>
>>> ***** High Performance Software Defined Radio Discussion List *****
>>>
>>> All,
>>>
>>> Thanks to the great work done by Kirk KD7IRS we have new version
>>> of FPGA code for all the HPSDR boards. The latest versions
>>> completely removes any remnants of board position sensitivity and
>>> should also allow operation at 192k/2048k on PC's that previously
>>> had difficulty with these rates.
>>>
>>> The new code also improves the performance using John Melton's GTK
>>> + Linux console -
>>>
>>> < http://javaguifordttsp.blogspot.com/ >.
>>>
>>> It is also essential for use with the shortly to be released
>>> Windows K.I.S.S. Konsole.
>>>
>>> In order to make use of this new code the ROMs on Penny and
>>> Mercury boards must be updated. If you're using Janus with Mercury
>>> and/or Penelope you will need to update it as well. A new
>>> version of PowerSDR that has the new Ozy and FX2 code has been
>>> posted.
>>>
>>> The latest version numbers are:
>>>
>>> Mercury - V2.7
>>> Penelope - V1.2
>>> Janus - V3
>>> Ozy - V1.3
>>> FX2 - 20090524
>>>
>>> The procedure to update the CPLD or EEPROMs on the various boards
>>> is the same as before. Use SVN to check out the files from
>>>
>>> < svn://206.216.146.154/svn/repos_sdr_hpsdr/trunk/USBBlaster-
>>> Binaries >
>>>
>>> and follow the instructions in the README.txt file.
>>>
>>> You must also use the latest Ozy_Janus.rbf, ozyfw_sdr1k.hex and
>>> PowerSDR files which can be obtained from the usual SVN place:
>>>
>>> < svn://206.216.146.154/svn/repos_sdr_windows/PowerSDR/branches/
>>> kd5tfd/PennyMerge/bin/Release >
>>>
>>> At this time Janus is only working well at 192khz, so PowerSDR is
>>> currently setup to use the prior version of Ozy and FX2 firmware
>>> when configured for an SDR 1000 + Janus setup. If that's you're
>>> configuration it is not recommended to update the Janus CPLD code
>>> at this time
>>>
>>> As before please report any successes or problems via the HPSDR
>>> mail reflector.
>>>
>>>
>>> Phil (VK6APH)
>>> Bill (kd5tfd)
>>>
>>> _______________________________________________
>>> HPSDR Discussion List
>>> To post msg: hpsdr at openhpsdr.org
>>> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
>>> HPSDR web page: http://openhpsdr.org
>>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>>
>> _______________________________________________
>> HPSDR Discussion List
>> To post msg: hpsdr at openhpsdr.org
>> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
>> HPSDR web page: http://openhpsdr.org
>> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>
1244128664.0
More information about the Hpsdr
mailing list