I have 5 blocks in my flowgraph:
USRP Src -> PFB Decim by 2 -> Mult 32768 -> Cplx-iShort -> FileSink
I am running 14 MS/s x 2 x 32 bits from the USRP, 7 MS/s x 2 x 16 bits
to the disk.
Previously, even setting the USRP num_recv_frames=512 or 1024, it
would run for about a minute fine then print 1-4
Date: Sun, 10 May 2015 17:18:58 -0400
From: "Marcus D. Leech"
You could try a simple experiment that tests your disk subsystem write
performance without SDR stuff at all. Something like:
time dd if=/dev/zero of=some-file-on-your-disk bs=200 count=15000
This should write a 30GB file. The 'ti
On 05/09/2015 09:02 AM, Murphy, John wrote:
Marcus et al,
Had to drop this to do some work on another project yesterday, but
still want to pursue this just a little further if you don't mind,
because the numbers you are giving all look to me like it should be
able to be made to work.
You found
Marcus et al,
Had to drop this to do some work on another project yesterday, but
still want to pursue this just a little further if you don't mind,
because the numbers you are giving all look to me like it should be
able to be made to work.
You found my SDD sequential sustained write speed of 69
On 05/07/2015 04:12 PM, Murphy, John wrote:
So /dev/null works, I do not know what that really says about this
though. Is there a difference between using dev/null and just running
any non-disk-write flowgraph? Because I know I can run a flowgraph at
16 MS/s decimated to 8 MS/s, with never a sing
So /dev/null works, I do not know what that really says about this
though. Is there a difference between using dev/null and just running
any non-disk-write flowgraph? Because I know I can run a flowgraph at
16 MS/s decimated to 8 MS/s, with never a single O even for hours of
operation.
With 16 GByt
It'll be under /usr/local/lib{64}/uhd/examples
I looked at their blurb on that drive, and its *sustained* rate comes
out to about 69Mbyte/second. Sure, it'll take bursts at screaming-fast
rates, because, like the Linux kernel, it has a whacking great
write-behind buffer.
Try specifying a fil
The sequential rates I gave are the published rates for the SSD. Maybe
(probably?) specsmanship, sure.
But since it does mostly keep up, isn't this a case of just needing
the correct buffer set-up to allow it to ride through the worst of the
hiccups?
I am going to have to find and figure out how t
For the record and completeness I tried again with just the complex
int16 USRP Source and File Sink, setting "Unbuffered = off", and it
still bahaved the same. It may matter but it is not enough to make a
noticeable difference in this case.
- John
On Thu, May 7, 2015 at 2:27 PM, wrote:
> Leave
Hi Marcus,
I am using num_recv_frames=512 but I have no idea why 512 or what the
ideal value should be for a system that has a lion's share of 16 GB of
RAM to burn.
In terms of the disk hardware sequential writes are up to 520
MBytes/sec. While there may still be some moments where things fall
beh
On Thu, May 7, 2015 at 2:01 PM, Murphy, John wrote:
> Transition bandwidth is sloppy, double the (sample rate minus
> two-sided passband width), or in this case something on the order of
> 1/4 the input sample rate.
Okay, actually I do have a tighter width, because with the decimation
by 2 it wra
Leave "unbuffered" = OFF. This flag was added for "slow" file-sinks,
when, for example, you're writing slow data to an external process via
somehthing like FIFO, and you don't want the default stdio buffering to
get in the way. The default, if you leave it off, is to use stdio
buffering.
The "
On Thu, May 7, 2015 at 1:01 PM, wrote:
> If you want high file-write performance, leave it in buffered mode.
> Also, a 175-tap filter, running at 16Msps is going to chew up a lot of CPU.
> How about a simple low-pass filter, decim=2? Make the transition bandwidth
> fairly sloppy.
> Or alterna
Or alternatively, just run the USRP at your desired sample-rate into the
file-sink.
On 2015-05-07 12:48, Murphy, John wrote:
> How would I best set up a UHD Source block for USRP B2x0 devices to
> output to a flowgraph that uses a File Sink block to write to disk
> without overflows (and how
If you want high file-write performance, leave it in buffered mode.
Also, a 175-tap filter, running at 16Msps is going to chew up a lot of
CPU.
How about a simple low-pass filter, decim=2? Make the transition
bandwidth fairly sloppy.
On 2015-05-07 12:48, Murphy, John wrote:
> How would I
15 matches
Mail list logo
