Category Archives: Electronics

Consumer electronics, portables, whatever

NASed and RAID1ed

Synology DS211jI finally got my act together and bought myself a Synology DS211j NAS  with two 2TB drives. I’ll use it as a shared network disk at home and I intend to backup to it – as I also have a home office it’ll feel better to be able to also backup company related data somewhat more safely. My previous backup was only copying data from one HDD to another within the same physical machine.

To make it slightly more resistant to disk and hardware errors I’ve configured the disks to do RAID1 (all data is stored on both disks simultaneously).

The GPLv2 license was provided printed on paper in the package.

Rockbox seen on iPod Classic

Rockbox tiny

After a very long time of work, a very very long time since these devices were introduced on the mp3 player market, the hard working guys from have produced something on yet another device. This is the same group that previously was called linux4nano and worked so long and fiercely to get code running on the 2nd generation iPod Nano and the 4th generation iPod Nano.

At the end of December 2010, Michael “TheSeven” Sparmann announced that he was running custom code including music playback on the iPod Classic. The (sometimes) so called 6th generation.

Robert Menes spiced up the story today by showing us a live picture of a Classic device that now actually is running Rockbox:

Rockbox on the iPod Classic

Awesome work Michael, truly impressive. I hope a lot of Classic owners soon will be able to try out Rockbox for real. Rockbox is said to not yet be very stable or functional, so there’s a lot of room for more hackers and developers to join in and help us improve!

Re-evaluating the criticism


A long while ago I posted my first version of the comparison of libssh vs libssh2. I have since then kept it updated and modified it over time. (Reminder: I am the libssh2 maintainer)

In that page, I included the performance differences I had measured which at the time showed libssh2 to be significantly faster when doing SCP operations.

The libssh guys always claimed I was wrong:

Please don’t be ridiculous. No competent network developer will take you seriously when you tell that libssh2 is 2.3 times faster that libssh.

and have even used rather harsh words when saying so.

you read this FUD page on the libssh2 website. I don’t want to start arguing here, the page is complete crap

(These two quotes are from the two leading libssh developers.)

Due to their complaints I withdrew the mentioning of the speed differences from the comparison page. Maybe I had done something wrong after all and since I didn’t care properly to go back and verify my methods and redo everything, I decided to just take it off until I have more backing or more accurate tests.

Fast forward to current time and Mark Riordan does his extensive performance tests of various SSH/SFTP implementations. He mailed the libssh mailing list about it, and his test results are interesting. I’m including it below for easier reading and just in case Mark’s original won’t be around as long as this.

It repeats very similar numbers to mine and shows the same speed difference that I was told cannot happen. Isn’t that funny? Am I still ridiculous?

SSH file transfer performance

The following table summarizes performance of SSH clients.

LAN: 1 Gbit/sec WAN: 6 Mb down, 0.9 Mb up
Solaris x86 server
Client Client OS Server Comp
libssh2 Win Solaris No No 0.147 12.2
libssh2 Win Solaris Yes No
libssh2 Linux Solaris No No 0.82 11.8
libssh2 Linux Solaris Yes No
libssh 0.4.6 Win Solaris No No
Bitvise Tunnelier Win Solaris No No 13.50 3.95
Bitvise Tunnelier Win Solaris Yes No 8.541 10.2
psftp Win Solaris No No 9.4 5.06 or 0.46
WS_FTP 12.3 Win Solaris No No 8.07 7.65
Ubuntu sftp Linux Solaris ? No 29.6 11.5
Linux server
libssh2 Win Linux No No 9.5 8.1 0.059 0.26
libssh2 Win Linux Yes No
libssh2 Linux Linux No No 7.4 7.4 0.083 0.267
libssh 0.4.6 Win Linux No No 15.4 2.8 0.10 0.13
libssh 0.4.6 Linux Linux No No 8.97 2.8 0.099 0.189
libssh 0.4.6 Linux Linux Yes Yes 19.7 3.3
libssh latest Win Linux No No 14.1 1.38
psftp Win Linux No No 4.59 6.58 0.070 0.10
WS_FTP 12.3 Win Linux No No 23.0 8.5 0.113 0.361
Bitvise Tunnelier Win Linux No No
Ubuntu sftp Linux Linux No No 16.2 6.6 0.11 0.51

What about SFTP?

It should be noted that in my original claim and in this test above we speak SSH speeds (like SCP), not SFTP. SFTP has its own slew of problems and libssh2 is in fact not very good at doing SFTP speedily yet. We have work in progress to improve this situation, but we’re not there yet. I’ll post a follow-up on SFTP speeds soonish as things have been developing nicely in there recently.

What about speeds compared to other clients?

libssh2 is not fully on par with for example openssh when it comes to raw SCP speed, but it is in the same “neighborhood”.

Mini 2440 Lyre

On ebay there’s a fancy S3C244-based board named mini 2440 with a 3.5″ touch LCD attached on sale for 85 USD. 64MB ram, 400MHz CPU, a nand flash and more. Lots of stuff for the money.


The guys in the lyre project seem to have adopted this as yet another hardware platform to attempt to run Rockbox on. After their Atmel AT91SAM target was ditched, they went the ARMopendous route and now this seems to have entered. This third hardware platform is called the Lyre prototype 2

You should note that this Mini 2440 board has no batteries or anything and thus is not really meant to be a portable device in this shape.

“Bob” seems to have initial Rockbox code running on this device, and well-established Rockbox hackers JdGordon and domonoky have both ordered their own kits so the future looks bright.

Sandisk: “our sound fidelity isn’t perfect”

Some owners of the SansSanDisk Sansa Clipa Clip player from SanDisk noticed that it does playback of all songs with a minor pitch. Due to a flawed HW setup they don’t do a proper 44,100 Hz but instead 43,791 Hz (0.993 times the target value) or something like that. According to some sources this problem might be fixed in the Sansa Fuze players now.

Bugs aren’t really so surprising, perhaps what is surprising is that this bug has been around now for almost two years. To make matters worse, SanDisk now decided that due to them making cheap players people shouldn’t expect them to be very good sound quality wise and therefore they can simply not fix the problems:

due to trade-off decisions that were made in engineering these products to deliver superior consumer value at what we believe are extremely attractive price points, our sound fidelity isn’t perfect. We have re-evaluated the possibility of reducing the pitch variation and due to the engineering trade-offs the decision was made to stay with the current design. Very few listeners, however, have noticed or complained about it as an issue in actual practice.  For those who can detect sound differences with their naked ears during actual use and not via frequency analysis, our products may not be the best choice for them.

Clip owners out there now put their hope even more on Rockbox for Clip.

Concepts of a new distributed build

It was time to make an overhaul of our distributed builds system for Rockbox. The one currently in place is quite fancy and it does build 106 builds in around 7-8 minutes, but during the years it has served us we have found a few areas where we want to improve.

The goals for the new system were primarily:

  • do all the builds faster
  • reverse the connection so that people can contribute clients easier
  • make a system that is more allowing for slower machines to contribute

The biggest weaknesses of the existing system:

  • The master uses ssh to the distributed clients, which forces them to have an accessible ssh server and port etc. It also makes it awkward for people behind NATs who wants to run more clients.
  • It only hands out a particular build to one client, so thus if a large build happens to get handed to a slow client towards the end of a build round, all the other clients will sit idle waiting for the last client to finish.
  • The build and the subsequent upload of results to the master are synchronous, so thus a client with a very slow uplink may spend a significant time on the upload before it can start the next build.

The  new system is currently in development. It consists of a server that runs on one of our main servers, and there’s a client script that each volunteer contributor runs on their systems.

The clients connect to the master on a dedicated TCP port, specifying user name, password, name of the particular client instance, what particular architectures the client can build and how many bogomips the client boasts. While bogomips is a bogus way to measure anything, we’ve started out using it for a rough way to sort the the build clients based on speed.

The clients keep connected to the server all the time. There’s a ping message from the master every N second of idleness to make sure the connection is kept alive. As soon as the master wants the client to do a build, it sends a message to it detailing exactly how it should build it and using what SVN revision. The client will then do the build at once, upload the results using HTTP to a dedicated place and then tell the server the build is complete.

The server knows about all builds to do at a  commit, what we call a build round. It has a rough “score” or “weight” for each build that grades them in a slow to fast order. When a build round starts, the server will first sort all builds based on number of times they’ve been handed out and as secondary sort key the “weight” of it. Then it loops over the currently connected build clients and hand out builds from the sorted build table. The server then continues to do that until all clients have three builds each to build. As soon as a build is reported to have been completed by a client, that client will get the next build from the sorted build list.

If a client connects to the server and the server deems the client to be too old (since it does specify its version in the handshake message), it will be told to update to a specific version instead and come back then. This way the server can update all build clients when important things are fixed.

The clients will soon start to get assigned builds that already have been assigned to another client. This is not a problem but in fact our intention. The client that completes the build first will simply tell the server, and the server will then tell all the other clients that build that same build that they should cancel that particular build.

A client that joins the server in the middle of a build round will simply get a bunch of builds immediately and join in. A client that disconnects during a build round simply won’t complete its builds and other clients will instead do them. The system is also tolerant against the fact that bogomips is lame to compare computers with, and that the build “score” may not be very accurate or even that some server will have very slow or very fast upload speeds at unpredictable times.

The build master itself does not know when to start a new build round. It simply knows about the concept and it knows how to tell clients to complete a round. To make the master to start a new round, you need to connect to the server’s listening port and issue a special command and provide a password and then you can tell the server to start a build of a specific SVN revision. Or to queue up a build to be performed after the current one if there happens to be one in progress already.

When a full build round is complete, a hundred or so builds have been done, and full packages and log files are now in a directory on the build server, the server will simply trigger an external script that then takes care of updating our build table etc. In fact, every single completed build will optionally trigger an external script to allow web pages or stats pages to get updated as we go.

This build system is currently pretty Rockbox-specific as this is the project and development system we’re writing this for, but there’s really nothing in this that must be this way. I’m sure that if someone (you?) wants to adapt this for another project, I’d be more than happy to assist and to help ensuring that this becomes a more generic distributed build system. Just raise your hand and step forward!

At the time of this writing, (primarily) me and Björn are still ironing out quirks in this new system to hopefully get it going live real soon…


Kernels on those phones

So Google says there could be 18 phones running Android by the end of this year. In Sweden we just days ago got HTC Magic, the first ever Android phone showing up here (tied to a ridiculous operator deal that makes me and lots of my friends not go that route). Then Palm shipped their Palm Pre just days ago, also based on Linux.

This has brought the interesting questions: how is the state of these kernel HTC Magicports in regards to the mainline Linux tree? They’re both using ARM cores (of course).

The ARM kernel maintainer Russell King himself is not impressed. Apparently Google hasn’t even tried to push their work upstream to the kernel in a long while. The tone in that discussion did make it sound as if they might be starting to work on this again now.

The Palm guys apparently haven’t even yet shown any code at all, but is said to be releasing their code within two weeks to  They have not even tried to push their work upstream, so I figure they’re either not even going to bother or they are facing a rather steep uphill battle in the future.


I’ve previously blogged about the initiative to build an own open hardware platform that can run Rockbox fine, and just today I noticed their new site is up and alive at:

The hardware has changed quite significantly since the last blog entry of mine, and they’re now using a LPC3130 from NXP instead of the Atmel they had before, and I believe they’ve also changed codec/DAC etc. Me knowingly, Rockbox does not yet run on this newly produced board.

Lyre PCB

I should probably also add that this board is of course still quite far from being portable and there’s no news or info anywhere on how or if you can actually get one of these yourself yet.

Eeepc with Linux and Swedish 3g

This is a follow-up on my “getting the new toy” from a week or so ago. An Eee PC S101.

I didn’t like easypeasy on it. It seems that distro is more or less Ubuntu Netbook Remix (UNR) with a little EEE flavor applied. What’s not to like about it? They seem to think that because this is a netbook, normal UI guidelines no longer apply so therefore they’ve scrapped the ordinary main desktop (and its menu) concept and instead have a new full-screen “app launcher”. That’s not too shabby, but it comes with another idea that I can’t accept: they run all applications in full-screen mode by default.md400 And I couldn’t figure out how to alter that default.

Full-screen might be fine for some apps at some times, but then I’d like to explicitly ask for it instead of having to learn now to “unmaximize” each app (they’ve also removed/altered the window decorations so there are no standard three buttons on the upper right corner of the maximized windows). To top it off, it seemed that the latest easypeasy isn’t built with the latest ubuntu and thus it failed to connect with my 3g modem…

Instead I took the base version of eeebuntu for a spin and that is so much closer to what I want in a linux. It’s ‘base’ so it only comes with the bare minimum. It has no fancy alternative UI but relies on the traditional well-proven and by me liked X11 (gnome) desktop.

I inserted my Sony Ericsson MD400 USB 3g modem that I got from Telenor/Bredbandsbolaget and within a few seconds I was online. It couldn’t have been a much smoother ride.

I know people have expressed opinions that it’s a better idea to use laptops/netbooks with an internal 3g modem so that you don’t have to use any external devices so that it’ll be more slick and all. I think I was of that opinion as well until I got this usb thing in my hand. It’s basically just a tad larger than any ordinary USB memory stick (70 x 28 x 15 mm) so it’s really not much “in the way” or disturbing when inserted in a laptop and it comes with windows drivers on it (as it dual-serves as a usb mass-storage device as well). It makes it a perfect little device to move between different laptops. We have so far three laptops in our household and now I can get any of them onto 3g if I want to.

A little side-note on my eeebuntu install on the SD card: when I ran unetbootin I selected to install the “live/install” version on the hard drive (which of course is a SSD but anyway) to then install it on my SDHC card, but it simply wouldn’t work. I tried three times and every time it froze somewhere in the middle of the install. When I then re-ran unetbootin and made a boot usb stick, and then ran from there instead when I did the install, it worked perfectly…

More HD sound

Proving my point from before that everything wants to be “HD” these days, I read the Zune HD specs that come out recently and in that I found out that it claims to support HD radio. Amusingly enough, it does not claim mp3hd support which probably would’ve made the buzzword bingo crowds go wild. We can always hope for the next model! 🙂

So what is HD radio? The site says:

Instead of sending out one analog signal, stations send out a bundled signal – both analog and digital. Because it is digital, textual data such as traffic, stock info and song titles can be sent out, as well.

From what I understand, pretty much the same way RDS is already done.

The technology is not even new. The site lists news items from 2006 and yet I’ve never heard of it before. They claim FM stations get “CD-quality sound” and (as I find pretty funny) AM stations get “FM-quality sound”. What is “CD-quality” in this context I wonder? I find no mention or details on what exact codecs or bitrates etc they use. Wikipedia’s page to the rescue: it says you get approximately 100-150 kbps of a lossy “proprietary iBiquity HDC codec” which claims to be able to provide “CD quality as low as 64 kbit/s”. Somehow I think that sounds a little too good to be true. According to wikipedia HD radio beats DAB in audio quality.

And to top it all of, the FAQ describes what the HD means:

It does not mean either hybrid digital or high definition, it is simply the branding language for this new technology.

Personally I’ll just rather go IP all the way and stream my music/radio/video over that. I think media or content-specific transfer mediums/concepts of this kind are technologies of the past. For this reason, I don’t think DAB+ will have much of a future either.