Open main menu

CDOT Wiki β

Changes

Winter 2010 Presentations/Storage Performance

662 bytes added, 21:23, 21 April 2010
What results are we interested in?
Storage Performance
By: David Chisholm (dmchisho@learn.senecac.on.ca)
 
===Pictures===
http://www.paladinretrieval.net/hard%20drive.jpg
=Introduction=
In order to have our '''Koji''' Build Farm run as efficiently as possible we needed to find out which form of data storage would be the fastest overall. The candidates were:
* '''PATA:''' Hard Drive connected via USB.* '''NFS:''' share Share from HongKong.* '''iSCSI:''' network Network connection to HongKong.
===What results are we interested in?===
There are 3 main results that we are interested in when rating storage performance.
1. *'''Read:''' The amount of data that can be read from the storage medium per second.<br>2. *'''Write:''' The amount of data that can be written to the storage medium per second.<br>3. *'''Access:''' Time required for a computer to process data from the processor and then retrieve the required data from a storage medium.
===Cost===
===Pictures===
http://david-chisholm.no-ip.org/networkdiagram.jpg
<br>
http://www.paladinretrieval.net/hard%20drive.jpg
=Approach=
The solution was '''Bonnie++''', a Linux command line utility which gives an extensive amount amount of storage performance information while also having the ability to test all of our storage systems.
 
===Pictures===
 
http://www.business-strategy-innovation.com/uploaded_images/Innovation-Process-799858.jpg
=Discovery=
===What did we discover during the process?=== We discovered that finding a viable benchmarking solution is harder then it sounds. Raw data will not always correspond with real results as it comes down to the application using those resources. This is evident in the mock tests using '''NFS ''' vs '''USB PATA ''' where '''USB PATA ''' performed faster even though its benchmark results were lower using '''Bonnie++'''. ===Pictures=== http://thumbs.dreamstime.com/thumb_122/1171633495w0G6A0.jpg
=Issues=
*We can login to an initiator, however, under heavy load the target receives invalid opcodes, causing the connection to fail.
*Experimenting with a alignment value of 3 did not clear the issue.
*Using the exact same target with a F12 x86_64 initiator is successful, issue seems to be '''ARM ''' related.
===Pictures===
* Access Time - http://en.wikipedia.org/wiki/Access_time
* cDOT iSCSI - http://zenit.senecac.on.ca/wiki/index.php/Fedora_ARM_Secondary_Architecture/iSCSI
* Pictures
**http://www.business-strategy-innovation.com/uploaded_images/Innovation-Process-799858.jpg
**http://david-chisholm.no-ip.org/networkdiagram.jpg
**http://www.paladinretrieval.net/hard%20drive.jpg
**http://david-chisholm.no-ip.org/bonnie.jpg
**http://thumbs.dreamstime.com/thumb_122/1171633495w0G6A0.jpg
**http://exportabel.files.wordpress.com/2009/10/train_wreck_at_montparnasse_1895.jpg
1
edit