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.

[denunge]

I would say that it requires a more in-depth analysis of where the extra latency/jitter comes from. Just saying that it is due to "vCMTS" is too easy.

Are there examples of Vodafone feeding RPDs from the regular CMTS, to compare?

[Verstärker.]

I would say that it requires a more in-depth analysis of where the extra latency/jitter comes from. Just saying that it is due to "vCMTS" is too easy.

Are there examples of Vodafone feeding RPDs from the regular CMTS, to compare?

Not that I'd know of, unless the lab is experimenting on a dead horse.
The usual way is the switch from the local hub to the RPDs, while the switch in the hub is connected to the data centers (going through some machines in the hub though). Not going deeper within the topic in public.
There are special cases in which the fiber glass line is rented via a contractor using different devices to encode and decode the data, but this is considered an older technique now and is getting replaced bit by bit (due to worse MER values and possibly other faults, at least sometimes).

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.

I have to agree on the latency going higher. With a CASA C100G, the connection at my parents home was 13ms to Berlin.
With the switch CableOS, the latency has risen to something around 24ms, though I can't reproduce how the jitter was at that time. Probably lower than today, but I could be mistaken.

[denunge]

A jump from 13 to 24 ms is a lot. Thinking outside DOCSIS for a moment: Has the routing changed?

[why_not]

A jump from 13 to 24 ms is a lot. Thinking outside DOCSIS for a moment: Has the routing changed?

No, that is sadly normal for the switch from cmts to vcmts without any routing changed. DOCSIS on a vcmts is so bad in latency in many parts of germany that jitter and ping doesn't compete anymore with DSL, we are at the point in some locations the latency and jitter is higher than via LTE which should really sound all alarm bells at vodafone, but they give zero fucks about latency. It is so bad that you pretty much have to recommend anybody who doesn't need more than 300 mbps down and does have DSL as alternative to avoid DOCSIS at all costs.
Because I need more than 300 mbps down I pay since many years for a DSL and DOCSIS connection and do route everything beside large downloads via DSL. I really would love to be able to stop paying for 2 connections and just have one fiber which is fast and does have good latency, that would still be cheaper if it would cost 60+€ compared to two connections.