Showing posts with label benchmark. Show all posts
Showing posts with label benchmark. Show all posts


TimeMachine encryption performance: Synology's vs. Mac OS X's

A quick experiment to see what is faster to encrypt a TimeMachine network volume: using Synology's folder encryption or OS X's automatic TM encryption.

Copying a directory with 1200 files and directories in it (source files and compilation products), about 125 MB in total:
Unencrypted: 86 sec
Synology's encryption: 90 sec
OS X's encryption: 10 sec

So, not much to discuss about it: OS X's encryption wins.

  • This was done by the verily scientific method of trying a couple of times and counting seconds aloud. At the beginning I was thinking about doing it in some scripted, repeatable, strict way to control for things like caching and blah blah. But, a 1:9 difference? That's convincing enough for me, kthxbai.
  • I simulated OS X's TM encryption by creating an encrypted disk image (AES 256 bit, sparsebundle) in an unencrypted folder in the Synology's server. This might not be the same than the real TM encryption, since that seems to be done by FileVault 2, but should be close enough. It certainly looks the same from the outside, judging by a verily scientific cursory look.
  • Probably the huge difference comes from the Synology server receiving just a bulk write of the pre-condensed small writes in OS X's side. Yet, that means a lot of work in OS X (right? caching all of the filesystem activity and encryption itself). But it was so quick that I didn't even realize. That's ironic in a way: I was rather expecting that Synology's server-side encryption would offload the work from the OS X client. Well, forget about that - I prefer such a burst (that I didn't even notice over the normal system activity) than seeing the TM updates languishing for what feels like hours.
  • The Synology server (DS412+) is using a SHR1 volume over 3 disks. Connection via WiFi, max substained speed about 9 MB/s.
  • The Synology OS version is DSM 4.3. OS X is Mavericks (10.9.0). Server folders mounted via the AFP protocol (which depending on who you listen to might be not the best option, with SMB2 being the new official recommendation, but that's what TimeMachine uses anyway).
  • Synology's terribly slow file indexing is disabled, so that's not the cause of the slowness. Just to confirm if it could be as bad as expected, I enabled it and repeated the unencrypted copy, and after 100 sec it was still half-way through the copy - so, yes, it really is so bad.  I just cancelled it.
  • An added convenience for using OS X's encryption: the Synology encrypted folder has to be hand-mounted (in the server) after every reboot (unless you use the point-defeating, password-remembering automounting). The OS X encryption is client-side, so you only need to turn on the server and can then forget about it.
  • Just for completeness' sake, I also tried copying the set of files to an unencrypted disk image in an encrypted and unencrypted Synology folder. The results were 20 sec for the encrypted folder, 10 sec again for the unencrypted one. So, looks like Synology's encryption plainly adds about a 2x penalty, and OS X's is pretty much transparent.
Given all of this, looks like even if Time Machine was not implemented as disk images, it would be very convenient to (try to) force it to use one, even if not caring for encryption!


Memory access stride in loops change loop timing in AVR C!

I found a strange situation when programming in C for AVRs. I have a bunch of structures to be worked on, but any of them can be flagged "active" or not at any given moment, to signal whether they need further work. My first approximation was to add a (uint8_t volatile: set in main, checked in interrupt time) member variable named "active" to the struct, to quickly check/set each structure.

Shock: only looping through the array checking the "active" member variables was taking an enormous amount of time – about 20 clock cycles per access!


Selecting a mobile internet operator in Poland

(see the 2014 update)

About one year ago I was tired of the problems with my then-current internet provider, Play. So I decided to try the 4 major operators in Poland. I got a "starter pack" for each one, which can be bought for about 10 zl each, and tried them with my telephones/modems/computers. These are the results of testing with,, youtube's speed test and torrenting some big Linux disc image. And since this is mobile internet, I tried each in a set of places in Warsaw - and some even outside of the city.

Note that I was looking for smartphone use: voice + data, with data being in the 5 GB/month range, possibly more. So data packages measured in MB didn't cut it (since they are usually much more expensive). And internet-only SIMs were out, too.

The tests are one year old, but I can confirm that the results are still valid at least for T-Mobile and Play, since I still use them both.

For non-technically inclined people, the summary is: get T-Mobile.  Play is unreliable, but cheapest. Orange is surprisingly crappy. And Plus didn't even have anything serious for smartphones (that is, for voice + data "in big quantities").

And the gory details:

Era / T-Mobile: the best one. One easily reaches the advertised speeds, while testing and downloading. Pingtest gives marks between 4.0 and 4.2 (C, sometimes even B). Pings between 160 and 190 (!), Packet Loss 0, jitter typically in the single digit (!), sometimes up to 20. Youtube averages 19.
It's not even the most expensive of the operators, if I remember correctly. The problem is that once you use up your monthly allowance, you can NOT extend it. So if you need more than 5 GB, you're toast. Their internet offer is advertised as unlimited, but that only means that after you use up your paid package, you can continue using internet at about 2 or 3 KB/sec. Practically unusable if you can't limit yourself to text.
Era is my main operator, so I can confirm that it still works well - even if I had some complaints at some moments because of weird connectivity problems, which were quickly and personally answered - even if in a useless way. :P

Play: the cheapest internet operator. Too good to be true, certainly. Half the price of T-Mobile, can be refilled as you wish, there are even options to use internet during the night without it counting against your allowance. But, even before getting into the numbers, it is plainly shitty. On average, more than once a day the telephone or modem will loose the connection; sometimes in "standard" ways ("the PPP server has stopped responding"), but more frequently the phone just suddenly shows no bars of network reception. Both the telephone/modem and the computer wait for it to come back, which never does - I have tried waiting for hours. You can just restart the phone and it will connect again, but sometimes in less than a minute it will happen again. I started thinking it was some problem with my telephone, with drivers, with the mac... But, it has happened with different computers (although always macs), with different telephones and modems, even using a VM with Windows to drive the modem. Same thing always. So, I can NOT recommend Play at all, for any serious internet usage at least. No idea about how it works for voice. And maybe for short connections, like those typical in a smartphone would be usable. I wouldn't risk it, though.
Anyway, I also tested it "numerically", and the results were: pingtest marks between 1.6 and 3.9 (F to D). Pings between 140-250, jitter between 80-260, packet loss 0. The max standard speed is 125 KBps. There is an option to get 400 KBps, but I feel lucky if I get just half of that.

I STILL use Play for "bulk internet"; it is so cheap (even more so with the free nights option) that it always gets me to try again. But it also always manages to get on my nerves; 3 times already in 4 years it has made me prefer to pay extra to other operators... and the 4th is coming soon. SO annoying, SO unreliable, SUCH helplessly blank faces in the hip shops when I tried to get some info. Fuck them.
Also: Play only provides HDSPA connections. If at any moment the phone has to fall back to EDGE, you're as good as with no coverage. That was the case when I tried it at my workplace, which is only about 2 km away from the city center: I couldn't even connect.

Orange: the only operator which showed packet loss (!) in pingtest. Marks between 1.1 and 3.9. Pings up to 440. Jitter between 18 and 205. I never reached the advertised speeds for downloads, but did for uploads. Keep in mind that I tried in different locations, with different modems and telephones, so I can only think that this was simply Orange being just shitty.

Plus: this was my first operator in Poland, and maybe that's why I had something of a soft spot for them. And it was impressive to be able to work with SSH and VNCs almost all the way in the train between Warsaw and Tricity. With Play, you'd loose coverage before you leave the city!
Alas, when I tested them a year ago they didn't have any specially competitive offer. In fact the only data+voice / smartphone-related offer they had was something tied to BlackBerries (heh, I wonder how are they doing now with that?). It was funny that the shopkeeper seemed rather desperated about the smartphone questions; it felt like I was n-th person to ask the same thing... and to be surprised that they had no options.
Anyway, I also tested with pingtest. Marks between 1 (!) and 4.25 (!). Pings between 134 and 388. Jitter between 13 and 104. No packet loss. Easy to reach advertised speed.

So, when looking for reliability and sanity keeping, T-Mobile seems the only one commendable. Also, with that small jitter, Skype and such were great. People prefer videoconferencing when I'm in the phone via T-Mobile than when I am in the computer via Play...

What I can't understand in T-Mobile is the lack of "refills": I just want to give them more money, after all :P. But, no way. So stupid.

A few more details: when testing with, I used the auto-selection of test sites. Each operator seemed to consistenly cause a different test site selection, so I guess it was the best one for each of them, surely according to ping times.

It's remarkable that T-Mobile has such a low jitter (and consistently so), that Orange reliably suffered packet loss (and was the only to suffer it at all), that Play is so damn unreliable, and that Plus... well... HELLOOO!! wake up and smell the 21.1 century!


Yet Another Nonsensical Javascript Benchmarking of Mostly Unreleased Browsers

After a couple of too-close-together performance-competition-between-browsers thingies, I decided to make my very own quick & dirty benchmark of current browsers. Webkit-based at least, although soon I'd like to at least try again Firefox; it's been months since I abandoned it for Webkit itself, due to a multitude of small problems, some of them caused by myself (much more than a hundred tabs always open, lots of extensions to lessen the load) but magnified by Firefox itself (extensions failing, slowness even when with much more reasonable numbers of tabs, sluggish Flash performance, problematic Java)...
In fact it's a great moment to make this kind of test, since Safari 4.0.2 has just appeared, Stainless 0.6.5 too, and ... well, WebKit has a recent nightly (r45641). Chrome is the available one right now: 3.0.192 (developer release)
A surprise has been to learn that Opera seems to have abandoned the race some time ago (ten times slower, javascript-wise, than any of the webkit-based browsers???). Will be... interesting to throw that to the next one who claims that Opera is holier than thou, blah, blah.
The benchmarks are Google's V8 (version 4) and Webkit's Sunspider.
v8: (bigger is better)
  • webkit: Run it once: 2160. Open new tab, run it again in the new tab: goes down to less than 2050, which is about 5% less. Next tabs hover just over 2050. Closing tabs and starting anew (but w/o restarting Webkit) goes back to 2160. (later I closed everything and retried, and didn't go over 2100)
  • safari: 2080 -> 1980. Same behaviour.
  • stainless: starts at 2064 and with each tab improves up to 2120!
  • chrome: pretty stable around 2950. Wow.
sunspider: (smaller is better)
  • webkit: starts at 787, worsens to 818 after a couple of new tabs with the same V8.
  • safari: from 795 to 805
  • stainless: again, improves from 695 to 680!
  • chrome: again, pretty stable winning at 650...
Interesting: Sunspider continually loads something between each subtest (something substantial). V8 only loads on, well, the first load; afterwards looks like the cache is enough, since every new tab with V8 doesn't cause (a lot of) traffic. BUT, in Stainless V8 seems to be reloaded in every new tab. Maybe Stainless is not sharing cache between the tabs?
And it looks like tabs are sometimes slow and sometimes fast: open tab, load V8, let it run. Let's say it gets a lowish score, 2050. Make new tab, load V8, let run. Let's say this one gets a somewhat high score, 2150. Now, run both tests again. The "slow" tab keeps being slow, and the "fast" tab keeps being fast... Strange.
(and looks like the first tab created in every window is "slow", and the next are "faster")
And with this, I forbid myself to keep wasting time benchmarking unreleased browsers. (But I sure will keep an eye on Stainless and chrome....if they had session saving, maybe I would switch right now! but at least they will be an interesting debugger...)
The machine used was a 2007 white macbook Core2Duo 2.16 GHz, with 3 GB RAM and about 5% of background CPU load.