[c] FAT32 throughput verhogen

[elgringo]

Ik heb een low level fat32 driver geschreven voor een arm9 processor (deze zit in een sat receiver). Nu haal ik hiermee 1,8 mbit met fat16 4,8mbit.
Dit omdat fat16 clusters van 32K heeft en fat32 van 4k. Dit houdt in dat je elke keer naar een andere plek moet om 4k data te lezen. Zoals je begrijp zal dit met 32k veel sneller gaan.

ik moet fat32 nu sneller hebben en zat te denken aan een FAT cache (hier staat in welke cluster naar welke volgende cluster verwijst). Dit werkt nu maar ik heb op precies te zijn 0,05 Mbit winst. Waarschijnlijk omdat de USB drive ook zijn cache gebruikt en de I/O vertraging niet langzamer is dan mijn cache functionaliteit.

Wat is een een (of DE) mogelijkheid om dit sneller te krijgen. Alle functies zijn al goed geoptimaliseerd (natuurlijk nog niet optimaal maar veel beter dan voorheen)

[Soultaker]

Voor zover ik weet ondersteund FAT32 clusters groter dan 4k (tot ook 32k, geloof ik), voor grotere schijven. Ik weet niet of dit per se betekent dat de partities groter moeten zijn, of dat je ook kunt kiezen voor die grotere cluster size op een kleine partitie. Als ik me niet vergis kun je de cluster size met tooltjes als Partition Magic wel instellen, dus dat doet vermoeden dat de keuze door de gebruiker te maken is (al wordt de minimumgrootte natuurlijk bepaald door de grootte van de partitie).

[.oisyn]

vziw heeft Fat32 ook verschillende clustersizes... in kan het iig specificeren als ik met Partition Magic een schijf als Fat32 formatteer

.edit: spuit11 /.edit

ook kun je kijken of de huidige lees/schrijf positie al op de goede plek staat, zodat de overhead van een seek naar een plek waar ie al is (als dat er al is) wegvalt

[ Voor 5% gewijzigd door .oisyn op 01-05-2003 14:14 ]

[elgringo]

Clustersize van fat32 kan wel anders ingesteld worden, maar is niet de oplossign omdat juist windows hem zo klein mogelijk maakt, omdat meer voordelen (zou hebben). Tools zoals partition magic vallen buiten beschouwing omdat ik op een arm 9 werk.
Kijken waar de kop staat ik ook geen optie omdat dit niet mogelijk is.

Er moet iets komen om snel te lezen (een file dus) en te schrijven. Met schrijven kun je denken om meerdere clusters achter elkaar te zetten, maar met lezen niet (hier mag je niet vanuit gaan)

[Verwijderd]

Ik weet niet watvoor hardware je gebruikt maar deze zal een x aantal bytes tegelijk inlezen. Dan moet je je driver daar eigenlijk op afstemmen. Zo heb ik eens een FAT16 driver geschreven voor een embedded java device met een flashdisk, maar deze las dus in blokken van 2k bytes gegevens in en FAT gaat uit van 512 bytes sectoren. Misschien kan je hier nog wat in optimaliseren, met buffers e.d.

[elgringo]

Verwijderd schreef op 01 May 2003 @ 14:28:
Ik weet niet watvoor hardware je gebruikt maar deze zal een x aantal bytes tegelijk inlezen. Dan moet je je driver daar eigenlijk op afstemmen. Zo heb ik eens een FAT16 driver geschreven voor een embedded java device met een flashdisk, maar deze las dus in blokken van 2k bytes gegevens in en FAT gaat uit van 512 bytes sectoren. Misschien kan je hier nog wat in optimaliseren, met buffers e.d.

De hd die ik gebruikt (zoals elk had) heeft sector van 512bytes, hieraan kan ik niet veranderen. Ik lees en schrijven met een door derden geven (en snel werkende) low level read en write functie, deze kan per sector of per meer opeenvolgende sectoren lezen, maar geen sectorgrote van iets anders dan 512 bytes.

Als alles gedefragmenteerd zou zijn zou het simpel zijn, dus ik moet ik hebben waardoor je sneller opeenvolgend moet kunnen lezen (en schrijven)

[Verwijderd]

elgringo schreef op 01 May 2003 @ 13:58:
Dit houdt in dat je elke keer naar een andere plek moet om 4k data te lezen. Zoals je begrijp zal dit met 32k veel sneller gaan.

Eerlijkgezegd begrijp ik dat alleen als je filesystem dus sterk gefragmenteerd is... Anders geldt die logica niet, nee...

Dit kan bijvoorbeeld komen doordat jouw driver elke vrije cluster die hij als eerste tegenkomt meteen gebruikt voor nieuwe bestanden, dan kun je beter eerst zoeken of er verderop niet een stuk vrij ruimte is dat precies of minstens groot genoeg is... Zo voorkom je ook een beetje dat het flashgeheugen niet de hele tijd alleen aan het begin wordt beschreven, maar nu juist ook eens aan het einde wordt gebruikt...

Een grotere clustersize wil ook zeggen dat je meer "wasted space" hebt, je bent namelijk voor een configuratie bestandje van 100 bytes al meteen 32kb kwijt... Voor embedded dus over het algemeen wel zo nuttig om overhead zo klein mogelijk te houden...

Aangezien FAT32 32 bit i.p.v. 16, zou het natuurlijk ook heel goed kunnen dat juist het gebruik van 32 bits datastructuren de boel zo traag maakt... Scheelt het veel in codesize tussen de twee?

Ben je trouwens afhankelijk van FAT - door uitwisselingsmogelijkheden met PC o.i.d.- of zou je ook gerust een filesystem kunnen gebruiken dat niet zo snel fragmenteert?

[ Voor 5% gewijzigd door Verwijderd op 01-05-2003 14:52 ]

[Verwijderd]

elgringo schreef op 01 May 2003 @ 14:42:
[...]

De hd die ik gebruikt (zoals elk had) heeft sector van 512bytes, hieraan kan ik niet veranderen. Ik lees en schrijven met een door derden geven (en snel werkende) low level read en write functie, deze kan per sector of per meer opeenvolgende sectoren lezen, maar geen sectorgrote van iets anders dan 512 bytes.

Als alles gedefragmenteerd zou zijn zou het simpel zijn, dus ik moet ik hebben waardoor je sneller opeenvolgend moet kunnen lezen (en schrijven)

Ah, ik dacht dat je gebruik maakte van een ander soort device, flashdisk oid. Misschien is het een idee om je fat tabel vooruit te kijken of de volgende cluster achter de huidig gelezen ligt zodat je de hardeschijf niet opnieuw hoeft te laten positioneren. Maar ik weet niet in hoeverre dit mogelijk is bij hardeschijven (of deze altijd geherpositioneerd moet worden na elke lees/schrijf actie).

[elgringo]

Verwijderd schreef op 01 mei 2003 @ 14:49:
[...]

Eerlijkgezegd begrijp ik dat alleen als je filesystem dus sterk gefragmenteerd is... Anders geldt die logica niet, nee...

Dit kan bijvoorbeeld komen doordat jouw driver elke vrije cluster die hij als eerste tegenkomt meteen gebruikt voor nieuwe bestanden, dan kun je beter eerst zoeken of er verderop niet een stuk vrij ruimte is dat precies of minstens groot genoeg is... Zo voorkom je ook een beetje dat het flashgeheugen niet de hele tijd alleen aan het begin wordt beschreven, maar nu juist ook eens aan het einde wordt gebruikt...

Schrijven en lezen gaat met blokken van x Kb. Dus als je copieert weet je niet of hoeveel je gaat en moet schrijven (behalve dan die blokgrote), ik schrijf nu per 32K achter elkaar, maar je zal altijd in de fat moeten kijken waar de tweede opeenvolgende cluster is.

Een grotere clustersize wil ook zeggen dat je meer "wasted space" hebt, je bent namelijk voor een configuratie bestandje van 100 bytes al meteen 32kb kwijt... Voor embedded dus over het algemeen wel zo nuttig om overhead zo klein mogelijk te houden...

Aangezien FAT32 32 bit i.p.v. 16, zou het natuurlijk ook heel goed kunnen dat juist het gebruik van 32 bits datastructuren de boel zo traag maakt... Scheelt het veel in codesize tussen de twee?

De cpu is een 32-bits processor, ik denk dat het weinig uitmaakt.

Ben je trouwens afhankelijk van FAT - door uitwisselingsmogelijkheden met PC o.i.d.- of zou je ook gerust een filesystem kunnen gebruiken dat niet zo snel fragmenteert?

Het moet in FAT das de opdracht. Er stond een ander filesystem op (voor PVR en zendertabllen) welke clusters van 1mb las, maar dit filesystem was te simpel en had amper mogelijkheden, vandaar dat ze het op fat willen hebben, maar om op te kunnen nemen heb ik minstens 6 mbit nodig.

[elgringo]

Verwijderd schreef op 01 May 2003 @ 15:05:
[...]


Ah, ik dacht dat je gebruik maakte van een ander soort device, flashdisk oid. Misschien is het een idee om je fat tabel vooruit te kijken of de volgende cluster achter de huidig gelezen ligt zodat je de hardeschijf niet opnieuw hoeft te laten positioneren. Maar ik weet niet in hoeverre dit mogelijk is bij hardeschijven (of deze altijd geherpositioneerd moet worden na elke lees/schrijf actie).

per leesactie moet ie op gepostioneerd worden. Dus dan moet je al meerdere sectoren achter elkaar lezen/schrijven, de fat vooruitlezen is wel een optie, maar dit kan overbodig zijn. Als bijv. hierbij met een andere file wordt gewerkt

[Verwijderd]

elgringo schreef op 01 mei 2003 @ 15:20:
Schrijven en lezen gaat met blokken van x Kb. Dus als je copieert weet je niet of hoeveel je gaat en moet schrijven (behalve dan die blokgrote), ik schrijf nu per 32K achter elkaar, maar je zal altijd in de fat moeten kijken waar de tweede opeenvolgende cluster is.

Dan kun je toch ook 32kb in een keer wegschrijven naar 8x 4kb clusters

De cpu is een 32-bits processor, ik denk dat het weinig uitmaakt.

Dat zegt niks over de codesize en snelheid en jullie hardwareontwerp...

Het moet in FAT das de opdracht. Er stond een ander filesystem op (voor PVR en zendertabllen) welke clusters van 1mb las, maar dit filesystem was te simpel en had amper mogelijkheden, vandaar dat ze het op fat willen hebben, maar om op te kunnen nemen heb ik minstens 6 mbit nodig.

Jammer dat degene die deze opdracht bedacht heeft, zich niet eerst enigszins verdiept heeft in alternatieve filesystemen... Kwa snelheid en betrouwbaarheid zijn er wel betere keuzes te maken dan FAT...

Maar wat geldt het meest in jouw situatie, (relatief in processortijd):
* Wordt er veel of weinig gelezen?
* Wordt er veel of weinig geschreven?
* Veranderen de groottes van bestand sterk of amper?

En wordt alles veel sneller als je er een snellere harde schijf aan knoopt, of maakt dat niet uit? Het zou helemaal mooi zijn als je DMA kon gebruiken, maar je zei al dat de HD aansturing is ingekocht...

[elgringo]

Verwijderd schreef op 01 May 2003 @ 15:53:
Dan kun je toch ook 32kb in een keer wegschrijven naar 8x 4kb clusters

Wordt aan gewerkt

Dat zegt niks over de codesize en snelheid en jullie hardwareontwerp...

Codesize is iets groter, snelheid iets trager maar nooit erg veel (dirlistings etc. gaan evensnel). hardwareontwerp ligt vast: usb 1.1 harddrive, we gaan binnekjort met de interne ata66 drive testen, kijken of dat veel scheelt.

Jammer dat degene die deze opdracht bedacht heeft, zich niet eerst enigszins verdiept heeft in alternatieve filesystemen... Kwa snelheid en betrouwbaarheid zijn er wel betere keuzes te maken dan FAT...

Moest uitwisselbaar zijn met windows systemen, dan blijft er weinig over

Maar wat geldt het meest in jouw situatie, (relatief in processortijd):
* Wordt er veel of weinig gelezen?
* Wordt er veel of weinig geschreven?

Nu wordt er getest dmv een kopieeer actie. in praktijk zal het ongeveer 50% zijn: film opnemen later kijken, vervolgens wissen.

* Veranderen de groottes van bestand sterk of amper?

Nu testen we met bestanden van 10mb, in praktijk zullen dit bestanden worden van 1gb en groter (gehele mp2 films, 1gb per uur)

En wordt alles veel sneller als je er een snellere harde schijf aan knoopt, of maakt dat niet uit? Het zou helemaal mooi zijn als je DMA kon gebruiken, maar je zei al dat de HD aansturing is ingekocht...

DMA en usb gaan slecht samen..... Met het andere filesystem is er ooit 8mbit gehaald, bmaar wij hebben een extra driver laag ertussen: virtual file system, wat hem ook weer wat trager maakt. Als de doorvoersnelheid 6mbit is ben ik tevreden.

[Verwijderd]

elgringo schreef op 01 mei 2003 @ 16:10:
Codesize is iets groter, snelheid iets trager maar nooit erg veel (dirlistings etc. gaan evensnel).

Alleen de snelheid van de benodigde handelingen voor het wegschrijven en lezen zijn van groot belang: als die per chunk echt veel schelen, dan zou dat heel goed de reden kunnen zijn voor de lagere overdrachtssnelheid voor FAT32.

hardwareontwerp ligt vast: usb 1.1 harddrive, we gaan binnekjort met de interne ata66 drive testen, kijken of dat veel scheelt.

Was USB 1.1 niet max 12Mbit of zo? dan is 4.8Mbit een behoorlijk goed resultaat... Ik denk niet dat je zo gemakkelijk 6Mbit kunt halen hoor...

Moest uitwisselbaar zijn met windows systemen, dan blijft er weinig over

Hoezo, als je een usb-kabeltje naar je PC hebt, maakt het filesystem verder niet uit, als je maar data kunt overbrengen... Of moet je de schijf kunnen loskoppelen en aankoppelen aan een PC?

Nu wordt er getest dmv een kopieer actie. in praktijk zal het ongeveer 50% zijn: film opnemen later kijken, vervolgens wissen.

Lange tijden alleen maar schrijven dus, vervolgens aan een stuk door lezen. Misschien dat het een idee is om in rusttijd de aanwezige bestanden te defragmenteren? Daarna heb je dan een lange lap vrije schijfruimte waar je dan in een ker achter elkaar data in kunt pompen.

Nu testen we met bestanden van 10mb, in praktijk zullen dit bestanden worden van 1gb en groter (gehele mp2 films, 1gb per uur)

Dan heb je aan FAT16 niet genoeg, ondersteunt geen partitie groter dan 2Gb... Met deze groottes kun je gerust een flink grote clustersize kiezen, dus gewoon in een keer 32kb of meer in FAT32.

DMA en usb gaan slecht samen..... Met het andere filesystem is er ooit 8mbit gehaald, bmaar wij hebben een extra driver laag ertussen: virtual file system, wat hem ook weer wat trager maakt. Als de doorvoersnelheid 6mbit is ben ik tevreden.

Dat was ook via USB? Want dat vind ik behoorlijk knap moet ik zeggen... 8Mbit overdracht met een bandbreedte 12Mbit... D'r zitten natuurlijk geen andere aparaten op dat wel...
Ik ging er vanuit dat je direct via de IDE bus zou lezen en schrijven, dan is DMA ideaal, omdat je processor dan kan doorwerken terwijl de HD data voor je klaarzet en/of wegschrijft.

[elgringo]

Verwijderd schreef op 01 mei 2003 @ 16:48:

Alleen de snelheid van de benodigde handelingen voor het wegschrijven en lezen zijn van groot belang: als die per chunk echt veel schelen, dan zou dat heel goed de reden kunnen zijn voor de lagere overdrachtssnelheid voor FAT32.

Per 4K lees actie verschilt het weinig

Was USB 1.1 niet max 12Mbit of zo? dan is 4.8Mbit een behoorlijk goed resultaat... Ik denk niet dat je zo gemakkelijk 6Mbit kunt halen hoor...

Zoals ik al zei er is 8Mbit mee gehaald

Hoezo, als je een usb-kabeltje naar je PC hebt, maakt het filesystem verder niet uit, als je maar data kunt overbrengen... Of moet je de schijf kunnen loskoppelen en aankoppelen aan een PC?

Dat werkt nu ook al ja, maar dat is niet de opdracht

Lange tijden alleen maar schrijven dus, vervolgens aan een stuk door lezen. Misschien dat het een idee is om in rusttijd de aanwezige bestanden te defragmenteren? Daarna heb je dan een lange lap vrije schijfruimte waar je dan in een ker achter elkaar data in kunt pompen.

Is supplement opdracht. Defragmentatie is veel code er erg lastig, nu doet de windows bak dat

Dan heb je aan FAT16 niet genoeg, ondersteunt geen partitie groter dan 2Gb... Met deze groottes kun je gerust een flink grote clustersize kiezen, dus gewoon in een keer 32kb of meer in FAT32.

Klopt, maar er komen ooit ook pendrives, zipdrives, etc aan te hangen, voor bijvoorbeeld mp3, maar vooral voor films en ja dan kun je het beste grote clusters gebruiken.

Dat was ook via USB? Want dat vind ik behoorlijk knap moet ik zeggen... 8Mbit overdracht met een bandbreedte 12Mbit... D'r zitten natuurlijk geen andere aparaten op dat wel...
Ik ging er vanuit dat je direct via de IDE bus zou lezen en schrijven, dan is DMA ideaal, omdat je processor dan kan doorwerken terwijl de HD data voor je klaarzet en/of wegschrijft.

Dat gaan we volgende week testen

[igmar]

elgringo schreef op 01 May 2003 @ 13:58:
Ik heb een low level fat32 driver geschreven voor een arm9 processor (deze zit in een sat receiver). Nu haal ik hiermee 1,8 mbit met fat16 4,8mbit.
Dit omdat fat16 clusters van 32K heeft en fat32 van 4k. Dit houdt in dat je elke keer naar een andere plek moet om 4k data te lezen. Zoals je begrijp zal dit met 32k veel sneller gaan.

ik moet fat32 nu sneller hebben en zat te denken aan een FAT cache (hier staat in welke cluster naar welke volgende cluster verwijst). Dit werkt nu maar ik heb op precies te zijn 0,05 Mbit winst. Waarschijnlijk omdat de USB drive ook zijn cache gebruikt en de I/O vertraging niet langzamer is dan mijn cache functionaliteit.

Gewoon de gehele FAT tabel in geheugen lezen indien mogelijk. Een van de redenen waarom FAT zo traag is is dat je elke keer terug moet naar het begin van de disk om te kijken waar je het volgende blok data vandaan moet halen / neer moet zetten.

USB is overigens ook een bottleneck, USB 2.x is een stuk sneller. Gebruik je wel burst transfers in je USB driver ??

[/quote]
Wat is een een (of DE) mogelijkheid om dit sneller te krijgen. Alle functies zijn al goed geoptimaliseerd (natuurlijk nog niet optimaal maar veel beter dan voorheen)[/quote]

Je zou kunnen kijken in welke functies je de meeste tijd spendeerd. Vaak betekend dat fast-path optimalisatie en dingen op elkaar af te stemmen.

[Verwijderd]

elgringo schreef op 01 May 2003 @ 16:54:
Per 4K lees actie verschilt het weinig

het gaat hier niet om de kleine beetjes, dus zelfs als dat niet helpt voor de snelheid, moet je gewoon maximale blokken wegschrijven.

Is supplement opdracht. Defragmentatie is veel code er erg lastig, nu doet de windows bak dat

Defragmentatie is gewoon sorteren, het wordt wat moeilijker als je schijf bijna vol zit en je krijgt problemen als de stroom uitvalt bij FAT , maar voor de rest is en blijft het gewoon blokjes achter elkaar zetten op de juiste volgorde... Niks magisch.

Klopt, maar er komen ooit ook pendrives, zipdrives, etc aan te hangen, voor bijvoorbeeld mp3, maar vooral voor films en ja dan kun je het beste grote clusters gebruiken.

Dat zeg ik toch ook, grote clusters, en FAT32 omdat je anders niet meer dan 2Gb in een keer kwijt kan? Die twee dingen staan niet in verband verder, ook FAT32 kent clusters van 32kb...

En zet in elk geval niet de ATIME (als je dat al deed) en dat soort dingen, dat scheelt ook weer...

[elgringo]

igmar schreef op 01 mei 2003 @ 17:02:
[...]


Gewoon de gehele FAT tabel in geheugen lezen indien mogelijk. Een van de redenen waarom FAT zo traag is is dat je elke keer terug moet naar het begin van de disk om te kijken waar je het volgende blok data vandaan moet halen / neer moet zetten.
[...]
USB is overigens ook een bottleneck, USB 2.x is een stuk sneller. Gebruik je wel burst transfers in je USB driver ??
[...]
Je zou kunnen kijken in welke functies je de meeste tijd spendeerd. Vaak betekend dat fast-path optimalisatie en dingen op elkaar af te stemmen.

Ja daar wordt ook nog aan gewerkt

[elgringo]

Verwijderd schreef op 01 May 2003 @ 17:07:

En zet in elk geval niet de ATIME (als je dat al deed) en dat soort dingen, dat scheelt ook weer...

alle tijd en datums worden op 0x00 gezet, het systeem kent nml geen realtime klok.

En fat32 ondersteund officeel maar tot 32Kb clusters, en dat nog best klein als je toch alleen maar 2gb bestanden hebt....

[Soultaker]

elgringo schreef op 01 May 2003 @ 18:09:
En fat32 ondersteund officeel maar tot 32Kb clusters, en dat nog best klein als je toch alleen maar 2gb bestanden hebt....

Het idee is dat je je clusters zo klein mogelijk houdt om daarmee de verloren ruimte op de harde schijf (gemiddeld de helft van de clustersize per bestand) te minimaliseren. Om het probleem van het heen-en-weer-lezen op te lossen laadt een gewoon operating system gewoon de FAT in z'n geheugen en dan is er eigenlijk geen verschil meer (aangenomen dat de bestanden even gefragmenteerd zijn).

[Verwijderd]

elgringo schreef op 01 May 2003 @ 18:09:
En fat32 ondersteund officeel maar tot 32Kb clusters, en dat nog best klein als je toch alleen maar 2gb bestanden hebt....

Voor zover ik weet odersteunt FAT32 ook 64kb clusters... Kijk maar naar tools als partiton magic e.d. die ondersteunen allemaal clusters van 64kb voor FAT32... Ook de VFAT driver in de linux kernel ondersteunt dit, dus ik neem aan dat dat in elk geval bijna zo niet volledig officieel ondersteund is.

Maar aangezien je externe apparaten wilt gaan aansluiten, zou je je ook moeten gaan verdiepen waarom de snelheid zo laag is bij 4kb clusters... Kun je jouw code ook profilen om te kijken wat er nou precies zo veel tijd kost?

Als je de partitie tabel en FAT tabellen gaat cachen, is het misschien een optie om dit in non-volatile memory te doen, zodat de gecachede tabellen bewaard blijven... (mocht de stroom uitvallen)