DOCSIS 3.1 Kanal für Upload nun verfügbar?

[Flole]

Was du schreibst gilt für FritzBoxen mit den aktuellen Firmware versionen, bei anderen Modems stehen teilweise andere Dinge im Webinterface. Mein TG3442 zum Beispiel rechnet das direkt auf 6.4MHz um und zeigt das entsprechend an, die Pegel die dort dargestellt werden sind also identisch (bzw. fast identisch) mit den SC-QAM Pegeln. Das muss man einfach wissen bzw. interpretieren, denn das steht nicht dran. Und das TG3442 habe ich jetzt nur mal exemplarisch herausgepickt, das sieht aber bei anderen Modems teilweise genauso aus.

[mar123]

Ich möchte einmal ein Update zu meiner Erfahrung seit der Aufschaltung des OFDMA-Kanals geben (alter Beitrag: viewtopic.php?p=704642#p704642).

Die volle Upload-Geschwindigkeit kommt hier inzwischen wieder ziemlich durchgängig an, große Einbrüche gab es jetzt schon länger nicht mehr. Das war anfangs noch ziemlich anders, da hatte ich meistens weniger als 20MBit.

Seit dem 11.09. habe ich regelmäßig den Upload der Hetzner 10GB-Testdatei (https://speed.hetzner.de/10GB.bin) auf mein Google Drive mit dem Programm "NetTraffic" zur Überprüfung der Uploadgeschwindigkeit aufgezeichnet.

Anbei dazu meine Grafiken, die den vollständigen Upload zeigen + Zusatzinfos dazu (OFDMA-Modulation + T3-Timeouts - ermittelt mit FRITZ!Box Support-Log): (mehrere Grafiken wurden wegen der Limitierungen von NetTraffic zusammengefügt)

24-27_20210911_2213-2240_64QAM_T3x2.png

29-32_20210912_1420-1448_128QAM_T3x2.png

33-36_20210912_2253-2320_128QAM_T3x0.png

37-40_20210913_2134-2201_64QAM_T3x1.png

41-45_20210916_1508-1536_64QAM_T3x1.png

50-53_20210917_1035-1102_64QAM_T3x0.png

54-57_20210918_2122-2150_128QAM_T3x0.png

58-61_20210919_1900-1927_64QAM_T3x0.png

64-67_20210920_1409-1436_256QAM_T3x0.png

68-71_20210920_2123-2150_256QAM_T3x0.png

72-75_20210921_2034-2101_256QAM_T3x1.png

76-79_20210922_2115-2142_256QAM_T3x1.png

83-86_20210923_1107-1134_256QAM_T3x0.png

87-90_20210926_0800-0827_256QAM_T3x0.png

91-94_20210929_0201-0228_256QAM_T3x0.png

95-98_20210930_1223-1250_256QAM_T3x1.png

99-102_20211001_0847-0914_256QAM_T3x0.png

Bei einigen der Graphen sieht man die Einbrüche noch ganz gut, am Anfang war es aber deutlich extremer, leider hatte ich da noch keine Graphen mit dem Programm aufgezeichnet.

Die Modulation des OFDMA-Kanals war in der ersten Zeit meist bei 64QAM mit kurzen Phasen 128QAM. Nach längerer Zeit ist es dann aber auf 256QAM gewechselt und dabei bis jetzt auch bis auf minimale Unterbrechungen geblieben.
Der DOCSIS-Eventlog ist inzwischen auch ziemlich ruhig geworden: (Stand des Logs: 02.10.2021 08:03, letzter Neustart 11.09.2021 19:48)

Code: Alles auswählen

DOCSIS CM Eventlog:
   21: 2021-09-11 19:48:37 90000000 warning   MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1
   22: 2021-09-11 19:48:42 82001200 warning   RNG-RSP CCAP Commanded Power in Excess of 6 dB Below the Value Corresponding to the Top of the DRW
   23: 2021-09-11 19:48:42 82000200 critical  No Ranging Response received - T3 time-out
     - 2021-09-11 19:49:08 2 times
   24: 2021-09-11 19:49:43 67061601 notice    US profile assignment change.  US Chan ID: 10
     - 2021-09-11 20:12:32 3 times
   25: 2021-09-11 22:29:15 82000200 critical  No Ranging Response received - T3 time-out
     - 2021-09-12 06:32:27 6 times
   26: 2021-09-12 07:47:59 67061601 notice    US profile assignment change.  US Chan ID: 10
   27: 2021-09-12 09:13:31 82000200 critical  No Ranging Response received - T3 time-out
     - 2021-09-13 01:19:54 12 times
   28: 2021-09-13 01:22:02 67061601 notice    US profile assignment change.  US Chan ID: 10
   29: 2021-09-13 04:00:58 82000200 critical  No Ranging Response received - T3 time-out
     - 2021-09-14 13:49:26 27 times
   30: 2021-09-14 16:25:10 67061601 notice    US profile assignment change.  US Chan ID: 10
   31: 2021-09-14 16:30:53 82000200 critical  No Ranging Response received - T3 time-out
     - 2021-09-14 17:48:30 3 times
   32: 2021-09-14 18:07:06 67061601 notice    US profile assignment change.  US Chan ID: 10
     - 2021-09-14 19:04:32 2 times
   33: 2021-09-14 20:16:57 82000200 critical  No Ranging Response received - T3 time-out
     - 2021-09-14 22:36:21 5 times
   34: 2021-09-14 23:25:34 67061601 notice    US profile assignment change.  US Chan ID: 10
   35: 2021-09-15 00:47:08 82000200 critical  No Ranging Response received - T3 time-out
     - 2021-09-15 04:20:09 5 times
   36: 2021-09-15 06:12:17 82001200 warning   RNG-RSP CCAP Commanded Power in Excess of 6 dB Below the Value Corresponding to the Top of the DRW
     - 2021-09-15 06:16:23 4 times
   37: 2021-09-15 06:48:34 82000200 critical  No Ranging Response received - T3 time-out
     - 2021-09-18 06:36:05 45 times
   38: 2021-09-18 09:03:10 67061601 notice    US profile assignment change.  US Chan ID: 10
   39: 2021-09-18 10:12:25 82000200 critical  No Ranging Response received - T3 time-out
     - 2021-09-18 11:15:44 4 times
   40: 2021-09-18 11:39:45 67061601 notice    US profile assignment change.  US Chan ID: 10
   41: 2021-09-18 12:50:21 82000200 critical  No Ranging Response received - T3 time-out
     - 2021-09-18 13:22:04 3 times
   42: 2021-09-18 14:26:39 67061601 notice    US profile assignment change.  US Chan ID: 10
   43: 2021-09-18 15:00:12 82000200 critical  No Ranging Response received - T3 time-out
     - 2021-09-19 05:53:40 8 times
   44: 2021-09-19 06:21:43 67061601 notice    US profile assignment change.  US Chan ID: 10
   45: 2021-09-19 07:39:35 82000200 critical  No Ranging Response received - T3 time-out
     - 2021-09-20 07:53:29 25 times
   46: 2021-09-20 09:21:46 67061601 notice    US profile assignment change.  US Chan ID: 10
     - 2021-09-20 10:02:56 2 times
   47: 2021-09-20 10:09:12 82000200 critical  No Ranging Response received - T3 time-out
     - 2021-09-29 00:00:42 146 times
   48: 2021-09-29 01:16:57 74010100 notice    CM-STATUS message sent.  Event Type Code: 24
     - 2021-09-29 01:23:32 3 times
   49: 2021-09-29 03:53:23 82000200 critical  No Ranging Response received - T3 time-out
     - 2021-09-29 05:21:12 2 times
   50: 2021-09-29 08:34:42 74010100 notice    CM-STATUS message sent.  Event Type Code: 5
     - 2021-09-29 08:34:43 2 times
   51: 2021-09-29 09:15:31 82000200 critical  No Ranging Response received - T3 time-out
     - 2021-09-30 23:56:52 36 times
   52: 2021-10-01 00:38:54 67061601 notice    US profile assignment change.  US Chan ID: 10
     - 2021-10-01 01:18:44 4 times
   53: 2021-10-01 01:31:30 82000200 critical  No Ranging Response received - T3 time-out
     - 2021-10-01 23:42:58 22 times
   54: 2021-10-02 00:35:37 67061601 notice    US profile assignment change.  US Chan ID: 10
     - 2021-10-02 00:36:46 2 times
   55: 2021-10-02 04:22:03 82000200 critical  No Ranging Response received - T3 time-out
     - 2021-10-02 07:03:14 5 times

Upstream-Werte aus dem selben Support-Log: (Sendepegel sind niedriger als bei meinem letzten Post, da ich die Upstream-Verstärkung des Verstärkers angepasst habe)

Code: Alles auswählen

  Single-Carrier Channels: 8 (4 currently active)
   ID | Active | Frequency | SymRate | ChWidth | Attenuation | Power  | Power16 |  P-High  |  P-Low   | P-DRW-High | P-DRW-Low | DeltaPF |   Mod   |  Mux
      |        |   [MHz]   |  [MHz]  |  [kHz]  |    [dB]     | [dBmV] | [dBmV]  | [dBmV]   |  [dBmV]  |   [dBmV]   |   [dBmV]  |   [dB]  |         |
  ----+--------+-----------+---------+---------+-------------+--------+---------+----------+----------+------------+-----------+---------+---------+------
    6 |    YES |    44.600 |   5.120 |    6400 |      16.065 | 44.021 | 38.000  |   49.500 |   17.000 |     40.750 |    28.750 |   0.000 |   64QAM | ATDMA
    8 |    YES |    30.800 |   5.120 |    6400 |      18.248 | 42.021 | 36.000  |   49.500 |   17.000 |     40.750 |    28.750 |   0.000 |   64QAM | ATDMA
    7 |    YES |    37.200 |   5.120 |    6400 |      18.248 | 42.021 | 36.000  |   49.500 |   17.000 |     40.750 |    28.750 |   0.000 |   64QAM | ATDMA
    5 |    YES |    51.000 |   5.120 |    6400 |      15.769 | 44.021 | 38.000  |   49.500 |   17.000 |     40.750 |    28.750 |   0.000 |   64QAM | ATDMA
    0 |     NO |     9.961 |   0.000 |       0 |       0.000 |  0.000 |  0.000  |    0.000 |    0.000 |      0.000 |     0.000 |   0.000 |      er | ATDMA
    0 |     NO |     9.961 |   0.000 |       0 |       0.000 |  0.000 |  0.000  |    0.000 |    0.000 |      0.000 |     0.000 |   0.000 |      er | ATDMA
    0 |     NO |     9.961 |   0.000 |       0 |       0.000 |  0.000 |  0.000  |    0.000 |    0.000 |      0.000 |     0.000 |   0.000 |      er | ATDMA
    0 |     NO |     9.961 |   0.000 |       0 |       0.000 |  0.000 |  0.000  |    0.000 |    0.000 |      0.000 |     0.000 |   0.000 |      er | ATDMA

  Multi-Carrier (OFDMA) Channels: 2 (1 currently active)
   ID | Active | First Subcarrier | Last Subcarrier | Active Subcarriers | Max Mod |  Gain  | Power  |  FFT Size
      |        |       [MHz]      |      [MHz]      |                    |         |  [dB]  | [dBmV] |
  ----+--------+------------------+-----------------+--------------------+---------+--------+--------+-----------
    0 |    YES |           29.800 |          64.750 |                640 |  256QAM |  0.156 | 39.000 | 4K
    1 |     NO |            0.000 |           0.000 |                  0 |       0 |  0.000 |  0.000 | None

Der Jitter ist hier interessanterweise wieder auf dem alten Level (vor der OFDMA-Aufschaltung) seit dem Wechsel der OFDMA-Modulation auf 256QAM. Der Unterschied beim Jitter zwischen 64QAM und 256QAM (128QAM ist vergleichbar mit 64QAM) lässt sich beim folgenden ThinkBroadband-Graphen ganz gut erkennen, da dort von 00:27-06:01 Uhr (bei ThinkBroadband 23:27-05:01 Uhr wegen anderer Zeitzone) kurzzeitig 256QAM anlagen:

11-09-2021.png

Der DOCSIS-Log zeigt den Modulations-Wechsel dazu:

Code: Alles auswählen

   59: 2021-09-11 00:27:17 67061601 notice    US profile assignment change.  US Chan ID: 10
   60: 2021-09-11 00:54:50 82000200 critical  No Ranging Response received - T3 time-out
   61: 2021-09-11 02:34:18 82001200 warning   RNG-RSP CCAP Commanded Power in Excess of 6 dB Below the Value Corresponding to the Top of the DRW
     - 2021-09-11 02:34:18 2 times
   62: 2021-09-11 02:57:19 82000200 critical  No Ranging Response received - T3 time-out
     - 2021-09-11 05:38:22 2 times
   63: 2021-09-11 06:01:44 67061601 notice    US profile assignment change.  US Chan ID: 10
     - 2021-09-11 06:30:29 4 times

Zur Veranschaulichung des Jitter-Unterschieds hänge ich einem weiteren Post (wegen Bilder-Limit für diesen Post) noch drei ThinkBroadband- und Pingplotter-Graphen an.

[mar123]

Zur Veranschaulichung des Jitter-Unterschieds nachfolgend noch drei ThinkBroadband- und Pingplotter-Graphen:

15-08-2021.png

13-09-2021.png

03-10-2021.png

Jitter8.8.8.8-15.08.2021.PNG

Jitter8.8.8.8-13.09.2021.PNG

Jitter8.8.8.8-04.10.2021.PNG

[NoNewbie]

Was du schreibst gilt für FritzBoxen mit den aktuellen Firmware versionen, bei anderen Modems stehen teilweise andere Dinge im Webinterface. Mein TG3442 zum Beispiel rechnet das direkt auf 6.4MHz um und zeigt das entsprechend an, die Pegel die dort dargestellt werden sind also identisch (bzw. fast identisch) mit den SC-QAM Pegeln. Das muss man einfach wissen bzw. interpretieren, denn das steht nicht dran. Und das TG3442 habe ich jetzt nur mal exemplarisch herausgepickt, das sieht aber bei anderen Modems teilweise genauso aus.

Habe noch nicht einen Screenshot gesehen, wo angezeigt wird, dass der OFDMA auf 6,4MHz hochgerechnet wird.
Kannst du mal bitte einen hochladen.

[Flole]

Den brauch ich gar nicht hochladen, jemand anders hatte das freundlicherweise schonmal hier im Thread vor ein paar Seiten übernommen:

Nachdem auf dem gestern angeschlossenen Austausch Gerät (wieder Arris Vodafone Station TG3442DE), nun die aktuelle Firmware (AR01.02.068.13_052421_711.PC20.10) über Nacht problemlos installiert wurde hier noch mal ein richtiger Screenshot.
Screenshot_20210807-061226_Chrome.jpg

Entweder dort sendet der OFDMA Kanal 6dB stärker (was natürlich überhaupt keinen Sinn macht), oder es wird entsprechend schon einmal umgerechnet. So verhält sich das übrigens auch für freie TG3442 (wo ich es dann auf einem Diagnosegerät auch über die Kommandozeile überprüfen kann, da steht nämlich dann daneben worauf es sich jeweils bezieht).

[robert_s]

Entweder dort sendet der OFDMA Kanal 6dB stärker (was natürlich überhaupt keinen Sinn macht), oder es wird entsprechend schon einmal umgerechnet. So verhält sich das übrigens auch für freie TG3442 (wo ich es dann auf einem Diagnosegerät auch über die Kommandozeile überprüfen kann, da steht nämlich dann daneben worauf es sich jeweils bezieht).

Das erscheint mir aber nicht sinnvoll. Wenn man schon "ähnliche" Werte anzeigen wollte, würde ich doch eher zum P1.6r_n Wert tendieren, denn den hat man ja offenbar in der DOCSIS-Spezifikation zur "übergreifenden Referenz" erhoben.

Der Technicolor CGA6444VF macht das übrigens offenbar NICHT, denn da bekomme ich aktuell 41,1dBmv für den OFDMA angezeigt und 4x 47,8dBmV für die SC-QAM Upstreams.

[NoNewbie]

Den brauch ich gar nicht hochladen, jemand anders hatte das freundlicherweise schonmal hier im Thread vor ein paar Seiten übernommen:

Nachdem auf dem gestern angeschlossenen Austausch Gerät (wieder Arris Vodafone Station TG3442DE), nun die aktuelle Firmware (AR01.02.068.13_052421_711.PC20.10) über Nacht problemlos installiert wurde hier noch mal ein richtiger Screenshot.
Screenshot_20210807-061226_Chrome.jpg

Entweder dort sendet der OFDMA Kanal 6dB stärker (was natürlich überhaupt keinen Sinn macht), oder es wird entsprechend schon einmal umgerechnet. So verhält sich das übrigens auch für freie TG3442 (wo ich es dann auf einem Diagnosegerät auch über die Kommandozeile überprüfen kann, da steht nämlich dann daneben worauf es sich jeweils bezieht).

Da steht gar nichts vom Umrechnen. Das denkst du dir blos aus.
Entweder du zeigst hier etwas, was das Umrechnen belegt oder es bleibt ein Hirngespinst von dir.
Es macht ja auch gar keinen Sinn einen Träger auf irgend etwas umzurechnen, was er gar nicht ist.
Das hat man noch nie gemacht, obwohl es z.B. das Einpegeln im Dowstream erheblich vereinfachen würde.

[maik005]

Es ist ein totales Durcheinander.
Ein Techniker der hier war meinte auch in seinen "Schulungsunterlagen" zu DOCSIS 3.1 stand der Hinweis drin beim OFDMA zum angezeigten Wert des Modems 6dB dazu zu addieren um den tatsächlichen Wert zu bekommen.
Das passt ja auch zu den Berichten hier.
Nur, dass es beim TG3442DE von VF nach hinten los geht, weil dieses den Pegel des OFDMA schon anders berechnet.

[Flole]

Den brauch ich gar nicht hochladen, jemand anders hatte das freundlicherweise schonmal hier im Thread vor ein paar Seiten übernommen:

Nachdem auf dem gestern angeschlossenen Austausch Gerät (wieder Arris Vodafone Station TG3442DE), nun die aktuelle Firmware (AR01.02.068.13_052421_711.PC20.10) über Nacht problemlos installiert wurde hier noch mal ein richtiger Screenshot.
Screenshot_20210807-061226_Chrome.jpg

Entweder dort sendet der OFDMA Kanal 6dB stärker (was natürlich überhaupt keinen Sinn macht), oder es wird entsprechend schon einmal umgerechnet. So verhält sich das übrigens auch für freie TG3442 (wo ich es dann auf einem Diagnosegerät auch über die Kommandozeile überprüfen kann, da steht nämlich dann daneben worauf es sich jeweils bezieht).

Da steht gar nichts vom Umrechnen. Das denkst du dir blos aus.

Richtig da steht nichts von umrechnen. Aber nochmal: Dasselbe Verhalten sehe ich auf einem Diagnose TG3442 ebenfalls. Dort wird der Power Wert doppelt angegeben, jeweils mit entsprechender Beschriftung auf was es sich bezieht.

Entweder du zeigst hier etwas, was das Umrechnen belegt oder es bleibt ein Hirngespinst von dir.

Ich könnte dir den Quellcode der es berechnet und an das Webinterface übergibt für eines der Referenz-Designs zeigen, die verhalten sich nämlich genauso. Dafür müsstest du mir nur das schriftliche Einverständnis von MaxLinear (bzw. der ehemaligen Intel CHD) das ich diese vertraulichen Informationen weitergeben darf. Die stehen nämlich unter einem NDA.

Es macht ja auch gar keinen Sinn einen Träger auf irgend etwas umzurechnen, was er gar nicht ist.

Er ist aber weder 6.4MHz noch 1.6MHz breit, damit muss also umgerechnet werden. Entweder auf das eine oder auf das andere. Allein da geht diese These schon völlig ins leere. Ignorieren wir das für einen Moment aber mal: Macht es Sinn, dass eine FritzBox und ein TG3442 bei identischen SC-QAM Pegeln am selben Anschluss plötzlich im OFDMA 6dB Unterschied haben? Nicht wirklich....

Das hat man noch nie gemacht, obwohl es z.B. das Einpegeln im Dowstream erheblich vereinfachen würde.

Und wieder einmal zeigst du, dass du überhaupt nicht verstanden hast worum es eigentlich geht. Im Downstream werden die Kanäle je nach Provider unterschiedlich stark eingespeist. Wenn Vodafone dort was draufrechnen lassen würde hätte man genau dieses Chaos das man sich nicht weiß worauf sich eigentlich was bezieht zwischen Leih- und Fremdgeräten. Und man traut den Technikern die Addition einer einstelligen positiven Zahl wohl gerade noch zu, obwohl einige damit wohl offenbar kleine Probleme haben und sich das lieber ausrechnen lassen würden.....

Aber bei dem was du hier von dir gibst wundert es mich überhaupt gar nicht das es bei Vodafone mit dem OFDMA teilweise Probleme gibt..... Wenn die Techniker alle so ein Fachwissen haben und sich ohne Sinn und Verstand auf noch so unplausible Messwerte verlassen kann das ja nur schief gehen...

[Flole]

Entweder dort sendet der OFDMA Kanal 6dB stärker (was natürlich überhaupt keinen Sinn macht), oder es wird entsprechend schon einmal umgerechnet. So verhält sich das übrigens auch für freie TG3442 (wo ich es dann auf einem Diagnosegerät auch über die Kommandozeile überprüfen kann, da steht nämlich dann daneben worauf es sich jeweils bezieht).

Das erscheint mir aber nicht sinnvoll. Wenn man schon "ähnliche" Werte anzeigen wollte, würde ich doch eher zum P1.6r_n Wert tendieren, denn den hat man ja offenbar in der DOCSIS-Spezifikation zur "übergreifenden Referenz" erhoben.

Der Technicolor CGA6444VF macht das übrigens offenbar NICHT, denn da bekomme ich aktuell 41,1dBmv für den OFDMA angezeigt und 4x 47,8dBmV für die SC-QAM Upstreams.

Sinnvoll ist es definitiv nicht, aber so wird es gemacht. Die CGA* Modelle sind auch nicht Intel/MaxLinear basiert. Mich würde es nicht wundern wenn der Code dort einfach nicht angetastet wurde und direkt aus dem SDK übernommen wurde, ebenso wie bei Arris. Wer einmal das Webinterface eines freien TG3442 mit dem der Referenzimplementierung verglichen hat und festgestellt hat, dass der einzige auf den ersten Blick offensichtlich Unterschied eigentlich nur im Logo besteht dürfte sich darüber kaum wundern.

AVM bewegt sich ja schon immer etwas weiter weg von der Referenzimplementierung (dort bastelt man ja sogar selbst an der Hardwarebeschleunigung rum, mehr oder weniger erfolgreich). Insofern würde es mich nicht wundern wenn das aktuell der einzige Hersteller ist der es dort "anders" angibt als alle anderen.