SFP-VDSL-Modem auf einem MikroTik-Router einrichten

Reine VDSL-Modems sind eine aussterbende Art. Trotzdem gibt es noch hier und da entsprechende Modems, unter anderem im SFP-Standard. Diese SFP können genutzt werden z.B. einen MikroTik-Router mit einer entsprechenden Funktionalität nachzurüsten. In diesem Fall sollte es die Möglichkeit sein VDSL über das Interface sfp1 zu nutzen. Die erhältlichen SFP-Module für VDSL sind meist baugleich mit dem VersaTec VX-160CE VDSL2-SFP.

Ein VDSL Modem als SFP

Nachdem das Modul im MikroTik-Router installiert wurde, ist das Interface sfp1 aktiv. Die Auto Negotiation muss für das Modul deaktiviert werden. Andernfalls schlägt später die Neuverbindung nach einem Neustart fehl, da das Modul nicht mehr erkannt wird.

Die Auto Negotiation muss für das Modul deaktiviert werden

Eingestellt wird das Modul hierbei auf 1Gbps bei Full Duplex. Im nächsten Schritt muss ein VLAN für die Schnittstelle angelegt werden. Hintergrund ist, das erwartet wird das die Daten sich im VLAN mit einer bestimmten ID befinden. Bei der Deutschen Telekom ist dies die 7, bei anderen Anbietern kann dies teilweise abweichen. So z.B. bei 1&1; dort wird je nach genutzter Infrastruktur die 7 oder die 8 genutzt.

Das VLAN-Interface

Beim anzulegenden VLAN-Interface ist darauf zu achten, das kein Service-Tag gesetzt wird. Nachdem das Interface sfp1 und das entsprechende VLAN-Interface konfiguriert sind, kann im nächsten Schritt die PPPoE-Verbindung eingerichtet werden. Dazu wird unter PPP ein neues PPPoE-Interface eingerichtet. Das zu nutzende Interface für das PPPoE-Interface ist hierbei das VLAN-Interface, im Beispiel sfp1-v7.

Das PPPoE Interface

Im Tab Dail Out müssen die Zugangsdaten von Internetanbieter eingetragen werden. Im Falle einiger Anbieter wie z.B. 1&1 kann es notwendig sein vor dem eigentlichen Nutzernamen ein H zu setzen, da dieser sonst nicht akzeptiert wird und der Authentifizierungsvorgang fehlschlägt. Damit ist das SFP-Modul eingerichtet und die Verbindung kann genutzt werden. Je nach genutztem Modell aus der MikroTik-Palette kann es sein, das nicht die volle Bandbreite genutzt werden kann. Das Problem ist in diesen Fällen meist die CPU-Auslastung durch die PPPoE-Verbindung da diese komplett durch die CPU verarbeitet werden muss. In einem solchen Fall kann zu den Cloud Core.Routern von MikroTik gegriffen werden.

Nachdem die Verbindung hergestellt war, stellte ich im Laufe eines längeren Testes allerdings fest, dass der PPPoE-Link in regelmäßigen Abständen nach 30 – 80 Minuten zusammenbrach und somit leider kein stabiles Internet lieferte. Vermutlich handelt es sich um ein Problem des SFP-Moduls im Zusammenhang mit dem DSLAM.

Was steckt hinter Stadia?

Der Spielestreaming-Dienst Stadia versteht sich als neue Plattform. Wer für diese Plattform entwickeln möchte, kann sich unter stadia.dev dafür bewerben. Auf der Seite erhält der Leser daneben weitere Informationen über die Plattform.

stadia.dev

Auf der Hardwareseite wird aktuell eine 2,7-GHz-Hyperthread-x86-CPU mit AVX2 SIMD und 9,5 MB L2- und L3-Cache, eine AMD-GPU mit HBM2-Speicher und 56 Recheneinheiten mit einer Leistung von 10,7 Teraflops, 16 GB RAM mit einer Bandbreite von bis zu 484 Gbit/s und SSD-Speicher in der Cloud genutzt.

Auf Softwareseite wird Linux genutzt. Google nutzt hierbei die Linux-Distribution Debian als Grundlage. Als Grafikschnittstelle müssen die Spiele Vulkan benutzen. Dazu wird eine API bzw. ein SDK mitgeliefert, welches Funktionalitäten für die Verwaltung von Spielständen, die Nutzung der Multiplayer-Modi und der Funktionen für die Unterstützung der Unterbrechung und Fortsetzung des Spieles liefert.

Zurzeit unterstützen das Entwicklerwerkzeug Unity und die Unreal Engine den Spielestreaming-Dienst. Daneben existieren weitere Werkzeuge von Google, welche bei der Entwicklung von Spielen für Stadia helfen.

Vergleichen von Fließkommawerten unter Java

Einen Integerwert unter Java zu vergleichen ist trivial. Man nehme zwei Variablen vom Typ Integer und vergleiche sie, unter Zuhilfenahme des entsprechenden Operators, miteinander:

int a = 7;
int b = 7;

boolean equal = a == b;

Am Ende ist der Wert in der Variable equal true, da die Werte in der Variable a und b identisch sind. Nun könnte das Ganze bei Fließkommazahlen ebenso funktionieren:

double a = 7;
double b = 7;

boolean equal = a == b;

Auch in diesem Fall ist das Ergebnis am Ende true. Trotzdem sollten Fließkommazahlen niemals auf diese Weise verglichen werden. Spätestens bei folgendem Beispiel fällt dies auf:

double a = 4.1 + 0.8;
double b = 5.7 - 0.8;

boolean equal = a == b;

Obwohl beide Rechnungen eigentlich 5,9 ergeben sollten, wird in der Variable equal der Wert false enthalten sein. Hintergrund hierfür ist die Speicherung der Fließkommazahlen. Diese ist im Standard IEEE 754 festgelegt. Bei dieser Darstellung besteht die Zahl aus einem Vorzeichen, einem Exponent und einer Mantisse. Bei der Umwandlung der Dezimalzahl in ihre binäre Darstellung und der Verrechnung kann es zu Ungenauigkeiten (z.B. bei der Rundung im Prozessor) kommen. Wenn diese Werte nun binär verglichen werden, sind sie nicht identisch. Statt durch direkten Vergleich, sollte die „Gleichheit“ durch eine Differenzrechnung ermittelt werden:

public static boolean compare(double a, double b) {
    return Math.abs(a - b) < 0.0001; // Diff smaller epsilon?
}

Nachdem die Differenz der beiden Werte gebildet wurde, wird überprüft ob diese kleiner als Epsilon sind. Epsilon stellt den Threshold bzw. eine Schwelle oder Toleranz dar. Solange die Differenz unter diesem Wert liegt, werden beide Werte als identisch angenommen. Natürlich fehlt in dieser Methode noch eine Absicherung gegenüber NaN-Werten.

Statt sich eine solche Methode selber zu schreiben, können Methoden aus bekannten Utility-Bibliotheken wie Guava (DoubleMath.fuzzyCompare) genutzt werden.

Offene Kerne

Bei der Software hat es die Open Source Bewegung schon weit gebracht, für so ziemlich jeden Anwendungsfall gibt es auch eine freie Applikation. Anders sieht das bei der Hardware aus. Hier ist vieles noch proprietär. Damit das nicht auf ewig so bleibt gibt es Projekte wie OpenCores welches unter http://opencores.org/ zu finden ist.

Die Projektübersicht von OpenCores

Die Projektübersicht von OpenCores

Gegründet im Oktober 1999 von Damjan Lampret, gibt es auf den Webseiten des Projektes eine Reihe von offenen Rechenwerken bis hin zu ganzen Prozessoren. Geschrieben ist das ganze meist in einer Hardwarebeschreibungssprache wie VHDL, Verilog oder SystemVerilog. Die Lizenzen variieren je nach Projekt meist zwischen der LGPL oder einer BSD Lizenz.

Eine eigene CPU Architektur

Wenn man mal auf der Suche nach einem kleinen Zeitvertreib ist, kann man natürlich so einiges ausdenken, so z. B. eine eigene CPU-Architektur. Dabei muss man diese nicht in Hardware gießen, sondern es reicht wenn man diese emuliert. Und so entstand in einiger Zeit eine CPU, welche auf den Namen Structura hört. Ein Designziel war es dabei, die CPU nur mit den nötigsten Maschinenbefehlen auszustatten. Das führte bei der Structura zu folgenden Befehlen (hier als Assembler Mnemonics dargestellt):

  • [0] – JUMP
  • [1] – ADD
  • [2] – COPY

Das bedeutet, dass es unter anderem keine Nichtoperation wie z.B. NOOP bzw. NOP im Befehlssatz der CPU gibt. Der Grund dafür ist ganz einfach. Eine Nichtoperation lässt sich durch einen JUMP um null Byte emulieren, was im Endeffekt nur eine Erhöhung des Instruction Counters kurz IC zur Folge hat. Da JUMP auf den Opcode 0 gelegt wurde führt, dies zu einer interessanten Reaktion der CPU, wenn sie das Ende des Programms erreicht und versucht den restlichen Speicher zu interpretieren. Die CPU interpretiert das als Sprung an die Adresse 0 und beginnt mit dem Programm von vorne.

Der Befehlsaufbau der Maschinenbefehle stellt sich dabei so da:

JUMP (Breite: 40 Byte)
  [Int64|Befehlswort - 0]
  [Int64|Adressinterpretation - 0/ANCTAAV 1/ACTAAV 2/RNCTAAV 3/RCTAAV]
      ANCTAAV - Adress not contains target adress as value
      ACTAAV - Adress contains target adress as value
      RNCTAAV - Register not contains target adress as value
      RCTAAV - Register contains target adress as value
  [Int64|Sprungbedingung - 0/NONE 1/ZERO 2/POS 3/NEG 4/OVF]
  [Int64|Sprungadressierung - 0/ABS 1/REL] 
  [Int64|Adresse oder Wert]

ADD (Breite: 32 Byte)
  [Int64|Befehlswort - 1]
  [Int64|Modus - 0/RAR 1/RANR 2/RAV] 
      RAR - Register and register
      RANR - Register and negative register
      RAV - Register and value
  [Int64|Register] 
  [Int64|Register oder Wert]

COPY (Breite: 40 Byte)
  [Int64|Befehlswort - 2] 
  [Int64|Modus - 0/NACTAAV 1/FACTAAV 2/SACTAAV 3/BACTAAV]
    NACTAAV - No adress contains target adress as value
    FACTAAV - First adress contains target adress as value
    SACTAAV - Second adress contains target adress as value
    BACTAAV - Both adress contains target adress as value
  [Int64|Menge an kopierenden Daten in Byte]
  [Int64|Register, Speicheradresse oder ZERO] 
  [Int64|Register oder Speicheradresse]

Jeder Opcode auf der CPU ist 8 Byte lang und wird als Int64 interpretiert. Die Structura ist mit den Registern A bis Z ausgestattet, was 26 Allzweckregister mit einer Breite von 8 Byte sind. Neben diesen Allzweckregistern besitzt es das Spezialregister IC bei welchem es sich um den Instruction Counter handelt und einige Flags mit den Namen Zero, Positive, Negative und Overflow. Beim Start beginnt die CPU mit der Ausführung des Programms ab der Adresse 0. Eine Besonderheit ist, das die CPU keinen Stack und keine Interrupts unterstützt.

Damit Peripherie angesprochen werden kann, gibt es bestimmte Bereiche im Speicher, in welche sich diese Geräte einblenden. Der Bereich für Einblendungen ist dabei ab der Adresse 9.000.000.000.000.000.000 (7CE66C50E2840000) bis 9.223.372.036.854.775.807 (7FFFFFFFFFFFFFFF) zu finden.

Die Grafikkarte wird dabei ab der Adresse 9.000.000.000.000.000.000 bis einschließlich 9.099.999.999.999.999.999 eingeblendet. In den ersten 4096 Byte befindet sich dabei der Konfigurationsblock der Grafikkarte, welcher Informationen über die Auflösung und andere Einstellungen enthält.

Ab der Adresse 9.100.000.000.000.000.000 bis einschließlich 9100000000000008191 wird die Tastatur bzw. deren Eingabepuffer eingeblendet. Die ersten zwei Byte im Speicher der CPU sind dabei ein UInt16 welcher den aktuellen Zeichenindex der Tastatur in ihrem Tastaturpuffer angibt. Jede Eingabe auf der wird dabei vom Tastaturgerät in Form eines Bytearrays mit der Größe von fünf Byte übertragen. Das erste Byte gibt dabei den Modifier an, die restlichen 4 Bytes enthalten das erzeugte Zeichen in Form eines UTF-32 Zeichens.

Der schematische Aufbau der CPU und deren Peripherie

Der schematische Aufbau der CPU und deren Peripherie

Der Assembler für die CPU unterstützt eine Reihe von Mnemonics, welche anschließend in die Maschinensprache übersetzt werden. Diese sind:

ABS [Register]
ADD [Register] [Register oder Wert]
CLR [Register oder ALL]
COPY [Int64|Menge an kopierenden Daten in Byte] [Register oder Speicheradresse] [Register oder Speicheradresse]
DIV [Register] [Register oder Wert]
LOAD [Speicheradresse] [Register]
DEC [Register]
INC [Register]
JUMP [Sprungbedingung|NONE|ZERO|POS|NEG|OVL] [Sprungadressierung|ABS|REL] [Adresse oder Wert]
MOD [Register] [Register oder Wert]
MUL [Register] [Register oder Wert]
NEG [Register]
NOOP
SHIFTL [Register] [Register oder Wert]
SHIFTR [Register] [Register oder Wert]
WRITE [Register] [Speicheradresse]

Beim Assembler handelt es sich genaugenommen nicht um einen Assembler der reinen Lehre, sondern um eine Kreuzung aus Assembler, Makroassembler und Hochsprache. Für die komplexeren Kommandos wie MUL oder SHIFTL werden bestimmte Register während der Berechnung belegt (im Fall von MUL z. B. das W, X, Y und Z Register). Die vom Kommando belegten Register sind dabei in der Dokumentation aufgeführt. Das führt natürlich dazu das eine solche Multiplikation nach der Auflösung aus sehr vielen Befehlen besteht:

COPY 8 Y A;
COPY 8 Z ZERO;
ADD Z 3;
COPY 8 X ZERO;
ADD Y 0;
JUMP POS REL 72;
JUMP ZERO REL 32;
ADD X 1;
ADD Z 0;
JUMP POS REL 72;
JUMP ZERO REL 32;
ADD X 1;
COPY 8 A ZERO;
ADD Y 0;
JUMP POS REL 184;
JUMP ZERO REL 144;
COPY 8 W Y;
ADD Y -W;
ADD Y -W;
COPY 8 W ZERO;
ADD Z 0;
JUMP POS REL 184;
JUMP ZERO REL 144;
COPY 8 W Z;
ADD Z -W;
ADD Z -W;
COPY 8 W ZERO;
ADD A Y;
ADD Z -1;
JUMP POS REL -104;
COPY 8 W X;
ADD W -2;
JUMP ZERO REL 368;
COPY 8 W X;
ADD W -1;
JUMP ZERO REL 112;
COPY 8 W X;
ADD W 0;
JUMP ZERO REL 144;
COPY 8 W A;
ADD A -W;
ADD A -W;
COPY 8 W ZERO;
COPY 8 X ZERO;
COPY 8 Y ZERO;
COPY 8 Z ZERO;

Während der Entwicklung gab es dabei einige interessante Ideen wie man bestimmte Sachen im Assembler lösen könnte. So zum Beispiel folgendes Problem:

ADD A 555;   // Fülle das Register A mit dem Wert 555
COPY 8 B A;  // Kopiere Register A zu B
DEC B;       // Reduziere B um 1
COPY 8 *A B; // Kopiere der Wert von B an die Adresse welche im A Register A definiert ist (555)
COPY 8 D *A; // Kopiere das was ab 555 steht in den Register D

Im D Register sollte nun der Wert 554 stehen. Möglich wird dies dadurch, das die CPU weiß, dass sie nicht den Wert nach A kopieren soll, sondern den Wert welcher in A enthalten ist, als Zieladresse benutzt. Theoretisch wäre dies auch anders lösbar gewesen. So hätte der Assembler das * in selbst modifizierenden Quellcode auflösen können. Aus einem COPY 8 *A D wäre dann in etwa folgender Quelltext erzeugt worden:

COPY 8 (IC+32) A;
COPY B [IC+32];

Das Problem an dieser Geschichte ist, das der Assembler bei dieser Variante sehr viel über die Innereien der CPU wissen muss. So muss z. B. genau definiert sein, wann der IC erhöht wird, da dieser für den selbst modifizierenden Code benötigt wird. Zur Erklärung: Die erste Zeile kopiert die Adresse welche in A liegt in die nächste Zeile und modifiziert somit den COPY Befehl während der Laufzeit. Dadurch wird die Adressierung über den Registerwert möglich.

Interessant ist auch die Berechnung eines Sprungzieles. Möchte man z. B. folgendes Programm ausführen:

ADD A 7;
JUMP NONE REL -104

stellt sich die Frage wie man die relative Sprungweite ausrechnet. Hierbei kommt es auf die Breite der Befehle an. Bei den Grundbefehlen (ADD, COPY und JUMP) entspricht diese den in der Maschinencodebeschreibung angegebenen Breite. Andere Befehle wie MUL oder SHIFTL zählen zu den komplexen Befehlen, da diese im Maschinencode aus mehreren Anweisungen bestehen.

Hier besteht die einfachste Möglichkeit darin, den JUMP-Befehl im ersten Moment mit Fantasiewerten zu füllen. Anschließend wird der Emulator mittels:

Structura.exe program.asm -disassemble -withIC

aufgerufen. Bei der Darstellung mittels withIC wird der Wert des ICs am Anfang des Befehls und am Ende des Befehls angezeigt.

(256/296)            JUMP ZERO REL 32;
(296/328)            ADD X 1;
(328/360)            ADD Z 0;

Möchte man nun also zum Befehl ADD Z 0; springen so rechnet man 328-296 und hat so das richtige Sprungziel errechnet.

Und natürlich fehlt auch noch eine Umsetzung in Hardware, aber bis das so weit ist, kann es naturgemäß dauern. Bei der Structura handelt es sich natürlich nicht um eine effiziente CPU, sondern um eine bei welcher versucht wurde, die CPU internen Befehle auf ein Minimum zu begrenzen und das Design als solches einfach zu halten. Dies schlägt sich unter anderem darin nieder, das jedes Befehlswort 8 Byte lang ist, und somit für 3 Befehle überdimensioniert, aber dafür die Einfachheit der Maschine intern gegeben ist.

Und natürlich erkauft man sich dies mit einigen Nachteilen, so sind die Bitverschiebungsoperation eigentlich eine der schnellsten in einer CPU. Durch die Emulation über zusätzlichen Assemblercode wird es eine der langsamsten Operation. Aber eine CPU mit einem großen Befehlssatz zu emulieren, ist schließlich einfach und das war nicht der Sinn der Übung.

Anschauen kann man sich das unter der GPLv3 stehende Projekt unter https://github.com/seeseekey/Structura/. Eine vorkompilierte Version zum Testen gibt es hier zum Download. In der Implementation befinden sich sicherlich noch einige Fehler, auf welche mich gerne hingewiesen werden darf. Jetzt müsste nur noch jemand Linux auf das System portieren, wobei dies ohne weiteres nicht funktionieren sollte, das die CPU Dinge wie Interrupts nicht unterstützt. Allerdings wäre es natürlich durchaus möglich ein eigenes minimales Betriebssystem für das emulierte System zu schreiben.