Statistik om PIN-koder

Den här artikeln var intressant - den handlar om vilka pinkoder som är vanliga och ovanliga.  Den vanligaste koden är 1234 och den ovanligaste 8068. Intressant hur kodrymden visualiseras och hur man väljer.

http://www.datagenetics.com/blog/september32012/index.html

Bandwidth limit ssh

For all you who are interested in rate limiting ssh, to not consume too much bandwidth, here is a suggestion:

Use trickle! (apt-get install trickle for debian/ubuntu users)

instead of

ssh you@example.com

you use

trickle -u 123 -d 456 ssh you@example.com

where u is the upload limit in kbytes/s and d is the download limit in kbytes/s.

Very handy. I use it to rate limit file synchronization with unison. I have a ssh.sh script with

#!/bin/sh
trickle -u 20 -d 40 ssh "$@"

in it, and sshcmd=/path/to/ssh.sh in my unison profile.

Good luck!

Utveckling med OpenCL

Efter att länge ha varit nyfiken, har jag nu tagit steget och börjat använda OpenCL. För dig som inte vet vad det är, är det ett standardiserat sätt att kunna använda en grafikprocessor till generell beräkning, inte bara grafik. Den råa prestandan i ett modernt grafikkort är många gånger större än för en normal processor, men har helt andra egenskaper och kan inte alltid utnyttjas för alla typer av problem.

Jag tog en existerande algoritm jag jobbat mycket med och implementerade delar av den. På min medelmåttiga laptop, med teoretisk prestanda 155 GFLOPS lyckades jag genomföra beräkningarna en faktor 30 snabbare än på cpu:n! Detta helt utan att försöka optimera koden. Ett grafikkort för stationära datorer i 5000 kr-klassen når ca 3000 GFLOPS. Med ett sådant kort skulle alltså prestanda kunna öka till en faktor 600 gånger snabbare än cpu, för mitt problem. Tack alla ni som spelar datorspel och finansierar denna fantastiska utveckling!

Det tog ett tag att läsa igenom dokumentationen och förstå hur det är tänkt att fungera. Jag rekommenderar att läsa många olika tutorials innan man börjar, eftersom det är ganska annorlunda mot "vanlig" programmering och varje författare förklarar på olika sätt.

En liten disclaimer:
för att nå höga prestanda behöver man göra avkall på beräkningsprecisionen, samt kunna dela upp sitt problem i parallella delar. Därutöver tillkommer fördröjning när problemet ska flyttas till grafikkortsminnet, och kerneln kompileras. Och så behöver man installera ickefri programvara...

Best paper award

I am delighted to inform you that your paper, detailed above, has been awarded the joint winner of 2011 SAGE Best Paper Award by the Editor and Editorial Board of the Journal of Rail and Rapid Transit.

Detta mail fick jag för ett tag sedan. Jättekul! Jag har för kunds räkning utvecklat ett system för igenkänning av spårdefekter.
Efter att ha beskrivit detta i en artikel tillsammans med andra har det nu tilldelats pris som bästa artikel!

Läs sammanfattning här:
http://pif.sagepub.com/content/225/1/1.abstract

Direktlänk till artikeln:
http://pif.sagepub.com/cgi/reprint/225/1/1

Läsvärt om SSD

Jag tillhör en av dom som bytt till flashbaserad lagring (SSD) i min dator och kommer aldrig att byta tillbaka - prestandavinsten (både den verkliga och den upplevda) är helt enkelt så väldigt stor. För SSD är det mycket prat om TRIM och prestanda. Samt de eviga firmwareproblemen, som även jag drabbats av.
Nu snubblade jag över en mycket intressant artikel som går avsevärt djupare än vanligt och förklarar de största problemen och deras lösningar. Det gav mig en större förståelse för hur knepigt det måste vara att få till en välfungerande SSD med höga prestanda. Det finns mycket skräp på nätet, men då och då hittar man verkliga guldkorn!

Backup med hjälp av btrfs snapshots

En stark fördel med btrfs är möjligheten att på ett mycket effektivt sätt göra backup med hjälp av snapshots. De flesta oroar sig för dataförlust på grund av hårdvarufel men det är faktiskt (rent statistiskt sett) viktigare att skydda sig mot användarmisstag. Och här är btrfs snapshot ett mycket bra verktyg!

Det går till så att en kopia av filsystemet sparas, på ett sätt så att originalet och kopian i bakgrunden använder samma utrymme, ända till dess att en fil ändras. På detta sätt tar kopian inte särskilt stor plats. På btrfs går detta sekundsnabbt, och man har då en kopia att gå tillbaka till.
Jag har nu lagt upp ett cronjobb som åstadkommer just detta.

Min filstruktur har de subvolymer som används i katalogen /btrfs-stuff/subvolumes/
För att detta ska fungera som avsett har jag följande i /etc/fstab:

$tail /etc/fstab
/dev/mapper/sda2_crypt /root/btrfs-roots/sda2_crypt btrfs noauto,noatime,compress,subvolid=0 0 0
/dev/mapper/sdb2_crypt /root/btrfs-roots/sdb2_crypt btrfs noauto,noatime,compress,subvolid=0 0 0

och sen cron-jobbet:

$cat /etc/cron.daily/btrfs-snapshots
#!/bin/sh
#Av Paul Dreik 20120506
set -e
for t in /root/btrfs-roots/* ; do
    if [ ! -d "$t/btrfs-stuff" ] ; then
        mount "$t"
    fi
    /root/btrfs-snapshot.sh "$t/btrfs-stuff"
    umount "$t"
done

 och så har vi filen som gör själva snapshoten:

$cat /root/btrfs-snapshot.sh
#!/bin/sh
#gör snapshot. Scriptet antar att du har en struktur
# /some/path/subvolumes/
# /some/path/snapshots/
# där du anger /some/path som argument till scriptet.
#
# Scriptet gör sedan ett snapshot av varje subvolym och placerar det i
# snapshots.

#Paul Dreik 20120506

#bail out on error
set -e

#assume a directory structure where the subvolumes and snapshots are
#in subdirs of a specific directory. This directory should be given as
#the first argument to the script.
if [ $# -ne 1 ]; then
    echo "please give the btrfs root directory as the first argument."
    exit 1
fi
if [ ! -d "$1" ] ; then
    echo "directory $1 does not exist."
    exit 1
fi
cd "$1"

#make sure subvolumes exist, as well as snapshots.
for d in subvolumes snapshots ; do
    if [ ! -d "$d" ] ; then
    echo "directory $d does not exist"
    exit 1
    fi
done

for sv in subvolumes/* ; do
    echo "looking at subvolume $sv"
    #make sure the snapshot directory exists
    svname=$(basename $sv)
    mkdir -p "snapshots/$svname"
    #now make the snapshot
    datestamp=$(date --rfc-3339=s)
    btrfs subvolume snapshot -r "$sv" "snapshots/$svname/$datestamp"
done

echo all ok

Detta åstadkommer nu ett snapshot av varje volym, en gång per dygn. För att komma åt en gammal version är det bara att montera det snapshottet. Fungerar otroligt bra!

En liten fotnot:
backup måste naturligtvis ske "ordentligt" också, dvs på en annan fysisk plats. Att lagra gamla versioner lokalt är dock ett väldigt bra sätt att skydda sig mot att oavsiktligt råka ta bort eller ändra filer. Bra för oss med barn som "hjälper till" ibland....

kompression i btrfs

Mina experiment med btrfs fortsätter. Har nu slagit på kompression, vilket fungerar fantastiskt bra. Tänk att inte behöva hålla på att komprimera filer för att inte slösa på utrymmet! Eftersom jag använder ssd resp en högvarvig SATA-disk för att få höga prestanda är det viktigt att hålla ner storleken om det går.

Att slå på kompression är så enkelt som att lägga till compress som option i fstab, dvs att den btrfsrelaterade raden i /etc/fstab är
UUID=xxxx / btrfs noatime,compress 0 0
Jag är inte så modig att jag slår på lzo, utan jag håller mig till gzip än så länge...