USB3 på något i stil med RPi, BananaPi eller OrangePi?

[lillahuset]

Jag återkommer med test så får vi se. Och tillåter mig tvivla på 30 megabit per sekund. Så långsamt är väl inte ens ett gammalt SD-kort.

[limpan4all]

Så hur snabb är en av de snabbaste? T.ex WD 2.5" 1TB BLACK 32GB Cache.

Read
Avg. Sequential Read Speed 169 MB/s
Write
Avg. Sequential Write Speed 173 MB/s
4K Read
Avg. 4K Random Read Speed 0.97 MB/s
4K Write
Avg. 4K Random Write Speed 4.98 MB/s
Mixed
Avg. Sequential Mixed IO Speed 73.7 MB/s
4K Mixed
Avg. 4K Random Mixed IO Speed 0.68 MB/s
SusWrite
Avg. Sustained Write Speed 170 MB/s

Om man tittar på siffrorna så ser man att en copy från en sådan till en annan har en samanlagd bandbredd på maximalt 3Gbit/s men då dataflödena går åt olika håll (förutsätter att drivern i Linux är vettigt skriven) så blir det under 2Gbit/s i varje riktning. Så en ensam USB 3.0 med 5Gbit/s (i varje riktning, full duplex) kapacitet kommer inte att storkna. Den skall klara 400MB/s i varje riktning, så för kopiering så skall det vara mer än nog.

Nu skall allt sådant här tas med en rejäl nypa salt. Det krävs ju bara att någon lite skitdel av Linuxmjukvaran eller att HUB´en inte gör exakt vad den borde för att prestanda skall bli skit. Men i teorin så räcker det med en USB 3.0 port och en extern HUB som MÅSTE klara av att leverera typ 1.5A per port (i teorin så skulle det räcka med 500mA). Så att hitta rätt USB hubb kan nog bli det svåraste.

[lillahuset]

1,5A per port! Ojojoj, det lär inte min hub klara av. Men ditt exempel är ju en värstingdrive. 32GB cache.

[lillahuset]

Kod: Markera allt

root@igor:/home/jan# dd bs=1G count=100 if=/dev/zero of=/media/jan/Maxtor2T/data/hej
100+0 records in
100+0 records out
107374182400 bytes (107 GB, 100 GiB) copied, 3289,53 s, 32,6 MB/s
root@igor:/home/jan# dd bs=1G count=100 if=/media/jan/Maxtor2T/data/hej of=/dev/null
100+0 records in
100+0 records out
107374182400 bytes (107 GB, 100 GiB) copied, 3009,87 s, 35,7 MB/s
root@igor:/home/jan# dd bs=1G count=100 if=/dev/zero of=/media/jan/Maxtor2T/data/hopp
100+0 records in
100+0 records out
107374182400 bytes (107 GB, 100 GiB) copied, 821,38 s, 131 MB/s
root@igor:/home/jan# dd bs=1G count=100 if=/media/jan/Maxtor2T/data/hopp of=/dev/null
100+0 records in
100+0 records out
107374182400 bytes (107 GB, 100 GiB) copied, 808,718 s, 133 MB/s
root@igor:/home/jan# 

Då har vi lite resultat för en 2TB 2,5" extern snurrdisk från Maxtor (Seagate).
USB2 skrivning 32,6 MB/s
USB2 läsning: 35,7 MB/s
USB3 skrivning: 131 MB/s
USB3 läsning: 133 MB/s

Skrivning via USB3 är 4 gånger snabbare än skrivning via USB2.
Läsning via USB3 är 3,7 gånger snabbare än läsning via USB2.

Testen körda på min desktop.
Slutsatser får ni dra själva.

[Jolles]

Err what?! 130mb/sek skrivning på en mekanisk disk - är det verkligen görbart? Mig veterligen var bara 60-70mb/s uppnåeligt, men det är kanske bara snittsiffror då..?

[lillahuset]

130 millibit är inte mycket att komma med.

Det beror väl på hur mycket gegga det redan finns på disken, den här var i princip tom, och så är ju blockstorleken 1GB. Data från /dev/zero ger väl ganska lite overhead också antar jag. Och det är ju snitt under en knapp kvart.

Jag har inte hittat datablad på den här disken, Maxtor M3, men kollade på en 3,5" och där stod det något på 190MB/s.

[xxargs]

Den skall klara 400MB/s i varje riktning, så för kopiering så skall det vara mer än nog.

Men inte i duplex väl?? (svarar mig själv - tydligen...) - inte ens SATA-standarden kan köra i duplex trots separata TX och RX-par (lanes), för sådan duplex-drift med ECC-rättning på dataströmmen istället för enkel CRC ser man först på SAS-diskar (och i dubbel takt, och senare versioner kan man adaptiv välja riktning på båda lanes dynamiskt efter behov - dvs båda kan köras TX eller RX parallellt och med dual port är man uppe i 2.4 GB/s - dvs. i stort sett samma som dagens PCIe med 4 lanes på M.2 SSD)

[xxargs]

Err what?! 130mb/sek skrivning på en mekanisk disk - är det verkligen görbart? Mig veterligen var bara 60-70mb/s uppnåeligt, men det är kanske bara snittsiffror då..?

Du hänger inte med, 60-70 MB/s stämmer på en 2-skivors 1TB gammal WD-green 3.5" ano pre 2010

3.5" diskar ligger idag många gånger över 200 MB/s till 235 MB/s i ytterkant för de snabbare 7200-varvare

2.5-tummare som extern USB 4TB-disk från Seagate håller runt 133 MB/s när den läser ytterkant och genomsnitt mellan ytterkant till innerkant ligger på 103 MB/s, genomsnittlig söktid på 20.3 ms vid 1000 sökningar [1] (kollade nyss med gnu-disk ('disk' i ubuntu) med 1 GB läsblock - detta över USB3!

få se om Seagate får ut sina dubbelarmsdiskar - en 7200 rpm med två läskanaler parallellt skulle man vara farligt nära att mätta en SATA600 med tanke på att en dagens Seagate 10TB ironwolf med 1 läskanal toppar på 245 MB/s.

att det går så snabbt beror på att man packar bitarna så fruktansvärt tätt i ett spår (bit under 10 nm/bit) och håller hög dataflöde även vid medioker varvtal som 5400 och 5900 RPM

Jämför man en gammal 3.5" WD-green 2TB anno 2010 gentemot en dagens 3.5" 4TB från Toshiba så kommer WD-disken kännas oerhört trött - dagens NAS-diskar kör cirklar kring en anno 2010 WD-black med 7200 rpm

hade en post med lite uppmätningar - dock ej 2.5" diskar:

http://elektronikforumet.com/forum/view ... a#p1403887


[1] inte speciellt snabbt - 300 GB 2.5" 10 krpm SAS-diskar har genomsnittlig söktid på 4 ms

[Jolles]

Oj jag inser att jag helt missat att undersöka sånt här de senaste åren! Har dom hittat nån ny ultralätt metall på mars eller hur blev de plötsligt så snabba? Tyckte det lät för några årsedan som att man skulle ha nått något tak för vad en disk med en arm kunde uppnå..

Den enda mekaniska som sitter kvar i min maskin, en 2TB WD green 5400rpm från 2012 som snällt ännu tuggar på av någon anledning mätte upp för mig ganska imponerande 106MB/sek i snitt.

Provade att ssh'a in på min synology också med 3st modernare 3TB samt en 4TB (SHR) och provade samma sak..

Kod: Markera allt

dd if=/dev/zero of=/volume1/share/test1.img bs=1G count=1 oflag=dsync

men den kunde bara nå upp i 19,9MB/sek vilket bekräftar varför jag tycker den är så slö... Hur är det möjligt, är något kajk eller är SHR så långsamt?

EDIT: Ok, 114MB/sek med bs=512M (insåg att den bara har 512Mb ram)

EDIT": Fast det där stämmer väl inte heller om den bara fyller ramminnet...

[xxargs]

Fast den fördelen med snabbhet med RAM-chache har du bara dom första sekunderna - när det är fyllt så är det disken som bestämmer farten - mät flödet över en minut eller så, då är inverkan av RAM-cachen väldigt liten på den totala lästa/skrivna mängden.

Har man 56 GB ram som i min DL385-servern så kan jag säga att det blir mer missvisande - dessutom nu en 7 diskars RAID5 [1] med 2.5" 10 krpm 300 GB SAS-diskar goda för tillsammans över 650 MB/s kontinuerligt så kan jag säga att det är andra faktorer som börja bli dominerande för den slutliga hastigheten, som tillgänglighet av CPU mm.

Var ett litet 'oj då' med en VM-maskin i KVM (i ubuntu server på servern) med en ubuntu snurrande i VM:t där och på en virtuell disk där visade en bra bit över 2 GB/s... ...tills RAM-diskcachen blev full på servern och det gick ned till ca 650 MB när det börjande mata mot de fysiska diskarna... - det var väldigt mycket mer i diskhastighet än när jag provade linux i vmware tidigare (har full-licens av vmware på serven i fråga - men är (för?) gammal) - var flaskhalsen var där vet jag inte...

---

slutligen - har man börja prova ett riktigt server-järn, så är man inte vidare sugen att gå tillbaka till konsument NAS igen då det hela känns väldigt spartanskt och strippat gentemot en full server-ubuntu och rejält med både CPU och RAM... ovanstående dl385 med dubbelpropp skulle kunna hålla 4 st 1 GB-ethernet på full spett i båda riktningarna samtidigt utan att det stryper på vare sig CPU eller på lagringssidan, med komprimering och kryptering på filsystemsidan...

sådant är inte att tänka på en NAS med en ARM-prop med bara 1-2 GB i RAM




[1]

BTRFS mjukvaru RAID5 genom en P400-controller som _inte_ kan sättas i IT-mode, som jag provar just nu för att se om den är så dålig som alla (ofta inte så uppdaterade) gapskallar skriker om på olika BTRFS-forum, själv tycker jag den verkar vara väldigt robust, då har jag ändå plockat ur diskar under full skrivning, skrivit över en enskild disk med dd under full drift och lite andra fulheter som att rycka ström under skrivning ett flertal gånger - den repar sig och reparerar sig alldeles utmärkt och har ännu inte hittat en händelsesekvens med fel som får BTRFS RAID5 att dyka ohjälpligt och oreparebart.

att kunna plocka in nya diskar eller ta bort efter behov, diskar med olika storlek, välja olika raid-moder och byta mellan dessa 'on line' när man känner för det och utan att påverka driften av servern medans det konverterar är helt jäkla underbart - jag provade att lägga in en SATA 500GB-disk i samma RAID-set som SAS-diskarna med ungefär samma maximala överföringshastighet. - gör det inte - SATA-disken drar ned RAID-arrayen något helt enormt i hastighet och man såg ur SAS-diskarna hängde på spadskaften och tittade på den stackars SATA-disken som aldrig blev klar någon gång (konstant lysande disklampa medans sas-diskarna bara blinkade till lite då och då...) - samma sak i atop - konstant rött och 100% last med armlång skrivkö på SATA-disken medans det var helt rent på de andra SAS-diskarna...

Har fått lite annan inställning till sas-diskar efter detta, och frågan om det fan inte är värt premiumpris för dessa i tex. företagsserversammanhang...

skall man bygga privat (gamla beg hpe dl380-chassier är inte speciellt dyra - om man står ut med ljudet och relativt höga elförbrukningen alltså...) - och man behöver heller inte vara speciellt rädd för beg. sas-diskar heller trots flertal tiotusentals timmars drifttid, de går inte sönder speciellt ofta och ofta en prisbild där man kan ta med ett eller par extra i reserv - passa på om man får nys om företag som byter ut delar av sin serverpark - om inte annat så är det bra att känna till och själv provat vad som finns i serverväg och hur de fungerar när man senare skall diskutera företags-serverlösningar när behov uppstår.

[netrunner]

Det är ju ganska stor skillnad på vad det är man har diskarna till. Ska man kopiera filmer på 4GB från en disk till en annan? Då kan man ligga nära max överföringshastighet.

Tankar man ner saker med bit-torrent där programvaran vill skriva små mängder data till massor av olika ställen på disken ... snabbt så kommer alla mekaniska diskar att stoppa. Dom kan inte flytta pickupen snabbt nog. SSD har ju inte problem med detta så ... man får välja vad man ska göra med disken.

[xxargs]

Nu skall du inte dra ned snurrdiskar som generellt dålig bara för att windows och NTFS hanterar situationen ururselt.

Det som räddade NTFS kvar ett årtionde till var med SSD, det höll på att knaka bra i fogarna för MS och NTFS på snurrdisk runt 2010 kort innan SSD blev överkomlig i stora användarlager. För den krassa sanningen är att MS inte har någon bra framtida ersättare för sin NTFS och heller inte verka jobba seriöst på det (ett lamt försök var med ReFS som en billig kopia på ZFS och BTRFS, och nu verkar stoppas in allt djupare i garderoben (dvs snarare nu bara finns på enterprise-nivåerna av win-licenser) - nästan som att MS skäms över den...)

Byte från snurrdisk till SSD har inte alls samma magnituder till förbättring om man tex körde Linux. Visst lite kortar starttider ja, men inte alls på samma sätt som med win som var på gränsen till oanvändbarhet med snurrdisk och eviga letandet av småfiler i en ineffektiv NTFS långt efter starten och gjorde upplevelsen av datorn som seg.

och handen på hjärtat - upplevs dagens windows på SSD som snabb? - inte speciellt va, för nu har man hällt i dubbelt mer med skit som hela tiden pockar på småläsningar och lastar SSD bara för att det nu gick innan windows börja upplevas ohanterligt segt igen...

[lillahuset]

Nu när MS har börjat se verkligheten lite klarare, man har ju trots allt annamat vissa delar av pingvinen, så borde man väl kunna integrera något av filsystemen i Windows istf att skriva eget nytt. Billigt och beprövat.
Visst, det skulle ju vara en prestigeförlust men på sikt kommer nog den där prestigeförlusten iallafall.

[xxargs]

Gör som i linux - se till att kunna använda ett större flertal fs utan allt för mycket prestandaförlust, sedan får power-user välja don efter behov - annars köra på liknande ext4 som standard för hyfsad grundprestanda även på snurrdiskar - NTFS bara som kompabilitet när inget annat fungerar...

visst - flertal saker kommer att strula i MS egna produkter till en börja då de använder finesser i NTFS som ingen annan använder (tex dubbla strömmar för filnamen - en för namnen vi ser idag och en för den förkortade DOS 8+3 tecken - tar man bort det senare så blir en del trasigt i windows - men va fan, fixa det då i så fall eller ta bort beroendet!

---

Ett tips som verkar vara den bästa på länge om man har diskimage med okänt innehåll och försöka räkna offset var partitioner etc. ligger för att sedan mounta in på dem

losetup -f -P diskimage (under linux så klart, detta är inte uppenbart när man läser manualen...)

så letar den upp alla sådana detaljer och sedan gör loopback på de olika partitionerna den hittar och gör dem synliga med tex. lsblk och som enheter i filhanteraren i grafiska skalet som man sedan kan montera och sedan dyka ned i det

när man sedan är färdig så umountar man och därefter losetup -d /dev/loopx (se med lsblk för exakt benämning)

- så nu har jag skrivet det så att jag kan hitta det själv när jag glömt bort det

[arvidb]

Bryr sig verkligen Microsoft särskilt mycket om filsystem eller ens Windows längre? Nu är det väl "molnlösningar" som gäller? Och är då den lokala datorn snabb och smidig så blir kanske motståndet mot just molnlösningar för stort?