80% lägre prestanda med Veracrypt

Permalänk
Medlem

80% lägre prestanda med Veracrypt

Har nyligen köpt en QVO 8tb SSD, Den ska användas som sekondär hårddisk. Körde via crystaldiskmark 8.0.1 prestanda tester på den nyligen formaterad före och efter krypteringen.

Före kryptering hade jag dessa värden:
Read 4kQ32 228MB/s
Read 4k 40MB/s

Write 4kQ32 193MB/s
write 4k 103MB/s

Dessa är värden efter kryptering
[Read]
SEQ 1MiB (Q= 8, T= 1): 506.128 MB/s [ 482.7 IOPS] < 16536.88 us>
SEQ 1MiB (Q= 1, T= 1): 503.463 MB/s [ 480.1 IOPS] < 2081.94 us>
RND 4KiB (Q= 32, T= 1): 39.959 MB/s [ 9755.6 IOPS] < 3278.41 us>
RND 4KiB (Q= 1, T= 1): 19.793 MB/s [ 4832.3 IOPS] < 206.83 us>

[Write]
SEQ 1MiB (Q= 8, T= 1): 460.438 MB/s [ 439.1 IOPS] < 18155.78 us>
SEQ 1MiB (Q= 1, T= 1): 443.712 MB/s [ 423.2 IOPS] < 2361.89 us>
RND 4KiB (Q= 32, T= 1): 97.090 MB/s [ 23703.6 IOPS] < 1349.13 us>
RND 4KiB (Q= 1, T= 1): 67.200 MB/s [ 16406.3 IOPS] < 60.87 us>

Är detta normalt? 4kQ32 read har sjunkit över 80% från 228MB/s ner till 40MB/s, samt övriga 4k värden har också sjunkit rejält.

använde exFAT vid kryptering samt i windows partitionerade som GPT.

Permalänk
Medlem
Permalänk
Medlem

Mäter du verkligen lika, och på samma filsystem före och efter ?? - av hur noteringen är gjord så går det inte att avgöra då du inte har SEQ-mätningar på 1MB med i mätningarna före. Om dessa inte skiljer sig nämnvärt mellan före och efter veracrypt i sekventiell skrivning så är den större skillnaden av 4k-prestandan en effekt av mer overhead i någon kant. Om du mätte på NTFS innan formateringen och nu på exFAT så kan det vara en orsak till att 4k prestandan skiljer sig etc. - till detta är krypteringen i sig inte kostnadsfri utan käkar CPU-resureser även om Veracrypt är rätt bra optimerad ändå.

Men bortsett från detta så har du ett krypteringslager mellan och en overhead med flaskhals antingen i veracrypt i sig, i använda filsystem (exFAT) eller i lagret under mot disken via windows subsystem och tex, olika diskcache-hantering kan vara helt avgörande för faktisk prestanda och olika vid små eller stora skrivningar och hur länge det skrivs och ev kör slut på SSD-lagringens SLC-cache eller inte.

Sedan är inte exFAT värdens bästa filsystem då det är mer en transportfilsystem mellan enheter på samma sätt som ISO9660 på en CD/DVD-skiva, och faktiskt disketter där man har tappa allt rättighetshanteringen (avsiktligt eller oavsiktligt) än lagringsfilsystem tänkt för en OS som NTFS (den är i och för sig inte bra i jämförelse med moderna filsystem i Linuxvärlden - men bättre än exFAT i allafall).

Permalänk
Medlem
Skrivet av Svensktiger:

Japp, den verkar ha HW accel, det är Ryzen 7 5800x processor

Skrivet av xxargs:

Mäter du verkligen lika, och på samma filsystem före och efter ?? - av hur noteringen är gjord så går det inte att avgöra då du inte har SEQ-mätningar på 1MB med i mätningarna före. Om dessa inte skiljer sig nämnvärt mellan före och efter veracrypt i sekventiell skrivning så är den större skillnaden av 4k-prestandan en effekt av mer overhead i någon kant. Om du mätte på NTFS innan formateringen och nu på exFAT så kan det vara en orsak till att 4k prestandan skiljer sig etc. - till detta är krypteringen i sig inte kostnadsfri utan käkar CPU-resureser även om Veracrypt är rätt bra optimerad ändå.

Men bortsett från detta så har du ett krypteringslager mellan och en overhead med flaskhals antingen i veracrypt i sig, i använda filsystem (exFAT) eller i lagret under mot disken via windows subsystem och tex, olika diskcache-hantering kan vara helt avgörande för faktisk prestanda och olika vid små eller stora skrivningar och hur länge det skrivs och ev kör slut på SSD-lagringens SLC-cache eller inte.

Sedan är inte exFAT värdens bästa filsystem då det är mer en transportfilsystem mellan enheter på samma sätt som ISO9660 på en CD/DVD-skiva, och faktiskt disketter där man har tappa allt rättighetshanteringen (avsiktligt eller oavsiktligt) än lagringsfilsystem tänkt för en OS som NTFS (den är i och för sig inte bra i jämförelse med moderna filsystem i Linuxvärlden - men bättre än exFAT i allafall).

Gjorde om krypteringen med NTFS 4kb i Veracrypt, fick samma prestanda resultat, Dessa är med Veracrypt NTFS 4kb:

Veracrypt 4kb NTFS:
[Read]
SEQ 1MiB (Q= 8, T= 1): 505.153 MB/s [ 481.8 IOPS] < 16561.37 us>
SEQ 1MiB (Q= 1, T= 1): 503.481 MB/s [ 480.2 IOPS] < 2082.28 us>
RND 4KiB (Q= 32, T= 1): 39.672 MB/s [ 9685.5 IOPS] < 3302.31 us>
RND 4KiB (Q= 1, T= 1): 20.155 MB/s [ 4920.7 IOPS] < 203.11 us>

[Write]
SEQ 1MiB (Q= 8, T= 1): 459.078 MB/s [ 437.8 IOPS] < 18182.04 us>
SEQ 1MiB (Q= 1, T= 1): 440.515 MB/s [ 420.1 IOPS] < 2379.28 us>
RND 4KiB (Q= 32, T= 1): 97.652 MB/s [ 23840.8 IOPS] < 1340.49 us>
RND 4KiB (Q= 1, T= 1): 66.605 MB/s [ 16261.0 IOPS] < 61.39 us>

Windows 10 NTFS 4kb okrypterad disk:
[Read]
SEQ 1MiB (Q= 8, T= 1): 547.639 MB/s [ 522.3 IOPS] < 15285.75 us>
SEQ 1MiB (Q= 1, T= 1): 537.920 MB/s [ 513.0 IOPS] < 1948.71 us>
RND 4KiB (Q= 32, T= 1): 229.092 MB/s [ 55930.7 IOPS] < 571.10 us>
RND 4KiB (Q= 1, T= 1): 40.309 MB/s [ 9841.1 IOPS] < 101.53 us>

[Write]
SEQ 1MiB (Q= 8, T= 1): 483.327 MB/s [ 460.9 IOPS] < 17264.63 us>
SEQ 1MiB (Q= 1, T= 1): 473.972 MB/s [ 452.0 IOPS] < 2210.82 us>
RND 4KiB (Q= 32, T= 1): 193.384 MB/s [ 47212.9 IOPS] < 675.46 us>
RND 4KiB (Q= 1, T= 1): 103.152 MB/s [ 25183.6 IOPS] < 39.63 us>

Permalänk
Medlem

Då är det förmodligen någon extra overhead som är dominerande när veracrypt används vid random 4k-testet då det inte är dramatisk skillnad vid sekventiell skrivning/läsning och därmed ingen uppenbar tröghet i kryptering som trottlar.

att försöka ta reda på vilken och var overhead ligger någonstans i kedjan mellan programmet och när det skrivs mot disk är en annan femma...

Nu är konstant random 4K skrivning en väldigt syntetisk last som är intressant först vid aktiv databas med många transaktioner i sekunden (och/eller flera VM-maskiner med mycket aktivitet på var och en) och om disken skall vara backup-disk så är förmodligen sekventiell skrivning/läsning dominerande (dvs. att du flyttar hela filer i taget) och där har du inte tappat speciellt mycket prestanda.

tillägg: ser nästan ut som att veracrypt alltid skriver mot disken i Q1 och nyttjar inte parallella skrivköer för att det kanske hotar integriteten på den krypterade disken om man skriver fler parallella skrivningar i närheten av varandra då skrivordningen kan vara avgörande om sektorerna skall kunna läsas igen.

Permalänk
Medlem
Skrivet av xxargs:

Då är det förmodligen någon extra overhead som är dominerande när veracrypt används vid random 4k-testet då det inte är dramatisk skillnad vid sekventiell skrivning/läsning och därmed ingen uppenbar tröghet i kryptering som trottlar.

att försöka ta reda på vilken och var overhead ligger någonstans i kedjan mellan programmet och när det skrivs mot disk är en annan femma...

Nu är konstant random 4K skrivning en väldigt syntetisk last som är intressant först vid aktiv databas med många transaktioner i sekunden (och/eller flera VM-maskiner med mycket aktivitet på var och en) och om disken skall vara backup-disk så är förmodligen sekventiell skrivning/läsning dominerande (dvs. att du flyttar hela filer i taget) och där har du inte tappat speciellt mycket prestanda.

tillägg: ser nästan ut som att veracrypt alltid skriver mot disken i Q1 och nyttjar inte parallella skrivköer för att det kanske hotar integriteten på den krypterade disken om man skriver fler parallella skrivningar i närheten av varandra då skrivordningen kan vara avgörande om sektorerna skall kunna läsas igen.

Den främsta orsaken till att jag köpte denna disk var att ha mina installerade spel på den.
Tror att det ändå blir "ok" laddningstider på spelen, efter 10% hårddisk fylld så ligger 4KiB (Q= 1, T= 1): nere vid 17.8MB/s, Kanske blir märkbart långsam ifall den fylls till 90% men det återstår att se.

Permalänk
Medlem
Skrivet av joioi50:

Den främsta orsaken till att jag köpte denna disk var att ha mina installerade spel på den.

Skulle nog ta en funderare om det är värt med kryptering för spelinstallationer.

Permalänk
Medlem
Skrivet av joioi50:

Den främsta orsaken till att jag köpte denna disk var att ha mina installerade spel på den.
Tror att det ändå blir "ok" laddningstider på spelen, efter 10% hårddisk fylld så ligger 4KiB (Q= 1, T= 1): nere vid 17.8MB/s, Kanske blir märkbart långsam ifall den fylls till 90% men det återstår att se.

varför skulle din disk med spel behöva vara krypterad? ser ingen större poäng med det iaf. intye direkt så att filerna till div spel innehåller koderna för att skicka en kärnvapenmissil direkt...

Skrivet av Bozzeta:

Skulle nog ta en funderare om det är värt med kryptering för spelinstallationer.

Permalänk
Medlem
Skrivet av joioi50:

Den främsta orsaken till att jag köpte denna disk var att ha mina installerade spel på den.
Tror att det ändå blir "ok" laddningstider på spelen, efter 10% hårddisk fylld så ligger 4KiB (Q= 1, T= 1): nere vid 17.8MB/s, Kanske blir märkbart långsam ifall den fylls till 90% men det återstår att se.

För spelfiler behöver du inte lägga på krypterad disk - då är det bättre att skapa en mindre veracrypt-kontainer på sagda disk för dina mer känsliga data och bara logga in där när det behövs.

Är det QLC-disk så hamnar du snabbt i flaskhals avseende hastighet när du skrivit 20-30 GB data kontinuerligt och SLC-cachen tagit slut i din SSD/NVMe - pausa kopieringen - vänta en stund (typ tio minuter en kvart) och prova igen i avseende 4K-testet, så är den förmodligen tillbaka till farten som innan.

En dagens SSD/NVME med QLC och SLC-cache beter sig liknande som en SMR-disk på snurrsidan när den tvingas skriva slumpmässigt positionerade sektorer - med till skillnaden att SSD/NVMe alltid hamnar i den här flaskhalsen efter ett antal GB skrivet och går långsammare än en laptop-snurrdisk oavsett random skrivning eller sekventiell skrivning, medans en snurrdisk med SMR kan skriva fort väldigt länge vid sekventiell skrivning och på vissa filsystem som BTRFS nästa aldrig når 'stoppet' medans med NTFS och många småfiler når 'stoppet' ganska fort - och det är inte så konstigt då NTFS när den skapar en fil i windows, skriver upp till 10 gånger på samma sektorer i $MFT med små modifikationer hela tiden även för en minimal fil på under 700 byte storlek, vilket dränerar raderade/lediga sektorer i disk-cachar oavsett om det är SSD/NVME eller PRM-cachen på en SMR-snurrdisk[1].

[1] tror ni inte på det? - ta SMART-värden på antal fysiskt skrivna sektorer på diskenheten, notera - kör en pythonsnurra som skriver 10 miljoner småfiler där man använder hashvärde som filnamn och hashvärdet igen som datainnehåll på filen, efter det, ta igen SMART och antalet fysiskt skrivna sektorer och räkna hur många fler sektorer som skrivits och ni kommer att finna att för varje ny fil så har det skrivits 10 kByte data i $MFT hela vägen fysiskt ut till disken trots att utrymmet som förbrukas är bara 1 kByte efteråt -- och slutligen gör det inte på din systemdisk då du kommer att förlora 10 GB av ditt diskutrymme som du inte kan få tillbaka på annat sätt än att göra ny filsystem på disken - allokerad utrymme för $MFT lämnas inte tillbaka när filer raderas - utrymmet (åter)används dock igen i $MFT när nya filer skrivs igen med 1kByte per fil - men hur ofta har man 10 miljoner filer på en lagring? - 1 miljon på sin höjd vilket ger att 9 GB efter testet är utrymme som aldrig kan användas igen för datalagring eller TRIM:as bort (för att ge mera sektorer att raderas i förväg till cache-poolen i SSD/NVMe) på disken innan en ny omformatering görs.

I linux skriver det faktiskt bara 1 kByte fysiskt per fil i NTFS vid samma test då den sektorcachar skrivningarna i RAM tills det bestämt sig vad den slutliga värde skall vara och sedan skrivs mot disken - men Paragons NTFS-driver i linux är seg som stryk med typ 1/10-del i hastighet med skapande av filer (faktiskt lika långsamt i windows så det kan vara algoritm-begränsat) i jämförelse med BTRFS och ext4 och arbetar enkeltrådad - vilket det verkar göra i Windows också men där är dolt och man måste räkna ut det baklänges på processorlaster och se vad som fattas i redovisningen. Jag gissar att windows har en tråd som just bara hanterar $MFT då den förmodligen inte är trådsäker medans tex. extension av filer ( == data över ~700 byte som inte ryms i $MFT) troligen kan hanteras flertrådat så länge bokföringen ( == uppdatera $MFT) körs i en tråd.