meeven
- Beiträge
- 717
- Punkte Reaktionen
- 130
Ah ok, ja alles null bis auf die IP.
Hab mal die VF Station neu gestartet, kommt aber das gleiche
Hab mal die VF Station neu gestartet, kommt aber das gleiche
}, "connection": { "ip": "xx.xx.xx.xx", "ipVersion": "v4", "ipCountry": null, "remotePort": 0, "isp": null, "isCustomer": false, "plannedImprovement": null, "ispFootprint": null, "isVpnActive": null, "vpnDetectedBy": null }, "modem": { "vendor": null, "type": null, "name": null, "provisionedDownloadSpeed": null, "provisionedUploadSpeed": null, "bookedDownloadSpeedMax": null, "bookedDownloadSpeedAvg": null, "bookedDownloadSpeedMin": null, "bookedUploadSpeedMax": null, "bookedUploadSpeedAvg": null, "bookedUploadSpeedMin": null, "swapScenario": null, "swapLink": null }, "cmts": { "vendor": null, "isModemTestAvailable": false }, "communication": { "modemSwapLink": null, "modemSwap": false, "plannedImprovement": null
Das ist normal bei Vodafone, durch die Wartungsarbeiten haben sich deine IPs geändert und Vodafone braucht zwischen Tage bis Monate um die Zuordnung gerade zu ziehen. Bei dem wie Inkonsistent das ist hab ich ab und zu das Gefühl das der Azubi die DB händisch pflegen darf.Wie schön geschrieben, vor den Wartungsarbeiten ging es noch, daher denke ich das es mit diesen zu tun hat.
Es gibt hier doch weiter oben im Thread eine Beschreibung.ggf. gibt es auch einfach noch keine Schnittstelle zwischen CableOS und der Speedtestdatenbank?
Stimmt es eigentlich das die einzelnen Kunden in Docker/Kubernetes Containern laufen wenn sie am vCMTS hängen. Hab da Mal ein Video ich glaube von Comcast gesehen, da wurde das so erklärt.
Ja es funktioniert so ähnlich.Solange bei diesem Container Bäumchen-Wechsel-Dich Spiel auch immer die Spielregeln eingehalten werden, ist das ja auch durchaus im Sinne der Kunden ...
Wenn dann aber je nach Laune der Cloud beim Verteilen des Docker-Containers des vCMTS über die n-Server der Anschluss einmal sehr gut läuft, und ein andermal wieder grottenmäßig, wäre das nervig ...
Auch komplette Verbindungsverluste in einem Segment, weil zwischen Containern umgeschaltet wird, wären inakzeptabel ...
Alle Geräte die Timing benötigen holen sich dieses von einem externen Timing Server(PTP-GM) per Netzwerk, und da die Architektur immer symmetrische Pfade vorschreibt gibt es eigentlich keine Timing Unterschiede im Netz, und wenn synced das Gerät neu zur Master-ClockIch weiß nicht, was gegen Container spricht. Solange man dafür sorgt, dass der Container dort läuft, wo die Timing Anforderungen erfüllt werden können
Gegenüber dem Symbolbild auf der Fritzoberfläche wird sicherlich Platz gespart ;-)Wie viel solcher 1he Server braucht's eigentlich für ein Netz mit ~100.000 Modems?
EIN CMTS versorgt keine 100 000 Modems - das traut sich nicht einmal Vodafone ...100 Server? Und das soll Energie sparender sein als ein cmts? Ein cmts ist mit 3,2kW angegeben. 100 Server dürften wohl mehr ziehen
Man kann das in der Theorie mit 2 Einzelnen Servern ohne Redundanz regeln, aber ob das irgendwer so machen will wag ich zu bezweifeln.Wie viel solcher 1he Server braucht's eigentlich für ein Netz mit ~100.000 Modems?
100 Server? Und das soll Energie sparender sein als ein cmts? Ein cmts ist mit 3,2kW angegeben. 100 Server dürften wohl mehr ziehen
Jetzt alles für 3 Server Cluster...
Wie viele vCMTs Instanzen laufen parallel auf einen 1 HE Server?
Wie viele Redundanz / Hot Standby gibt es?
Wie viele Modems pro Instanz?
in foren hat man halt schon von anschlüssen gelesen, die virtualisiert wurden und deren latenz ein gutes stück schlechter wurde. Ich würde tatsächlich nur ungern mitansehen, wie die angenehmen 10ms, die man von dem anschluss hier derzeit nach frankfurt hat, nach oben gehen nur um kosten und platz zu sparen.reichen Platz und Energieersparnis etwa nicht?