Es ist wieder so weit!
>INTEL-SA-00320, a.k.a. "CrossTalk", is the newest Intel side-channel CPU vulnerability.
Es ist wieder so weit!
>INTEL-SA-00320, a.k.a. "CrossTalk", is the newest Intel side-channel CPU vulnerability.
Meine Ergebnisse auf einem RS 2000 G9, hab mit einer 8GiB-Datei getestet.
ramdisk:
fio --randrepeat=1 --ioengine=libaio --direct=0 --gtod_reduce=1 --name=test1 --filename=test1 --bs=4k --iodepth=64 --size=8G --readwrite=randrw --rwmixread=75
test1: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.16
Starting 1 process
test1: Laying out IO file (1 file / 8192MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=1363MiB/s,w=453MiB/s][r=349k,w=116k IOPS][eta 00m:00s]
test1: (groupid=0, jobs=1): err= 0: pid=16549: Sun Jun 7 20:02:06 2020
read: IOPS=352k, BW=1377MiB/s (1444MB/s)(6141MiB/4461msec)
bw ( MiB/s): min= 1342, max= 1382, per=99.16%, avg=1365.06, stdev=12.71, samples=8
iops : min=343660, max=353868, avg=349454.88, stdev=3254.32, samples=8
write: IOPS=118k, BW=460MiB/s (482MB/s)(2051MiB/4461msec); 0 zone resets
bw ( KiB/s): min=458400, max=473104, per=99.16%, avg=466799.00, stdev=4478.31, samples=8
iops : min=114600, max=118276, avg=116699.75, stdev=1119.58, samples=8
cpu : usr=22.49%, sys=77.22%, ctx=516, majf=0, minf=7
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued rwts: total=1572145,525007,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=64
Run status group 0 (all jobs):
READ: bw=1377MiB/s (1444MB/s), 1377MiB/s-1377MiB/s (1444MB/s-1444MB/s), io=6141MiB (6440MB), run=4461-4461msec
WRITE: bw=460MiB/s (482MB/s), 460MiB/s-460MiB/s (482MB/s-482MB/s), io=2051MiB (2150MB), run=4461-4461msec
Alles anzeigen
--direct=0, weil tmpfs kein direct-IO kann.
SSD mit btrfs und Copy-on-Write (default):
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test1 --filename=test1 --bs=4k --iodepth=64 --size=8G --readwrite=randrw --rwmixread=75
test1: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.16
Starting 1 process
test1: Laying out IO file (1 file / 8192MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=186MiB/s,w=62.2MiB/s][r=47.7k,w=15.9k IOPS][eta 00m:00s]
test1: (groupid=0, jobs=1): err= 0: pid=16647: Sun Jun 7 20:05:22 2020
read: IOPS=42.4k, BW=166MiB/s (174MB/s)(6141MiB/37069msec)
bw ( KiB/s): min=54064, max=208424, per=100.00%, avg=176696.48, stdev=24672.54, samples=71
iops : min=13516, max=52106, avg=44174.13, stdev=6168.14, samples=71
write: IOPS=14.2k, BW=55.3MiB/s (58.0MB/s)(2051MiB/37069msec); 0 zone resets
bw ( KiB/s): min=19264, max=69616, per=100.00%, avg=59008.63, stdev=8223.45, samples=71
iops : min= 4816, max=17404, avg=14752.13, stdev=2055.88, samples=71
cpu : usr=6.93%, sys=77.11%, ctx=39333, majf=0, minf=10
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued rwts: total=1572145,525007,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=64
Run status group 0 (all jobs):
READ: bw=166MiB/s (174MB/s), 166MiB/s-166MiB/s (174MB/s-174MB/s), io=6141MiB (6440MB), run=37069-37069msec
WRITE: bw=55.3MiB/s (58.0MB/s), 55.3MiB/s-55.3MiB/s (58.0MB/s-58.0MB/s), io=2051MiB (2150MB), run=37069-37069msec
Alles anzeigen
Denke also nicht, dass man 2x RAM braucht, die Ergebnisse sprechen für sich.
Ich glaube wenn man viel benchmarkt wird IO auch gedrosselt, ist mir zumindest aufgefallen.
Hierbei ist unbedingt darauf zu achten, dass hinter der Option --size= die Dateigröße x 2 der RAM-Größe sein muß, da ansonsten nicht die IOPS der SSD, sondern die IOPS des RAM´s gemessen werden.
Macht das nicht schon --direct=1?
Zitat von man fiodirect=bool
If value is true, use non-buffered I/O.
Bei --rwmixread sollten übrigens double dashes sein
Das geht leider nur über die openssl.cnf: https://dawnbringer.net/blog/1…abs%20score%20for%20Nginx
Ein Patch für OpenSSL ist dafür offensichtlich nicht mehr notwendig!
Danke für den Link. Also ist ChaCha20-Poly1305 doch im Standard vorgeschrieben.
Der Grund ist folgender:
stress macht nichts anderes als
int
hogcpu (void)
{
while (1)
sqrt (rand ());
return 0;
}
(ich muss das so posten, weil die "Code"-Formatierung die Zeilenumbrüche frisst )
ist also sehr einseitig, während stress-ng eine breite Palette an Algorithmen hat um die CPU zu bearbeiten, die jeweils verschiedene Bereiche testen.
https://manpages.ubuntu.com/ma…cal/man1/stress-ng.1.html (unter "--cpu-method method")
Starte einfach
in einer tmux/screen-Session oder einer separaten SSH-Session und schau dann, was bei "top" in der Zeile "%Cpu(s)" neben "st" (steal) steht (ganz rechts). Das ist der Prozentsatz, den dir der Hypervisor stiehlt
Wie habt ihr beim Nginx die TLS1.3 Ciphers angepasst ?
Wie fallobst hier schon geschrieben hat, geht das Anpassen von TLSv1.3-Ciphers derzeit nur mit einem gepatchten OpenSSL:
https://forum.netcup.de/sonsti…A4ngste-thema/#post144591
Der normale lässt dich die Ciphers nicht anpassen, weil dazu eine neue API benötigt wird oder so, hab erst kürzlich darüber gelesen. Um Bei SSL Labs 100% zu bekommen, muss man 128-bit Ciphers deaktivieren, die aber im TLSv1.3-Standard vorgeschrieben sind - Die bessere Crypto mit ChaPoly ist soweit ich weiß nur optional!
Deshalb muss ich meine Aussage von vorhin korrigieren - gerade mit einer standardkonformen Config sind keine 100% möglich.
Nichts gegen Dich oder Deine Konfiguration, aber das wundert mich jetzt etwas, dass man damit 100% bekommt. Wenn mehrere Cipher unterstützt werden, die SSL Labs selbst als WEAK kennzeichnet…
Interessanterweise kann man sogar leicht Android 5/6 aussperren, obwohl Android 4.4 noch zugreifen kann. (Damit erreicht man dann aber logischerweise auch keine 100%.)
100% bekommt man nur, wenn man schlechtere, aber standardkonforme Crypto erlaubt.
Gibt es dazu [um Volllast zu erzeugen] ein "anerkanntes Tool" um "Vollast" zu erzeugen?
Besser: stress-ng
Bei einem meiner VPS wird die Speicheroptimierung nicht gestartet.
Sie bleibt beim ersten Punkt "Server wird gestoppt" hängen. Wenn ich auf einen anderen Menüpunkt in SCP klicke und dann wieder auf "Medien", erscheint wieder die normale Seite, die Speicheroptimierung ist verschwunden.
ASS wie viel steal hast du denn unter Volllast beim VPS 1000 G8 Plus?
[netcup] Felix P. Vielleicht könnte man die NFS-Storages ja einfach als separates Produkt anbieten?
Wo wir schon dabei sind, bitte auch Snapshot-Exports als separates Produkt und nicht an einen Server gebunden.
Alles anzeigenmeine Heizflosse hat heute ein großes Update von Android 9 auf Android 10 vollbracht
wer eine Ahnung, wie man des rot eingerahmte dazu bringt nicht mehr derart dominant angezeigt zu werden,
ohne es einzurichten?
ich will keinen Fingerabdruck und auch keinen anderen Hintergrund udgl.
Einfach seitlich wegwischen?
Wenn das nicht geht, würd ich mir ein anderes ROM drauftun das micht nicht so gängelt.
Was anderes, hab gehört du magst gern Heizflossen, hier hab ich tolle Heizelemente gefunden:
Mir gefällt openSUSE sehr, insbesodere das Rolling-Release Tumbleweed. Aktuelle Pakete und dennoch nie Probleme, die ich nicht selbst verschuldet habe
An Debian-basierten Distros finde ich viele Designentscheidungen fragwürdig, zum Beispiel dass jeder Serverdienst den ich installiere gleich automatisch aktiv ist (systemd vendor preset: enabled). Wozu ich einen unkonfigurierten Dienst laufen lassen wollte, weiß nur Debian...
Die VPS werden immer noch mit Debian 8 bereitgestellt, ich glaub ich spinn.
Zur Erinnerung: Debian 8 ist im Lebenserhaltungsmodus (LTS), in genau einem Monat (30. Juni) läuft auch dieser erweiterte Support aus.
Ich wage mal zu behaupten, dass sehr viele ihre VPS mit dem vorinstallierten System betreiben, und ich bezweifle stark, dass die alle vorher noch brav auf strech (9) und/oder buster (10) upgraden werden.
Der arme Typ war ein schönes Beispiel für "Befehle erst verstehen bevor man sie eintippt". Pinguin-Betriebssysteme können da erstaunlich schnell und grausam sein.
dd steht doch für Disk Destroyer. Name ist (wörtlich) Programm.
vmk du kannst auch Game of Life selbst in Game of Life emulieren, gibt auf YT Videos dazu. Komplett abartig
Du hast dann auch nicht das aktuellste FC nn
Was ist ein "FC nn"?
Nur als kleiner Hinweis für Jitsi Nutzer:
Jitsi scheint, wenn ein Update per z.B. apt kommt, alle Einstellungen und Änderungen in /usr/share/jitsi-meet/* mit den Standarddateien zu überschreiben.
Backup hat zwar geregelt, aber ich werde meine geänderten Dateien in diesem Verzeichnisjetzt mal mit chattr sichern - hoffe das schützt mich vor weiteren Verlusten.
Ist da nicht der Paketmanager schuld? Ich weiß nicht wie Debian/Ubuntu das machen aber wenn ich unter openSUSE eine Config bearbeitet hab, legt er die neue Upstream-Config unter program.conf.rpmnew ab. Mit rpmconfigcheck kann man überprüfen, ob es neue Config gibt.
Fedora/RedHat macht das auch so, ist ja wie openSUSE RPM-basiert.
https://www.linux.com/news/dealing-rpmnew-and-rpmsave-files/
Ich mache gerade auf einem alten RPi 1 eine Upgrade-Orgie von Wheezy auf Buster
Auf Jessie ist er schon mal, weiter geht's…
Raspi 1 ist echt eine lahme Krücke. Ich habe auch noch so einen im Einsatz, aber für den Verwendungszweck (pihole) reichts.
Wenn ab und zu mal ein Update der Pakete fällig ist solls von mir aus ruhig dauern, ich kann am PC währenddessen eh was anderes machen.
Komisch ..., gerade hab ich das auf einer Mailingliste aufgeschnappt ... [updates on shutdown]
ein weiteren Kommentar eines anderen über diesen Bug trifft den Nagel so richtig;
wenn ich da an Windows denke, was/wo sich die alles abgeschaut haben es und dann als Neus Feature verkaufen ...
Magst du verraten auf welcher Mailingliste? Weil bei mir hab ich so ein Verhalten unter Linux noch nie erlebt.