The main deficiency is the USB core of the Broadcom SOC.The external use of the USB of the Rpi, even if not optimal, is not whose than in any other computer. Depending of the context, you could not expect mode than 1/10 to 1/3 of the total USB bandwidth.
Emmanuel. Le 03/03/2015 22:19, Paul Connolly a écrit :
> Is this a problem with the RP B/B+ or the RP 2B or all of the above? Short answer: All of the above. Longer answer: The real way to resolve a USB performance issue in the RPi hardware design is to either wait for Broadcom to release a version of the CPU/board with non-hub USB 2.0 port(s) (maybe the RPi 2 A), or simply do not use the RPi for any task that requires the movement of large amounts of data about fast. Its USB performance is broken by design, price was the primary design goal, and a lot of non-optimal design decisions were made, to achieve the price point.For software defined radio it is currently a bad choice of hardware except for maybe the Funcube Pro/+ at 9600Hz/19200Hz bandwidth.RPi Model A and Model A+ --------------------------------------It has a single dedicated USB 2.0 port, so maybe the throughput performance issue may not be there. But even if you could read the data in there is nowhere to send it. And the CPU only has equivalent performance 300 MHz Pentium II of 1997-1999, so it can not process the data in real time. And there is nowhere to buffer it to so unless you are only processing a few seconds of data in non-realtime, this is no good.RPi Model B --------------------It has a single USB 2.0 port, with a 3 port hub provided by the Microchip LAN9512 (one of the ports has a 10/100 ethernet connected at all times). But even if you could read the data in there is nowhere to send it (if you sent it to another USB device the throughput would be halved straight away). And again the CPU only has equivalent performance 300 MHz Pentium II of 1997-1999, so it can not process the data in real time.RPI Model B+ ----------------------It has a single USB 2.0 port, with a 5 port hub provided by the Microchip LAN9514 (one of the ports has a 10/100 ethernet connected at all times). But even if you could read the data in there is nowhere to send it (if you sent it to another USB device the throughput would be halved straight away). And again the CPU only has equivalent performance 300 MHz Pentium II of 1997-1999, so it can not process the data in real time.RPi Generation 2 Model B ------------------------------------It has a single USB 2.0 port, with a 5 port hub provided by the Microchip LAN9514 (one of the ports has a 10/100 ethernet connected at all times). But even if you could read the data in there is nowhere to send it (if you sent it to another USB device the throughput would be halved straight away). Ok the CPU's in total are about 6x the performance of the original RPi so it could be very roughly equivalent in performance, if the application is multi-threaded, to a 1200 MHz Pentium III chip from 2001-2002.On 03/03/2015 19:06, rgk wrote:Is this a problem with the RP B/B+ or the RP 2B or all of the above? All the RP's have the same IO chip, but the Pi 2B has a totally different CPU and that new chip on the bottom of the board. If I sound non-specific it's because I just got a Pi 2B and have had little time to research its new features and capabilities. I think if the IO chip is the problem (just not enough throughput) then what can be done to minimize the over run issues?Date: Tue, 3 Mar 2015 08:45:01 +0100From:[email protected] To:[email protected] Subject: Re: [Hackrf-dev] <DKIM> Re: HackRF with Raspberry Pi 2 OverrunsIt is a congenital deficiency of theRPi. It needs near realtime response and an awfull amount of CPU to not drop usb transactions. Search Rpi usb split transaction on google.Emmanuel. Le 03/03/2015 04:36, Silverfox a écrit :Idon't think it is unreasonable for the PI to cause overruns but others may prove me wrong. It takes considerable horsepower to process the data without overruns. However, if you aren't doing heavy processing in the flowchart. FFT is probably the biggest consumer of cycles. 73, Alan - W6ARHFrom:HackRF-dev [mailto:[email protected]] On Behalf Of Derek Murphy Sent: Monday, March 2, 2015 6:41 PM Cc:[email protected] Subject: Re: [Hackrf-dev] HackRF with Raspberry Pi 2 OverrunsDonald, I changed the sample to 2e6 andthen up to 4e6, both way the Overrun indicator starts to appear faster and then fills the terminal window faster.I am not sure if I have something wrongwith the driver or kernel config. It's a stock kernel from the raspbian distro. I tried a couple of different USB ports on the pi with no change.On Mon, Mar 2, 2015 at 2:22 PM, rgk<[email protected]> wrote:I am currently building a completely portable pi 2 setup that runs off of LIPOs. This is my intended purpose...IE my hackRF on my pi. I'm very interested in what others have done similar to this.From:[email protected]Date: Mon, 2 Mar 2015 08:00:50 -0500 To:[email protected] Subject: [Hackrf-dev] HackRF with Raspberry Pi 2 OverrunsI wanted to see if anyonehas had similar experience with the Raspberry Pi / Pi 2 with regards to the HackRF.The USB port bandwidthwas was around 18MB when I ran the transfer test.When I get into GNU, Ihave a very simple example that show the standard fft on coming from the hackrf source. I have the sample rate set to 1.0e6 but also run into similar issues when I run at 64k. I get the OOOOOO being posted and not just when I start the application.Thanks _______________________________________________HackRF-dev mailing [email protected] https://pairlist9.pair.net/mailman/listinfo/hackrf-devNovirus found in this message. Checked by AVG -www.avg.com Version: 2015.0.5751 / Virus Database: 4299/9207 - Release Date: 03/01/15_______________________________________________ HackRF-dev mailing list [email protected] https://pairlist9.pair.net/mailman/listinfo/hackrf-dev_______________________________________________ HackRF-dev mailing list [email protected] https://pairlist9.pair.net/mailman/listinfo/hackrf-dev _______________________________________________ HackRF-dev mailing list [email protected] https://pairlist9.pair.net/mailman/listinfo/hackrf-dev_______________________________________________ HackRF-dev mailing list [email protected] https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
_______________________________________________ HackRF-dev mailing list [email protected] https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
