Új hozzászólás Aktív témák
-
harom.14
tag
Az adminisztrációs vektortábla problémájára nagyon egyszerű a magyarázat: inicializáláskor betöltődik egy RAM-ba, majd kikapcsoláskor - ha változott - visszaíródik. Gigabájtonként 4KB szükséges a vektortáblához, tehát neadjisten azonnali áramtalanítás esetén is elég egy kondi a kiíráshoz.
Az pedig, hogy ne csak százezerszer lehessen bekapcsolni, elkerülhető egy indirekcióval. Nem fog a teljesítmény rovására menni, mert csak az inicializáción lassít, de azon is teljesen elhanyagolható mértékben. -
Dare2Live
félisten
Ahogy látom ez az a dolog amit 100%ra csak az élet mond meg.
Majd egy 2év múlva megkell nézni a tapasztalatokat, addig ugyis min duplázodik az a kapacitás amit a mai ár feléért megkaphatunk és sebességben is lesz nemkis gyorsulás.
Nomeg vmi prg is remélhetőleg lesz addig, hogy csak a 99%ban használt dolgok legyenek rajta: Ne olyan fileok amiket vista/én 2évenként 1* használok. -
liksoft
nagyúr
Nem kell állandóan foglalt terület. Elég, ha a háttérben a blokkokat átmásolja jobban használt területre, és ezeket így fel tudja szabadítani. Vagyis az egyenletes kihasználtság jó algoritmus használatával megoldható, legfeljebb az elérési idő illetve átviteli sebesség változik meg kicsit hátrányosan. Ha nincs adatvesztés, ez elviselhető.
Nekem inkább a belső adminisztráció sérülése (ami tartalmazza a blokkok logikai helyét) okoz fejfájást. Szintén gond lehet, ha egy cella (blokk kisebb része) valamilyen okból "gyengébb". Ilyenkor az adatok másolása (részleges írásnál ugye a blokkot fel kell olvasni, kicserélni benne az írandó részt, és csak utána írható vissza) sérülhet. Ez egyszerű szektorhiba a winyónál. Itt nehezebben megfogható, hiszen ha nem detektálja a drive (tételezzük fel ilyen nincs) akkor a hiba "vándorol". Ez akkor a legrosszabb, ha a blokkadminisztrációt érinti. Ami ugyebár nem dobható ki az ablakon.
A SMART esetén meg szerintem kevés az az egyetlen adat. Jó lenne tudni a törlések számán túl a kizárt területek számát is. Hiszen enélkül nem is lehet megjósolni, mikor krepál majd be. Sőt, az adminisztrációs területre vonatkozó értékeket is jó lenne ha visszaadná. Meg hőmérséklet, meg működési idő, meg..... Vagyis már 8-10 SMART értéknél tartunk, pedig még végig sem gondoltam mi kellhet még. Vagy nem véletlenül hiányoznak ezek?
-
-
Male
nagyúr
Köszi!
Tehát a statikus adatokat áthelyezi, ezzel tényleg egészen jól kivédhető amit említettem.
A táblázatos felvetésemre viszont nem találom benne a választ.
A cikkben említett 1 millió írási ciklust nehezen hiszem el, ha a gyártók is 100.000-rel számolnak csak. (A Samsung legalábbis, a többi gyártónál nem néztem utána.)
#65: Pedig nem volt egy apró hozzászólás
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Nagyon jók ezek a számítások és fejtegetések, hogy mennyire jó is ez az SSD meg hogy mennyire nem jó is ez az SSD. De mostmár olyat szertnék olvasni, hogy: "Gyerekek, már egy éve megy napi 24 órában az SSD-m, és semmi baja!" vagy "Gyerekek, két hónapja van SSD-m és már csak fele használható."
Szóval egészen eddig a pillanatig csak találgatunk...
Mod.: Van egyáltalán a PH-n valaki, aki használ SSD-t?
-
Male
nagyúr
Szerintem meg nem változtat a lényegen... de ezen nem fogunk összeveszni, elgépeltem, van ilyen.
Biztos? Az épp foglalt blokkok is felülírhatóak, ha épp az a blokk volt kevesebbszer írva eddig?
Tegyük fel hogy amint megvan a 32GB-os SSD-m, felmásolok rá 20GB adatot, amit nem fogok letörölni a használat során (kedvenc zenéim, OS és programok nem változó filejai, stb). Máris csak 12GB-nyi területen oszthatja el az írásokat az elektronika... és itt vége is annak a szép képletnek.
A másik hiba, hogy eszerint a képlet szerint, ha akár csak egyetlen blokk jó még a tárolón, akkor még jónak minősül az SSD...
A másik a wear-leveling megvalósítása. Konkrátan nem tudom hogy oldották meg (aki tudja dobjon linket), de ahogy én gondolom: tárolni kell melyik blokkot hányszor írták eddig. Mindig az eddig legkevesebbszer írt épp üres blokkkot használja írás során. Ezzel maximális a hatékonyság, ellenben kell még egy táblázat a virtuális blokk cím -> fizikai cím konverzióhoz. Ebben viszont a fizikai cím mezők folyamatosan változnak. Rossz esetben az OS valamelyik virtuális címet nagyon gyakran írja, így az ehhez tartozó fizikai címet folyamatosan át kell írni. Így ez a terület elsőként fog kihullani... és már meg is van az adatvesztés, hiszen innentől nem tudni hol is van valójában az a blokk.
Persze ez is kiküszöbölhető, ha ezt a táblázatot rendszeresen áthelyezzük... ez viszont tovább növeli a költségeket és a késleltetést, hiszen minden kérésnél meg kell nézni azt is, hogy ez a fordító-tbálázat hol helyezkedik éppen el. -
Raymond
titán
"OK, nem cella, hanem blokk, nem fogalmaztam elég pontosan, de a lényegen ez nem változtat."
De valtoztat, ezen akadtam fenn
Blokk != Cella.MOD:
Tehat a wear-leveling hasznalata mellett ugy jo ahogy szamolnak:blokkok szama * blokkonkenti irhatosag = minimalis elettartam
Es ezzel en nem latok gondot.
-
Male
nagyúr
Átfutottam a másik cikket is, amit harom.14 linkelt.
A képletben itt is ezzel számolnak, bár kicsit bonyolultabban, több tényezőt figyelembe véve.
(Ami ráadásul ránézésre se jó, hiszen a számlálóban 1MB-os blokkokkal számol, míg a nevezőben a file méretnél nem kerekít fel egész blokk méretre... tehát pl 1MB-os blokk esetén 30 darab 30KB-os egymás utáni írást egy darab írási ciklusnak vesz elhasználódási szempontból.)
-
Male
nagyúr
"Do the math: 4 GB has 32,000 128k sectors x 100,000 R/W cycles. That is over 1.7 million writes a day for five years or 20 IOPS every second, 24 hours per day."
De harom.14 hszében is ez a számolás szerepel. Bár ott ő ebből visszafelé számol a blokkméretre.
OK, nem cella, hanem blokk, nem fogalmaztam elég pontosan, de a lényegen ez nem változtat.
Ha már linkelgetek, ezt is bedobom (nem neked): 5. oldal, Reliability. Szóval a friss Samsung SSD-nél is 100.000 írási ciklust adnak meg blokkonként.
-
Raymond
titán
"Ami átverős: Úgy számolnak, hogy van x cella, y ciklust bír egy-egy cella,tehát a tároló élettartama: x * y írás."
Idezt be legyszi azt a szoveget amibol ezt ertelmezted. Mert ilyet nem lattam sehol. Tobbek kozott az iras/torles mennyisege blokkonkent van megadva nem cellankent a flash taroloknal, de gondolom valahol mast lattalk egyebkent nem allitanad amit irsz ugyhogy megvarom a linket/idezetet.
-
Male
nagyúr
Az SLC cellákhoz most is 100.000 ciklust írnak. (Kingstone és Intel szövegeket néztem, mindkettőben ennyit említettek, mindkettő friss.)
Ami átverős: Úgy számolnak, hogy van x cella, y ciklust bír egy-egy cella,tehát a tároló élettartama: x * y írás. Ami azért elég félrevezető, egyrészt kérdéses, hogy az elektronika 100%-osan tudja megosztani az írásokat, a másik, hogy az összes cella tönkremeneteléig számolnak... márpedig egy felére csökkent méretű tároló azért már nem valami jó...
Köszi, hasznos volt saját tapasztalatot olvasni!
Kiváncsi vagyok hosszabb távon mi lesz... mondjuk 3 év múlva hol fog tartani (Addigra pár cella valószínüleg elhullik azért... nem írták, hogy mennyi tartalék van?), illetve hogy az admin terület hogy bírja majd.
Pár hónap múlva priviben megdobnál az "állással" és a fejleményekkel? -
Male
nagyúr
válasz
Jim Tonic
#46
üzenetére
Nem jelentettem ki, hogy szar... ha így látod, akkor valamit nagyon félreértettél. A kétségeimet fogalmaztam meg a flash alapú megoldásokkal szemben, és ehhez felvázoltam pár dolgot, hogy mi alapján gondolom így.
Te kijelentetted, hogy nincs ezzel semmi gond (tartósság), hiszen a katonaság is ezt használja. Valahogy nem látom, hogy alátámasztottad volna tényekkel, hogy ez szempont volt a katonai felhasználás során...
Megjegyzem én is írtam, hogy nem tartalmaz ilyen elektronikát a CF.
-
harom.14
tag
Sokan vannak, akik félve viszonyulnak az SSD-khez a limitált írási ciklusok száma miatt. Akartam róla írni egy cikkszerűséget, de időhiány miatt most csak egy fórumbejegyzés lesz.
Van egy cikk, amit ilyen témában emlegetni szoktak: SSD Myths and Legends - "write endurance".
Az említett cikben - és még sok más helyen is - azt mondják, hogy a maximális 100.000 írási ciklus csak régen volt (1997), a cikk írója (aki egyébként magyar) 2 millió írási ciklussal számol. Ezzel én egyáltalán nem értek egyet! A flash chipek adatlapjain nem szerepel ilyen szám (ha valaki talál ilyet, nyugodtan mutassa).Az Mtron SSD-inek adatlapján a következő szerepel:
"Endurance for 32GB capacity Mtron SSD: >140 years @ 50GB write/day
Note: 100,000 program erase cycles are guaranteed by manufacturer making flash memory."Ebből az első adat nem bír túl sok információval, majd visszatérek rá, de a lényeg a megjegyzésen van, miszerint a flash chipek, amikkel dolgoznak, 100.000 újraírást garantálnak. Ez az egyik ok, ami miatt nem valós a fent említett cikk. A másik probléma, hogy nem számol többletköltséggel, amit a fájlrendszerek adminisztrációja okoz. Túlságosan tökéletes környezetet vesz alapul, és az nincs megbecsülve sem, hogy ez mennyire tér el a valós esetektől.
Az Mtron honlapján szerepel egy másik megjegyzés is az idézett adattal kapcsolatban: "Sequential Write". Azaz a napi 50GB-al akkor lehet 140 évnél tovább húzni, ha ezt az adatot szekvenciálisan írjuk. Ez teljesen valótlan egy operációs rendszernél. Szóval a kérdés, vajon mennyire befolyásolja a random write ezt a számot? Úgy már csak 1 hónapig bírja? Vagy 130 év? Én az ezzel kapcsolatos adataimat szeretném megosztani veletek.
Idén januárban úgy döntöttem beruházok egy SSD-re, sok olvasgatás és fontolgatás után úgy döntöttem, hogy az Mtron MSD 6000 széria 32GB-os változatát fogom megvenni. A rendelés menetéről, garanciáról, árról, vámról meg ilyesmiről most nem beszélek, nem ezen van a hangsúly. Február 8-án érkezett meg, másnap kezdtem el használni: felparticionáltam, feltelepítettem rá a rendszeremet, programjaimat. Az megint egy más téma, hogy milyen élmény használni, de erről van sok infó a neten, akár videók is, szóval ebbe nem megyek bele. Pár nappal üzembehelyezés után kiváncsi voltam, hogy mit is szólt a kezdeti terheléshez. A leírások alapján a meghajtó támogatja a S.M.A.R.T-ot, viszont sajnálatomra egyik programmal sem sikerült rendesen kiolvasnom. Egy rendes vinyóra kiköpnek vagy 15 értéket, konkrét nevekkel, ebből az SSD-ből pedig egyetlen, a program számára ismeretlen változó olvasható ki.
Megnézve a meghajtó adatlapját rájöttem, hogy nincs itt semmi gond. Tényleg egy változót támogat csak, de pont azt ami nekünk kell: darabszámra pontosan a virtuális blokkok törlésének számát. Az adatlap alapján akkor használódik el teljesen a 32GB-os drive, ha ez eléri a 3200 milliót. Ugyanebben a dokumentumban szerepel a 100ezres szám is, ezzel leosztva azt kapjuk, hogy 32000 darab blokkból áll az SSD, azaz egy blokk 1 MB-os. Tehát ha mondjuk 100 darab byte-ot kell megváltoztatni, de azok szétszórva vannak, akkor az ugyanannyira használja el a "lemezt", mintha 100 MB-nyit írtunk volna. Viszont összefüggően akár 10ezerszer annyit (1 millió byte-ot) is lehet úgy kiírni, hogy azzal csak egyetlen blokkot töröl. Emiatt nagyon fontos kritérium a szekvenciális írás a gyártó által feltüntett adatnál.
Minden fizikai blokk összesen 100ezerszer írható, ez jóval kevesebb mint a 3,2 milliárd - itt jön be a képbe a wear leveling. Ugyanis az algoritmus célja, hogy az írásokat a teljes "felületen" elossza, így ha egy blokkot szeretnénk megváltoztatni, akkor valószínűleg az új érték már teljesen máshol lesz eltárolva. 1 fizikai blokk összesen 100ezerszer írható újra, de az algoritmus miatt és mivel sok ilyen blokk van, a virtuális blokkok törölhetőségének száma sokkal nagyobb lesz.
Bocsánat azoktól akit nem érdekelt az elmélet, de sok hülyeséget láttam már, úgy gondoltam tisztázom. Remélem valemennyire érthető volt.
Szóval nagyon örültem neki, hogy teljes pontosággal látható az SSD elhasználtsága. Amikor ezt először néztem, február 10-én, az érték 700ezer-valamennyi volt, nem jegyeztem meg. Aztán írtam egy kis progit ami logolja az értékét, hogy követni tudjam az "elhasználódás sebességét". Egy 1,39 GB-os avi rámásolásától 1800 valahánnyal növekedett az érték. Ebből két dolog szűrhető le:
- Tényleg 1 MB-os egy blokk mérete.
- Még szekvenciális írásnál is egész nagy az overhead, 400MB-al több "fogyott" a virtuális blokkokból, mint ideális esetben kellene.Ma már február 19-e van, azaz már 10 napja használom. Játszani nem játszottam a géppel, viszont dolgoztam: több gigás mysql adatbázissal, scratch-et használó photoshoppal, vinyódaráló visual c#-al, eclipse-el, nagy cvs checkout-ok... Közben megfordult rajta több HDTV minőségű film, sok avi, napjában többször hibernáltam (2GB memóriával), a swap nincs kikapcsolva, bár az NTFS last access time követése le van tiltva. A gépet minden nap használtam, 3-15 órát, és összeségében szerintem jóval komolyabban, mint egy átlagfelhasználó tenné. Na és akkor jöjjön pár konkrét adat:
2008.01.11. 01:32 779998
2008.01.13. 17:26 1049107
2008.01.15. 17:47 1190969
2008.01.17. 14:27 1470696
2008.01.19. 17:20 1678346Ez így elég nyers, szóval számoljunk egy kicsit. Tegyük fel, hogy innentől kezdve minden egyes nap annyiszor írok rá, mint az elmúlt tíz napban összesen. Akkor több, mint 5 évig ki fogja bírni. De ha nem használom, "csak" annyira mint az elmúlt napokban átlagban, akkor 50 év múlva fog csak elhasználódni. Számomra ez tökéletesen megfelel, jóval több, mint amit vártam tőle.
Azt azért szeretném megjegyezni, hogy nem egy ócska SSD-ről írtam, az Mtron egy elég komoly márka a témában. És azt sajnos nem tudom, hogy melyik más márka termékeinél lehet még hasonlóan kiolvasni az írások számát, de nem hinném, hogy mindegyiknél.
-
OK, akkor most mutass konkrét bizonyítékokat arra, hogy ez az egész probléma, amiről beszélek nem létezik.
Ez már a vicc kategória. Valamire kijelented hasból, hogy szar. De nem azt kell bebizonyítani, hogy az, hanem azt, hogy nem. Kitalálsz egy tézist, majd bizonyítás helyett azt kéred, hogy cáfolják meg. LOL. Itt le is zártam ezt a vitát.Megjegyezném egyébként neked érdekességnek, hogy sem a CF, sem a vincseszter nem tartalmaz olyan vezérlőt elektronikát, ami arra figyelne, hogy egyenletesen legyenek a tárolók (direkt írom így) használva. Így az, hogy milyen a CF vagy 10^15-en a merevlemez, ebben a vitában teljesen irreleváns.
-
Male
nagyúr
OK, ez még nem volt az... de a hangnem igencsak érdekes volt...
Aha, persze
Miben is nincs igazam? Cáfolj valamit, amit tényként állítottam... aztán folytatjuk.Nekem mit is kéne alátámasztanom? Szeretném ha kiemelnéd azokat az általam itt tényként állított dolgokat, amik mögé érveket kéne felsorolnom, és megteszem.
-
orbano
félisten
ez nem személyeskedés, mert nem hülyéztelek, vagy akármi ilyesmi. ha magadra veszed az legfeljebb azért lehet, mert tudat alatt érzed, hogy nincs igazad
. valamint én nem közöltem "tényeket" és nem foglaltam állást egy olyan témában, amihez közöm sincsen. talán olvass vissza, megláthatod, így volt. ezen oknál fogva nem szükséges semmit sem alátámasztanom. -
Male
nagyúr
OK, akkor most mutass konkrét bizonyítékokat arra, hogy ez az egész probléma, amiről beszélek nem létezik.
Amiket írtam, azok nagyrészt feltevések valóban... azért azok, mert nincs bizonyítékom... de ha neked van az ellenkezőjéről, szívesen fogadom.
Annyi biztosan van róla, mint neked... de tán nem kéne személyeskedni
-
Male
nagyúr
válasz
Jim Tonic
#39
üzenetére
Persze... de az nem épp átlagfelhasználás. (nálam is le van tiltva)
CF-re és Penre tettem OS-t (WinMe), de az nem SSD. Megkérdezhetsz bárki mást is, aki ilyet csinált, hamar megdöglenek tőle. (Linuxszal illetve WinXP Embedded-del ez kiküszöbölhető, de egyik sem egy átlagos otthoni felhasználás, azthiszem ebben egyetértünk)
Vélemény volt, amit írtam, nem közöltem tényként, hogy márpedig x ideig bírja csak, stb. Több okból sem szimpatikus számomra ez a nagy SSD mánia (Nagyon nyomják azokat az előnyöket, amik otthon szerintem egyáltalán nem jelentősek.. pl a nincs benne mozgó alkatrész... egy asztali gépnél ez ugyan mit számít?).
Konkrétan SSD-t nem teszteltem... de szerintem te sem. Így aztán te sem tudsz semmi konkrétumot mutatni.
Amiből ki tudok indulni: írási ciklus 100.000 körüli értékek, max 1.000.000 amit eddig adatlapon láttam. Vinyón ha jól tudom ez 10^15 körül van (Már régen néztem, had ne kelljen most ilyet előkeresnem). Azért ez jópár nagyságrend eltérés nem?
A marketing anyagban mindenhol azt írják, hogy jól bírja... ehhez képest a kutatásaik valamiért pont a korlátozott írási ciklus növelése irányába mutatnak. Ha minden rendben lenne vele, akkor miért is ez a fő céljuk?
Ha ez nem probléma, akkor miért is kell drága-bonyolult áramköröket alkalmazni az írások elosztására flash esetén? (Azthiszem Liksofttól származik: ezzel meg az a gond, hogy ehhez egy táblázatot használnak, amit szintén flashben tárolnak... és pont ez lesz az a terület, ami majd elszáll, és búcsút inthetünk az adatainknak.) -
tbs
addikt
válasz
Jim Tonic
#39
üzenetére
Az Asus Eee kézikönyvében benne van, hogyan kell rá XP-t installálni. És benne van az is, hogyan kapcsolj ki ezt-azt (swap, indexelés, recovery, +pár apróság), hogy tovább tartson az SSD-je...
WinXP-s CF-kártya halált már láttam. ~2 hónap 24/7. SanDisk Extreme IV, 2G, csupaszított winXPSP2. SanDisk cserélte azért...
-
Ha elég ramot teszel bele, nem kell a virtuális.
De még mindig nem válaszoltál: Van konkrét tapasztalatod meghibásodásról, vagy téziseket mutatsz be, és az alapján írsz le valamit? Mutass valami konkrétat, amivel alátámasztod a szavaid, és meggyőztél. Levegőbe beszélni könnyű. -
Male
nagyúr
válasz
Jim Tonic
#35
üzenetére
Nem. Azért hoztam fel, mert egészen más terület, más követlemények. Ezért nincs nagy jelentősége szerintem, hogy a hadsereg is használja.
Pár dolog még hozzá:
- a hadseregnek gyártott SSD valószínüleg nem egyezik meg a kereskedelmi forgalomba kerültekkel.
- nem hinném, hogy azt a Win XP-t vagy Vistát használják, mint mi... márpedig nem a netezés, office, játék nyírja ki a flash alapú tárolókat, hanem az OS. (az XP megállás nélkül cseszteti... nem véletlenül van az EWF... és még ot a virtuális memória is)#36: Egyszerűen jelenleg még nem bízom benne... ha meg olcsóbb lesz, akkor itt is jön a spórolás (néhány Pendrive esetén is mi volt... kihagyták a hibajavítást-detektálást, mert így nem volt erre elvesztegetett kapacitás, tehát csökkent a gyártó MB-onkénti költsége... az már más kérdés, hogy mennyi adatvesztést okozott).
-
Male
nagyúr
Ha belém akarsz kötni, akkor legalább értelmezd amit írtam, és azt is nézd meg, hogy mire...
Szóval első lépésben keresd ki hol állítottam azt, hogy fél évente le kell cserélni....
Csak megjegyeztem, hogy ott akár ez is megtehető, nem követelmény az, hogy 5 évig működjön, ezért rossz példa az, hogy a hadseregnek is megfelel.
Ennyi erővel a Hummer jó városi kocsinak is, mert a hadseregnek is milyen jól bevált
"kevésbbé sérülékeny, jobban bírja a szélsőséges helyzeteket és ezáltal biztonságosabban őrzi az adatokat"
Igen, ezek a valódi követelmények ott... és ez hogy kapcsolódik ahhoz, hogy meddig bírja normál használat esetén? Tökéletesen megfelel nekik, ha mondjuk fél évig garantáltan hibamentesen dolgozik... ezesetben félévente lecserélik. A lényeg csak az, hogy egym eghatározott időtartamig garantáltan megbízható legyen. -
harom.14
tag
Vegyél SSD-t és akkor a power gomb első megnyomása után is síri csönd marad a szobában.
Én sem viccelek, egy jobbfajta notinál (na persze nem egy gamer vagy asztalileváltóra gondolok) tényleg így lesz. Nagy élmény amikor úgy áll fel a rendszer, hogy egy mukk nem jön ki belőle, meg nem érzed azt az enyhe rezgést a csulód alatt, ahogy a vinyó pörög. Csak sajnos a dedikált videókarim miatt egy negyed óra múlva bekapcsol kicsit a venti. -
-
orbano
félisten
ezt hol álmodtad? vagy netán vannak konkrét papasztalataid hogy fél év múlva le kell cserélni egy ilyen meghajtót? a hadseregnél pedig valóban nem fontos az adatbiztonság, tényleg. áruld el, mi másért használnák, ha nem azért, mert kevésbbé sérülékeny, jobban bírja a szélsőséges helyzeteket és ezáltal biztonságosabban őrzi az adatokat?
-
.mf
veterán
Sajnos nem írnak dátumot, de a 0.12 és 0.16um adatok alapján nem mai az az oldal. A mai "alap" flash chipek 300-500e írást bírnak ki, de az ellenállóbbakra 1-5milliót is írnak a gyártók (tudom, a gyártók sokmindent mernek állítani..). Ezen felül a SSD-okon általános wear-leveling algoritmusok használata, meghibásodott cellák kivonása.
-
-
t72killer
titán
Nincsen szerencsétlen egy ennyire profi rendszerre optimalizálva
A játékbetöltések is elég heterogén képet mutatnak, 1 SSD-ből mindenki szépen profitál, a többiből már nem feltétlenül. Ez lehet annak is az oka, hogy nincs megfelelő párhuzamosítás, vagypedig más tényező lesz a szűk keresztmetszet (pl RAM, CPU sebesség) -
Thrawn
félisten
Nem Samsung, de SSD tesztek: Link Link
9 SSD RAID 0 -
tbs
addikt
Linux alatt bármilyen fájlrendszer jó a dologhoz ramdiszkes megoldással, kevés ram esetén JFFS, SquashFS a legjobb. JFFS nagy barát.
Win alatt mind az XP Embeddednek, mind a CE-nek van readonly lehetősége, sok ram kell hozzájuk. Normál WinXP-t butítani kell erősen, de a swap kikapcsolása elég 2-3 hónap 24/7-es működésre akkor is. (Tapasztalat.
Szintén embedded. WinXP Embedded a jó megoldás winhez. )Ja, bocs. Olvasni sem tudok.
Azért köszönöm a lehetőséget, hogy beleröfizhettem. Milyen rendszerek? Priv.? -
Male
nagyúr
Talán mert ott nyugodtan lehet cserélni félévente
Azért ezt is vedd figyelembe... meg azt is, hogy a hadsereg számára gyártott nem biztos, hogy azonos a piacival...A cikkhez: az elején azt írjátok, hogy a csatoló sávszélessége fogja vissza, de itt már SATA2-re cseréltek, és így gyorsabb lehet. Majd késöbb 100 MB/s ill. 80 MB/s sebesség van.... szerintem ezt igazán nem fogná vissza a SATA1 a maga 150 MB/s-os sebességével...
-
jasohn
tag
Akárki akármit mond a fejlődés megállíthatatlan,csak megfékezni lehet maximum!
Ez az újdonság annyira nem újdonság,mert már egy ideje létezett csak a kiskernek szállították nemrég.A technológia igaz még gyerekcipőben jár,ám nem kell elfelejtkezni arról,hogy vannak még hasonló újítások(pl.DDR2)amik nem nagyon akartak tetszeni a népnek,nem akarták befogadni és ma már szinte élni sem lehet nélküle!
Egy újdonság és mivel jól hangzik bizalom kell és kicsit hinni,hogy jó lesz!
Érdemes csak az előttem lévő hsz-t elolvasni
-
DarkByte
addikt
Mivel most nekem is aktuálisak a flash alapú meghajtók (embedded rendszert építek Compact Flash kártyával) ezért érdemes tudni hogy van már elég rég óta célfájrendszer illetve hardveres megoldás is arra hogy egy flash meghajtó élettartamát jelentősen meghosszabbítsák. A legalapabb a wear leveling ami nyílvántartja hogy melyik blokkot hányszor írták már életében és úgy irányítja át az írásokat hogy mindig a legkevésbé györtört blokkokra mennek a következő írások. Így az nem fordulhat elő hogy a vinyó eleje már meghalt a végét meg még sosem használtad. Átlagos használat mellett azért elég sokára fogsz így minden blokkot egymilliószor teleírni
És még ki tudja mi bújik meg a háttérben amiről nincsenek egyenlőre publikációk, hiszen kulcsfontosságú üzleti titkok. -
JoeYi
őstag
Hmm, az slc chipek 100e műveletet bírnak ki. Ez egy pendriveon jónak hangzik, de egy merevelemz esetében igencsak kevéske. Nem egy biztonságos megoldás.
-
#1
Thulcandra
senior tag
Thulcandra
senior tag
A címben javítsátok már a 64 mb -ot gigabájtra
Egyébként meg köszönöm még mindig nem kérek ilyet
![;]](http://cdn.rios.hu/dl/s/v1.gif)
. valamint én nem közöltem "tényeket" és nem foglaltam állást egy olyan témában, amihez közöm sincsen. talán olvass vissza, megláthatod, így volt. ezen oknál fogva nem szükséges semmit sem alátámasztanom.
A 9 SSDnél a RAID vezérlő a szűk keresztmetszet... LoL 
Azért köszönöm a lehetőséget, hogy beleröfizhettem. 
Új hozzászólás Aktív témák
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- sziku69: Fűzzük össze a szavakat :)
- Elektromos autók - motorok
- DUNE médialejátszók topicja
- Milyen billentyűzetet vegyek?
- A lapkakészlet és az akku különbözteti meg a Motorola Edge 60 és Edge 60 Pro-t
- BMW topik
- Xbox Series X|S
- Counter-Strike: Global Offensive (CS:GO) / Counter-Strike 2 (CS2)
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- További aktív témák...
- Lexar NM790 2TB M.2 NVME PCI-E 4.0 x4 - Új - 7400-6500 MBs - Eladó!
- Lexar NM1090 PRO 4TB M.2 NVME PCI-E 5.0 x4 - Új - 14.000-13.000 MBs - Eladó!
- 100/100 WD Blue SN570 1 TB M. 2 NVMe SSD
- Crucial P310 2TB M.2 2230 NVME PCI-E 4.0 x4 - Új - 7100-6000 MBs - Eladó!
- WD SN8000S 4TB M.2 2280 NVMe SSD Gen4 7300-6800MB/s
- Xbox Game Pass Ultimate előfizetések kedvező áron
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Telefon felvásárlás!! Samsung Galaxy S23/Samsung Galaxy S23+/Samsung Galaxy S23 Ultra
- ÁRGARANCIA!Épített KomPhone i9 14900KF 32/64GB DDR5 RAM RX 9070 XT 16GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest