Author: Martin

It's October again and Munich's Oktoberfest is in full swing. In the tents, 100.000 seats are available to celebrate and mobile networks are challenged by the number of devices per square meter. They seem to hold out quite well though according to these interesting reports (in German, sorry) by Teltarif. But how much of a challenge is the Oktoberfest really to the networks? Let's play a bit with the numbers!

If there are 100.000 seats available in the tents then let's say that at any point in time there are around 150.000 people present, inside and outside of the tents. According to Wikipedia, the Theresienwiese on which the Oktoberfest is celebrated has 31 ha, which is roughly 500 x 500 m. I've put a map on the left to give you an idea of the location's size. 150.000 people packs a place this size quite tightly. If you have a look at the pictures from people taken at the Oktoberfest or on Wikipedia it's obvious the number is not overstated.

The next number that's available from this report is that one of the four network operators has put up 8 additional cell sites for the event and I assume the other network operators have put up similar numbers and the same or different sites. Let's say there are two sectors on each site as some of them must be at the border of the event area and hence the third sector pointing outwards doesn't carry as much traffic. GSM, UMTS and LTE are up and running but GSM doesn't carry a lot of data so I'll leave it out of the game.

Let's say out of those 150.000 people, 100.000 use a smartphone and do so heavily. Tweeting, texting, sending WhatsApp messages, pictures, Facebook, etc. etc. should drive uplink traffic well beyond the normal uplink/downlink ratio. After all, you need to show your friends where you are by sending pictures and they probably interact with you heavily so phones are unlikely to stay in pockets for long. So let's say the mobiles of those 100.000 people are connected to the network once every 3 minutes and stay connected for around 20 seconds. That means that each mobile device is online 60 times per hour for a total of 7 minutes every hour. 60 times an hour is perhaps a bit on the high side for an average, but let's be pessimistic.

Now, let's divide the 100.000 users by 4 network operators so each serves around 25.000 customers. There are 8 cell sites with two sectors each so 25.000 / 16 means each sector of each network operator serves 1562 devices. Each device is on air for 7 minutes per hour which means 208 mobile devices are on the air in each sector of each operator simultaneously. Sounds like quite a lot and if there was only UMTS, it would probably have a hard time, even if each network operator had deployed two carriers. But LTE cells can quite cope with such a number of simultaneous devices. And if the maximum capacity is reached it's possible to deploy extra LTE carriers, e.g. a 2600 MHz low power signal to catch the devices close to the cell and a somewhat higher power 1800 MHz signal to serve devices further away. Add UMTS to the overall mix and I would say there's still a healthy margin to work with.

Obviously the numbers I've used above are only assumptions and could be off by quite a bit. If you have more precise numbers please let me know, I'm happy to adapt my calculations.

When I moved to Cologne 5 years ago I upgraded from a 6 Mbit/s down – 384 kbit/s up ADSL line to a 25 Mbit/s down – 5 Mbit/s VDSL line and it felt really fast. It still does, well, sort of. That's because I could recently benchmark a 1 Gbit/s Fiber to the Home (FTTH) line in France and the results are nothing short of breathtaking.

When benchmarking such a connection it's necessary to have a server on the other end that can actually deliver such high speeds, a transit/peering connection of the fiber operator that is broad enough and a device at home that can handle data at such a high speed as well. As I couldn't go and benchmark that fiber link in person, I prepared a Banana Pi to be my remote test laboratory. A Raspberry Pi would not have done as it 'only' has a 100 Mbit/s Ethernet port and the processor can handle data transfer speeds of about 30 Mbit/s. The Banana Pi on the other hand has a Gbit Ethernet port and when I tested data transfers to and from a local server before shipping it to France I could reach speeds of 80 MB/s, i.e. 640 Mbit/s. That's not the full gigabit/s the Ethernet port is capable of but to get a feeling for the fiber line it's a good start.

To access the Banana Pi remotely I prepared it to automatically establish an SSH TCP port forwarding connection to my virtual server on th net with a public IP address. Via this little detour I could connect back to the Banana Pi despite it being behind a NAT. To test up- and download speeds I used CURL and http up- and downloads. The results are breathtaking. In the downlink direction I could reach speeds average speeds of 33 MByte/s, that's around 264 Mbit/s. A "small" 160 MB Linux distribution downloads in 6 seconds and is more than 10 times the speed of my VDSL line at home… In the uplink direction I could reach speeds of around 6 MByte/s, i.e. 48 Mbit/s which is also 10 times more than what my VDSL line can do. I ran the tests at 10 in the morning, in the evening during the busiest hours and also at 4 o'clock in the morning and always got the same results.

So which part is the bottleneck, the fiber line, the peering/transit link or the server on the other end? To find that out I ran two downloads simultaneously from two different servers, one connected to the French network via Level 3 and another one that was connected via the German Internet Exchange (DECIX). With this setup I got an aggregated 33 MByte/s. This means that the fiber link into the home was the limiting factor as otherwise I would have seen a higher aggregated speed.

It's pretty amazing what a fiber line directly to the home can do today and it also shows quite clearly that the copper cable to homes won't be able to compete for much longer in areas where fiber gets deployed.

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.