[Discuss-gnuradio] Hard Disk Bottleneck
Hi everybody, just a quick question: has anybody managed so far to provide the usrp with the 8 Complex Msps needed to transmit an 8 MHz wide band? My problem is that such a bandwidth yields a 32MiBps throughput and, even if the USB2 bus and the CPU speed of my machine are all right with this, it looks like my IDE HARD DISK cannot provide such a data rate. Can anyone please confirm whether he's been successful in something similar, and, if so, with what kind of HD? thanks vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 500;800 MHz Tx
Hi, this question is meant especially for Matt, are there any possibilities that a TX front-end might be available in the near future on a band including the spectrum segment 400-850MHz? Even a less wide band would be definitely interesting, if set in such spectral zone. thanks vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Hard Disk Bottleneck
Vincenzo Pellegrini wrote: Hi everybody, just a quick question: has anybody managed so far to provide the usrp with the 8 Complex Msps needed to transmit an 8 MHz wide band? My problem is that such a bandwidth yields a 32MiBps throughput and, even if the USB2 bus and the CPU speed of my machine are all right with this, it looks like my IDE HARD DISK cannot provide such a data rate. Can anyone please confirm whether he's been successful in something similar, and, if so, with what kind of HD? thanks vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio You can successfully store data at those rates using SATA-II drives. You can also set up a RAID-O configuration with IDE drives and should get enough bandwidth. Actually we are using a more intensive system here with 8 SATA-II drives using an areca PCI-E card with a RAID-5 configuration and achieve continuous rates close to 200MBPS - so I know it can be done. If you format your IDE drive and use a benchmarking program, you will typically see that, as the disk fills, data write speeds decrease linearly due to your position on the disk. You can sometimes look at the numbers and then create a smaller partition that can maintain these speeds. Also, using isolated drives for data is important and we find the XFS filesystem to outperform all other filesystems for continuous writing. Ryan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC version 0.60
Josh Blum schrieb: Hello, For those of you who don't know, GRC is a graphical interface for generating flow graphs in gnu radio. There was much struggle when deciding the cut-off point for a new version. I finally drew the line and released version 0.60. I put a lot of work into GNU Radio Companion since I last announced to the list. GRC includes over 150 blocks from GNU Radio, supports all the data types (vectors too), and includes USRP support. Looks pretty good. How does one take the 'xml' output and turn that in to a traditional python program. Thanks John Clark. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC version 0.60
Matt Ettus schrieb: Is it a manual or automatic process for a gr block to be "imported" into grc? Is there anything which could be done in the main gnuradio library to make it easier or more automated for all gr blocks to be supported? There's a note on how to import 'stuff'. But I've not tried to get my blocks that I'm currently working on installed. John Clark. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Hard Disk Bottleneck
On Fri, Feb 09, 2007 at 10:11:48AM +0100, Vincenzo Pellegrini wrote: > Hi everybody, > > just a quick question: has anybody managed so far to provide the usrp > with the 8 Complex Msps needed to transmit an 8 MHz wide band? > > My problem is that such a bandwidth yields a 32MiBps throughput and, > even if the USB2 bus and the CPU speed of my machine are all right with > this, it looks like my IDE HARD DISK cannot provide such a data rate. > > Can anyone please confirm whether he's been successful in something > similar, and, if so, with what kind of HD? > > thanks > vincenzo Buy a new disk and controller ;) Lots of commodity 7200 RPM SATA drives can sustain 40 - 60 MB/sec, no problem. Take a look at the Seagate Barracuda 7200.10 Zipzoomfly.com has the 300GB version for $100. http://www.zipzoomfly.com/jsp/ProductDetail.jsp?ProductCode=101457 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Hard Disk Bottleneck
Has there been much discussion on building a modulator into the FGPA? That would obviously reduce down the bandwidth required for transmission of some very wideband signals. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Hard Disk Bottleneck
> >> >> just a quick question: has anybody managed so far to provide the usrp >> with the 8 Complex Msps needed to transmit an 8 MHz wide band? >> >> My problem is that such a bandwidth yields a 32MiBps throughput and, >> even if the USB2 bus and the CPU speed of my machine are all right with >> this, it looks like my IDE HARD DISK cannot provide such a data rate. >> >> Can anyone please confirm whether he's been successful in something >> similar, and, if so, with what kind of HD? >> The real point here is that you can generate signals on the fly much faster than you can read them from a disk. We have no trouble generating the 32 megabytes per second of FM, PSK, or whatever else, in real time. Do you really need to store these files to a disk? Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Hard Disk Bottleneck
Brian Padalino wrote: > Has there been much discussion on building a modulator into the FGPA? > That would obviously reduce down the bandwidth required for > t Why build it into the FPGA when you can do it in software? He's running into a bottleneck in the disk->computer link, not the computer->USRP link. A modulator in software solves the first, a modulator in hardware solves the second. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC version 0.60
Hi Josh, This is really nice. A great interface. The only problem is that it doesn't have some of the blocks I am using. :( Feature request: rational_resampler and freq_xlating_fir_filter Thanks, Hans - Original Message - From: Josh Blum To: discuss-gnuradio@gnu.org Sent: Thursday, February 08, 2007 3:01 PM Subject: [Discuss-gnuradio] GRC version 0.60 Hello, For those of you who don't know, GRC is a graphical interface for generating flow graphs in gnu radio. There was much struggle when deciding the cut-off point for a new version. I finally drew the line and released version 0.60. I put a lot of work into GNU Radio Companion since I last announced to the list. GRC includes over 150 blocks from GNU Radio, supports all the data types (vectors too), and includes USRP support. Check out my main page for GNU Radio Companion: http://www.joshknows.com/?key=grc You can get GRC from my downloads page: http://www.joshknows.com/download/grc/ Feedback for bugs or comments is always helpful. Thank you, -Josh Blum -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.17.30/674 - Release Date: 2/7/2007 3:33 PM ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 500;800 MHz Tx
Vincenzo Pellegrini wrote: > Hi, > > this question is meant especially for Matt, > are there any possibilities that a TX front-end might be available in > the near future on a band including the spectrum segment 400-850MHz? > > Even a less wide band would be definitely interesting, if set in such > spectral zone. > The RFX400 can be modified to move its coverage band around, but it can't cover that whole range at once. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC version 0.60
On Saturday 10 February 2007 04:25, Hans Glitsch wrote: > Hi Josh, > > This is really nice. A great interface. The only problem is that it > doesn't have some of the blocks I am using. :( > > Feature request: rational_resampler and freq_xlating_fir_filter > Hallo Hans, the frequency translating fir filter is supported. Just select the low/high/bandpass filters, double click on the box and select the desired filter type from the drop-down menu, e.g. "Xlating FIR: Complex->Complex" cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC version 0.60
Josh, Hey that's great. Is there any way to set the Mux through GRC? Thanks very much, Hans - Original Message - From: Josh Blum To: Hans Glitsch Sent: Friday, February 09, 2007 10:06 AM Subject: Re: [Discuss-gnuradio] GRC version 0.60 Hans, Ok i will add rational_resampler and let you know. freq_xlating_fir_filter is actually there, if you use any of the passband filters, some of the options are Xlating FIR Filter. A few of the other filters also support this. Let me know if I had implemented the filter incorrectly. Suggesting blocks help me make GRC better. Thank You -Josh On 2/9/07, Hans Glitsch <[EMAIL PROTECTED]> wrote: Hi Josh, This is really nice. A great interface. The only problem is that it doesn't have some of the blocks I am using. :( Feature request: rational_resampler and freq_xlating_fir_filter Thanks, Hans - Original Message - From: Josh Blum To: discuss-gnuradio@gnu.org Sent: Thursday, February 08, 2007 3:01 PM Subject: [Discuss-gnuradio] GRC version 0.60 Hello, For those of you who don't know, GRC is a graphical interface for generating flow graphs in gnu radio. There was much struggle when deciding the cut-off point for a new version. I finally drew the line and released version 0.60. I put a lot of work into GNU Radio Companion since I last announced to the list. GRC includes over 150 blocks from GNU Radio, supports all the data types (vectors too), and includes USRP support. Check out my main page for GNU Radio Companion: http://www.joshknows.com/?key=grc You can get GRC from my downloads page: http://www.joshknows.com/download/grc/ Feedback for bugs or comments is always helpful. Thank you, -Josh Blum -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.17.30/674 - Release Date: 2/7/2007 3:33 PM ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Software stopping of runaway realtime processes?
Hey, I'm hoping someone has run into this problem before... We have a that lab we access remotely, and sometimes the students get a little overzealous in e.g. their rate selection, and the machines become unresponsive. I seem to be having a hard time getting them to stop using realtime mode. 2 Questions: 1) Can I somehow disable their ability to use realtime mode? The software fails gracefully in that case, I just can't find anything online about how to make the enable_realtime() call fail. 2) Can I set up some sort of watchdog process to auto-kill a process that is clearly going to cause the machine to become unresponsive? I'm not even sure how to identify such a process... Thanks, Dan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Software stopping of runaway realtime processes?
On Fri, Feb 09, 2007 at 11:17:12AM -0800, Dan Halperin wrote: > Hey, > > I'm hoping someone has run into this problem before... We have a that > lab we access remotely, and sometimes the students get a little > overzealous in e.g. their rate selection, and the machines become > unresponsive. I seem to be having a hard time getting them to stop using > realtime mode. Yep, you can blow your foot off ;) > 2 Questions: > > 1) Can I somehow disable their ability to use realtime mode? The > software fails gracefully in that case, I just can't find anything > online about how to make the enable_realtime() call fail. If they have access to root, it's kind of hard to keep them from hosing themselves: # rm -fr / In general, the only GNU Radio application I run as root is tunnel.py. That's because it opens the the tun interface, and because I've been too lazy to code up the suggestion below. Sounds like you may have a higher motivation level than I do ;) In order to run tunnel.py (or other programs using tap/tun) without being root, you could implement a small setuid-root wrapper that would acquire the CAP_NET_ADMIN capability, drop root, then exec python or whatever. You'll probably also need a udev rule to set the permissions on /dev/net/tun to something that they can open without being root, perhaps making it rw for group usrp. This is similar to the rule that we use to enable the USRP to be opened without being root. http://gnuradio.org/trac/wiki/UdevConfig If they're not running as root (or holding CAP_SYS_NICE), the call sched_setscheduler (the system call that enables realtime) will fail. To reduce the likelihood of people wedging the machine accidentally, probably the easiest thing to do is to add a command line parameter that is required to be set to enable realtime mode. I suspect that would reduce wedging of the machine through the choice of bad parameters. Once they've got a set of parameters that do work, they could, if they thought it useful, pass the "--enable-realtime" flag. [I wedged a couple of machines in the ORBIT testbed this way a while back. It took me a while to figure out what happened. Why are these machines crashing??? The machines were less powerful than the machines I normally ran on, and they couldn't keep up. Ooops...] > 2) Can I set up some sort of watchdog process to auto-kill a process > that is clearly going to cause the machine to become unresponsive? I'm > not even sure how to identify such a process... The traditional way to handle this problem is with a shell session, connected via a serial link, running at higher priority than any of your experiments. The default real-time priority set by gr_enable_realtime_scheduling is in the middle of the RT priorities. You might be able to cook up some kind of "UDP packet of death" that would kill all python processes belonging to a particular user. The question is whether the networking stack will get enough cycles to deliver the packet. The serial port trick is known to work. FWIW, the code that enables real time scheduling is contained in gnuradio-core/src/lib/runtime/gr_realtime.cc Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Win a USRP - The GSMSP Challenge1
Hi, i hope this is not spam but I would feel bad if i wont tell you. We are giving away a USRP starter kit. *** CHALLENGE *** CHALLENGE *** CHALLENGE *** CHALLENGE *** GSM Scanner/Receiver Project http://scratchpad.wikia.com/wiki/Gsm *** CHALLENGE *** CHALLENGE *** CHALLENGE *** CHALLENGE *** This is a challenge and the winner get's a FREE USRP starter kit: - USRP - DBSRX - Antenna - Cable *** Deadline: Sunday 18th of February 2007 The Challenge: - Get most information out of Robert's samples. (http://www.segfault.net/gsm/resources) The one who can identify most frames and information from Robert's samples wins the challenge and gets the FREE USRP Starter Kit. To take part in the challenge please submit: - The frames you could identify - Other information you found out from the samples (signal strength, number of basestations, base station identify, ) - List of programs and tools you used. - Short Explanation to [EMAIL PROTECTED] before the 18th of February 2007 23:59. Your work will be submitted to the Mailinglist and published on our website (http://scratchpad.wikia.com/wiki/Gsm) I'll announce the winner of the USRP Starter Kit on the 19th! good hunting, steve ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] rational_resampling question
Hello, If I want to use the rational resampler without filtering, is it valid do this? taps = [1] self.resampler = gr.rational_resampler_base_scc( 3, 2, taps ) Thanks, Hans___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Software stopping of runaway realtime processes?
Eric Blossom wrote: > If they're not running as root (or holding CAP_SYS_NICE), the call > sched_setscheduler (the system call that enables realtime) will fail. > They're not running as root, I just added the Ubuntu udev rules on the website. I never explicitly enabled the SYS_CAP_NICE, it just happened, and I can't figure out how to remove it. -Dan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Bit Error Rate Testing?
I have been experimenting with the gmsk demodulation block, and am able to successfully demod 50M+ continuous pseudorandom symbols at 2.0 MSym/sec. Kudos to the USRP + GNURadio devs for making that possible, and thanks for making GNU Radio open-source. The testing methodology so far has been to output the demodulator to a file sink, eg: self.gmsk_demod = gmsk_demod(self, samples_per_symbol=2, verbose=True, log=False) limiter = gr.head(gr.sizeof_char, 1000) dst = gr.file_sink(1, 'output.dat') self.connect(self.u, self.gmsk_demod, limiter, dst) then to read the file into matlab and cross-correlate against the known bit sequence. However, the time has come to start doing some bit error rate tests at various SNRs, and the previously mentioned methodology starts to become impractical for low BERs (given that you generally want to wait until you get 100-1000 or so errors). SO: is there any way to get the demodulator's output out to a pin without seriously harming the current performance of the demodulator? I have a 2nd USRP available if that opens up additional options. Thanks for any advice. -Steven ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Software stopping of runaway realtime processes?
Dan Halperin wrote: > Eric Blossom wrote: > >> If they're not running as root (or holding CAP_SYS_NICE), the call >> sched_setscheduler (the system call that enables realtime) will fail. >> >> > They're not running as root, I just added the Ubuntu udev rules on the > website. I never explicitly enabled the SYS_CAP_NICE, it just happened, > and I can't figure out how to remove it. Update: I installed lcap, and ran lcap 23, which disables CAP_SYS_NICE: [EMAIL PROTECTED]:~# lcap Current capabilities: 0xFF7FFEFF 0) *CAP_CHOWN 1) *CAP_DAC_OVERRIDE 2) *CAP_DAC_READ_SEARCH 3) *CAP_FOWNER 4) *CAP_FSETID 5) *CAP_KILL 6) *CAP_SETGID 7) *CAP_SETUID 8) CAP_SETPCAP 9) *CAP_LINUX_IMMUTABLE 10) *CAP_NET_BIND_SERVICE 11) *CAP_NET_BROADCAST 12) *CAP_NET_ADMIN 13) *CAP_NET_RAW 14) *CAP_IPC_LOCK 15) *CAP_IPC_OWNER 16) *CAP_SYS_MODULE 17) *CAP_SYS_RAWIO 18) *CAP_SYS_CHROOT 19) *CAP_SYS_PTRACE 20) *CAP_SYS_PACCT 21) *CAP_SYS_ADMIN 22) *CAP_SYS_BOOT 23) CAP_SYS_NICE 24) *CAP_SYS_RESOURCE 25) *CAP_SYS_TIME 26) *CAP_SYS_TTY_CONFIG 27) *CAP_MKNOD 28) *CAP_LEASE 29) *CAP_AUDIT_WRITE 30) *CAP_AUDIT_CONTROL * = Capabilities currently allowed If I as root attempt to set the priority of a process via nice, it fails: [EMAIL PROTECTED]:~# nice -n -50 top nice: cannot set niceness: Permission denied The same thing happens to user processes. However, if I run an application that calls the GNU Radio enable_runtime function, that call succeeds and Python gets priority -50. Even though I have disabled CAP_SYS_NICE system-wide. This happens even if I log out all users and re-log in or do so remotely via ssh, do so with a user that's not even in the wheel group, etc. I can't think of what else to try... -Dan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Software stopping of runaway realtime processes?
Dan Halperin wrote: > I can't think of what else to try... /etc/security/limits.conf? Frank ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
