Mini-ITX HTPC/File server

Facts:
- Throughput performance of file copy operations on lots of small files all boils down to IOPS performance of your hard drive (i.e. how fast the drive can seek). That's because the OS needs to update the 'file tables' (ie MFT on NTFS) and copy the actual file data (so the HDD head seeks a lot)
-Write behind caching can make file copy operations a lot faster, by actually just writing to RAM and the writing the data to disk in an optimized manner (to minimise hdd seeking).
- A typical mechanical hard drive has a seek time of around 8-9 milli seconds, so best case seek time is 125 seeks per second. So if you copy a million 1KB files, your throughput will be around 125/2 * 1024 = 75KB/s (worst case, but as I said write behind caching improves it a lot)
- File activity consumes VERY little CPU, that's because all data is actually transferred using your motherboard/CPU's DMA controller!
- a CPU/dma memory controller can move data around at sick speeds without consuming much CPU cycles (just interrupt service routines every now and then)

Download a tool call AS SSD (it's a SSD benchmarking tool but works just as good on any other hard drive) and see for yourself, what you can achieve on a hard drive.

The fact that you got 100-200 MB/s throughput while copying to a USB3 connected device means:
- Write behind caching enabled
- The device plugged in was not a mechanical hard drive but a FLASH based storage device, ie memory stick, ssd, etc.


So......
You can go and buy a super dooper PC in the hopes that It will give you uber performance, but it won't (by much). If you want super dooper performance:
- Get an SSD
 
Mr.Jax said:
Facts:
- Throughput performance of file copy operations on lots of small files all boils down to IOPS performance of your hard drive (i.e. how fast the drive can seek). That's because the OS needs to update the 'file tables' (ie MFT on NTFS) and copy the actual file data (so the HDD head seeks a lot)
-Write behind caching can make file copy operations a lot faster, by actually just writing to RAM and the writing the data to disk in an optimized manner (to minimise hdd seeking).
- A typical mechanical hard drive has a seek time of around 8-9 milli seconds, so best case seek time is 125 seeks per second. So if you copy a million 1KB files, your throughput will be around 125/2 * 1024 = 75KB/s (worst case, but as I said write behind caching improves it a lot)
- File activity consumes VERY little CPU, that's because all data is actually transferred using your motherboard/CPU's DMA controller!
- a CPU/dma memory controller can move data around at sick speeds without consuming much CPU cycles (just interrupt service routines every now and then)

Download a tool call AS SSD (it's a SSD benchmarking tool but works just as good on any other hard drive) and see for yourself, what you can achieve on a hard drive.

The fact that you got 100-200 MB/s throughput while copying to a USB3 connected device means:
- Write behind caching enabled
- The device plugged in was not a mechanical hard drive but a FLASH based storage device, ie memory stick, ssd, etc.


So......
You can go and buy a super dooper PC in the hopes that It will give you uber performance, but it won't (by much). If you want super dooper performance:
- Get an SSD
Click to expand...

My hard drive was Plain western digital Green power drive to USB3.0 3TB drive I bought from makro
 
So I created 99000 1kb files (that happened to be 1k of zeroes, but I don't think that should make any difference). Total file size came to 781MB, according to du.

I did this test on an N36L microserver.

Code: 
root@nas:/media/2f0436d2-4ea2-43f3-bdec-2cd521db8776/tmp/test# find . -type f | wc -l
99000
root@nas:/media/2f0436d2-4ea2-43f3-bdec-2cd521db8776/tmp/test# du -sk .
781840	.
root@nas:/media/2f0436d2-4ea2-43f3-bdec-2cd521db8776/tmp/test# time cp -r . /media/94d436c6-2a44-43ca-b64b-4d6fd3edb9ec/test/

real	0m38.481s
user	0m1.076s
sys	0m12.265s
root@nas:/media/2f0436d2-4ea2-43f3-bdec-2cd521db8776/tmp/test# echo "781840 / 38.4" | bc
20360
root@nas:/media/2f0436d2-4ea2-43f3-bdec-2cd521db8776/tmp/test#

Total time elapsed was 38.4 seconds, resulting in an average transfer rate of 20 MB/s.

By comparison, I tried to copy the same amount of data in a single file:

Code: 
root@nas:/media/2f0436d2-4ea2-43f3-bdec-2cd521db8776/tmp/test# dd if=/dev/zero of=single_file bs=1024 count=99000
99000+0 records in
99000+0 records out
101376000 bytes (101 MB) copied, 0.602427 s, 168 MB/s
root@nas:/media/2f0436d2-4ea2-43f3-bdec-2cd521db8776/tmp/test# time cp single_file /media/94d436c6-2a44-43ca-b64b-4d6fd3edb9ec/test/

real	0m0.339s
user	0m0.000s
sys	0m0.320s
root@nas:/media/2f0436d2-4ea2-43f3-bdec-2cd521db8776/tmp/test#

Clearly there was a lot of overhead in the file structure, etc. Let's try to be fair about this:

Code: 
root@nas:/media/2f0436d2-4ea2-43f3-bdec-2cd521db8776/tmp/test# dd if=/dev/zero of=single_file bs=1024 count=781840
781840+0 records in
781840+0 records out
800604160 bytes (801 MB) copied, 6.94344 s, 115 MB/s
root@nas:/media/2f0436d2-4ea2-43f3-bdec-2cd521db8776/tmp/test# time cp single_file /media/94d436c6-2a44-43ca-b64b-4d6fd3edb9ec/test/

real	0m6.148s
user	0m0.020s
sys	0m2.260s
root@nas:/media/2f0436d2-4ea2-43f3-bdec-2cd521db8776/tmp/test#

In both cases, the filesystems were ext4, source disk is a Model=ST2000DL003-9VT166, destination disk is a Model=ST31500341AS. In both cases, write caching was disabled.

I suspected that I would get much better throughput on the small file case if I enabled write caching on the target disk. Surprisingly, that didn't seem to help much at all:

Code: 
root@nas:/media/2f0436d2-4ea2-43f3-bdec-2cd521db8776/tmp/test# hdparm -W 1 /dev/sdb

/dev/sdb:
 setting drive write-caching to 1 (on)
 write-caching =  1 (on)
root@nas:/media/2f0436d2-4ea2-43f3-bdec-2cd521db8776/tmp/test# rm -rf /media/94d436c6-2a44-43ca-b64b-4d6fd3edb9ec/test/*
root@nas:/media/2f0436d2-4ea2-43f3-bdec-2cd521db8776/tmp/test# time cp -r . /media/94d436c6-2a44-43ca-b64b-4d6fd3edb9ec/test/

real	0m33.302s
user	0m1.080s
sys	0m10.609s
root@nas:/media/2f0436d2-4ea2-43f3-bdec-2cd521db8776/tmp/test#

Write caching saved about 5 seconds. Not that big a deal. But the difference between copying a single file and lots of small files was about 6 to 1.

As always, your mileage may vary.
 
@RoganDawes.

Nice little test.

For comparison, it would be great if you could repeat the test on a typical mid-high range desktop machine. I say the trend will be the same, proving that cpu/ram/mobo has little effect on disk performance, when using the same underlying (slow) storage technology.

The fact that one can achieve 20MB/s throughput on small files, just shows how well a hard drive's internal cache works.
 
AMD APU's offer the best value for money. A friend of mine built one with an A10 and it games well and is very quick for other uses.
 
Mr.Jax said:
@RoganDawes.

Nice little test.

For comparison, it would be great if you could repeat the test on a typical mid-high range desktop machine. I say the trend will be the same, proving that cpu/ram/mobo has little effect on disk performance, when using the same underlying (slow) storage technology.

The fact that one can achieve 20MB/s throughput on small files, just shows how well a hard drive's internal cache works.
Click to expand...

Ok, so for interest, I did the comparison on a faster machine. I have an i5 2500K (not overclocked), in an Asus P8Z68V board with 16GB RAM. The N36L microserver had 8GB, for what it is worth, but I don't think that affected anything.

While I slipped up and created an extra thousand files, I don't think it materially affects the results. Note that /tmp/ (Model=ST3160815AS) and /home (Model=ST3500630AS) are on different disks. However, it seems that by default, Write cache is enabled on both disks, so you should expect to see slightly better performance.

Code: 
rogan@aphrodite:/tmp/test$ find . -type f | wc -l
100000
rogan@aphrodite:/tmp/test$ du -sk .
781124	.
rogan@aphrodite:/tmp/test$ cd
rogan@aphrodite:~$ cd tmp
rogan@aphrodite:~/tmp$ mkdir test
rogan@aphrodite:~/tmp$ time cp -r /tmp/test/ .

real	0m34.220s
user	0m0.328s
sys	0m3.764s
rogan@aphrodite:~/tmp$

Basically, no difference worth writing home about. 4 seconds less, copying 1% more files.

For a final datapoint, I copied them over the network from the 2500k to the N36L microserver. That took a LOT longer than I expected, and SMBD on the microserver was pegged between 30% and 60% of the CPU most of the time, according to top. However, afpd (netatalk) was also quite high, so I wonder if there was a conflict of some sort between the two daemons.

Code: 
# time cp -r ~rogan/tmp/test/ .

real	6m0.204s
user	0m1.712s
sys	0m18.004s
#

Where the current directory was mounted from the NAS using mount.cifs.

Guess the netatalk daemon didn't materially affect anything either. While the afpd was no longer running, smbd still got up to about 60% of the CPU. In total, it managed to copy 20s faster:

Code: 
# time cp -r ~rogan/tmp/test/ .

real	5m39.722s
user	0m1.692s
sys	0m16.580s
#
 
If you installed OS in AHCI mode set in BIOS, the first step is fine.
Further it depends on OS/drivers.
For Windows with Intel chipset I think in Intel Matrix Store Manager.
For Linux see link: http://exemen.wordpress.com/2011/05/16/enabling-disabling-and-checking-ncq/

Edit: For Intel chipset NCQ is enabled automatically after enabling AHCI mode in BIOS, for AMD I hear it has to be enabled manually, perhaps depends on drivers.
 
Last edited:
sajunky said:
If you installed OS in AHCI mode set in BIOS, the first step is fine.
Further it depends on OS/drivers.
For Windows with Intel chipset I think in Intel Matrix Store Manager.
For Linux see link: http://exemen.wordpress.com/2011/05/16/enabling-disabling-and-checking-ncq/

Edit: For Intel chipset NCQ is enabled automatically after enabling AHCI mode in BIOS, for AMD I hear it has to be enabled manually, perhaps depends on drivers.
Click to expand...

NCQ was enabled on my desktop, and on the N36L.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X