AT Blog

Hoeveel bytes bevat een kilobyte?
Volgens sommigen: 1000. Volgens anderen: 1024. Weer anderen zeggen: "Het hangt er van af aan wie je het vraagt."
Er is spraakverwarring over en dat komt de duidelijkheid en transparantie niet ten goede.

Het SI-voorvoegsel (Uit het Frans: Système International d'unités) kilo staat voor 1000 (x 10³). Mega staat voor x1000x1000 (x 10⁶). Daarna komen nog giga (x 10⁹), tera (x 10¹²), peta (x 10¹⁵), exa (x 10¹⁸), zetta (x 10²¹) en yotta (x 10²⁴).
Computers werken met bits (binair, 0 of 1: 2 mogelijkheden) en rekenen daardoor makkelijker met grootheden van 2 tot de macht X. Het getal 1000 wordt daarbij het dichtst benaderd door 2¹⁰ (= 1024).
Toen het computeren nog in de kinderschoenen stond, werden de SI-voorvoegsels misbruikt voor veelvouden van 1024. Bijvoorbeeld: 1 kilobyte = 2¹⁰ bytes = 1024 bytes. 1 megabyte is dan 1024 kilobyte.
Handig in het gebruik en het verschil is ook niet zo groot.

Hoe worden de voorvoegsels in de praktijk gebruikt?

• Een kachel van 2 kilowatt heeft een vermogen van 2.000 watt.

• De afstand tussen Utrecht en Nijmegen is 85 kilometer, dat is dus 85.000 meter.

• Deze foto kost 2 megabyte. Dat is 2 x 1024 x 1024 = 2.097.152 bytes (en niet 2.000.000).

• Via mijn ADSL-aansluiting kan ik downloaden met een snelheid van maximaal 8 megabit per seconde. Dat is 8.000.000 bits per seconde.

• Op mijn nieuwe harddisk past 1 terabyte, ofwel 1000 gigabyte, ofwel 1.000.000.000.000 bytes.

• Op een 3,5" floppy past 1,44 megabyte. Dat is niet 1,44 x 1000 x 1000 bytes, ook niet 1,44 x 1024 x 1024, maar wel 1,44 x 1000 x 1024 (= 1.474.560).
  Namelijk: 2 koppen x 80 cylinders x 18 sectoren x 512 bytes = 1.474.560.

Dit was niet tot ieders tevredenheid: afgezien van het feit dat er spraakverwarring optreedt, is 1000 gewoon niet gelijk aan 1024.
En is het verschil bij kilo nog niet zo groot (2,4%), bij tera (1000⁴ t.o.v. 1024⁴) is het verschil al opgelopen tot 9,95%. Om nog maar niet te spreken over yotta (20,89%).

Daarnaast is er ook een probleem met afkortingen: Het is niet duidelijk of met de afkorting kb nu kilobyte of kilobit wordt bedoeld. Een (stilzwijgende) afspraak is dat voor bit een kleine b wordt gebruikt, en voor byte een grote B.

Verwarring alom.
De International Electrotechnical Commission (IEC) heeft zich de kritiek aangetrokken. In 1998 is een standaard ingevoerd die orde in de chaos heeft geschapen door een handvol nieuwe voorvoegsels (prefixen) te introduceren. Deze IEC-prefixen verwijzen naar binaire veelvouden: kibi (2¹⁰), mebi (2²⁰), gibi (2³⁰), enz.

Storagefabrikanten - zoals producenten van harddisks - rekenen in megabytes en terabytes, dus in 1000-tallen. Dat zorgt nogal eens voor een stukje consumentenfrustratie: "Ik heb een nieuwe harddisk gekocht, maar die blijkt veel kleiner te zijn dan op de verpakking wordt aangegeven!"
Als je een harddisk van 1 terabyte (1 TB) koopt, krijg je een rauwe opslagcapaciteit van 1.000.000.000.000 bytes, ofwel 90.95% van de grootte die je verwacht als je ervan uitgaat dat 1 kilobyte 1024 bytes bevat. En daar gaat dan nog wat snijverlies en overhead van af omdat er partities en/of filesystemen gemaakt moeten worden.

De zebibyte (ZiB) en yobibyte (YiB) zijn momenteel nog niet daadwerkelijk in gebruik als je het over opslagcapaciteit hebt. Om een YiB aan informatie op te slaan op 3,5" floppies (wie gebruikt ze nog?), heb je een stapel floppies nodig ter grootte van 2 maal de afstand van de aarde naar de zon.

Meer leesvoer:

• http://physics.nist.gov/cuu/Units/binary.html

• http://en.wikipedia.org/wiki/Binary_prefix

Het Probleem

Ik was laatst een nieuwe disk aan het in-gebruik-nemen, waarbij ik veel grote files moest kopieren van de oude (kleinere) disk. Dat soort dingen doe ik normaliter met rsync (daarvan zitten de opties in mijn vingers). Maar nu zag ik dat de performance bedroevend was. Ik moest zo'n 700GiB aan data overpompen, en dat ging met een tempo van zo'n 30MiB/s. Beide disks kunnen ieder minstens 100MiB/sec lezen en/of schrijven. En ik haalde dus nog geen derde daarvan. (We hebben het over een totale doorlooptijd van ruim 2 uur versus 6 uur!)

Meten...

Ik ben toen eens wat gaan meten en gaan spelen. Hiervoor bedacht ik een simpele benchmark: het kopieren van een file van 10GiB. Zowel de bronfile als de bestemming stonden op een ext4 filesysteem dat ik op de buitenste (snelste) tracks van de twee fysieke disk formatteerde.

Als kopieerprogramma's gebruikte ik:

• rsync
• cpio
• cp
• cat

uiteraard voorafgegaan door commando's om de cache te legen en afgesloten door een sync om de cache te flushen. Dus bijvoorbeeld:

sync                               # forceer dirty buffers naar disk
echo 3 > /proc/sys/vm/drop_caches  # gooi caches weg
time sh -c "cp $SRC $DEST; sync"   # meet cp én sync tijd

De echo naar /proc/sys/vm/drop_caches forceert het volledig invalideren van de cache. Dat werkt alleen voor de niet-dirty pagina's, daarom dat we eerst een sync commando gebruiken om alle dirty pagina's naar disk te forceren. Het betreffende kopieer programma zal de 10GiB file kopieren, maar ook eindigen vóórdat de laatste blokken naar disk worden geschreven (die blijven nog 30 seconden in de cache plakken). Daarom meet het time commando de tijd die nodig is voor het kopieer programma, en de sync om de laatste restjes te flushen.

De metingen voor rsync, cpio, cp en cat wezen het volgende uit:

user      sys     elaps  hog  MiB/s  test
158.75   108.71  320.08  83%   31   rsync
  5.24    80.60  116.81  73%   87   cpio
  0.73    53.41  109.36  49%   93   cp
  1.42    62.03  108.80  58%   94   cat

Ik ben daarop wat nader gaan kijken. Wat blijkt: rsync heeft 3 processen nodig: een lezend, een schrijvend en een niets-doend (control?) proces. Op mijn 4-core systeem draaien ze bijna de hele tijd alledrie op één enkele CPU. Met het commando taskset kun je afdwingen op welke CPUs een proces mag draaien. Stel dat de drie rsync processen de PID's 1111, 1112, 1113 hebben, dan kun je afdwingen dat ze ieder op hun eigen CPU draaien met:

taskset -pc 0 1111   # forceer op CPU0
taskset -pc 1 1112   # forceer op CPU1
taskset -pc 2 1113   # forceer op CPU2

Door met het taskset commando meteen na het starten ieder rsync proces zijn eigen CPU te geven, gaat de throughput omhoog van 31MiB/s naar 39MiB/s. Als de drie rsync processen met taskset geforceerd worden op één CPU, loopt de performance terug naar 27MiB/s.

rsync heeft daarnaast erg veel user+sys CPU-tijd nodig. Ondanks dat, schaalt de on-demand cpufreq niet de frequentie omhoog. Als ik de frequentie forceer op de hoogst mogelijke met:

for i in 0 1 2 3 ; do
  echo performance > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor
done

dan gaat de throughput van rsync fors omhoog: 58MiB/sec. De CPU's draaien dan op de hoogst mogelijke frequentie (op dit systeem 2.6GHz). Als we dat combineren met de taskset truuk om de drie rsync processen ieder hun eigen CPU te geven, weten we er zelfs 79MiB/s uit te persen. Nog altijd zo'n 20% lager dan de andere, en tegen flink CPU-verbruik, maar toch.

De conclusie is dat je door in plaats van rsync, cp te gebruiken in de default instellingen, je van 30MiB/s naar 93MiB/s kan gaan. Maar ook door een beetje te spelen met de instellingen van het systeem, kun je zelfs met rsync flinke verbeteringen bereiken!

throughput #CPUs    frequentie
22MiB/s    1 CPU,    0.8GHz
23MiB/s    1-3 CPUs, 0.8GHz
27MiB/s    1 CPU,    ondemand
31MiB/s    1-3 CPUs, ondemand     << default
38MiB/s    3 CPUs,   0.8GHz
39MiB/s    3 CPUs,   ondemand
58MiB/s    1-3 CPUs, 2.6GHz
58MiB/s    1 CPU,    2.6GHz
79MiB/s    3 CPUs,   2.6GHz

In de tabel geeft de tweede kolom aan hoe de rsync processen over de CPU's verdeeld werden: 1 CPU wil zeggen dat met taskset de drie rsyncs alledrie op één en dezelfde CPU gedwongen werden. 1-3 CPus wil zeggen dat de scheduler zelf de vrije hand had, en 3 CPU's wil zeggen dat ieder rscyn proces met taskset zijn eigen CPU kreeg.

Je kunt duidelijk zien dat het slechter kan dan de default instellingen, maar ook heel veel beter!

De toekomst...

Op Linux Weekly News http://lwn.net/Articles/384132/ stond recentelijk een bericht dat de ondemand scheduler moeite heeft met processen die veel I/O doen en ook vrij veel CPU tijd nodig hebben: In de tijd dat de CPU op disk I/O staat te wachten, wordt de CPU weer naar een lage frequentie teruggeschaald. Als het proces dan weer wil rekenen duurt het enige tijd voordat er weer omhoog wordt geschaald. Arjan van de Ven van het Intel Open Source Technology Centre heeft een aanpassing op de ondemand scheduler aangebracht die de CPU pas omlaag schaalt als deze echt idle is (en niet op disk I/O staat te wachten).

Je kunt dit verschijnsel ook mooi zien:

Als je

modprobe cpufreq_stats

doet, krijg je precies (in jiffies gemeten) het aantal hits te zien voor de verschillende te gebruiken clock frequenties.

Bekijken we dit voor een rsync commando, dan zien we bijvoorbeeld voor cpu nummer 2:

cat /sys/devices/system/cpu/cpu2/cpufreq/stats/time_in_state
2600000 423293
1900000 363
1400000 534
800000 6645805

Je kunt hier dus zien dat cpu2 (sinds het laden van de module) het grootste deel van de tijd in de lage frequentie (0.8GHz) heeft gelopen.

De aanpassing van Arjan van de Ven is nog een lapje voor het bloeden, want hij heeft een hele nieuwe governor in voorbereiding.