Posts by jah

  • zenbleed

    Quote from m_ueberall

    Wenn auf dem Host keine "EPYC Rome"-CPU zum Einsatz kommt, gibt es noch kein Microcode-Update von AMD, siehe hier. Und Netcup wird

    sicherlich keine eigenen Microcode-Updates einspielen. Allerdings hat Netcup eben auch vorgenannte CPU-Modelle im Einsatz. Details werden sie aber wohl eher nicht preisgeben. ;)

    Deinen Post verstehe ich nicht.

    • Hat netcup überhaupt nicht-Rome EPYCs im Einsatz (als VServer-Hosts)? M.W. gab es vor den aktuellen EPYCs (7702) nur Xeons.
    • Betroffen sind nach aktuellem Stand nur Zen2-CPUs (müßte also eigentlich eher zen2bleed heißen) und somit auch nur Rome-EPYCs.
    • Entsprechend brauchen nicht-Zen2-CPUs kein ucode-Update.
    • Warum sollte netcup keine ucode-Updates einspielen? Die sind offiziell und freigegeben. Bei gängigen Distributionen werden sie durch normale Paket-Updates eingespielt. (Natürlich sollte man vorher in so einer Umgebung entsprechende Tests damit machen, klar.)
    • Warum sollte netcup keine Details preisgeben? Gibt ja nur zwei Möglichkeiten, das Problem zu beheben. Aus dem zweiten Post von Christina kann man ja schon schließen, daß als erste Maßnahme das "chicken bit" gesetzt wurde und die ucode-Updates später kommen.
    Quote

    cpu-model: AMD EPYC 7452 32-Core Processor

    Was ist das für ein Server?

  • zenbleed

    ok, danke für die schnelle Reaktion. Der Test-Exploit wirft tatsächlich nichts mehr aus.


    Könnt Ihr sagen, wie das gefixt wurde? uC-Update wäre naheliegend, aber bei laufendem System wohl nicht einfach so machbar. Oder wurde erstmal nur das o.g. chicken-bit gesetzt?

  • zenbleed

    Hi,


    siehe zenbleed.


    Soweit ich sehe, sind die in den aktuellen Root-Servern eingesetzten EPYCs auch anfällig dafür. Gibt es Pläne, die Server zeitnah upzudaten?


    Grüße

    J

  • Minimale Linux-Distri für VPS 10 G7

    Quote from Paul

    Versuche es mal mit Alpine Linux (https://www.alpinelinux.org/).

    hm, das hatte ich eher als Cloud/Container-OS in Erinnerung. Hab's mal installiert, das "Virtual" Image hat gerade mal 40MB, war in weniger als 5 Minuten erledigt - rekordverdächtig! Und gerade mal 50 MB belegt... ok, mit paar Paketen dazu sind es jetzt 130 MB, aber das ist immer noch sehr wenig. Macht bis jetzt einen sehr guten Eindruck - also schonmal vielen Dank dafür!

  • Minimale Linux-Distri für VPS 10 G7

    Hallo zusammen,


    ich habe seit einiger Zeit einen VPS 10 G7, der wirklich sehr klein ist (128 MB RAM, 10GB HD), als secondary nameserver hat der mir aber immer locker gereicht. Leider ist bei einem Update neulich die Festplatte vollgelaufen (hatte nicht aufgepasst), so daß jetzt kein Kernel mehr drauf ist und er entsprechend nicht bootet. Leider bootet auch keines der im SCP verfügbaren DVD-Images oder das Rettungssystem (grml). Etwas befremdlich, aber auch nicht so wild, setzte ich die Kiste eben neu auf. (Ist wahrscheinlich schneller erledigt, als das irgendwie im snapshot zu fixen.)


    Hat jemand einen Tip, was man da nehmen könnte. Ich hatte damals Arch Linux installiert, das auch ganz gut lief (mußte nur ab und zu mal alte Pakete löschen, damit die Platte nicht volläuft), vor ein paar Monaten aber immer wieder hängen blieb, weil der Hauptspeicher voll war (hab dann einfach den Kernel so eingestellt, daß er in dem Fall neu startet).


    Hat jemand einen Tip für eine Minimal-Distri, die damit auskommen kann? Da läuft i.W. der Kernel, sshd und der nameserver (nsd), also nicht viel. Auf meinen Systemen hab ich sonst Fedora laufen, aber das dürfte viel zu bloated für diese Kiste sein...


    Grüße

    J

  • RS 1000 G9.5: unchecked MSR access error

    Hi!


    Ich habe vor ein paar Tagen meine Server-Installation von einem RS 1000 SSD G8 auf einen RS 1000 G9.5 umgezogen. Das läuft soweit auch problemlos, nur eine kernel-Meldung beim Start (die vorher nicht da war) verunsichert mich etwas:

    Das hängt wohl mit bestimmten CPU-Fähigkeiten bzgl. Spectre/Meltdown-Schutz zusammen, die evt. nicht freigeschaltet sind. Weiß jemand was dazu?

  • Routing 1&1 Versatel

    IPv6 sieht noch etwas komisch aus... in Richtung Versatel ok (die fehlenden Hops vor dem letzten liegen glaub ich an meinem DSL-Router):

    In Richtung netcup/Anexia noch etwas komisch, 20ms bis FRA ist normal bei meinem Anschluss, aber über 10ms von FRA nach NBG ist unüblich viel. Naja, jammern auf hohem Niveau, ist ja jetzt wieder viel besser!

    Code
    HOST: _________                                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- fritz.box (2001:16b8:245c:de00:de15:c8ff:febc:831c)             0.0%    10    1.2   1.4   1.0   2.6   0.5
  2.|-- 2001:1438::62:214:63:95                                         0.0%    10   18.8  17.5  13.7  22.3   2.6
  3.|-- 2001:1438:0:1::5:1f2                                            0.0%    10   11.6  14.3  11.6  25.3   4.9
  4.|-- 2001:1438:0:1::5:72                                            10.0%    10   34.3  22.8  18.0  42.8   9.2
  5.|-- ae3-1337.bbr02.anx25.fra.de.anexia-it.net (2001:7f8::a5e9:0:3) 10.0%    10   45.5  22.5  18.4  45.5   8.7
  6.|-- 2a00:11c0:47:1:47::140                                         10.0%    10   21.6  21.9  21.5  23.0   0.5
  7.|-- 2a00:11c0:47:3::21                                             10.0%    10   21.9  27.5  21.8  71.4  16.4
  8.|-- ____.__ (2a03:4000:28:________________)                        10.0%    10   33.4  33.6  33.1  34.4   0.4

  • Routing 1&1 Versatel

    Good news everyone! ^^

    Seit 12 Uhr sieht es wieder gut aus:

    pasted-from-clipboard.png

    Code
      1.|-- 94.16.112.2                                                 0.0%    10    0.5   0.4   0.3   0.5   0.1
  2.|-- ae3-4019.bbr02.anx84.nue.de.anexia-it.net (144.208.211.10)  0.0%    10   23.4   3.7   0.4  23.4   7.1
  3.|-- ae0-0.bbr01.anx84.nue.de.anexia-it.net (144.208.208.139)    0.0%    10    4.0   3.9   3.7   4.0   0.1
  4.|-- ae2-0.bbr02.anx25.fra.de.anexia-it.net (144.208.208.141)    0.0%    10   88.0  12.2   3.6  88.0  26.6
  5.|-- fra020isp005.versatel.de (80.81.193.80)                     0.0%    10    3.8   4.0   3.8   4.2   0.2
  6.|-- 62.214.38.173                                               0.0%    10   10.6  10.9  10.5  12.9   0.7
  7.|-- i59F4B4__.versanet.de (89.244.180.___)                      0.0%    10   21.9  22.0  21.7  22.5   0.2

    Support hatte vorgestern Abend gemeldet, daß das an die "entsprechende Abteilung" weitergeben wurde, heute morgen nochmal kurze Meldung. Na hoffentlich bleibt das so :saint:

  • Routing 1&1 Versatel

    Quote from frank_m

    Wird man das so einfach trennen können? IP-Adressen haben nicht unbedingt einen geografischen Bezug.

    Üblich ist m.W. immer noch hot-potato routing. D.h. man übergibt so früh wie möglich an den nächsten Provider.

    In diesem Fall (Peering in AMS und FFM, AMS ist für Client günstiger, FFM ist für Server günstiger) wäre es so, daß Pakete vom Client in AMS übergeben werden (weil das IGP des Access-Providers diesen Weg bevorzugt), die Pakete vom Server aber in FFM.


    AMS besser erreichbar als FFM dürfte für einen deutschen Kunden aber sehr unüblich sein... magst du sagen, wo du bist und welchen Provider du hast?

  • Routing 1&1 Versatel

    Quote from frank_m

    Ich würde mich von dem Gedanken verabschieden, dass der kürzeste Weg immer der beste ist. 700km auf Glasfaser sind eine Handvoll Nanosekunden, das macht den Braten nicht fett. Es ist eher die Anzahl der Hops, die sich da niederschlägt.

    Ja, 700km Glas sind nur 3,5ms, aber dieser Weg wird nicht ohne aktive Technik überbrückt, und die kostet Latenz, die sich auch nicht einfach so wegdiskutieren läßt.


    Ich sehe, daß die Anbindung an meinen Access-Provider schlechter ist, als sie sein könnte und schon war. Das sollte doch schon aus Eigeninteresse von Netcup/Anexia behoben werden. Ein so ausschweifendes Routing belastet nicht nur eigene Strecken unnötig, sondern auch fremde.

  • Routing 1&1 Versatel

    IPv6 sieht noch schlechter aus, war aber schon länger sehr schwankend... traceroute gibt wenig her, reverse DNS ist da leider nicht gut gepflegt...

    pasted-from-clipboard.png


    Dass traceroute/ICMP mit etwas Vorsicht zu genießen ist, ist schon klar. Ich gehe aber mal davon aus, daß nicht von einem Tag auf den anderen alle Router langsamer geworden sind.


    Wenn man zynisch ist, könnte man das so sehen, aber wir wollen hier doch konstruktiv sein ;)

    FFM <-> AMS sind alleine Luftlinie ~ 350km, und der Weg muß ja auch wieder in die andere Richtung zurückgelegt werden...


    Transferraten sind weiterhin ok (soweit ich gesehen habe), Überlast gibt's also wohl nicht. Bei interaktiven Anwendungen merkt man das aber schon etwas. Und würde ich auch nicht gerade als Idealzustand betrachten...


    Früheren Traceroute (bzw. mtr report) habe ich leider nur von der Gegenrichtung gefunden:

    Code
      2.|-- stu1902aihr001.versatel.d  0.0%    10   12.8  12.7  12.5  13.4   0.0
  3.|-- 62.214.37.253              0.0%    10   18.7  22.0  18.5  50.9  10.1
  4.|-- 62.214.37.134              0.0%    10   18.9  18.9  18.4  19.3   0.0
  5.|-- gw-decix.ffm.netcup.net    0.0%    10   18.9  22.9  18.8  52.8  10.6
  6.|-- 4010.nbg-juniper1.netcup.  0.0%    10   22.9  28.1  22.7  74.7  16.3
  7.|-- ___________                0.0%    10   23.0  23.0  22.8  23.3   0.0

    Im Gegensatz zu heute:

  • Routing 1&1 Versatel

    Hallo zusammen,


    seit Anfang Dezember '21 ist das Routing von und zu 1&1 Versatel (also nicht die Hosting-Sparte, sondern Access, DSL und so) deutlich schlechter geworden:


    pasted-from-clipboard.png


    Vor einem Jahr waren es noch gute <20ms, dann ist es hoch auf etwas über 20ms (immer noch ordentlich), letztes Jahr gab's dann mal einen Faserbruch und Probleme bei DECIX, dann war wieder ok, aber seit Dezember eben konstant auf 40ms oder sogar darüber, außerdem mit mehr Gezappel (also Leitung höher ausgelastet). Liegt offenbar daran, daß mittlerweile über AMS-IX geroutet wird, wenn man dem traceroute glauben darf:

    Code
     1  94.16.112.2 (94.16.112.2)  0.429 ms  0.386 ms  0.403 ms
 2  ae3-4019.bbr02.anx84.nue.de.anexia-it.net (144.208.211.10)  0.338 ms  0.358 ms  0.341 ms
 3  ae0-0.bbr01.anx84.nue.de.anexia-it.net (144.208.208.139)  10.929 ms  10.911 ms  10.891 ms
 4  ae2-0.bbr02.anx25.fra.de.anexia-it.net (144.208.208.141)  10.810 ms  10.888 ms  10.993 ms
 5  ae0-0.bbr01.anx25.fra.de.anexia-it.net (144.208.208.143)  10.741 ms  10.725 ms  10.702 ms
 6  ae2-0.bbr01.anx63.ams.nl.anexia-it.net (144.208.208.210)  10.672 ms  10.725 ms  10.708 ms
 7  ae1-10.bbr02.anx63.ams.nl.anexia-it.net (144.208.208.157)  10.589 ms  10.580 ms  10.569 ms
 8  xnl1002aihb001.versatel.de (80.249.209.109)  11.182 ms  11.233 ms  11.446 ms
 9  62.214.38.173 (62.214.38.173)  30.313 ms  26.901 ms  32.580 ms
10  i59F4BC__.versanet.de (89.244.188.__)  38.666 ms !X  38.496 ms !X  39.305 ms !X

    Laut einem Kontakt bei Versatel gibt es wohl kein direktes Peering zwischen netcup/Anexia und VT, die AS-Pfade in FFM sind alle länger weil dazwischen immer ein Carrier ist (NTT, Telia, DTAG etc.), in AMS kommt die Route über den Route-Server (d.h. der vom DECIX in FFM wird noch nicht benutzt?).


    Wie es vor 12/21 genau war, kann ich nicht sagen, aber die Zeiten von da sehen schon eher nach DECIX aus.


    Das geht doch bestimmt wieder besser, oder? VT ist ja mittlerweile schon einer der größten deutschen Access-Provider...


    Achja, als kleines Kuriosum noch ein traceroute zum DTAG VDSL eines Freundes. Obwohl die Route bis zum 4. Hop identisch ist, sind die Zeiten beim 3. und 4. Router deutlich unterschiedlich... Interessant, aber wahrscheinlich nicht so wild...

    Code
     1  94.16.112.2 (94.16.112.2)  0.233 ms  0.224 ms  0.196 ms
 2  ae3-4019.bbr02.anx84.nue.de.anexia-it.net (144.208.211.10)  0.399 ms  0.396 ms  0.374 ms
 3  ae0-0.bbr01.anx84.nue.de.anexia-it.net (144.208.208.139)  5.169 ms  5.144 ms  5.122 ms
 4  ae2-0.bbr02.anx25.fra.de.anexia-it.net (144.208.208.141)  14.498 ms  14.506 ms  14.662 ms
 5  80.156.161.185 (80.156.161.185)  3.925 ms  4.188 ms  4.162 ms
 6  p57ba8dc9.dip0.t-ipconnect.de (87.186.141.201)  8.159 ms  8.054 ms  8.112 ms
 7  p57ba8dc9.dip0.t-ipconnect.de (87.186.141.201)  7.740 ms  7.815 ms  7.777 ms
 8  p5b0bca__.dip0.t-ipconnect.de (91.11.202.___)  15.781 ms !X  15.765 ms !X  15.777 ms !X


    Grüße

    Jakob

  • Server Generation 8

    Ok, mit sysbench --test=cpu --cpu-max-prime=20000 run bekomme ich nur noch ca. 342 raus.

    Quote

    Hinweis: Da single Threaded ist es normal dass ein RS 500 da ziemlich gleichgut zu einem RS 8000 abschneiden würde!

    Naja, zwischen den CPUs liegen immerhin 2 Generationen und 3 Jahre, da würde ich schon ein bisschen Fortschritt erwarten (auch wenn der Entwicklungsfokus wohl eher auf dem Stromverbrauch liegt).

    Quote from ThomasChr
    Code
    sysbench --test=cpu run
...
events per second:  1064.4

    Das ist ggü. meinen 857 schon ein nettes Plus.

    Hatte sowieso ein Upgrade vor, das wird nächsten Monat passieren. Der Preisunterschied zum 1000er ist ja mittlerweile recht gering.

  • Server Generation 8

    Quote from ThomasChr

    Hier mal ein RS 4000 alt:

    Code
    CPU speed:
    events per second:   357.95

    Ist das einfach "sysbench cpu run"? Das wundert mich, bei meinem ollen RS 500 (G7SEa1) kommt ja schon deutlich mehr raus..


    Oder benutzt du was ganz anderes (bzw. eine andere Version)?