-
IT café
Milyen SSD-t vegyek? Mielőtt kérdezel, kérünk az összefoglalót olvasd el! Ha ezt végigolvastad, de még mindig nem sikerült dönteni, akkor amikor kérdezel, kérünk, feltétlen tüntesd fel az alábbi adatokat!
Új hozzászólás Aktív témák
-
jeni
félisten
válasz janos666 #2051 üzenetére
Én az ODD helyére tenném a HDD-t, a HDD helyére az SSD-t és külső DVD lapos írót vennék. Samsung SE-208AB 8500 Ft
Kevésbé károsodik a HDD a cipeléstől.Ha a notid sata 3-s vezérlésű akkor egy stabil minőségi SSD-t vennék.
Akár a Vertex 3 120GB,még a Agility 3 is jó.Vertex Plus,Octane,Petrol ezek nem minőségiek.
sok a gond velük[ Szerkesztve ]
-
Bodor
veterán
válasz janos666 #2080 üzenetére
Hát nem is tudom. Szerintem nem sok ilyen "megtöltött " SSD-val találkozni itt a fórumon, mert úgy tűnik mindenki nagyon be lett oltva SSD írásból, meg hát mindenki óvja is, mert nem tesztelésre vette, hanem évekig használni. Nekem a Samu 80-nál az 54 GB-ból
( eleve ennyire formáztam, hogy biztos legyen szabad hely ) általában 20 GB mindig szabad, de semmi lassulást nem éreztem, és a tesztek sem mutatnak ki semmit. Olyan, mintha új lenne.
A neten lehet keresni SSD endurance teszteket. -
korcsi
veterán
válasz janos666 #2126 üzenetére
Hagyjuk már ezt a szinkron-aszinkron kérdést, az egész csak a Nand és a vezérlő közti interfészről szól, egyértelmű, hogy szinkron nagyobb nyers teljesítményre képes (10-11. oldal), de mivel egy meghajtóban sok lapka van ezért ezt a vezérlő nagyon szépen eltünteti, lásd agility 3 vs. vertex 3.
Az utolsó mondathoz pedig, nem a jmf602 volt mlc-s hanem a nand, nem a nand miatt szarakodott a meghajtó, hanem vezérlő miatt.
[ Szerkesztve ]
referencia 5700(XT) plexi ARGB-s blokk eladó!
-
peterk
senior tag
válasz janos666 #11259 üzenetére
Nem. Ha egy Intel Core I3 vagy erősebb proci lenne a vezérlőbe építve, akkor persze igaz lenne amit írsz (ezért van pl., hogy az NTFS tömörítés egy mai átlag gépen gyorsítja az olvasást, még SSD-n is, mert a kitömörítés még mindig gyorsabban megy a RAM-ban, mint az amúgy kva gyors SSD-ről való olvasás.)
De a vezérlőkben nem ilyen erős chipek vannak, ezért a ki/be tömörítési sebesség lényegesen lassabb, mint amit az SSD fizikailag képes lenne kiírni. Egy csak nullákból álló fájlt persze ez is villámygyorsan tömörít, de azt ma már egy kávéfőzőbe épített chip is villámgyorsan tömöríti. Ezért is van az, hogy tömörítős vezérlővel ellátott SSD-t mindenki zero fillben tesztel. Mert csak ott éri el (majdnem) a szekvenciális olvasás és írás az SSD fizikai képességeit. Amint nem zero fillel, hanem random adattal futtatod a tesztet, az ilyen SSD-k azonnal be is fékeznek rendesen, mert a tömörítés belassítja őket. Ezzel szemben pl. a samsungok - amikben nincs tömörítés - lényegében ugyanolyan sebességgel dolgoznak, az adat jellegétől függetlenül. Ezért ajánlottam neki a samsungot. Azzal nem lesz sebesség csökkenése.
(A tömörítés vs írási mennyiség csökkenésében igazad van, valóban kevesebb az írás így. Node, naponta ötször megbeszéljük körülbelül, hogy ennek kimondott szerver jellegű használaton kívül nincs jelentősége. Nem tudsz annyit ráírni egy mai SSD-re, hogy belátható időn belül leamortizáld. Akkor pedig mindegy, hogy a tömörítés kímél-e vagy sem.
De, ha már itt tartunk, van egy előnye a belső tömörítésnek: Az, hogy kifelé nem látszik. Azaz, ha pl. egy Intel vagy Kingston meghajtót teljesen teleírsz, a belső tömörítés miatt az valójában nem lesz teljesen tele, hanem marad egy 10-25%-nyi szabad hely, mert "belül" kisebb helyen elfér az adat. Azaz, ezzel a drive automatikusan biztosítja magának a wear leveling megfelelő működéséhez a helyet, nincs szükség arra, hogy te hagyjál valamennyi szabad helyed a meghajtón. Az ilyen drive-kat nyugodtan akár állandóan is teljesen tele lehet írni. Ez a tömörítést nem használó SSD-kre nem igaz. A samsungokon pl. érdemes valamennyi szabad helyet hagyni.)
[ Szerkesztve ]
Aki hisz a parajelenségekben, emelje fel a kezem!
-
peterk
senior tag
válasz janos666 #11263 üzenetére
Rosszul képzelted. A tömörítési algoritmus az tömörítési algoritmus. az mindenképpen egy plusz fázis a kiírásban.
Ha már el akarod valahogy képzelni, akkor képzeld azt, hogy tömörítési algoritmus nélkül a bemenő adat egyszerűen bekerül a kiírási cache-be és a kiírást végző alrendszer innen már írja is ki egyből ahogy tudja. A tömörítő algoritmussal rendelkező vezérlőknél pedig közbe van iktatva egy átmeneti tár, ebbe érkezik a bemenő adat, ebben a tárban a vezérlő betömöríti azt, és a tömörített adatot teszi a kiírási cache-be.
Namost, ezekben a vezérlőkben nyilván valami nagyon gyors algoritmus működik, mint pl. az NTFS tömörítésnél. Az NTFS tömörítés az un. LZNT1 algoritmust használja, annak is a gyorsított, un. "3-byte minimum search " verzióját. Ez egy rendkívül gyors, de cserébe persze kevésbé hatékony tömörítés (egy zip, rar, 7zip, gzip sokkal jobb tömörítési arányra képes, de nagyságrendekkel lassabb). A Sandforce vezérlőben konkrétan nem tudom milyen algoritmus dolgozik, de biztos vagyok benne, hogy valami nagyon hasonló, mint az NTFS tömörítésben. De legyen akármilyen gyors is, akkor is egy plusz lépés. Annál, hogy odaadom az adatot, amit egyből ki is írok, csak lassabb lehet az, ha odaadom az adatot, tömörítem, és úgy írom ki. Ehhez egyébként nem kell másik drive másik vezérlőjével összehasonlítani, elég, ha összehasonlítod ugyanannak a Sandforce-os drive-nak a zero fill-ben mérhető és a random adattal mérhető sebességét. A zero fill (minden nulla) tömörítése kerül a legkevesebb időbe (lényegében szinte időveszteség nélkül elvégezhető), ezért a sebesség - szinte - eléri a tömörítés nélküli optimális maximális sebességet. Azt, amire a vezérlő és a NAND lapkák fizikailag képesek (feltéve, hogy a busz nem fogja vissza. A SATA3 van olyan gyors, hogy ne legyen szűk keresztmettszet.) Amint azonban "valós" adatot kap a vezérlő, azonnal lelassul a tömörítés - természetes módon. A teszt ezt vissza is igazolja, a drive minden teszt paraméterben alaposan lelassul random tesztben. Megjegyzem, a tömörítés elve miatt - legyen szó bármilyen algoritmusról - a nagyon jól tömöríthető adatok gyorsabban tömöríthetők, mint a lassan tömöríthetőek. Ezt le is tesztelheted. Csinálj egy 100 megás fájlt csupa nullákból és csomagold be zip-el, majd csomagolj be egy ugyanakkora avi fájlt zippel. Az avi fájl betömörítése sokszor annyi ideig fog tartani. Ugyanezzel a módszerrel letesztelheted a Sandforce vezérlőt is. Csak ott nagyobb fájlt használj. Mondjuk készíts egy 4 gigás csupa nullás fájlt, és egy ugyanakkora film-fájlt, és másold át mindkettőt ugyanazon a drive-on egy másik mappába. Markáns különbséget fogsz látni a sebességben. A Samsung esetén pedig - mivel nincs benne tömörítés - a két esetben meg fog egyezni a sebesség.
Aki hisz a parajelenségekben, emelje fel a kezem!
-
peterk
senior tag
válasz janos666 #11268 üzenetére
Hogy őszinte legyek, nem fogom, hogy mit is cáfoltál azzal amit írsz. Felhasználó szempontból baromi egyszerű a történet: Fogod magad és írsz az SSD-re valami adatot, majd fogod magad és olvasol róla adatot. És azt tapasztalod, hogy az egyik SSD esetén az történik, hogy ha nullával teli fájlt olvasol, akkor 500MB/s körül olvas, ha véletlenszerű adatokkal teszed ugyanezt, akkor a teljesítmény csökken. Esetenként feleződik, harmadolódik. A másik SSD esetén pedig, amelyik hasonlóan 500MB/s körül olvas, nincs ilyen jelenség, mindenféle adattal ugyanezt a teljesítményt hozza.
Aki hisz a parajelenségekben, emelje fel a kezem!
-
peterk
senior tag
válasz janos666 #11274 üzenetére
Se kötekedni nem akarok, se pedig arról nincs szó, hogy amit leírsz, azt ne értettem volna meg elsőre. A grafikonjaidat, belinkelt adataidat sem vonom kétségbe. Ugyanakkor másról beszélünk. Értem, hogy miért hozod elő azt, hogy a NAND tárhelyek növelésével lényegében lineárisan nő a sebesség. Ezzel látod kizárva látni azt a tényt, hogy a tömörítés negatív impact-ot jelentsen. Nos, miközben logikusnak tűnik az érv, aközben két probléma van ezzel. A belinkelt ábra csak akkor jelentené ezt, ha a vezérlőben szereplő tömörítő chip minden típusban pontosan ugyanúgy működme, azaz igaz lenne, hogy a kisebb és nagyobb meghajtók között semmi más különbség nincs, mint a NAND-ok és a szálak száma. De honnan tudod, hogy a vezérlő így működik? Honnan tudod, hogy egy kisebb drive-ban csak a szálak száma kevesesebb (nincs munkára fogva mind), de ugyanez nem igaz a tömörítő chip-ren nézve? A vezérlők belső felépítése nem nyilvános, ezért nem tudhatod. Csak azt látod, hogy a nagyobb meghajtó átvitele egy ideig lineárisan nő, de hogy ebben mi játszik szerepet (kirázólag a NAND pipeline-ok száma, vagy esetleg a vezérlő egyéb más paraméretei is - pl. cache méret, a 16/32/64 compound parancskészlet használati aránya/módja, stb.), azt nem.
Lényeg a lényeg: tizenöt éve foglalkozom adattömörítéssel ("egyszerű" kommunikációs/adattranszfer tömörítéstől, pl adatbázisok online tömörítéséig), és egy dolgot hadd mondjak: Olyan nincs, hogy "a tömörítés gyorsít". Olyan van, hogy a tömörítés gyorsíthat. Éppen ettől válik szakmává, hogy megtaláld mikor alkalmazd, és mit, illetve mikor ne. Namost, egyikünk sem ismeri az SSD vezérlők belső lelkivilágát, de abban majdnem biztos vagyok, hogy egy egyszerű SSD vezérlőben nincs annyi intelligencia (vagy csak egészen minimális), hogy analíziseket végezzen az érkező adaton, és eldöntse, hogy tömörítse-e vagy sem. Felteszem, hogy a tömörítést (ez ma az általános) egy VLIW társproszesszor végzi (manapság a 3-set az elterjedt). Ennek a kihasználása skálázható - amit a verzérlő nyilván meg is tesz, hogy ne legyen a kimeneten adattorlódás, de várakozás sem -, viszont intelligenciát nem tartalmaz általában (ha van ilyen, akkor csak drágán, speciális eszközökben, és nem magában a processzorban).
Na mindegy, nem akarom nyújtani, mert szerintem senkit sem érdekel. A lényeg amit akartam mondani: A felhasználót - ide ilyenek járnak - nem érdekli, hogy belül mi zajlik egy SSD vezérlőben. Nem érdekli, hogy mi miről vitatkozunk, nem érdekli, hogy egy adatírás/olvasás - ami ráadásul blokkokban történik - mely blokkja gyorsul éppen a tömörítés miatt, és melyik nem. Egy dolog érdekli. Az, hogy ha "kiírok egy word fájlt", akkor azt melyik SSD teszi meg gyorsabban? Vagy az, hogy "ha kiírok egy mkv HD filmet, akkor melyik lesz a gyorsabb"? Ilyen egyszerű. És innentől kezdve pedig már az van ahonnan kiindultunk. Lehet itt technikai vitákba bonyolódni, de ha valaki cad-el foglalkozik, főleg, ha compressált projekt fájlokkal dolgozik, akkor egy Samsung SSD jobban fog teljesíteni nála, mint egy Sandforce vezérlős. (De pl. egy Intel-nél is.) Ennyi volt a kiindulás, ennyit akartam mondani, és ez továbbra is igaz. A "compression magic" véget ér ott, ahol nem tömöríthető adatok jönnek szembe. Ezt hidd el nekem, aki ezzel foglalkozik.
(Még valami. Érdemes látni, hogy mindezzel nem a Sandforce vezérlőt - illetve a tömörítő algoritmust használó vezérlőket - "szidtam". Azok nagyon is jók, sőt, consumer szegmensben szerintem kiváló találmány a dolog, mert a tipikus felhasználó számára több előnyt is biztosít, miközben a hátrányaival egy tipikus felhasználó alig találkozik. Rögtön egy előnye például, hogy az ilyen SSD-k esetében nem kell figyelni arra, hogy mennyi szabad helyet hagy, mert a vezérő megoldja, hogy ez ne legyeb probléma. Pont a belső tömörítés által. Vagy pl., böngésző cache-ként kimondottan jól jön a tömörítés. Márpedig otthoni felhasználój jelentős része böngészik. Vagy mondjuk játékok esetén, ha a játék adatai (pálya adatok) nem erősen tömörített formában vannak. Ésatöbbi. De vannak szerepkörök, amiben viszont kimondott hátrány tud lenni. Ilyen az, ha valaki döntően tömöríthetetlen állományokkal dolgozik. Legyen az film, tömörített projekt fájlok, stb. Az ilyen esetekben jobb nem keverni bele automatikus, alacsony intelligenciájú algoritmusokat a folyamatba.
Hogy egy gyakorlati példával illusztráljam: Manapság aktív vírusirtó, ill. tűzfal nélkül "őrültség" egy átlag felhasználó számára egy windows-os gépet használni. De én, mint fejlesztő, sosem használtam ilyent, mert én nem kapok be vírust. Manuálisan meg tudom oldani azt, hogy elkerüljem. Ergo magam vagyok a vírus védelem, nincs szükségem egy "automatikusra". Ugyanez lehet igaz az adattömörítésre is. Én inkább választok egy automatikus tömörítés nélküli SSD-t, és inkább NTFS tömörítést használok, ahol ráadásul jómagam választom ki, hogy melyik fájl legyen tömörítve és melyik ne. Adatátvitelben, helyspórolásban - sőt az SSD "kímélésben" ez még jobb is, mint az automatikus belső tömörítés, mert több benne az intelligencia: csak azt tömörítem amit érdemes, és azt nem amit nem. De ezt meg tudom csinálni én, meg a hozzám hasonlók, a felhasználók 99%-a viszont nem. Ezért ők csak telepítsenek vírusírtót, mert úgy járnak jól. És ha átlagos otthoni felhasználásra vesznek SSD-t, akkor vegyenek nyugodtan belső tömörítéssel dolgozó SSD-t, mert azzal is általában jól járnak.
Így már elhiszed, hogy nem kötözködni akartam veled, illetve érthető, hogy mire akartam kilyukadni? (Esküszöm, 2 hónapra kiírtam magam. Elnézést, hogy ilyen hosszú lett, mindenkinek havaslom Attila-n kívül, hogy ugorja át. Több ilyen post-szörnyet ígérem, nem produkálok.
[ Szerkesztve ]
Aki hisz a parajelenségekben, emelje fel a kezem!
-
peterk
senior tag
válasz janos666 #11295 üzenetére
"Persze, fennáll a lehetősége, hogy attól függetlenül, hogy nem szitálnak rá más jelölést, még nem pont ugyan azt a SandForce chipet rakják az SSD-kbe minden kapacitáshoz, hanem pl. a belső cache mérete, és/vagy a magok száma változik, mert a selejtes chipeket megnyesik kisebbre, és azokat küldik a kisebb kapacitású SSD-khez. De ezt viszonylag hihetetlennek érzem. Ezekből az adatokból inkább azt tudnám elhinni, hogy a gyártók piszkálnak bele úgy a firmware-be, hogy mesterséges limitekkel korlátozzák a kisebb kapacitású modellek sebességét."
Az utóbbi a valószínűbb, igen. Elég csak az Intel processzorokra gondolni, amikből lényegében 1 fajta készül, aztán letiltogatnak a funkciókból a kisebbik modellekben. Lényeg a lényeg, hogy amíg nem ismerjük a belső felépítést, addig sajnos az ilyen adatok, mint amiket a különböző méretű SSD-k átvitelénél kapunk, sok következtetésre nem engednek jutni - azon kívül, hogy nyilván több párhuzamos pipeline/busz dolgozik. Ennél többre nem. Nemcsak a tömörítéssel kapcsolatban nem, hanem pl. azt sem nagyon tudjuk, hogy milyen algoritmussal optimalizálják az írást a kisebb ill. nagyobb meghajtókon. Arra gondolok, hogy az újraírás ugye több ciklusos - előbb törölni kell -, namost, hogy mit tesz egy vezérlő ha van üres és van törlendő egység is, hogyan "optimalizál" közöttük, arról sincs fogalmunk. Egyet tudunk csak: minden tömörítési algoritmus időt vesz igénybe, ezért bármilyen adat-transzerbe épülő algoritmusra igaz (nem csak SSD/háttértárnál, hanem különböző protokollok esetén is is), hogy van egy "határpont", ami alatt a tömörítés növeli az adatátviteli kapacitást (mert a tömörítés kevesebb időt vesz igénybe, mint a tömörítetlenül átküldött és a tömörítetten átküldött adatmennyiség különbségének időigénye), míg efölött megfordul a történet. Az tisztán látszik, hogy a random (lényegében tömöríthetetlen) adatoknál a Sandforce vezérlő már megszenved, jelentősen esik a sebessége. Általános használati körülmények között ez nem gond, mert ami veszik a réven, az bőven bejöhet a vámon (a jól tömöríthető fájloknál). De annak aki tipikusan eleve tömörített fájlokkal dolgozik, az jó eséllyel belefuthat abba, hogy a "határponton" innen kerül, és akkor már több veszik a réven.
[ Szerkesztve ]
Aki hisz a parajelenségekben, emelje fel a kezem!
-
Vasinger!
nagyúr
válasz janos666 #11337 üzenetére
Biztos, hogy kell mellé HDD, ez nem kétséges, lesz mellette egy 1 TB-os, mivel ez a munakeszközöm, erre is megy a letöltés, szeretem ha minden egy helyen van és nem kell minden héten menteni külső winyóra, ha meg valamire szükségem van, akkor megint külső winyó stb. Nyűg.
120-as bőven elég, csak progrmok futtatására kell, ami X év múlva sem lesz se több, se kevesebb. Háttértárnak természetesen HDD-t fogok használni.
A notiban egy i5-ös Ivy Bridge HT-s 3.1 GHz-es proci van, tehát cseppet se nevezhető gyengének, de nem a CPU-t érzem gyengének, hanem a winyót.
Persze amennyiben van használtan 250-es winyó egy új 120-as árában, akkor nyilván azt venném, de ezt kétlem, de ha tudsz mutatni, mutass.
Egyáltalán miket érdemes nézegetni a régiekből? Nincs azoknak még sok gyermekbetegségük amiket az új szériákkal javítottak?
-
Vasinger!
nagyúr
válasz janos666 #11339 üzenetére
Tehát, ha jól értem 120-as szegmensből hosszútávra legalább 3 év garival nincs jobb vétel a Samsu 840 Basic-nél 22 000 Ft-os árszegmensben?
Programok amik mennének rá igazából nem helyigényesek, de azért van közöttük 1-2 nagyobb, kb ezek lennének fent:
4 böngésző, Chrome elég terjedelmes lesz(kb. 3 GB), természetesten Office programok, C, C++, C#, Java fejlesztőkörnyezetek pl.: CodeBlocks, Visual Studio 2013, iTunes, zenelejátszók, NYÁK és digitális áramköröket tervező programok (ezek nem nagyok) és ami fontos az 1-2 linux virtuális gép, amit szintén innen indítanék, mert annak nagyon dobna a sebességén.Ha nincs érezhető különbség a pro és a sima között, akkor tényleg nem költenék rá feleslegesen.
Rendszerként természetesen Win 8 Blue megy majd rá.
[ Szerkesztve ]
-
peterk
senior tag
válasz janos666 #11342 üzenetére
Ez offtopic, úgyhogy próbálok rövid lenni: Azért vágtam ketté, mert ez elsősorban munkagép és így könnyebb menedzselni. Úgy van megoldva, hogy minden, a rendszerhez tartozó adat a c:\-n van, és minden személyes, munka és beállítás jellegű adat pedig a d:\-n. Olyan szintig, hogy pl. a profile-om is fizikailag a d-n van (a c-n egy softlink mutat a d-n levő mappára, így a windows "azt hiszi", hogy a c:\users\profil mappába ír, de az valójában a d-n van).
Namost a komplett d meghajtóra be van állítva egy folyamatos verzionált differential felhőbe mentés, így az adatokról azonnali offsite mentés van mindig. A c partícióról pedig készítünk egy komplett (sector by sector) partíció mentést abban az állapotban amikor az általunk használt szoftverek, fejlesztőeszközök mindegyike telepítve és konfigurálva van. Ez viszonylag ritkán változik - lényegében csak a szoftver update-ek érkeznek -, így elég ha 1-2 havonta csinálunk egy-egy új mentést a c-ről. Mindennek az a lényege, hogy akármilyen baj történik - legyen szó hardverhibáról, vagy a windows "elcsesződéséről" - , akkor hamar lehessen folytatni a munkát. Ezzel a módszerrel 30-40 percen belül visszaállítható egy teljes gép, és ott lehet folytatni a munkát ahol 40 perccel korábban abbamaradt.
Tudom, hogy felmerül a kérdés, hogy de miért pont így, hisz lehetne máshogy is, de erre hosszú lenne a válasz. Az itthoni NAS-omon - ami most éppen 12TB-os- nekem is egyetlen volume (partició) van, mert ennél ez a praktikus. De a munkagépemen nem, és az okok részletezése hisszú lenne. Mindenhol azt kell használni ami az adott körülmények között a legjobb. Légyszi hidd el, hogy megvan az oka, hogy a laptopomon miért ez a rendszer.
[ Szerkesztve ]
Aki hisz a parajelenségekben, emelje fel a kezem!
-
Bodor
veterán
válasz janos666 #25075 üzenetére
Ésszerű magyarázat nincs az árazásra, de ha 30K-ért szeretnél 120 GB-os SLC-s példányt, akkor vehetnél két 64 GB-osat, és RAID0-ba téve máris megkapod a 120 GB-ot. Ráadásul ha nem makkan meg valamelyiknek a vezérlője, akkor annyit írhatsz rájuk, amennyit nem szégyellsz.
(#25081) windlord: Veheted, mert jó , bár nem tudom hol kapsz még újat.
Garancia nélkül meg nem venném.[ Szerkesztve ]
-
djculture
félisten
válasz janos666 #25120 üzenetére
Ez ugye mindig is igy volt hogy minél nagyobb méretű egy ssd annál több csatornába vannak rendezve a memória chippek. Azért is érdemes minél nagyobbat venni, meg a nagyobb több irási műveletet is képes elviselni ez is evidens. Viszont 4k-ban már elég sokszor a vezérlő a visszafogó tényező és ez esetben ezt a visszafogást a rad0 semlegesíti elég szépen. Különben akarok még kettő ilyet venni csak úgy próbából megnézni 4db mit muzsikál. 2db is elég durva már 4k-ban érezhetően.
FishAir: Minden attól függ mire használod én nekem nem pálya az slc és mlc sem mert audiot szerkesztek rengeteget, elmentés kivágás efekt beszúrás szerkesztés elmentés ... renegeteg irással jár. Viszont ssd meg kell, mert előtte egy 8-10 órás felvételt 2 óra alatt mentettem le és akkor még nem volt megvágva szerkesztve stb. Most a lementés 7 perc ugyhogy még előtte normalizálást is futtatok.
[ Szerkesztve ]
-
djculture
félisten
válasz janos666 #25124 üzenetére
Csináltam róla pár tesztet de nincs elmentve fejből emlékszem az adatokra, most meg éppen mással próbálkozom, szereztem jópár transcend 32 gigás ssd-t, abból kötöttem be eddig hármat raid0-ban, holnap meg a negyediket is kötetbe rakom. Adaptec 6805E vezrlőre fér rendesen 8darabot is tud kezelni raid0-ban.. Most telepitem a left4dead2-t és kipróbálom ennél mit tapasztalok, audió szerkesztés még gyorsabb az biztos.
[ Szerkesztve ]
-
djculture
félisten
válasz janos666 #25133 üzenetére
Azt is vedd figyelembe hogy mondom elég sokszor a busz kihasználtság az ami lassitja az adatfolyamot és 2 különálló sata busz mindig jobb mint egy
Ez az egész rendszer olyan mint egy nagy medencét tápláló vizvezeték hálózat , hiába van nekem az elején 4-8 tömlőm ha a közepén egy darab slaggal kötöm át az egészet. Persze ezt csak az tapasztalhatta ki aki már elég régen különböző raid megoldásokat használ a gépében.
Mondjuk erre megoldás mindenféle raid nélkül a direkt pciex csatis ssd, csak az még drága plusz az azt lekezelő alaplap/eszköz is.[ Szerkesztve ]
-
válasz janos666 #25208 üzenetére
Most nem tervezek 4-500 ezért gépet összerakni, volt de eladtam (abba Samu Pro volt 256GB)
Ez az SSD már megvan így ha jó akkor nem küldeném vissza, mert 30nap mire a nagyker visszautalja a pénzemL
◄►Clevo® X170SM-G "DTR" Laptop *i9-10900K @ 5GHz (AIO Water System)*4x16GB=64GB 3200MHz CL20 RAM*RTX 2080 Super 8GB MXM 200W+ *4x2TB=8TB M2 SSD -_- LG® V30+ ThinQ DS 4/128GB "Blue"►Samsung® S20 Ultra 5G◄SM E80 3.5mm Jack►"Szép, a kinek esze nincs, de még szebb, a kinek van."◄►
-
válasz janos666 #25212 üzenetére
Igen, ez már megvan és minőségi cucc, ez biztos korábban is volt 64GB és 256GB méretben ADATA mSata SSD-m (XPG Series) és nagyon meg voltam velük elégedve! A Samu Pro PC-be jobban pörgött mint pl. Y580 notiba az mSata, de ez érthető is! (elvártat hozza, talán még többet is)
L
◄►Clevo® X170SM-G "DTR" Laptop *i9-10900K @ 5GHz (AIO Water System)*4x16GB=64GB 3200MHz CL20 RAM*RTX 2080 Super 8GB MXM 200W+ *4x2TB=8TB M2 SSD -_- LG® V30+ ThinQ DS 4/128GB "Blue"►Samsung® S20 Ultra 5G◄SM E80 3.5mm Jack►"Szép, a kinek esze nincs, de még szebb, a kinek van."◄►
-
worxland
addikt
válasz janos666 #25284 üzenetére
És Te elhiszed, hogy az egyik tesztcsomagban (nem csak egy szintetikus vagy real life tesztben, hanem egy elméletileg különféle teszteket tartalmazó gyűjteményben - ami arra szolgálna, hogy a cuccok átlagos teljesítményét mutassa és ne csak az egyik értékét emelje ki) az egyik SSD 30-50%-al gyorsabb, mint a másik, majd egy másik hasonló célú, frissebb tesztcsomagban pedig 3x lassabb. Lelked rajta. Más portálok (pölö a Prohardver) másfajta tesztjein ilyen durva eltérések nem tapasztalhatóak az SSD-k között.
[ Szerkesztve ]
''It's difficult to work in a group when you're omnipotent.'' - Q
-
Új hozzászólás Aktív témák
-
HARDVERAPRÓD
(rögzített hozzászólás)
Köszönöm a türelmeteket, megszületett egy megoldás. A Flash topik a továbbiakban SSD kibeszélő néven fog tovább futni, így ott szabadabban lehet az SSD-ket kibeszélni, megosztani pozitívumot és negatívumot is.
Itt most elég sok hsz szüleletett, ami jobb lett volna oda. Ezeket már nem bolygatom, maradni fog, de kérek mindenkit, (a topik tisztasága miatt) hogy ezeket oda írjuk be ha lehet, vagy onnan linkeljük ide ha nagyon muszáj.
Köszi
[ Szerkesztve ]
- Tudástár Az SSD kondíciója, tények és tévhitek
- Tudástár Windows 7/8/10 SSD-vel! Hogyan is?
- Elemzés Milyen SSD-t vegyek?
- Elemzés Átfogó elemzés az SSD-k természetéről
- WD BLACK SN850P 2 TB M.2 NVME PCI-E 4.0 x4 - Új, Tesztelt - 7300-6600 MBs - Eladó!
- WD BLACK SN770 2 TB M.2 NVME PCI-E 4.0 x4 - Új, Tesztelt - 5150-4850 MBs - Eladó!
- SK Hynix Platinum P41 2 TB M.2 NVME PCI-E 4.0 x4 - Új, Tesztelt - 7000-6500 MBs - Eladó!
- RaidSonic IB-1823MF-C31 - Dobozos, újszerű
- Bontatlan Seagate & Western Digital HDD-k 3TB - 12TB -ig - Számla + Garancia, Ár alatt! BeszámítOK!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen