Beiträge von mainziman

    Sollen die Router von netcup hellsehen?

    sag es 2mal, und auch andere Router können wie aus dem Nichts auf einmal hellsehen;

    nennt sich dann MMRTP (MIster Merlin Routing Protokoll) :D


    ich hatte vor rund 1-2 Wochen bei mir im LAN beim IPv6 etwas geändert (IPv6 ist bei mir nach wie vor nur via 6in4-Tunnel erreichbar)

    und siehe da, auf einmal ist forum.netcup.de ohne komischer Krücke¹ auch über IPv6 erreichbar;

    sogar ping6 forum.netcup.de geht ohne Probleme :)


    ¹ ip6tables -t mangle -A FORWARD -i br0 -o sit1 -d 2a03:4000:35:8e2::95 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1421:1536 -j TCPMSS --set-mss 1420

    ens3: wie gesagt: die fe80::... Adresse hat nichts mit der IPv6 auf dem Interface gemeinsam.

    aber genau das sollte es ... wurde bereits mehrfach darauf hingewiesen;


    Samstag 18:54

    hast Du dem vServer die 'default'-IPv6 gegeben, welche er Dir im SCP anzeigt?

    Samstag 19:28

    Samstag 20:31

    und befindet sich unter den IPv6-Adressen des ens3-Interfaces eine Scope:Global des vServer-IPv6-Prefixes,

    deren hintere 64-bit ident mit der Scope:Link Adresse fe80::... des vServers ist?

    Sonntag 18:39

    Entscheidend ist folgendes: das Ziel für das geroutete Netz ist fest vorgegeben. Diese Adresse muss statisch fest auf dem primären Interface eingestellt sein - ohne Schnickschnack, ohne irgendwelche RA Spielereien oder sonstwas. Wenn da irgendwas an der Adresse rumfummelt, dann würde das zuverlässig deine Probleme erklären.


    mach das einfach mal und Deine Probleme sind gelöst ...

    ThomasChr wenns hochperformant notwendig is, leg ich noch Hand an, der Compiler pfuscht da schon oft gewaltig Bits und Bytes 'rein;


    zur anderen Sache, ob gcc und Co dieses Problem wirklich kennen; ich weiß nicht so recht,

    aber man kann sich beim gcc ja den Assembler-Code ausgeben lassen, welcher da eigentlich zur Anwendung käme,

    und da findet man dann schon Dinge wo genau das zur "Anwendung" gelangt;

    (ich hab diese Kenntnis bereits seit Jahren nachdem ich doof aus der Wäsche geguckt hab, was der gcc mir da präsentiert)

    Aber all das ändert halt nichts dran, dass die offiziell verkündete Inflationsrate letztlich nach den Regeln, die dafür gelten, wohl schon korrekt ermittelt ist.

    ob dem tatsächlich so ist, da habe ich ernste Zweifel daran ... :/

    tab klar kommt es darauf an, was man anschaut, aber so komisch kann doch kein Durchschnitt gerechnet werden, dass unterm Strich weniger rauskommt, als die Einzelwerte;


    ein Arbeitskollege letzten Freitag: "mir hat der Stromversorger gekündigt, wenn ich weiter Strom haben will, an Stelle der bisherigen monatlichen A-konto-Zahlung von rund 90 EUR dann mehr als 500 EUR"


    bei Gas wird von Steigerungen jenseits der 1000% gesprochen; klar gibt es genug das überhaupt nicht teurer geworden ist - z.B. Bio-Lang-Semmeln beim Lidl;

    aber will man mir damit tatsächlich erklären, des hätte in Summe eine derart hohe Gewichtung im Warenkorb, dass es die Inflation derart in den Keller drückt?


    weil des widerspricht sich dann doch irgendwie, weil dann kann man ja ruhig das Gas abdrehen und es hätte überhaupt keine bis marginale Auswirkung,
    wenn es wirklich eine so niedrige Gewichtung im Warenkorb hat, oder? ;)

    Sonntagsfrage f. Fortgeschrittene ^^


    wer glaubt, dass die momentane Inflation tatsächlich nur die paar Prozent sind,

    welche in den diversen Medien breit(gestampft,getreten,...) wird?

    an Hand dem läßt sich vermuten, dass das NIC Interface auf Deinem vServer ens3 ist,


    und befindet sich unter den IPv6-Adressen des ens3-Interfaces eine Scope:Global des vServer-IPv6-Prefixes,

    deren hintere 64-bit ident mit der Scope:Link Adresse fe80::... des vServers ist?

    du hast jetzt 2 IPv6-Netze

    das welches beim Server dabei ist nennen wir es 2a03:4000:1:0::/64

    und das zusätzliche nennen wir es: 2a03:4000:1000:0::/64


    im SCP siehst Du irgendwo sowas


    2a03:4000:1000:0::/64 -> 2a03:4000:1:0:aaaa:bbbb:cccc:dddd


    und genau die IPv6 rechts ist die IPv6-Adresse welche Du deinem Server am eth0, ens3, ... Interface geben musst;

    Ich wuerde keine lokale SSD fuer die Gaeste verwenden, sondern den Storage ueber FC, FCOE oder aehnlichem anbinden.

    wo die SSDs f. die Gäste letztendlich liegen, ist unerheblich, es sollte lediglich zeigen, dass es mehr braucht als nur die CPU-Kapazität ...

    was ebenfalls Kosten sind;


    Und dank RAID5 kommt der externe Storage auch mit weniger Overhead aus.

    im Konjunktiv bitte, die RS und VPS haben allesamt RAID 10 ;)

    (die Storage Server haben ein RAID 6, bei dieser Mischung wird es interessant wo man die als "Lückenfüller" unterbringt;

    od. sind die ohnehin wegen der doch erheblich größeren HDD-Kapazität ein Kapitel f. sich)

    TBT f. diese 6 RS8000 Kunden brauchst auch noch die entsprechende Menge an RAM und die entsprechende Menge an SSD Kapazität, damit sieht die Rechnung dann auch wieder etwas anders aus; ich würd meinen die Nodes haben ½ TByte RAM und 32 TByte SSD nativ (Raid10 halbiert!) installiert;


    wie die kalkuliert sind, wissen wir nicht,

    ich würd es so kalkulieren, dass innerhalb der halben Lebensdauer der Hardware diese durch die Einnahmen finanziert ist,

    und die Einnahmen danach nur noch den Energie-, Personalaufwand, ... decken müssen und den Gewinn abwerfen;

    Ersatzteile - z.B. Raid-Controller, Netzteile, ... - soferne diese nicht beim Lieferanten regressieren, müssen ebenfalls sich innerhalb der Halbzeit finanzieren;

    ich werfe hier ein, dass beim Vergleich der G8 (Intel) und G9 (AMD Epyc) auch folgender Aspekt zum Tragen kommt,

    die AMD Eqyc CPU ist Single-Socket spezifizieet; der Intel Gold ist f. 4 Sockel spezifiziert;


    sprich ob nicht evtl. tatsächlich 4 Sockel in Verwendung sind, und damit sind es pro Host 4 mal 18 Cores;

    und dann hast als Vergleich 4 mal 18 Cores (Intel) vs. 1 mal 64 Cores (AMD)

    die Kosten effektiv sind bei den Nodes in etwa die selben,

    was aber bei Intel einen Vorteil haben kann -> mehr Leistung in Relation zum Stromverbrauch;

    wenn es wenigstens wahr wäre, aber die Probleme bringen schlicht und einfach die Architektur mit sich;

    das eine oder andere Bugilein mag vielleicht ausgebessert sein, aber im wesentlichen sind die noch vorhanden;

    bei AMD nicht anders ...


    es ist und bleibt eine 32-bit Architektur welche zufällig auch 64-bit kann ...


    wohlgemerkt, AMD hat das mit der AMD64-Sache erfunden;

    EM64T von Intel ist nur der 'kompatible' Nachbau;


    aber bei folgendem zermatscht man sein Hirn ...

    RAX, RBX, RCX, ... sind die 64-bit Register

    EAX, EBX, ECX, ... sind die 32-bit Register bzw. im 64-bit Modus die niederwertigen 32-bit der 64-bit Register

    auf die ganzen 64-bit Register kann man nur zugreifen, sobald man die CPU in einen 64-bit Modus schaltet;

    das mag ja noch irgendeinen Sinn ergeben¹, ABER:

    Code
    SUB ECX,ECX                 ; das 32-bit ECX Register (Counter) mit 0 initialisieren,
                                ;             durch Subtraktion sich selbst von sich selbst
    MOV RAX,1234567812345678H   ; das 64-bit RAX Register (Akkumulator) auf den Wert 1234567812345678H setzen
    MOV EAX,ECX                 ; kopiere das 32-bit ECX Register (Counter) auf das 32-bit EAX Register (Akkumulator)

    jetzt darf gewettet werden: welchen Wert hat hier das komplette 64-bit RAX Register (Akkumulator)?


    ¹ von den Adressen her betrachtet ja, von den Daten her betrachtet definitiv nein

    TPM 2 kann virtualisiert werden - damit juckt mich das in meiner Windows VM nicht.

    nur weil es virtualisiet werden kann muss es nicht heißen, dass es gut ist;


    habe ehrlich gesagt kein Verständnis wegen dem Klamauk, auf einmal verschlüsselte VMs zu haben ...

    und auf den Punkt gebracht: eine TPM 2 emulation in einer VM, welche nicht verschlüsselt ist, sinnbefreit ist;