Printable View
seeing u'r point,Quote:
It is not about packet sizes.
yet you say, that if the controller cache is for exp. 256MB, then u'll have to specify a bigger packet/transfer size e.g >256MB to measure it's speed, right?
that was -better said- the earlier meaning..
Packet size/block size is something else entirely...Quote:
Originally Posted by onex
File does not work for me - hangs in iometerQuote:
Originally Posted by Anvil
SteveRo,
Did you try the new file?
Link to new file
Link to the file at the Norwegian forum
edit:
Posted a link to the config file at the norwegian forum, don't know why there's a problem with the attachments at XS.
you mean as in packet sizes that are flowing through the transfer length same as in ATTO? e.g 8MB/4MB chunks etc. could be tested through a 256MB 'thread'?Quote:
Packet size/block size is something else entirely...
IOMeter has transfer-request-size at the access specifications, from 1B to 1024MB, meaning if u set the TRS for >256MB, then the software would test the actual controller speed (when controller cache is 256MB) ?.
ok, attached is 2x x25-V on Areca 1231ML-4G iometer random read per your provided rar config file - screen capture of some of it below.Quote:
Originally Posted by Anvil
I had to use open 7-zip to open the file - attached.
To open the file - save to desktop - open archive with 7-zip then right click on the archive (iwithn 7-zip) and then "open inside".
http://img715.imageshack.us/img715/5164/acapture.jpg
Thanks SteveRo,
I'll inform GullLars, I expect the new thread will be up sometime this weekend.
At what size did you run the test?
Yes it would test the actual speed because if the TRS was large then the file you will have to make on the array has to be larger and will no longer fit in cache. It is not about the TRS, but about the size of the file that the test runs on. Large TRS will force the file size to be large so it would work correctly.Quote:
Originally Posted by onex
Your TRS can be 1B and it would also work correctly given you specify the file size to be larger than cache.
yeah, bring it on,Quote:
I expect the new thread will be up sometime this weekend.
already made a graph from Tiltervos results.
yeah, exactly,Quote:
It is not about the TRS, but about the size of the file that the test runs on. Large TRS will force the file size to be large so it would work correctly.
understood.
can u specify?Quote:
Your TRS can be 1B and it would also work correctly given you specify the file size to be larger than cache.
IOMeter isn't giving any option to set a file size, only options are @ the worker->disk->Max Disk Size - # of sectors which might limit the iobw.tst file, or aligning IO's @ the AS tab,
they both doesn't seem to affect file size.
tried different configuration and couldn't play with the size, it remained 350MB, after deleting it and re-entering all-in-one test, it came back 3.5GB ..:mad:
E: ohh http://www.xtremesystems.org/forums/...cons/icon3.gif, so this is the answer^^,
:hm: yet it doesn't allow for a file less the 350MB..:mad:
E: oh yes it does! setting the transfer size low and deleting the file,
lol, it's funny seeing it grows :D.
E: o.k got the all thing http://www.xtremesystems.org/forums/...ons/icon14.gif, cylinders/sectors/tracks/heads, setting the size etc :up:.
Good morning, files size was at default.Quote:
Originally Posted by Anvil
impressive.Quote:
Originally Posted by Anvil
Post - 56 - I thought the numbers i was seeing were to good to be true - test file size was only 1GB - measuring mostly cache performance when the cache is 4GB?
OK - so try again - this time same x25-V x2 Raid 0 on Areca 1231ML-4G, file is attached - zipped using TUGZip.
Partial screen capture below -
http://img641.imageshack.us/img641/1586/21307490.jpg
SteveRo,
Sorry about that, the default size is 1GB, 4x the size of the controller cache should be fine.
The cache run was impressive, especially at low QD's, it did flatten out quite early compared to my LSI 9260 but then again the LSI is more like your last run at lower QD's.
(I've never tried a run using only cache on the LSI so I'm tempted to try)
It looks like xs somehow is nesting the zip files, strange one.
I nearly ordrered an Areca 12xx when I looked at your first results file :)
The Areca 1880 series is still a few months ahead, must resist.
Good morning again, This is 12x_R0_acard_9010_1231ML4G random read using your iometer config file - results file attached, excerpt screen shot below -Quote:
Originally Posted by Anvil
http://img62.imageshack.us/img62/8026/73749948.jpg
Very good - yes both of the last 2 runs where with files size -Quote:
Originally Posted by Anvil
x25-V - 16.7GB
acards - full drive - 31.9GB
I am taking my test system apart to upgrade to UD7 now - so no more testing for a little while.
Thanks again SteveRo,
Should be an interesting analysis :)
Looking forward to your impression of the UD7.
My UD5 has been (and still is) a great MB, really couldn't ask for more but the UD7 offers a few more tricks up its sleeve.
@Tiltevros,
could you add a random write bench, and specify u'r system specs?
e: i'll find that.
Aside from the Intel 80GB MLC G2's, which are in a different size category & have better random r/w & read speed...
Would I be correct in asserting that MLC SSD's based on Indilinx, are currently the best "overall" performers at 30-40GB?
Of course a controller alone does not make a good MLC SSD:
*Quality of NAND flash (define)
*Cache size/implementation (define)
*Firmware implementation (define)
Can all have an impact on the overall performance of a drive.
What about Intel 40GB X25-V's (G2?), do they also have superior read performance compared to Indilinx drives?
If so & assuming their random r/w is still better, than perhaps it's a better choice for my intended app?
Alas there doesn't seem to be any Vertex Turbo 30GiB available in Oz, it only starts at 60GiB.
However there's three other barefoot controller based brands available at very reasonable prices:
http://www.hboutlet.com.au/catalog/c...-p-362913.html
http://www.megabuy.com.au/corsair-ex...5-p137095.html
http://store.livefire.com.au/product...ee1750e70fa558
Is the vertex turbo worth the premium for the actual performance gain over the non-turbo?
I'm yet to look at local pricing for the X25-V....
I really don't need more than 40GiB, it's to house a Ubuntu MythTV BE+FE environment.
Based on others experiences I won't need more than 20GiB, & that's less stripped down then I intend to go.
I don't have time to wait for the nextgen stuff, and I doubt any of it will be available in 30-40GB anyway.
One other thing I want to confirm; SATA II's ceiling for actual data transfer speed is 300MB/s right?
I mean it's absolute limit is 375, but one has to allow for 2bit error correction and protocol overhead right?
I ask this because unfortunately there's still no H55/7 or Q55/7 mATX motherboards with SATA6G.
Hopefully later in the year there will be, but for the time being I'll have to make do with SATAII...
Any thoughts/advice greatly appreciated! Thanks.
Good morning jalyst,
I have had both x25-v's and 30GB vetex turbo's - each has its advantages over the other.
The turbos are generally faster in seqential iops where the intel drive is faster in small file random iops.
So it really comes down to how you intend to use the drive.
I don't know much about MythTV - I would assume you might be recording some large files?
Did you intend to store these files on SSD?
Any video editing?
Any large file storage/retrieval?
Single drive only or do you intend to raid?
Seems like SATA II max speeds are probably in the 270-280 range (you lose some speed due to overhead).
The x25-e is advertised to do 270.
MythTV dumps raw ts-something (name escapes me), it's basically an mpeg2 stream
Depending on the broadcast format -SD or HD- the resulting files of recorded TV can vary.
I'm not sure off the top of my head what the typical bitrates/sizes are, but at a guess the biggest it'd ever get, perhaps 1.5GB?
I'm not sure what I'd do yet, maybe I'd have stream/s that I'm watching in real-time go straight to the SSD.
And streams that I want to actually record/archive for later viewing could perhaps just go straight to my 1TB WD Black?
There will be advert flagging & when the machine's least used (during the day) some transcoding of archived mpeg2 to a better format.
The idea -I think- would be mostly to use the SSD as the system/boot volume, and the 1TB WD Black for storage.
I did have plans for a RAID but that's been scrapped for the time being
http://episteme.arstechnica.com/eve/...1#769006643041
Really, only 280? I thought once one accommodates for overhead it was more like 300MB/s?
Yikes 4am, good night!
OK - sounds like either a vertex or a x25-v would work great as your boot/app drive.Quote:
Originally Posted by jalyst
Then you would want lots of rotating storage and room to add more later.
I'm not sure if I understood your question but If you want a SSD for streams or physical encode or decode, first you need to know much much MB/s these formats require.Quote:
Originally Posted by jalyst
http://en.wikipedia.org/wiki/Blu-ray_DiscQuote:
For users recording digital television programming, the recordable Blu-ray Disc standard's initial data rate of 36 Mbit/s is more than adequate to record high-definition broadcasts from any source (IPTV, cable/satellite, or terrestrial). BD Video movies have a maximum data transfer rate of 54 Mbit/s, a maximum AV bitrate of 48 Mbit/s (for both audio and video data), and a maximum video bit rate of 40 Mbit/s. This compares to HD DVD movies, which have a maximum data transfer rate of 36 Mbit/s, a maximum AV bitrate of 30.24 Mbit/s, and a maximum video bitrate of 29.4 Mbit/s.
This quote above illustrates the Blu-ray which uses far more resources than other products alike.The Intel X25-V will do just fine.
Regards,
Yeah I'm sure both would be great, but the tricky part is determining which would be optimal.Quote:
Originally Posted by SteveRo
Yeah I'm pretty sure BR is usually higher bitrate than even HD DVB content.Quote:
Originally Posted by Metroid
I'm sure both SSD's could handle multiple streams of a similar bitrate whilst doing other things, but which would be optimal is still a tricky question.
I guess in most usage scenarios the differecne are unlikely to show up :shrug:
I would go Intel, reason 'reliability', never had any problems with Intel products.Quote:
Originally Posted by jalyst