Arithmetic performance of Raspberry Pi

jlinkels · 03-04-2013, 08:12 PM

I am working on a data acquisition system using a USB DUX Sigma and a Raspberry Pi. The Raspi came as an aftertought into this system. First I had projected normal Intel hardware. But I ordered some Pi's to test, and was so impressed with the speed I am now considering using the Raspi.

I have no idea as to what the arithmetic performance of the raspi is in terms of my application. Can someone provide some more information?

I am planning to sample data 6 channels, 2 kHz. Each two samples need to be multiplied (chan1 x chan2, chan3 x chan4...) and the products need to be averaged over 2000 samples. The data acquisition is performed on the DUX, and transferred to the Raspi over USB.

First, is that something which is in the range of the Raspi's capabilities?

Second, I get the sampled values in 24-bit integers. Would it be wise to perform the multiplications in integer arithmetic and convert it to float when I have the average value in integer. Or is there a powerful FPU so it is even better to convert each sample to float right away and perform multiplications in floating point?

jlinkels

business_kid · 03-05-2013, 03:33 AM

Quote:

I have no idea as to what the arithmetic performance of the raspi is in terms of my application. Can someone provide some more information?

You should really read the datasheet of the appropriate cpu. The arm is a less powerful but more internally favourable environment.

Quote:

I am planning to sample data 6 channels, 2 kHz. Each two samples need to be multiplied (chan1 x chan2, chan3 x chan4...) and the products need to be averaged over 2000 samples. The data acquisition is performed on the DUX, and transferred to the Raspi over USB.
First, is that something which is in the range of the Raspi's capabilities?

.
First thing to say is that everything in the Pi is work for the cpu. It's a matter of total load. Seat of pants guess, I feel the Pi should handle it. If it's doing web surfing as well, no. The only way to be sure if to try it. There is the useful program 'time' which you can use. Take a figure in from the usb, do a calculation, repeat that 100(0) times and get the time. You'll have a guesstimate as to how long it takes. Or go to assembler, and you can count cpu cycles.

Do you get the same result in the math if you add the 2000 samples, multiply by another channel then (1 multiplication) and divide by 2000? BTW, 2000 is a human number. Use 2048 and you can simply move digits right for the divide :-D.

Quote:

Second, I get the sampled values in 24-bit integers. Would it be wise to perform the multiplications in integer arithmetic and convert it to float when I have the average value in integer. Or is there a powerful FPU so it is even better to convert each sample to float right away and perform multiplications in floating point?

I have no idea on this one. It's _your_ project. Again, I would try to work with the samples I have for adding/multiplying them. The separate FPU was an invention of intel's who nobbled their own fpu in things like the 486sx. I would have high expectations of the arm fpu - for what it is.

pan64 · 03-05-2013, 04:18 AM

http://raspberrypi.stackexchange.com...-point-support

jlinkels · 03-07-2013, 08:27 PM

I think the question is moot.

When I sample there are 12,000 conversions from integer to physical values using the Comedilib function. Then I do that 6,000 multiplications. The processor load is around 1.3%.

However, in the example there is a print command which prints formatted output

Code:

fprintf(datafile, "%#8.6g \t%#8.6g\t", u_phys, i_phys)

When I include that statement, processor load jumps to 13%.

So the fp multiplication is not something to worry about. Other program parts are much more significant.

jlinkels

theNbomr · 03-08-2013, 04:12 PM

I bet if you wanted to be very very clever, you could figure out how to offload some of the arithmetic onto the GPU, which is probably very optimized for that sort of work.
24-bit data, huh? Is this a CAMAC-related project, perchance?
--- rod.

jlinkels · 03-09-2013, 09:04 AM

Quote:

Originally Posted by theNbomr

I bet if you wanted to be very very clever, you could figure out how to offload some of the arithmetic onto the GPU, which is probably very optimized for that sort of work.

I am not very clever and time is waaaaay not permitting these projects. And it is not needed. With the few FP arithmetic operations I do right now the CPU load stays under 2%. I have to do some more calculations but with this result I don't expect any problems.

You see, the last time I did something embedded (although you can argue if the Raspi is embedded) it was on 68000, and the sucessor, the 68020 was way fast so we could move the code of 2 68000's in one 68020. We did pattern recognition and 3D transformations for welding robot control and all calculations were made in 32-bit integer. Accuracy needed was only 16 bits, but to compensate for inacuracies, values were SHL 16 bits so some kind of binary fixed point arithmetic was used. So my first reaction for calculations on less powered hardware is still to do that in integer.

Quote:

Originally Posted by theNbomr

24-bit data, huh? Is this a CAMAC-related project, perchance?
--- rod.

Noooo... it is orders of magnitude less sophisticated. I am building an energy measurement and logging system. Those exist, I know, but I need:
- fast sample rate, less than 1 second, to gather statistical information about variation in solar energy production.
- non-proprietary and simple data formats
- "unlimited" storage capacitiy
- data accessible and retrievable thru ethernet
- ability to react on external events so I need additional digital inputs
- ability so send me a nice mail now and then

Systems which do all this are not available to my knowledge, or prohibitively expensive. Most systems allow you to run a Windows application to display some graphs. Heck, my client even installed a measurement system somewhere and all he can do is login thru remote desktop to look at the graphs. No data export!

As for obtaining the measurement values, I sample 50 Hz signals with 2kHz sample rate and simply multiply U and I and average the product to obtain data-per-second.

I am using the USB DUX Sigma www.linux-usb-daq.co.uk/tech2_duxsigma/ because it has a decent comedi driver. The DUX has a 24-bit ADC (which is overkill). DAS cards were out of the question because the original idea was to use an Atom based nettop which would not allow an internal card. But when I evaluated the Raspi it would even be a better solution.

Gee, long rant. No people in a circle of 2000 km seem to understand what I am doing so I guess I have to vent that somewhere.

jlinkels

theNbomr · 03-09-2013, 11:34 AM

No need to apologize. It's great to hear about interesting projects such as yours.

As to the philosophy about integer vs floating point for intermediate calculations, I think that as long as you do not risk overflowing the range of integers, and if your data originates as integer data types, then stick with integer calculations for as far as you can go in the algorithm. With luck (and care, of course), your only conversion to floating point may be at the final conversion to engineering units at the end of the process.

There are frameworks/systems out there for structuring and building on what you are doing. 'SCADA' is the generic term; a Google search should turn up some interesting hits. Most will be commercial packages, but there are free open source systems too. I use EPICS, which is a similar package, geared more toward control systems, but it can work in a data acquisition role as well. Using packages like those will give you a lot of the infrastructure and end-user tools for free, and many will be happy on various platforms. They also provide extensibility by allowing you to craft your application-specific components to use well formed and mature standards; all you have to do is write the low-level stuff and plug it in to the rest of the system.

--- rod.

jlinkels · 03-17-2013, 09:18 PM

Quote:

Originally Posted by theNbomr

As to the philosophy about integer vs floating point for intermediate calculations, I think that as long as you do not risk overflowing the range of integers, and if your data originates as integer data types, then stick with integer calculations for as far as you can go in the algorithm. With luck (and care, of course), your only conversion to floating point may be at the final conversion to engineering units at the end of the process.

Well, I ran some tests on the Raspi with FP and integer, and the performance is amazing. I hope the compiler was not that smart to detect that I actually never used the result and really carried out the code:

Code:

gettimeofday(&start, NULL);
    fprintf(stderr,"Start time before %d double calculations: %ld.%06ld\n", nr_records, start.tv_sec, start.tv_usec);
    for (chan_nr=0; chan_nr < nr_records; chan_nr++){
        power[chan_nr]=(u_raw+chan_nr) * u_raw;
    }
    gettimeofday(&end, NULL);

It did 1,000,000 FP multiplications in 100 ms.
Integer calculations are about 3 times as fast.

At first I wanted to detect zero crossings in the 50 Hz signal for find the relative phase of the signals. These measurements lead me to believe that an once-per-second FFT is feasible. That saves a lot of coding and debugging.

While I was reading thru documentation of FFT (for the first time in my life understanding FFT!, thanks to this web site: http://www.earlevel.com/main/2002/08...on-to-the-fft/) I also believed that I could find U I cos phi thru FFT. After all, this is exactly what the real part of the fundamental frequency gives. Unfortunately, with only the slightest deviation of the 50 Hz frequency the dispersion become significant as then I don't have an integer number of periods in my samples. And with the dispersion increasing, so is the inaccuracy.

Quote:

Originally Posted by theNbomr

There are frameworks/systems out there for structuring and building on what you are doing. 'SCADA' is the generic term; a Google search should turn up some interesting hits. Most will be commercial packages, but there are free open source systems too. I use EPICS, which is a similar package, geared more toward control systems, but it can work in a data acquisition role as well. Using packages like those will give you a lot of the infrastructure and end-user tools for free, and many will be happy on various platforms. They also provide extensibility by allowing you to craft your application-specific components to use well formed and mature standards; all you have to do is write the low-level stuff and plug it in to the rest of the system.

I know what SCADA is, and until now I found it almost impossible to interface with open source tools. I have worked with Siemens, which is totally Windows oriented. Siemens has the Profibus to which I can interface with a Hilscher Profibus card and Hilscher even provides Linux drivers. But that is the lowest level imaginable to talk to a PLC, on the raw memory level. It works, I had some other genius develop an interface box for me so I could translate my SNMP to Siemens. Furthermore I have been using Avantech remote I/O using modbus from within TCL.

So thanks for the pointer to EPICS. I never heard about it, never found it. Surely I will take a deeper look into it.

BTW, by mentioning CAMAC and providing this kind of information it looks like you are involved in particle physics and so. Hence the nick theNBomr?

jlinkels

business_kid · 03-18-2013, 04:42 AM

While you are going at sound & fft, I presume you're processing it deeply

Are you aware of fftw? Fastest Fourier Transform In The West - it's a unix gpl program with library
http://www.fftw.org

You're going at sound analysis. I presume you're not doing it for love or money, so you're doing it for paper. The guys in dit.ie have done that before you. My son studied there under one Dan Barry, who has since parted ways with them and is behind http://45sounds.com & http://www.riffstation.com/. There is still some good audio resources on the dit.ie website, although there was a court case and some of it might have come down as a result of that.

My son wanted to pick the tune out of a track, but Barry had put through 4 audio enthusiasts in succession who tried that as their project and failed, so he did an about face and did a multitouch thing.

theNbomr · 03-18-2013, 01:01 PM

Quote:

Originally Posted by jlinkels

I know what SCADA is, and until now I found it almost impossible to interface with open source tools. I have worked with Siemens, which is totally Windows oriented. Siemens has the Profibus to which I can interface with a Hilscher Profibus card and Hilscher even provides Linux drivers. But that is the lowest level imaginable to talk to a PLC, on the raw memory level. It works, I had some other genius develop an interface box for me so I could translate my SNMP to Siemens. Furthermore I have been using Avantech remote I/O using modbus from within TCL.

So thanks for the pointer to EPICS. I never heard about it, never found it. Surely I will take a deeper look into it.

BTW, by mentioning CAMAC and providing this kind of information it looks like you are involved in particle physics and so. Hence the nick theNBomr?

jlinkels

Yeah, I have a connection there. My nick has nothing to do with that, however.

If Siemens PLC interfacing is part of your project, I suggest you look at their Fetch/Write & Read/Put (?? I think... senior moment...) protocols that work on ethernet. I have used Fetch/Write to interface to Siemens PLCs with just a few lines of Perl code, and have written C code to do the same. The protocol is quite simple. Knowing what PVs to read and write in the PLC is a lot trickier, unless you are the author.

Thanks for posting your timing results on the Pi. I think it might be a useful platform for some dedicated special purpose applications like yours.

--- rod.