"Plugin FileCopyEx umožňuje ze zdrojového umístění číst a na cílové umístění zároveň zapisovat,"
To akože Total Comander, či štandardný Explorer vo WIndows takto nerobí???

No nevím, ale 6% je tak možná chyba měření ale ne relevantní výsledek, z kterého se dají dělat nějaké dalekosáhlé závěry. Nemůže necitovat : A zase prd :-)

Posuzovat rychlost rozhrání podle rychlosti "HW" "RAID" 0 na jednom konkrétním řadiči? Myslel jsem, že DIIT má trochu větší úroveň...

No ono je to jednodussi nez se zda.Ve skutecnosti ten 6Gb disk by rchlejsi nez 3Gb nebyl.Coz si vyrobci velmi odbre uvedomuji.Takze se zvetsila cache a voila mame vyssi vykon a marketing muze tvrdit ze to je dano tim ze je 6Gb.

Mám SSD, které čte 220Mb/s. Budu tudíž muset vyměnit svou "starou" základní desku a svůj "starý" disk (protože jsou oba jen SATA II) a pořidit novou desku a tento mechanický disk, abych dosáhl vyššího výkonu, které 6Gbit SATA nabízí, hned si to běžím koupit :-D

co to treba zkusit pod linuxem? jakej tam bude rozdil oproti driverum ve win? sw raid? jinak ten pseudo raid v radici se s hw raidem neda sravnovat ale to je vam v diit snad jasny

Mam jen dve poznamky:
1. zajimave by bylo srovnat dva disky stejne kategorie, ovsem jeden se SATA 3Gbs a druhy 6Gbs, nekde jsem cetl, ze ty 6Gbs verze maji rychlejsi kontroler, coz muze byt pricinou rozdilu ve vykonu.
2. znate nekdo RAID 1 radic, ktery skutecne zvysuje vykon pri cteni ? Pro sekvencni cteni je to totiz prakticky vyloucene (tedy pokud se bavime o klasickych discich ne o SSD), protoze disku je uplne jedno kolik sektoru behem cteni musi preskocit, stejne mu to cteni tech zbyvajicich sektoru trva +- stejne dlouho, tedy dokud by preskakovany usek nebyl dlouhy presne na cely track nebo tak neco. Aby fungoval interlacing tak jak jej zminuje WIFT, musela by byt data ulozena napr. na prvnim disku od zacatku do pulky jen liche logicke sektory and pak sude a na druhem naopak (tedy sude od zacatku do pulky). Pak by se z obou cetlo sekvencne jeden sektor za druhym a v radici (nebo ovladaci) by se to prokladalo a kombinovalo. Toto jsem ovsem jeste nikdy nevidel, data na RAID1 diskcich jsou vzdy ulozena klasicky sekvencne (coz lze snadno overit po vyjmuti disku a pripojeni k ne-RAID radici). Jedine urychleni tedy pripada v uvahu pouze pri nahodnem pristupu, napr. pri soucasnem cteni dvou rozdilnych souboru, by teoreticky mohl byt jeden nacten z jednoho disku a soucasne z druheho by se mohl nacist ten druhy. To by ovsem vyzadovalo sakra inteligentni logiku v radici (dlouhou frontu, velkou cache s read-ahead logikou, atp.), proto se obavam ze bez spoluprace s OS na urovni file-systemu je to take velmi nepravdepodobne.

Tsss...to jsou problemy :-))
Pamatuju, jak jsem na 286/16MHz laboroval s formatovanim MFM disku a hledal optimalni Interleave :-) Vetsinou to vychazelo tak, ze zatimco na pro XTcka bylo potreba nejaky Interleave mit, protoze radice nestihaly z disku tak rychle cist, a tudiz rychlost cteni / zapisu byla cca 20kb/sec , tak 286 uz stihaly komunikovat rychleji, a po odstraneni interleavu (interleave 0) slo z MFM disku dostat az 200kb/sec, z nekterych i 220-230kb/sec :-)))
Tady se resej nejake 3GB/6GB ... tssss :-)))

není to tak dávno, co byly kontroléry jen na PCI sběrnici, která měla reálnou propustnost maximálně 90MB/s. I blbé PCIe x1 v2.0 už má v jednom směru teoretických 500MB/s a i kdyby to bylo v reálu o 20% méně, tak má SATA 6Gbit ještě stále rezervu. Ovšem RAID kontroléry na PCIe x1 považuji za hračky, tam už se limit sběrnice x1 projeví