This document contains only my personal opinions and calls of judgement, and where any comment is made as to the quality of anybody's work, the comment is an opinion, in my judgement.
[file this blog page at: digg del.icio.us Technorati]
So I am dealing with two backup servers and most backups will happen over SSH. That's regrettable, because SSH is not that great (as it is not) a transport protocol, but it works almost everywhere, so we are stuck with it.
One of the problems is that encryption and checksumming overheads can slow it down considerably, and with default configuration much of the transfers I have seen were limited by that to around 40MB/s on a 1Gb/s line capable of 100-110MB/s.
Various people have been looking at which mix of cipher and MAC algorithm gives the best speed and I was impressed by a note that MAC algorithm speed also matters and some comprehensive comparisons, so I decided to do my own confirmatory quick tests in my environment where there is a mix of older and newer hardware, and my results are faily clear:
Overall I have 3 different lists for very recent, recent and legacy distributions:
Ciphers email@example.com,firstname.lastname@example.org,aes128-ctr,aes128-cbc,email@example.com,aes192-ctr,aes256-ctr,aes192-cbc,aes256-cbc,firstname.lastname@example.org MACs email@example.com,firstname.lastname@example.org,email@example.com,firstname.lastname@example.org,hmac-md5-96,hmac-sha1-96,email@example.com,firstname.lastname@example.org,email@example.com,firstname.lastname@example.org,hmac-md5,hmac-sha1,email@example.com,hmac-sha2-256,firstname.lastname@example.org,hmac-sha2-512
Ciphers email@example.com,firstname.lastname@example.org,aes128-ctr,arcfour128,aes128-cbc,email@example.com,aes192-ctr,aes256-ctr,arcfour256,aes192-cbc,aes256-cbc,blowfish-cbc,arcfour,firstname.lastname@example.org MACs email@example.com,firstname.lastname@example.org,email@example.com,firstname.lastname@example.org,hmac-md5-96,hmac-sha1-96,email@example.com,firstname.lastname@example.org,email@example.com,firstname.lastname@example.org,hmac-md5,hmac-sha1,email@example.com,hmac-sha2-256,firstname.lastname@example.org,hmac-sha2-512
Ciphers aes128-ctr,arcfour128,aes128-cbc,aes192-ctr,aes256-ctr,arcfour256,aes192-cbc,aes256-cbc,blowfish-cbc,arcfour,email@example.com MACs firstname.lastname@example.org,hmac-md5-96,hmac-sha1-96,hmac-md5,hmac-sha1
I also tried the same transfer from and to localhost from and to a tmpfs filetree wholly resident in RAM, on a recent CPU with AES acceleration, and the fastest rate I got was 230MB/s with aes128-ctr (and 180MB/s with arcfour128. That is rather less than a 10Gb/s network link can do, and rather slower than what IPsec with AES acceleration can do, which is disappointing; probably going faster would require OpenSSH to run fully multithreaded.
Some time ago I found online a low price
of line offer for an Acer KA270HK as it was about to be replaced
with a newer model, and I bought it.
Part of the reason was that it is a 27in monitor, and my previous 32in Acer B326HUL was too big for my small home desk (fairly good for my bigger work desk, but still a bit big), and the 24in Dell U2412M I was using at home felt a bit too small.
Part of the the reason was that it has a
QHD) display, with a
3840×2160 160DPI resolution, while the B326HUL is
2560×1440 and the U2412M is 1920×1200 both with a
The monitor overall is very good: it is pretty decently built, the IPS panel has excellent image quality (almost equal to that of the amazing U2412M), and even if it has a low end unadjustable stand, I have a nice monitor arm and the monitor has a compatible VESA mount and is (crucially) light enough to be mounted on it (the 32in Acer was way too heavy).
As to the specific size I find that 27in is the ideal compromise between 32in and 24in: it is way more comfortable than 24in, and not as huge as 32in, and at 27in it is still light enough that can be mounted on an ordinary monitor arm. When using the 32in monitor I find that I tend not to use, except perhaps to hold unused windows, a slice of the left and right ends of its surface, and that the 24in one make me overlap windows too much, while the 27in it both fully used and does not require me too much overlapping.
Also as mentioned in another blog a 160DPI display is a definite improvement on a 100DPI one. At the distance I which I put monitors pixels are already difficult to discern with a 100DPI display, but are really invisible on a 160DPI one, where the optical DPI are around 200.
It also turns out that most recent GUI libraries handle well
HiDPI displays, that is they use scalable
fonts, scalable icons, scalable geometries. I have used
GNOME 3, KDE 5, XFCE 4 and they all scale
fairly well, and the few things that don't scale are still
somewhat readable at what is roughly half-size.
As to media, looking at photos from recent digital cameras and cellphones in something more like their native resolution is a definite improvement, and while most movies are distributed in rather smaller resolution, the enlargement algorithms in most players work pretty well. Games are usually inherently scalable, except for textures, but they work fairly well for me in a window at 3200×1800 pixels. Very cool to look at, and while the more recent games demand a powerful and costly GPU (which I don't have), older games don't, and even recent games benefit from the resolution being so high that anti-aliasing, which is usually very expensive, is not necessary or can be dialed down a lot.
So far these impressions look rather positive, so what are the downsides? Well, really only one and relatively minor: bandwidth. To refresh a 3840×2160 32 bit image at 60Hz takes a lot of bandwidth and there are several case where it is not supported:
But all this is relatively minor as currently the bandwidth limitation is rather less of an issue for me, as I have moved some time ago to using mostly by relatively recent desktop instead of my older laptop as my main home system.
So I am again annoyed by wireless keyboard and mice, especially in an office environment, because: