"Nu stiu la hdd; la cdrom in mod date ai vreo 276 de octeti (nu biti) de ECC pentru fiecare 2048 de octeti de date, nu doar 32 de biti de detectie"
pentru ca la cdroame, inca de la aparatia lor s-a pus problema CORECTIEI de erori, nu doar a DETECTIEI. (re)vezi lectiile despre "coduri detectoare si coduri corectoare de erori". t. 2013/11/16 Dan Borlovan <d...@level7.ro> > > --- Prespunind ca ajunge corect acolo.Oricum, nu stim cit de bun este > > acel ECC (16bit, 32 bit...ce algoritm…) > > La mediile magnetice sau optice iti trebe un ecc destul de serios. Mai > ales la densitatea de informatie de acuma (c'mon, 6TB intr-un singur hdd cu > 7 platane… in alte epoci hdd-ul avea 10MB) > > Nu stiu la hdd; la cdrom in mod date ai vreo 276 de octeti (nu biti) de > ECC pentru fiecare 2048 de octeti de date, nu doar 32 de biti de detectie > > Ideea de aici e nu cit de "bun" e - in sensul cite erori poate corecta - > ci faptul ca exista un mecanism de _detectie_ a erorilor > > Pe noi ne deranjeaza silent corruption - erorile nedetectate - nu erorile > detectate > > Da in 18 ani in zona IT am vazut > - un hdd de desktop care corupea silent datele la scriere, banuiesc ca > memoria de pe el era defecta si nu avea mecanism de detectie a erorilor > - doua laptop-uri care corupeau datele de pe hdd, unul dupa ce bause > cafea/cola, celalalt posibil din cauza ca a stat prea mult pe patura la > caldurica > > Nimic voodoo / cabluri posedate / radiatii cosmice, doar defecte care duc > la coruptie de date in etape in care nu exista paritate/crc/ecc > > Dan > > _______________________________________________ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
