c + + - usb disk skrive latency (windows)

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg skriver til USB-disk fra en lavest prioriteret tråd, ved hjælp af chunked buffer skrivning og stadig, fra tid til anden systemet i overordnede lag på denne operation. Hvis jeg kun deaktiverer at skrive til disk, fungerer det fint. Jeg kan ikke bruge Windows-filoperationer API-opkald, kun C-skriv. Så jeg troede måske, at der er en WinAPI-funktion til at tænde/slukke USB-disk skrive caching, som jeg kunne bruge i forbindelse med FlushBuffers eller lignende alternativer? Antallet af drev til operationer er udefineret.


Ideelt set vil jeg aldrig ligge ved hjælp af skriveopkald og caching, hvis det bliver udført, er det også okay.


EDIT: vil \_O\_SEQUENTIAL flag på skrive kun operationer være til nogen nytte her?

Bedste reference


Prøv at reducere I/O-prioritet for tråden.
Se denne artikel: http://msdn.microsoft.com/en-us/library/windows/desktop/ms686277(v=vs.85).aspx
Brug især THREAD\_MODE\_BACKGROUND\_BEGIN til din IO-tråd.
Advarsel: Dette virker ikke i Windows XP [6]

Andre referencer 1


Trådprioriteten har ikke påvirket forsinkelsen, der sker ved at skrive medierne, fordi den er lavet i kernel-tilstand ved hjælp af filsystem/diskdrivere, der ikke tager højde for prioriteten for kaldetråden.


Du kan prøve at bruge 'T' -flagget (\_O\_SHORTLIVED) og skyll bufferne i slutningen af ​​operationen, og forsøg også at reducere bufferstørrelsen.

Andre referencer 2


Der er forskellige typer dataoverførsel til USB, for data der er 3:
1.Bulk Transfer,
2.Isochronous Transfer, og
3.Interrupt Transfer.



  1. Bulkoverførsler giver:


    Used to transfer large bursty data.
    Error detection via CRC, with guarantee of delivery.
    No guarantee of bandwidth or minimum latency.
    Stream Pipe - Unidirectional
    Full & high speed modes only.
    


    Bulkoverførsel er god for data, der ikke kræver levering i en garanteret tid USB-værtskontrollen giver lavere prioritet til masseoverførsel end de andre typer overførsler.

  2. Isokrone overførsler giver:


    Guaranteed access to USB bandwidth.
    Bounded latency.
    Stream Pipe - Unidirectional
    Error detection via CRC, but no retry or guarantee of delivery.
    Full & high speed modes only.
    No data toggling.
    


    Isokrone overførsler forekommer løbende og periodisk. De indeholder typisk tidsfølsomme oplysninger, såsom en lyd- eller videostrøm. Hvis der var en forsinkelse eller forsøg på data i en lyd stream, så ville du forvente nogle uregelmæssige lyd indeholdende fejl. Slaget kan ikke længere synkroniseres. Men hvis en pakke eller ramme faldt igen og igen, er det mindre sandsynligt, at det bliver lyttet til.

  3. Afbrydelsesoverførsler giver:


    Guaranteed Latency
    Stream Pipe - Unidirectional
    Error detection and next period retry.
    


    Afbrydelsesoverførsler er typisk ikke-periodiske, små enheder 'initieret' kommunikation, der kræver afgrænset ventetid. En afbrydelsesanmodning er køet af enheden, indtil værten afstemmer USB-enheden, der beder om data.



Fra ovenstående ser det ud til, at du vil have en Garanteret forlængelse , så du skal bruge isokronøs tilstand. Der er nogle biblioteker, som du kan bruge som libusb, eller du kan læse mere i msdn [7] [8]

Andre referencer 3


For at finde ud af, hvad der laver dit system hænge, ​​skal du først bore ned til Windows-hængen. Hvad var Windows, mens du oplevede hangen?


For at finde ud af dette kan du tage en kerne dump. Sådan får du og analyser en Kernel Dump læs her. [9]


Afhængig af de resultater, du kommer derhen, skal du beslutte, om der er noget under din kontrol, du kan gøre ved. Da du bruger et tredjepartsbibliotek til at skrive, er der lidt, du kan gøre, undtagen for at indstille IO-prioritet, trådprioritet på tråd eller procesniveau. Hvis biblioteket du fik links til en specifik CRT, kunne du prøve at opbygge din egen tilpassede version af den til f.eks. skyll efter hver skriv for at forhindre skrivekombination af operativsystemet til kun at skrive data i store klumper tilbage til disken. [10]


Edit1


Din bedste indsats ville være at skylle enheden efter hver skrivning . Dette kan tvinge OS til at skylle eventuelle ventende data og skrive den aktuelle afventning skriver til disk uden at cache skriveren op til et bestemt beløb.


Det næstbedste ville være at simpelthen vente efter hver skrivning for at give operativsystemet chancen for at skrive ventende ændringer, dog små tilbage til disken efter et bestemt tidsinterval.


Hvis du er dybere i performance, bør du prøve XPerf, som har en god GUI, og viser dig selv opkaldsstakken, hvor din proces hængte. Windows-teamet og mange andre hold hos MS bruger dette værktøj til at fejle hængeoplevelser. Den nyeste udgave med mange flere funktioner leveres med Windows 8 SDK. Men pas på, at Xperf kun virker på OS> Vista. [11] [12] [13]