CubieTruck Ethernet RX drops

22.11.2014 19:16

Last month I've written about occasional CRC errors on CubieTruck's SATA bus. Wired Ethernet interface is another device on this same board that is reporting intermittent errors in a similar fashion. This is how the packet error statistics page on Munin looks like:

CubieTruck eth0 errors by month.

190 micropackets per second on average is not a lot. That's around one dropped packet every two hours or one for every 47000 packets received. Supposedly the higher-level protocols detect the dropped packet and request a retransmission, so apart from higher lag every once in a while, this shouldn't be noticeable (in contrast for instance to the EeePC TCP checksum thing). Still, it is curious. This CubieTruck board is the only Linux-running computer I've personally seen that has the drops figure higher than zero.

Munin picks up the number from /sys/class/net/eth0/statistics/rx_dropped. This counter is somewhat ambiguously described by kernel documentation:

Indicates the number of packets received by the network device but dropped, that are not forwarded to the upper layers for packet processing. See the network driver for the exact meaning of this value.

First I thought the drops might be Ethernet frame CRC errors. However, it turns out that those are counted somewhere else. The errors also don't seem to go away when changing the UTP cable or the switch the CubieTruck is connected to. At least judging by a simple test with iperf, the occurrence of errors isn't correlated with the load on the interface (in other words, pushing more packets around doesn't make drops more common).

I guess it's time to look into the kernel source as the documentation suggests. I dug into Linux 3.4.95 for Allwinner A20 I'm currently using. The errors however also appeared when I was running the kernel shipped in CubieTruck Ubuntu Server installation. As far as I can see, no recent changes were committed to the git repository that would affect this driver. In any case, the only place where the rx_dropped count is incremented is in drivers/net/ethernet/allwinner/gmac/gmac_core.c on line 1179:

skb = priv->rx_skbuff[entry];
if (unlikely(!skb)) {
	pr_err("%s: Inconsistent Rx descriptor chain\n",

This is about as far as I got so far in tracking the source of this problem. I have no idea what an "inconsistent Rx descriptor chain" is or why it might happen.

Searching the web didn't turn up any complaints regarding CubieTruck's Ethernet, so I might just be lucky and got a marginal board. Or maybe I'm just more annoyed by non-zero error counts than most. On the other hand, some quick inquiries on the IRC channels turned out that it is indeed quite unusual to see any rx_dropped number higher than zero. So, if anyone has seen similar errors on a CubieTruck, please leave a comment below.

Posted by Tomaž | Categories: Code | Comments »

Coax attenuation

16.11.2014 17:33

Two years ago, when the Institute was setting up the network of spectrum sensing nodes in Logatec, we required a set of antennas to cover the TV broadcast band. Based on the frequency range of VESNA's receiver, I chose to buy several Super Scan Sticks from Moonraker. The 50 MHz - 900 MHz range we were intending to use them for was well within the Scan Stick's specification and it was also very reasonably priced compared to some other offers for broadband antennas we got at the time.

Since then this antenna proved to perform reasonably well compared to others we tried. For instance, the hand-held MRW-210 we have on some nodes because of its small size is practically useless. However, all work so far has been done above 470 MHz and it doesn't look like that will change in the future. In hindsight it would probably be better to choose an antenna that performs better at higher frequencies.

I was recently reminded of that when it was pointed out to me that even the connection between the antenna and the sensor might be causing significant attenuation in our setup. The Scan Stick has a (non-replaceable) SO-239 connector and we bought each antenna together with a matching 10 m long RG-58 coaxial cable. I overlooked that at the time, but neither that cable type, nor the connectors were designed with frequencies much above 400 MHz in mind.

SO-239 panel connector wired to a SMA plug.

Lately I have been preparing a handful of new receivers for deployment. The way you're supposed to wire a panel-mounted SO-239 (left on the picture above) to an internal coaxial cable was another reminder that this setup was not made with high frequency signals in mind.

Unfortunately I don't have equipment necessary to measure the characteristics of the antenna itself. However to get at least an estimate of how much signal power I'll actually be losing in the cable, I conducted some measurements with just the cabling. I connected the receiver through the pigtail shown above, 10 m of the RG-58 cable and a SO-239-to-N-type adapter to our Rohde&Schwarz SMBV vector signal generator. Then I swept the frequency of the generator and measured the detected power on the other end. As a control, I performed the same measurement using 60 cm of a LMR-195 cable with SMA connectors and a SMA-to-N-type adapter I had laying around.

Detected power versus frequency for two different cables.

As you can see, the difference between the cables is significant, while not exactly show-stopping. The big variation in detected power between 500 MHz and 550 MHz is due to variation in detector sensitivity.

There are some typical attenuation figures versus frequency for both types of cable available on the web. LMR-195 supposedly has less than .2 dB attenuation at 60 cm length on these frequencies. On the other hand, 10 meters of RG-58 has around 5 dB.

This suggests that the attenuation in the short LMR-195 cable is insignificant compared to longer RG-58. To get just the attenuation in the RG-58 cable and ignore changes in detector sensitivity, I subtracted the measurements with LMR-195 from those with RG-58. In the plot below, I compare this figure with the typical attenuation versus frequency for RG-58.

Cable attenuation measurement versus model.

From this graph it seems that RG-58 is performing better than expected. For lower frequencies the attenuation is actually a good decibel lower than it should be according the cable model. I also did not take into account any return loss, so the attenuation in just the cable must be even lower than what I measured. The SO-239 connector is pretty bad at keeping correct characteristic impedance above 400 MHz, so I'm guessing the reflection becomes significant at higher frequencies.

In the end, 6 dB loss means only one quarter of power at the antenna reaches the receiver. In the context of radio that might not be as bad as it sounds, but it definitely ruins the otherwise good noise figure of VESNA's receiver. We're running out of our stock of Scan Sticks anyway and I'll be looking into new antennas and cabling for future deployments.

Posted by Tomaž | Categories: Analog | Comments »

CubieTruck SSL performance

08.11.2014 17:24

For years now the general consensus seems to be that the overhead of serving web sites securely over SSL is negligible compared to plain-text HTTP, at least as far as CPU load is concerned. This might be true when talking about big, dynamically generated websites served by expensive rack servers humming away in some data center. But how about serving a small blog with mostly static HTML from a small ARM-based computer? It turns out that such a view is overly optimistic.

Before moving this site to HTTPS-only today, I performed some benchmarks with my CubieTruck server. I reused the same benchmarking scripts I used back in January to estimate the number of requests Apache can handle per second for a few different types of content.

My setup today is mostly identical to what I used then. Hardware is the same CubieTruck A20 on 100 Mb/s Ethernet, although now the root filesystem is on a Samsung 840 EVO SSD. Kernel is Linux 3.4.95 for Allwinner A20 from Static content is served by Apache 2.2.22 as shipped in Debian Wheezy armhf architecture. Dynamic parts are rendered with Perl 5 and HTML::Template and served through Apache and Speedy CGI.

I compared the following two Apache configurations:

  • Plain text HTTP and
  • secure HTTPS using TLSv1 protocol, ECDHE-RSA-AES256-GCM-SHA384 cipher and 2048 bit RSA key (a reasonably secure setup according to SSL Labs).

Below are results from the Apache benchmarking tool. Numbers in parentheses show size of HTTP body (without headers).

Requests per second for static HTML.

Requests per second for dynamic HTML.

Requests per second for image.

Requests per second for API call.

As you can see, encryption unfortunately makes the server somewhere between 2 and 7 times slower. The impact is highest when serving small static files. Most likely CPU time spent in the SSL layer dominates there. On the other hand, there is less slow-down with the dynamic content where the CPU had something to do even in the plain-text case.

Can something be done to improve these numbers without degrading the cipher settings? Not much, it seems.

Relatively recently, OpenSSL in Debian was compiled on ARM without hand-optimized assembly routines. I have checked, however, and the version of OpenSSL I was using has the patch that enables them already applied (together with around 50 other OpenSSL patches that Debian ships with these days).

The Allwinner A20 SoC appears to have some kind of crypto hardware on board. Unfortunately, there is very little information available about it. If it could be exposed through the kernel's crypto API, it might speed things up a bit. An experimental kernel driver has been around from June this year. The remark about not using DMA however makes me a bit pessimistic regarding its usefulness at this point. I might try to set it up eventually, but it will probably be tricky. Even with working kernel support, enabling hardware acceleration for OpenSSL in this way seems to be non-trivial.

Posted by Tomaž | Categories: Code | Comments »