[TCP/IP] Is de ECC nog wel toereikend (corrupte files)?

[TD-er]

Ik heb tegenwoordig vrij vaak last van corrupte files. (2 a 3 files/week)
Nu gaat dit vrijwel altijd om RAR- , zip-, .gz, BZ2 files en soms een vaag paars of groen blokje in een divxje, oftewel de gecomprimeerde files.
Ik heb al zitten denken aan de volgende dingen...
• dat het juist daar opvalt, omdat daar een foutje meteen zichtbaar is doordat de archiver klaagt over CRC-fouten of omdat je een foutje ziet in de film.
• gecomprimeerde files nagenoeg volledig random data bevatten (is niet verder comprimeerbaar) en zodoende een grotere kans hebben om juist die uitzonderingen aan data-sequenties te bevatten die in TCP headers gebruikt worden (zie Onderzoek naar onbrandbare bestanden bij Digit-Life )
• zelfde verklaring als hiervoor, maar dan dat er sommige combinaties van bitjes een grotere kans hebben om verkeerd ontvangen te worden. Bijvoorbeeld 10x een 1 kan gelezen worden als 9x een 1.
• we hebben ook thuis tegenwoordig zoveel TCP/IP verkeer dat het wel een keer mis moet gaan, statistisch gezien. (hier thuis heb ik het wel over in de orde van 100 GB per week aan intern verkeer, aangezien ik vaak zat files van 20 GB verwerk en de DVD-images over en weer vliegen tussen 2 computers)
• ik gewoon brakke hardware zou kunnen hebben.

Mocht het dus zo zijn, dat ik geen brakke hardware heb, dan zouden veel andere mensen er tegenwoordig ook wel eens last van moeten hebben.

De vraag is dan natuurlijk hoe groot is de kans dat een IP-pakketje fout is, maar niet als zodanig gezien is?
Is die kans te beïnvloeden door vrij kunstmatige files als RAR-files?
Is Gigabit gevoeliger voor storingen op dit vlak of zit er in de Gbit standaard al enige zekerheid hiervoor ingebakken, doordat ze op een lager niveau mischien een extra ecc-laag hebben? (ikzelf gebruik hier namelijk Gbit thuis)
Heeft IPv6 een uitgebreidere ECC, of in elk geval een kleinere kans dat fouten niet gezien worden?
Of zou mischien in een hoger liggende laag extra bescherming ingebouwd moeten worden, bijv in een (nieuwe versie van) SMB of NFS?
Of moeten we de files zelf voorzien van betere redundantie, waardoor de files groter gaan worden (zou een beetje onzinnig zijn, omdat elk medium een andere foutgevoeligheid heeft)

[DDX]

mja dat is dus gewoon :

>ik gewoon brakke hardware zou kunnen hebben.

mijn fileserver doet wel eens 5TB in een weekend aan traffic
maar dan vallen er echt geen bitjes om hoor....

[TD-er]

DDX schreef op 25 februari 2004 @ 17:31:
mja dat is dus gewoon :

>ik gewoon brakke hardware zou kunnen hebben.

mijn fileserver doet wel eens 5TB in een weekend aan traffic
maar dan vallen er echt geen bitjes om hoor....

Als jij 5TB in een weekend verstookt aan traffic, is de situatie dan mischien een lanparty? (of "computerfeestje" zoals mijn ouders het noemen als mijn broertje weer eens naar een toe is.)
Als ik kijk naar hoe mijn broertje daar met data omgaat... iedereen kopieert van iedereen. Oftewel jij zelf ziet dus niet of al die files correct zijn over gekomen.
Daarnaast wat doe jij als een film of een rar-file niet werkt? ik neem aan weggooien, of je er niet aan storen, of de file nog een keer kopieren, of mischien zelfs niet eens merken, dat doen anderen dus ook.
Kortom je weet dan niet zeker dat er geen fouten zijn opgetreden en de mensen op een lanparty zullen echt niet bij iedereen aankloppen dat die-en-die file corrupt is, temeer ook omdat niet op dat moment gekeken wordt of de file goed is overgekomen.

Ik ben hier de enige gebruiker tussen met name deze 2 computers en dus zal het mij hier sneller opvallen, dan op een lanparty-situatie.

[Henk007]

Ik denk dat er voorlopig niets anders opzit dan het zelf toevoegen van errordetectie en/of -correctie doormiddel van bijv een md5-hash owel Parchive par2 foutcorrectie.

[DDX]

TD-er schreef op 25 februari 2004 @ 17:57:
[...]

Als jij 5TB in een weekend verstookt aan traffic, is de situatie dan mischien een lanparty? (of "computerfeestje" zoals mijn ouders het noemen als mijn broertje weer eens naar een toe is.)
Als ik kijk naar hoe mijn broertje daar met data omgaat... iedereen kopieert van iedereen. Oftewel jij zelf ziet dus niet of al die files correct zijn over gekomen.
Daarnaast wat doe jij als een film of een rar-file niet werkt? ik neem aan weggooien, of je er niet aan storen, of de file nog een keer kopieren, of mischien zelfs niet eens merken, dat doen anderen dus ook.
Kortom je weet dan niet zeker dat er geen fouten zijn opgetreden en de mensen op een lanparty zullen echt niet bij iedereen aankloppen dat die-en-die file corrupt is, temeer ook omdat niet op dat moment gekeken wordt of de file goed is overgekomen.

goed ik kan dus niet voor alle data spreken
maargoed stel er zou corrupte data tussen zitten
dan zou ik van de paar honderd gb die aan 'nieuwe files' op mijn server gezet wordt een aantal gb corrupt moeten zijn ?
ik heb geen enkele corrupte rar file op mijn server....

ook thuis wel eens 800gb overgezet van 1 server naar andere server
ook dan geen enkele file corrupt

nee ik zou echt eens gaan kijken naar je hardware
heb je misschien een slechte netwerkkaart ? (ik gebruik enkel intel/3com hier)
of misschien cat4/5 kabel van tig meter waarover je gigabit probeert te pompen ?
(cat 5e is vereist voor gigabit, liever nog cat6 als het grote afstanden zijn)

[mvdejong]

Ik zou in eerste instantie je disks, disk-controllers en met name je bekabeling daarvan gaan verdenken.

[Skaah]

Geheugen misschien?

Als TCP een beschadigt pakketje ontdenkt, wordt er toch een verzoek uitgestuurd om het pakketje nog een keer te sturen? Enz. totdat het pakketje goed aangekomen is.

[Voutloos]

Skaah schreef op 25 februari 2004 @ 22:12:
Als TCP een beschadigt pakketje ontdenkt, wordt er toch een verzoek uitgestuurd om het pakketje nog een keer te sturen? Enz. totdat het pakketje goed aangekomen is.

Zeker weten.

Bovendien, TD-er, nofi, maar het is totale onzin dat 10x 1 een hoge error kans heeft. De synchronisatie is heel streng en derhalve kunnen bepaalde reeksen niet van invloed zijn.

Verder bestaan er in TCP geen 'uitzonderlijke/onhandalbare' data. Dit komt omdat in de header er een veld staat met de lengte. Dus de TCP layer kijkt helemaal niet naar de inhoud, op de CRC na dan.

[ Voor 3% gewijzigd door Voutloos op 25-02-2004 22:17 ]

[Verwijderd]

De hardware lijkt mij ook de hoofdverdachte. Kan je de bestanden ook eens op een andere machine downloaden? Het is natuurlijk weer een aantal gieg, maar je moet ergens mee beginnen.

[TD-er]

Dat van die 10x een 1 was maar een ideetje, ik heb namelijk niet echt een idee hoe het met Gbit electrisch gezien over de kabel gaat, maar ik kan me voorstellen dat wanneer je een 1 als hoog signaal stuurt en een 0 als laag signaal, dat je na een lange periode aan 1-tjes de zender en ontvanger niet meer in fase lopen. (het is maar een ideetje, niet schieten als het bagger is)

Maar goed, ik heb hier 2x Intel kaartjes, Gbit switch en gekochte FTP-kabels met afgeschermde connectoren, elk 2 meter.

Het is zeker nog steeds mogelijk dat mijn hardware bagger is, alleen is het zo enorm lastig na te gaan.
Geheugen is voor zover ik dat kan testen 100% OK (merkgeheugen) en de linux heeft nog nooit een kik gegeven op de fileserver.
Mijn werkbak is ook niet plat te krijgen, dus die beschouw ik ook stabiel.
Blijft over de VIA-chipset in de fileserver, het EXT3 filesysteem en het software matige RAID5. De CPU's aan beide zijden worden elk ongeveer 30, resp 40 graden @full load en zijn Intels en de IDEkabels zijn nergens gekreukt.
Ik verwacht niet dat dat RAID-algoritme lek is, ext3 heb ik ook redelijk vertrouwen in en de schijven/filesysteem in de werkbak spelen geen rol, omdat het bij de rar-file testen ook al bagger is.

Kortom, ik weet het wat betreft mijn hardware ook niet meer.
Mischien als ik ooit geld heb, dat ik een leuk serverboardje in de fileserver zet, maar dat zit er nog even niet in.

Vandaar dat ik dus voor wilde stellen een discussie te starten over wat er fout kan gaan over het netwerk.

een pakket kan gecontroleerd worden of deze goed is overgekomen, maar er kunnen natuurlijk ook pakketten tussen zitten die toch goed gekeurd worden, maar eigenlijk bagger zijn. Een heel simpel bewijs is dat de ecc-code van een pakket kleiner is dan het pakket zelf, dus er zijn meerdere pakketten mogelijk die dezelfde ECC-code hebben.
Hetgeen ik echter niet weet, is hoe groot is de kans dat een pakket ten onrechte geaccepteerd wordt?
en is die kans dus groter naarmate er gecomprimeerde files over het netwerk gaan?
De header is een deel van het pakket en als ik me goed herinner staat in de header hoe lang het pakket is. Wanneer de header corrupt raakt, kan dan ook niet de pakketlengte verkeerd worden weergegeven? Ik neem aan dat deze laatste mogelijk een stuk onwaarschijnlijker is, want ik neem aan dat er ook een ecc is van de header, of niet? (onwaarschijnlijker want header : ecc is een heel andere verhouding dan pakket : ecc)

Kortom, ik wil een schatting kunnen maken van hoe groot de kans is dat een pakket verkeerd over het netwerk gaat en toch geaccepteerd zal worden.
Daarnaast zou ik graag willen discussieren over wat er veranderd zou moeten/kunnen worden wanneer het dus redelijk aannemelijk te maken is dat er met het huidige verkeer 1 byte per dag verkeerd over kan komen.


Ik zal van de week mijn werkbak wel instellen als file-leacher onder linux ofzo.
Dan mount ik mijn fileserver wel via NFS en dan ga ik proberen om van een aantal files (40 - 50 GB ofzo) eerst op de fileserver de MD5 te berekenen en dan via het netwerk de MD5 te berekenen op de werkbak en dat achter elkaar en in een file opslaan. en dan de nacht erop andersom. Dan kan ik een schatting geven van hoe vaak het fout gaat en of er een richting is waarop het vaker fout gaat.

[TD-er]

Verwijderd schreef op 25 februari 2004 @ 23:15:
De hardware lijkt mij ook de hoofdverdachte. Kan je de bestanden ook eens op een andere machine downloaden? Het is natuurlijk weer een aantal gieg, maar je moet ergens mee beginnen.

Het komt niet alleen voor met gedownloadde files.
Ook files die ik zelf maak.

[LynXz]

TCP gebruikt een checksum van slechts 16-bit. In theorie zou dit goed genoeg moeten zijn voor het detecteren van (1-1/2^16) -> 99.9985% van alle fouten. Er zijn dus inderdaad fouten die niet gedetecteerd kunnen worden. De volgende fouten worden in ieder geval altijd herkent:

* een datapakket met 1 fout bit
* een datapakket met 2 foute bits
* een datapakket met een oneven aantal foute bits
* een datapakket met meer dan 16 foute bits

Dus als je pakket 4, 6, 8, 10, 12, 14 foute bits bevat kan het zo zijn dat 'ie goedgekeurt wordt terwijl die wel fout is!

Kijk eens naar het aantal *wel* fout gedetecteerde pakketen met /sbin/ifconfig
Als er uberhaupt geen foute pakketen gedetecteerd zijn (of heel weinig) word de kans dat er een onjuist pakket doorheen glipt wel heel klein!
En als er wel veel foute pakketten zijn: kabels testen? ander systeempje?

-EDIT-

Ethernet zelf gebruikt ook nog eens een 32 bits checksum (CRC-32), hiermee kan 99.9999% procent van alle fouten gedetecteerd worden. Dit is dus voordat een pakket door de tcp laag gaat.

Conclusie: er kunnen theoretisch fouten insluipen maar erg waarschijnlijk is dit niet!

[ Voor 15% gewijzigd door LynXz op 26-02-2004 01:44 ]

[Emmeau]

even terug naar de TS, dit soort zaken zijn al eerder voorbij gekomen, corrupte zipfiles, en in de meeste gevallen zover ik weet (alle?) was het brakke hardware, waarbij memory de grootste boosdoener was

[Verwijderd]

TD-er schreef op 25 februari 2004 @ 23:25:
[...]

Het komt niet alleen voor met gedownloadde files.
Ook files die ik zelf maak.

Dit riekt des te meer naar een hardware probleem.