A Pi Straight Flush – Comparing the Pi 2

Extract

The Pi 2 Model B was release on the 2nd February 2015 promising a 1.5 to 6 times performance boost over the earlier generation one hardware.  If that boost occurred across the entire pipeline then even a minimal 1.5 improvement would reduce the latency from 120 to 80 milliseconds (a 33% reduction) and make a very useable FPV system.  Not enough for racing, but enough for most everything else.  Anyway, a 250mm racing quad would be too small to carry a Raspberry Pi.

In reality the processor is only one small part of the video streaming pipeline and while the Pi 2 does reduce the latency, the improvement is not nearly as much as you might think.  In fact most of the improvement over previous tests has come from a change in test procedure.  The final conclusion though is that the Pi 2 does at least allow us to break the 100ms barrier.  If I can just get a 5 GHz wifi system running on the Pi 2, then the next step is to actually get it airborne.

In addition to the Pi 2, I also have a Pi 1 A+ that had not been tested.  The A+ is smaller and lighter than the previous boards which is an advantage if you’re trying to fit it in a tight fuselage.  As I was using a new build of Raspbian, I thought I would run the test on all versions of the Pi: the A, B, B+, A+ and Pi 2B; a straight flush of Pi.

Setup

Nothing new here.  I used the build of Raspbian from the previous test.  As I haven’t managed to get 5 GHz WiFi running on the Pi 2 yet, the test was done using the Edimax EW-7612UAn V2 2.4GHz USB WiFi stick as this was compatible with all versions of the Pi.  Following the previous tests where the Dual Band AC600 Wifi Adapter had similar performance to the on board ethernet port, I also tested the B and 2B over LAN.  The idea being to see what the Pi 2B could achieve with a good WiFi adapter.

Procedure

These tests were a straight comparison between the five Pi devices using the same settings and the same testing methodology as previously.  The resolution was 1280 x 720 pixels with a 6Mbps bit rate.

Results

My first impression of the Pi 2B was that it was faster than the series one models, however when I started analysing the results, I could see no improvement after seven iterations.  So I went back and calculated the latency at each step.  This revealed a general trend for the latency to increase with each step.

With the Pi sampling at 48 fps, that’s 21ms for each frame.  The screen is refreshing at 60 fps or once every 17ms.  Depending on when the image appears on the screen bright enough for the camera to detect there could be a significant increase in latency towards the end of the iteration loop.  In practice these things tend to average out and the general trend seems to be a 20ms increase between iterations 1 and 7.

I started using the multiple iteration technique right back at the start of this testing when we were looking at a latency in the 200 to 300ms range. Back then there was also a lot of variation at each step and so this increasing trend was not immediately apparent.  Now that the latency is around 100ms and more consistent it has become so.

Because of this, I have changed my result reporting to only use the average of the first iterations and I always collect at least 10.  From the above graph you can see that over WiFi the Pi 2B has the lowest latency at 103.3 ms, but that’s only  2.3 ms faster than the Pi 1B.

Using the ethernet port the Pi 2B does better with an average latency of 97.2 ms whereas the Pi 1B could only manage 107.4 ms.

Here is a summary of the final results.

From fastest to slowest the final results are Pi2B, Pi1B, Pi1A+, Pi1A, Pi1B+.

Discussion

So where is the 1.5 to 6 times performance improvement, the 33% reduction?  The best result achieved is a 10% reduction.  The answer is that the processor represents only a part of the complete video capture and transmission pipeline and each stage involves converting the stream into different forms through multiple processors.  Remember each device (camera, bus controller, Pi, USB controller, USB hub, WiFi Adapters, PC CPU, Video Card and display) has their own processor and most are not as powerful as the Pi.  Unfortunately, there is no easy way to measure the latency at each stage to determine where the main bottlenecks are.

It must also be remembered that gstreamer is a complete pipeline in itself, with multiple conversions between the raw video and the packetized stream sent to the WiFi adapter.

It is interesting to note that the A models were faster than the Pi1B+ even though they have half its memory.  The A models only have a single USB interface.  The B models don’t have multiple USB interfaces, they have the same single USB interface and that feeds a built-in two or  four port hub.  This adds an extra stage to the transmission pipeline making the Pi1B+ slower than the A models even with twice the memory.   I assume the two port hub in the Pi1B is faster than the four port hub in the Pi1B+ which combined with the extra memory makes it faster than the A models.

Conclusion

If the Pi 2B can be made to work with one of the dual band WiFi adapters and achieve this sub 100ms average latency then it has promise to finally deliver a low cost and useable high definition FPV system.

At the moment Raspbian is still optimised for the arm6 architecture of the first generation hardware.  With an operating system optimised for the arm7 in the Pi 2B further latency improvements should be possible.

There are no immediate plans for a Pi 2A.  If this was released with the 512MB of memory of the current B models, a single USB interface and a small form factor, it could be the idea platform for HD FPV.

Perhaps the way to improve the latency further is to switch from a raspivid/gstreamer RTSP (Real Time Streaming Protocol) solution to some other protocol.  Perhaps MpegStreamer holds the answer.  Only more testing will tell.