Új hozzászólás Aktív témák

• #131 demagóg aktív tag #25583896 #128

  Új Válasz 2014-09-26 01:09:16 #131

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  demagóg

  aktív tag

  válasz #25583896 #128 üzenetére

  A wear-leveling is már agyon van optimalizálva a minél kevesebb írásra. Erősen függ a használt terület méretétől, az alkalmazás jellegétől. Általában igaz, hogy az algoritmus a "régi" fájlt (ami nekem persze, hogy régi, mert már régen nem módosítottam) pont emiatt teszi majd idővel egy leharcolt, fáradt területre (persze ezt én nem látom, ez a kontroller belső ügye). És ez meg azért nem lesz jó, mert a szerencsétlen szivárgó cella nem frissül, mert én a fájlt nem módosítom, a wear-leveling meg pláne nem akarja írni, kíméli a fáradt cellát. A cellák még egy chipen sem egyformák, nincs egységes paraméter, hogy egy adott cella mikortól válik túl használttá, hogy már ne nagyon legyen átírás mert az is egy élettartam korlát, de ha már elöregedett és pihen akkor milyen gyakorisággal kell mégiscsak átírni mert különben meg elszivárog a töltés (ami valójában mindkét irányú töltésáramlás lehet tehát szökhet befelé is, inkább tartalom torzulást kellene írni). Na és a felülírás: ha jön a megváltó felülírás akkor a wear-leveling döntése alapján akár újabb, friss másik cellába történik az írás vagy akár ugyanoda vissza, a jelszintek visszaállnak a rendes értékre (a töltésmennyiség valós tárolt biteket reprezentál). Nincsenek belső téves bitek, a hibajavításra nincs szükség, a tároló az eredeti gyári sebességen tud olvasni is nemcsak írni. Az írással való spórolás miatt ameddig az ECC biztonságosan tud javítani addig a kontroller (FW) nem forszírozza a blokk reallokálását.

  -De ez hogy lehet? ... Tegnap még működött! ...

Új hozzászólás Aktív témák