WirelessMoves

In a previous post I wrote down my first impressions on the Banana Pi and how it would fare as a platform for Owncloud. While the general message was 'quite well' there was no room in the post for more detailed benchmark results. So here we go:

To see how the Banana Pi costing €75 with casing and SD card fares compares to a slower Raspberry Pi costing €50 (with casing and SD card) and a faster Intel NUC based Owncloud installation costing around €200, I ran a number of everyday use cases on all three of them. The picture on the left shows my setup for a direct comparison between the Banana Pi and the Raspberry Pi. The NUC was not on the table for the test but connected over Wi-Fi. Obviously that reduces the data transfer speeds to and from the NUC somewhat but probably not by much.

On all three systems I've used https. It doesn't seem to have a big impact, however as the multiple file upload test described below didn't show a performance difference between the use http and https. On the Banana Pi, all data was put on the SD card, i.e. no external SATA drive was connected. This would have perhaps made the Banana Pi faster but my usage scenario is to have a small Owncloud box without external hardware to keep cost and space requirements down.

Login Test

My first test focused on how long it takes to log into an Owncloud user account after the Owncloud server has been rebooted. The time it takes is similar to the time it takes to log in after having logged out. I ran the same test three times on the Raspberry Pi and the Banana Pi to show that there is a certain variance.

• NUC: 5 seconds
• Raspberry Pi: 43 seconds, 41 seconds, 48 seconds
• Banana Pi: 7 seconds, 7 seconds, 14 seconds

Speed-up compared to the Raspi: approx. 6x

File Uploads

For this test I uploaded 38 images with a size of around 3 MB each on each Owncloud instance. After each upload an icon was generated that is shown next to the filename. The second picture on the left shows a side by side comparison of the upload progress on the Raspberry Pi and the Banana Pi respectively.

• NUC: 65 seconds (1 minute 5 seconds)
• Raspberry Pi: 420 seconds (7 minutes)
• Banana Pi: 142 seconds (2 minutes 20 seconds)

Speed-up compared to the Raspi: approx. 3x

Link download screen shown after reboot

Another important scenario is how long it takes for a download page to be shown to someone to whom I've sent a link for a shared file. To make sure there is no buffering, I rebooted the two Pis before each run.

• NUC: 5 seconds, 4 seconds
• Raspberry Pi: 32 seconds, 26 seconds
• Banana Pi: 8 seconds, 6 seconds

Speed-up compared to the Raspi: approx. 4x

Summary

The results show quite nicely that the Banana Pi runs an Owncloud instance much faster than a Raspberry Pi. The time it takes to log in, to upload files and to open a shared link is not as short as on a NUC but from my point of view it is still fast enough to be usable.

Recently I had a post on what I have done with the 8 Raspberry Pis I have bought in the past 18 moths. Owncloud has certainly been the most important use case at the beginning. While using Owncloud on a Raspberry Pi is great for calendar and address book synchronization between devices, other things such as the browser based GUI are too slow to be much fun on the long run. This is why I upgraded my Owncloud installation to an Intel NUC a couple of months ago which leaves nothing to be desired speed wise. Unfortunately we are looking at a €200 price point for the solution. While this is o.k. for me it, might be too much for others. As a consequence I was looking for an alternative between the Raspi and a NUC that is fast enough for an Owncloud installation that is used for more than just address book and calendar synchronization while still having a price point below 100 euros.

During my summer vacation I read some more about the Banana Pi and some people were claiming that it was about 5 times faster than a Raspberry Pi. This encouraged me to get one as well to see how it would fare with Owncloud. As you can see on the picture on the left, the Banana Pi at the top is just a bit bigger than the Raspberry Pi and you can get all the technical details here. While I will write a follow up post with benchmark results of how Owncloud runs on a Raspberry Pi vs. on the Banana Pi vs. on a Celeron based Intel NUC, suffice it to say at this point that Owncloud's browser based GUI runs around 5-7 times faster on a Banana Pi than on a Raspi and about half as quick as on the NUC. In other words, log-on times and reaction times of the web based GUI are quite usable. And at a €70 price point which includes the Banana Pi at €45, a €15 casing and a €10 sd-card, it's definitely an interesting platform for Owncloud from a cost point of view.

On the other hand there are a few things that make me hesitate a bit. In one of the Banana Pi forums I have read that sometimes the Ethernet interface does not come up during the boot process. I rebooted the Banana Pi many times during my tests and it only happened to me once. However, once is already once too often, especially for remote installations that need to boot properly without exception after a power failure or software reboot. Not a total showstopper but something to keep an eye on.

The second thing that needs some attention is that hardware and software are from a so far unknown Asian company. Not that this is a bad thing per see but it's a bit difficult to trust a company one has never heard of before. On the positive side, all software is open source and I ran my Owncloud tests on a Lubuntu 14.04 image. However, the Linux kernel and the sd-card image are not from Canonical but assembled by lemaker.org. Trust can mean many things and in this regard I have to trust that there's no software bundled in their kernel and sd-card image that does 'unwanted' stuff. While Lubuntu is updated via the Canonical repository, the kernel is not. That means I have to trust that the company will still be around in the next couple of years and willing to support the hardware or that somebody else picks up kernel maintenance should they walk away from the product.

And thirdly, I am not quite sure they have a Linux kernel upgrade process in place yet. What I can see on their web page are ready-to-burn sd-card images for a number of Linux distributions but no word on how the kernel can be upgraded. And speaking about the upgrades, the kernel patch level (3.4.90) used by the current distribution seems to be somewhat outdated, the official counting is already at 3.4.105 when I looked. Let's see, it's still a young project, there's a good chance these things will resolve over time.

A final thought for this post: It's great fun to tinker around with the Banana Pi, it is significantly faster than the Raspberry Pi and I have learnt a lot about the independence of Linux distributions such as Lubuntu, Debian, etc. from the kernel. After all, taking Lubuntu 14.04 that has been designed to run with 3.13.x kernels and using it with a 3.4.x kernel shows how independent distributions are from kernels. And for the details of how to marry a kernel with a distribution, here's a very insightful description from the Banana Pi makers on how to compile the kernel and integrate it with a distribution yourself in case you are inclined to put the software together yourself.

Last year I bought a coupler of faster USB-2 Flash sticks and was actually delighted with their read and write performance of 35 MB/s and 12 MB/s respectively compared to cheaper devices which were much slower. But the size of files I occasionally have to transfer between between devices keeps growing and 2 GB files are no longer the exception. In other words, I have to wait again two to three minutes for a file to be copied to the memory stick. Since then, however, I've upgraded to USB-3 on the PC and USB-3 capable flash memory sticks have become much cheaper. Since their advertised read and write speeds are phenomenally higher I tried my luck with a Transcend JF780 32 GB stick which is advertised with read and write speeds of 210 MB/s and 75 MB/s respectively. And here is the result I achieved in combination with my rather 'underpowered' Intel i3 notebook that has two USB-3 ports:

Write Performance

When copying a large 1.6 GB file to the stick from a non-encrypted partition of my notebook's solid state disk, the sustained data rate was 59 MB/s. This is 5 times faster compared to writing the same file to the USB-2 stick I bought a year ago (which I did again this time around just to make sure the stick is still fast and the new notebook compared to a year ago has no influence on the result). In other words, while the file takes over 2 minutes to be copied to the USB-2 stick, it copied to the USB-3 stick in just 27 seconds.

Read Performance

Read performance is even more breathtaking. Reading the file from the USB-3 flash stick and writing it back to the SSD after having ejected and reinserted the stick to make sure the file or a part of it is not read from memory) the sustained data rate was 100 MB/s which corresponds to a transfer time of 16 seconds for the 1.6 GB file.

Running the same benchmark program as in the year before resulted in a maximum read performance of 214 MB/s (without writing the data to another volume) and an average write rate of 29.6 MB/s as shown in the screenshot on the left. The write rate is lower in the benchmark because as far as I can tell, the program performs random writes, which is slower than to write a continuous file to the stick.

Price

The USB-2 8GB Transcend memory stick cost around €10 one year ago vs. €30 for the 32 GB Transcend memory stick with USB-3 this year. So while the per GB price has dropped, the overall price of the stick has increased. Cheaper USB-3 models are also available but their advertised read and write speeds are around 50 MB/s and 15 MB/s respectively. In other words, speed still has its price.

It's been an exciting year so far with many projects and many great things happening and I'm very excited to announce the completion of one of my bigger projects this year: As of today, the third incarnation of my book (now) titled "From GSM to LTE-Advanced" has been published and is now available in book stores online and offline!

If you've bought a previous edition you might have noticed that the title has changed slightly to reflect that it now also contains information not only about LTE but also about LTE-Advanced. That's not the only update, however, as lots has happened with other network technologies as well. The previous edition is from 2011 and from my point of view the following things have changed quite a bit since then and hence are now included in the book:

• In Chapter 1, I've included additional information on the 3GPP Release 4 Mobile Switching Center architecture that is now used in most networks.

• In Chapter 2, only few updates were necessary because the deployed feature set of GPRS and EDGE networks have remained stable in recent years.

• Chapter 3 was significantly enhanced as High Speed Packet Access (HSPA) features such as higher order modulation, dual carrier operation and enhanced mobility management states are now in widespread use.

• While only few LTE networks were in operation at the publication of the previous edition, the technology has since spread and significantly matured. Chapter 4 was therefore extended to describe Circuit Switched Fallback (CSFB) for voice telephony in more detail.

• Additionally, a section on Voice over LTE (VoLTE) was added to give a solid introduction to standardized voice over IP telephony in LTE networks. Furthermore, a description of LTE-Advanced features was added at the end of the chapter.

• As the global success of LTE has significantly reduced the importance of WiMAX, the chapter on this technology was removed from this revised edition.

• In Chapter 5 on Wi-Fi a new section was added on the new 802.11ac air interface. Also, a new section was added to describe the Wi-Fi Protected Setup (WPS) mechanism that is part of commercial products today.

• And finally, the chapter on Bluetooth has also seen some changes as some applications such as dial-up networking have been replaced by other technologies such as Wi-Fi tethering. Bluetooth has become popular for other uses, however, such as for connecting keyboards to smartphones and tablets. The chapter has therefore been extended to cover these developments.

There we go, as you can see I spent a lot of effort on the update. So whether you are a first time reader or consider 'upgrading' to the latest edition I hope you like the result!

What happens when I get a SIM card with unlimited and unthrottled Internet access while I'm on vacation? Right, I have to find out if it's really unlimited. A hypothetical scenario? No, not at all, Austrian operator 'Drei' (Hutchison Three) offers unlimited and unthrottled HSPA Internet access on their prepaid SIM cards for 18 Euros a month (without contract). Perfect for my recent vacation in Austria. The result: After pretty much behaving like at home with a fixed line connection, i.e. no moderation as far as video and audio streaming was concerned, I ended up transferring 16 gigabytes of data during my vacation over their 3G network. I have to admit I didn't check their max throughput but it was sufficient for video streaming and it never felt slow in the first place. Very nice!

Ever since I got my first Raspberry Pi I wondered how much power it really requires in my standard configuration, i.e. only with an Ethernet cable and an SD card inserted. Recently I got myself a USB power measurement tool to find out. As you can see in the picture on the left, the Raspberry Pi draws a current of 400 mA with the OS up and running and being idle. With a measured USB voltage of 5.4 V, the resulting power consumption is 2.16 Watts. At an efficiency of 90% of the power adapter itself, the total power consumption is therefore around 2.4 Watts.

Recently, I wrote two posts (see here and here) on how to use the Android/Linux 'hosts' file to block advertising and unwanted automatic OS downloads. Since then I've taken the approach further and have put the 'hosts' file for blocking on Github from where it can be downloaded by anyone.

To simplify usage I've put together a couple of scripts:

One script that runs in a terminal app on Android can be used for occasional updates of the blocking list. The script would have been a no-brainer but unfortunately the Android Busybox 'wget' implementation does not support https. Github, however, rightly insists on using https. So I had to find a different solution. The solution I found is to use 'curl'. Fortunately, the curl developers provide binaries for a number of operating systems, including Android here. The zip file for Android contains 'curl' and 'openssl' which have to be copied to '/system/bin' on a rooted Android device. The script to download the hosts file and copy it to '/etc/hosts' then looks as follows:  

mount -o rw,remount /system
cd /etc
mv hosts.blocked hosts.blocked.bak

curl -k https://raw.githubusercontent.com/martinsauter/Mobile-Block-Hosts-List/master/hosts.blocked >hosts.blocked

cp hosts.blocked hosts
mount -o ro,remount /system

In addition, 'ho.sh' (hosts — open) puts the original 'hosts' file back in place to disable blocking while 'hb.sh' (hosts — block) overwrites the 'hosts' file with a local copy of the blocking list to switch blocking back on again.

Simple, effective and quick!

I recently traveled to Italy and since my home network operator has an LTE roaming agreement with TIM, I could of course not resist to try out their LTE network. While many network operators have started with LTE quite a while ago and are now in the process of optimizing their networks, it seems TIM is not as far down that road yet. Both in Udine and Mestre I got LTE coverage from a 10 MHz carrier on the 800 MHz band. When making phone calls, the LTE network would always send my device to the GSM network and not in to the also existing UMTS network. This is quite a shame since it increases the call setup time and also denies me a data connectivity during the call. Hm, I wonder if they have optimized their network next time I have a look because this looks like early days.

While I like music streaming when I'm at home, things are quite different when it comes to listening to music on my smartphone. Here, I don't have a large library of individual tracks ripped from CDs or other sources, it would be too much work… Also, I don't use online streaming services while I'm on the go as the amount of data I have on my mobile contract per month is limited, the battery goes flat much too quickly and there are spots on my daily commute where I don't have coverage. So what I have on my mobile are recordings of the radio streams I like, each spanning several hours. The player to play these must only do one thing: play them. No album art, no database lookups, just play and play them instantly.

Unfortunately, pretty much all native players I've come accross. Especially the CyanogenMod Apollo player has problems with my recordings as it takes at least 10 seconds before it starts playing. I have no idea what it does in the meantime. So I had to go on the lookout for another player app that meets my needs and I had to find out that there's a large assortement, but all not to my (privacy) taste. But then I stumbled over a player I use on my notebook as well that fits perfectly: VLC. It's open source, simple to use, there's no album art lookups and privacy leaks, it plays pretty much any audio and video codec ever invented and it plays my files without any delay. Perfect!

After my previous posts on how to trace and analyze A-GPS SUPL requests (see here and here) I thought I'd also write a quick post with some references to more details on the parameters that are contained in an A-GPS SUPL message. When discussing GPS, two terms are regularly mentioned, The 'Almanac' and the 'Ephemeris data'. Here's a link to some background information on those terms and here's my abbreviated version:

Almanac: This information is broadcast by each GPS satellite and contains rough orbital parameters of each satellite. This information helps a GPS receiver to find other satellites during its startup procedure once it has decoded this information from a downlink signal. Note that this information is NOT contained in a SUPL response as it only gives long term rough orbital parameters that can only be used for satellite search but not for navigation.

Ephemeris: These are the precise orbital parameters of a satellite which is only valid for a short amount of time. While each satellite broadcasts the Almanac of all satellites, a satellite only broadcasts its own Ephemeris data. SUPL responses contain the Epehemeris data of all satellites the SUPL server thinks might be visible at the rough location a mobile device is currently located, perhaps, I'm not sure, in order of certainty, as the satellite IDs in the list were not ordered. I've also run a SUPL request with a cell-id that the SUPL server did not know and as a result the server returned a very long list of Ephemeris data with ordered satellite ID numbers, probably of all the satellites it knew.

And finally, here's a link to additional background information on the individual Epehemeris parameters.