# Performance :) ? - FreeBSD 9.0 and HP N36L with 5GB RAM



## PTVi (Apr 2, 2012)

Hello

I created a raidz1 with 3 HDDs. They are all encrypted with AES 256 Bit (GELI). I boot from a USB Stick into my system which runs on a harddisk with zfs (also encrypted). My question to you guys is: how can *I* improve the data transfer rate.

My tests:
200MB bin File from Macbook Pro (SSD+Gbit) to Netatalk Share:

raidz1 (3hds) takes 10 sek. (20mb/s)
raidz0 (1hd) takes 15 sek. (15mb/s)
All copied through my Gbit switch (performance with debian linux was about 3 times higher even with truecrypt encryption).

Do you have a clue how to *i*ncrease data transfer rate (without canceling my encryption  )

My hardware:


```
CPU: AMD Athlon II Neo N36L, 2x 1.30GHz 
RAM: 5GB 
HDs: 

WDC WD15EADS-00P8B0 01.00A01>     (ada0,pass0) zfs zpoolnonraid raidz0 - 1,5TB
WDC WD10EACS-00ZJB0 01.01B01>     (ada1,pass1) zfs zpoolraid raidz1 - 1 TB
SAMSUNG HD103SI 1AG01118>         (ada2,pass2) zfs zpoolraid raidz1 - 1 TB
ST31000333AS SD15>                (ada3,pass3) zfs zpoolraid raidz1 - 1 TB
SAMSUNG HD322HJ 1AC01108>         (ada4,pass4) zfs zpool raidz0 - 300 GB (system disc)
```

Thanks for every single input guys,
Patrick 

PS.: *I* already read the tuning guide. All the things in there were not really working (it*'*s an AMD64 installation).

PPS.: Infos about gstat


```
[root@myserver:/zpoolraid/data] diskinfo -c /dev/ada1.eli
/dev/ada1.eli
512 # sectorsize
1000204885504 # mediasize in bytes (931G)
1953525167 # mediasize in sectors
0 # stripesize
0 # stripeoffset
1938020 # Cylinders according to firmware.
16 # Heads according to firmware.
63 # Sectors according to firmware.
WD-WCASJ1075246 # Disk ident.

I/O command overhead:
[B]time to read 10MB block 1.278254 sec = 0.062 msec/sector
time to read 20480 sectors 7.986134 sec = 0.390 msec/sector[/B]
calculated command overhead = 0.328 msec/sector

[root@myserver:/zpoolraid/data] diskinfo -c /dev/ada1
/dev/ada1
512 # sectorsize
1000204886016 # mediasize in bytes (931G)
1953525168 # mediasize in sectors
0 # stripesize
0 # stripeoffset
1938021 # Cylinders according to firmware.
16 # Heads according to firmware.
63 # Sectors according to firmware.
WD-WCASJ1075246 # Disk ident.

I/O command overhead:
[B]time to read 10MB block 0.164825 sec = 0.008 msec/sector
time to read 20480 sectors 4.853294 sec = 0.237 msec/sector[/B]
calculated command overhead
```


----------



## DutchDaemon (Apr 3, 2012)

PTVi, you really need to start formatting your posts now.


----------



## faithful (Apr 3, 2012)

I see two kind of problems:
1) you have probably a WD 4K drive (my WD20EADS is 4K);
2) encryption. 

The Microserver processor isn't fast enough (I had the same machine and I have the same problem) to encrypt very fast. You must put in an hardware crypto card to speed up cryptographic operations (I haven't found one affordable yet). I see that you have probably at least one of the infamous Western Digital Green drives that have the 4KiB block but they lie to the SO telling that they have a 512b block.

Solutions:
1) Use gnop to "change" the physical sector size of your green drives (and also for the drives of the same zpool even they aren't green ones).
2) To speed up the encryption I haven't found an affordable solution, encryption accelerators are very pricey and not well supported. My top speed using Solaris 11 and the native encryption of ZFS (ver. 31) is 40/50MiB/s which is good enough for me but isn't enough to saturate a gigabit ethernet connection.

Bye.


----------



## Zare (Apr 3, 2012)

OP mentions running Linux/TrueCrypt with 3 times faster results. I'd say that hardware is capable, since TrueCrypt is a userland application and GELI is a kernel subsystem. GELI should be faster on any hardware.

Lying disks are probably the issue.


----------



## faithful (Apr 3, 2012)

Zare said:
			
		

> OP mentions running Linux/TrueCrypt with 3 times faster results. I'd say that hardware is capable, since TrueCrypt is a userland application and GELI is a kernel subsystem. GELI should be faster on any hardware.
> 
> Lying disks are probably the issue.



Trust me: you can achieve more than 30/40 MiB/s when using AES with a key of 128 bit. I tested the Microserver N36L on Solaris and Linux (with cryptsetup and the 64 bit Linux kernel implementation of the AES). No AES-NI <http://en.wikipedia.org/wiki/AES-NI>, no party!


----------



## fred974 (Jan 17, 2014)

Hi @PTVi

I have currently having the same problem as you had. Would you mind telling me if you managed to solved the problem? Would you mind posting the options you used in the kernel to enable aesni Did you have any of these options set? 


```
#options IPSEC
#options IPSEC_NAT_T
#device crypto
#device cryptodev
#device aesni
```


----------

