Neue Partner für vCMTS und R-PHY

[reneromann]

Wie soll das gehen, wenn man Hardware in Software emuliert?
Das Jitter-Problem entsteht durch die Emulation...

Da wird nichts emuliert. Den Unterschied wird wohl eher machen, ob die CMTS-Software den PHY lokal innerhalb von Mikrosekunden abfragen und umprogrammieren kann, oder remote 3-4 Größenordnungen länger dafür benötigt.

Genau da liegt doch aber die Emulation - statt ein komplettes Gerät mitsamt direktem Hardwarezugriff zu haben, wo der Zugriff quasi in Mikro- oder Nanosekunden passiert, nutzt man stattdessen eben eine Emulation dieses Hardware-Direktzugriffs auf das rPHY per Netzwerk...
Im dümmsten Fall passiert der Spaß dann nicht mal auf realer Hardware, sondern virtualisiert in der Cloud, wo die Dienstequalität gar nicht gegeben ist...

Wenn bei der (v)CMTS <-> Remote-PHY Anbindung nicht auf die benötigte Dienstqualität geachtet wird, muss man sich über schlechte Ergebnisse nicht wundern.

Nicht nur da - wenn das vCMTS dann noch virtualisiert läuft, wird die Sache noch schlimmer, sofern die Hardware nicht exklusiv genutzt wird...

Die beste Kompensation für den "Trägheitsnachteil" von Remote-PHY soll wohl Low Latency DOCSIS sein, aber das benötigt für das wichtigste Element Datenkapazität, die man mit Low Split bestimmt nicht hat.

Low-Latency-DOCSIS und vCMTS mit rPHY widersprechen sich eigentlich - denn jegliche Latenz zwischen vCMTS-Standort und rPHY sowie insbesondere Latenzen der Geräte dazwischen addieren sich alle (negativ) auf.
Wenn das vCMTS dann nicht mal ortsnah liegt, wird es noch schlimmer...

Also könnten die negativen Effekte daher rühren, dass Remote-PHY mit Low Split eher als Übergangsphase zum High Split angedacht ist, und das System für einen längerfristigen Low Split Betrieb eigentlich nicht angedacht war...

Ein Teil sicherlich, aber alleine die Latenz der Netzwerkverbindung zwischen vCMTS und rPHY verhagelt halt die Gesamtlatenz.

[Edd1ng]

Selbst mit vCMTS kann man noch auf einer Analogen Node hängen, wenn sie R-PHY nur im HUB einsetzen (R-PHY-SHELF)

[denunge]

Nobody is doing vCMTS in the public cloud today. Will it come? Maybe.

The vCMTS of today uses containers only, no virtual machines. Each service group gets a dedicated CPU core, so no context switching.

The distance/delay between the upstream scheduler and modems has an impact on latency. More latency efficient scheduling can mitigate the issue. The upstream scheduler may also be moved out to the RPD/node in the future, if necessary.

Has the distance been increased in Vodafone's deployments?

[Edd1ng]

I think it's purely due to a conservatively configured scheduler. Several people have noticed higher average latency and significantly higher jitter.
My average latency is about 4 ms higher than on the bare-metal Arris CMTS before.
The jitter has also increased a lot.
That said, I still see the 4-5 ms minimum when pushing upstream traffic, so low latency is still possible.