Posts Tagged ‘Latenz’

Montag, 20. April 2020

upc kappt Peering mit Init7 / Fiber7

Ich habe vor einigen Jahren mit OpenVPN ein Site-to-Site VPN zu einem Bekannten in der Agglomeration Bern aufgebaut und betreibe dieses VPN bis heute.

Der Bekannte ist Kunde von upc cablecom (der schnellste und preiswerteste Anbieter in der Agglomerationsgemeinde) mit einem 300 MBit/s Download-Abo, ich als Städter bekanntermassen Kunde von Fiber7 mit (theoretisch) symmetrischen 1 GBit/s.

Letzte Woche (KW16 2020) waren SSH-Verbindungen zu einem Server beim Bekannten auf einmal sehr, sehr hakelig — die Latenz zwischen Tastatureingabe und erscheinen des Zeichens auf dem Bildschirm war sehr hoch. Bestätigt wurde diese durch meine Überwachung der Geschwindigkeit mit speedtest-cli und Aufzeichnung und Visualisierung der Werte mit Cacti:

image-8955

Der Einbruch am Dienstag-Morgen war offensichtlich.

Eine fiebrige, verbissene Suche begann: War ein Angreifer in das Netzwerk eingedrungen und zog nun Gigabyte-weise an Daten ab? Oder war ein Rechner eines Mitbenutzers von Malware gekapert worden? Oder führte der Mitbenutzer einfach nur tonnenweise Bittorrent-Downloads durch? Oder war eine Netzwerkkomponente ausgetickt und flutete das Netzwerk und den Router mit Paketen? Oder hatte upc cablecom einfach etwas am Netzwerk geschraubt, worauf der Geschwindigkeitseinbruch manchmal nur mit einem Neustart des Modems behoben werden konnte?

Die Nachforschungen brachten nichts zu Tage, aber immerhin lernte ich folgende Netzwerkanalyse-Tools/Features meiner Infrastruktur kennen:

  • Traffic Analysis des EdgeRouters X ER-X, welcher am Kabelmodem hängt
  • iftop Zeigt in Echtzeit an, von und zu welchen IPs ein Server Daten übertragt (Homepage)
  • iptraf-ng (Homepage)

Am Dienstag-Abend ereilte mich ein Geistesblitz: speedtest-cli misst die Geschwindigkeit von einem Server am Agglomerations-Standort zum Ookla Speedtest-Server von Init7 (Server „Init 7 (Winterthur, Switzerland)“ mit ID 3026). Aus Interesse wählte ich einen anderen Server aus der Liste aus, und zwar den Speedtest-Server von Sunrise. Zuerst führte ich einen manuellen Speedtest zu Init7 durch, danach zu Sunrise. Und siehe da, hier lag die Antwort wie auf dem Präsentierteller:

$ ./speedtest-cli --server 28045
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from UPC Schweiz (80.218.X.X)...
Hosted by Sunrise Communication AG (Lausanne) [6X.XX km]: 30.667 ms
Testing download speed........................................
Download: 302.88 Mbit/s
Testing upload speed..................................................
Upload: 42.32 Mbit/s

$ ./speedtest-cli --server 3026
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from UPC Schweiz (80.218.X.X)...
Hosted by Init 7 (Winterthur) [13X.XX km]: 165.956 ms
Testing download speed........................................
Download: 25.82 Mbit/s
Testing upload speed..................................................
Upload: 9.48 Mbit/s

Am selben Abend sendete ich eine Anfrage an Init7 raus, ob und wie sie sich diesen markanten Geschwindigkeits-Unterschied erklären können. Am Morgen hatte ich die Antwort, und wurde auf folgendes Schreiben verwiesen. Diese Meldung war bei mir im Corona-Trubel vollkommen untergegangen.

Fazit: upc cablecom, how dare you?

Nachtrag

smokeping visualisiert die Latenz von DNS-Abfragen aus dem upc cablecom-Netz gegen den DNS-Server von Init7 ebenfalls sehr schön:

image-8956

Auf Wunsch Thomas‘ (siehe Kommentar unten) noch dieselbe Grafik für Test-Abfragen an einen der DNS-Server der upc cablecom (ns10.cablecom.net) …

image-8957

… zu Swisscom (dns2.bluewin.ch) …

image-8958

… und zu Sunrise (cache02.sunrise.ch)

image-8959

Tags: , , , , , , , , , , , , , , , , ,
Labels: IT, Schweiz

6 Kommentare | neuen Kommentar verfassen

Sonntag, 15. Oktober 2017

Nach einem RAM-Upgrade eines iMacs laufen die Module nur noch mit 1600 MHz

Kürzlich habe ich mir einen iMac Late 2015 mit 27 Zoll Retina-Display geleistet. Nun haben ausnahmslos all meine Apple-Geräte (iPhone, iPad, iMac, MacBook) Retina-Auflösung.

Die popeligen 8GB RAM musste ich aber noch aufrüsten, weshalb ich mir zusätzlich zwei Mal 8GB Riegel geleistet habe. Nach der Installation dann die Ernüchterung: Während vor dem Upgrade die zwei Mal 4GB Riegel mit 1867 MHz angesprochen wurden, laufen die insgesamt vier Module nun nur noch mit 1600 MHz.

Wieso ist das so? Nach etwas Recherche die Antwort:

Die Originalbausteine von Apple haben eine CAS Latency CL von 13. Die zusätzlich installierten Module von Corsair mit der Produktenummer CMSA16GX3M2C1866C11 haben dagegen CL 11.

Dies führt zu folgendem Verhalten:

EDIT: Actually, looks like it’s just that the default RAM can’t run below CL13 at 1866, so when you add another set of 1866 with a lower CL, it decides to slow it down so it can match the faster CL at the cost of lower frequency.

Quelle: Late 2015 iMac Not Picking up 1866MHz RAM

Doch offenbar spürt man diese Verlangsamung im Alltag nicht, wie jemand in einem anderen Thread erklärt:

RAM speed is one of those things that really only helps at the margins, and isn’t worth stressing about too terribly much (unless you use onboard graphics that use regular RAM for VRAM). That said…
The formula for figuring out the true latency (as opposed to CAS latency) is: CAS latency / clock speed. That’s a measure of time, usually expressed in nanoseconds, and you want to minimize it. The two kits you mentioned:

  • 14 / 2400000000 = 6 ns
  • 16 / 3333000000 = 5 ns

On paper, the 3333 MHz RAM wins. But in the real world, you won’t actually notice a difference between the two. So get whichever you would prefer.

Quelle: Choosing DDR4: Clock vs Latency? C14 vs C16

Tags: , , , , , , , , , , , , , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen