#1  (Permalink
Alt 24.05.2015, 14:48
user user ist offline
Mitglied
 
Registriert seit: 31.07.2005
Beiträge: 77
Standard VDSL2 Overhead Berechnung

Hi,
da ich jedes Mal einen dicken Hals bekomme bei der unklaren Berechnung zwischen Nutzlast Ausbeute und Overhead eines VDSL2 Anschlusses, hiermit meine Überlegung.
  1. Motivation
    Berechnung des Overheads eines Schicht 3 Pakets bezogen auf die VDSL2 Leitung
  2. Konfigurationsbeschreibung der VDSL2 Leitung
    ITU G.993.2 Annex B (VDSL2) [Quelle nicht gesichert]
    Type 3: Ethernet and generic packet transport (PTM-TC) [Quelle nicht gesichert]
    The 64/65-octet encapsulation [Quelle nicht gesichert]
  3. Technische Leitungsbeschreibung
    ITU-T G.993.2 (12/2011) Very high speed digital subscriber line transceivers 2 (VDSL2) [https://www.itu.int/rec/T-REC-G.993.2/en]
    "The functionality of the PTM-TC shall implement 64/65-octet encapsulation as defined in Annex N of [ITU-T G.992.3]"
    "For frame error monitoring, the transmitting PTM-TC shall insert the 16-bit CRC defined in clause N.3.3 of [ITU-T G.992.3]"
    G.992.3 (04/2009) Asymmetric digital subscriber line transceivers 2 (ADSL2) [https://www.itu.int/rec/T-REC-G.992.3/en]
    Annex N (64/65-octet PTM-TC sublayer functional specifications)
    "The basic encapsulation and coding shall comply with clause 61.3.3 of [IEEE 802.3]"
    "NOTE 2 – If the PTM-TC carries IEEE 802.3 (Ethernet) packets, the packet length is at least 64 octets, in
    which case the codeword formats to support short packets do not occur."
    "NOTE 3 – If the PTM-TC defined in this annex carries a single Ethernet packet flow (no preemption and no
    short packets), it is identical to the Ethernet packet encapsulation defined in clause 61.3 of [IEEE 802.3]."
    "NOTE 4 – If the PTM-TC carries IEEE 802.3 (Ethernet) packets, it is assumed that the preamble and
    SFD fields have been discarded by the PTM entity before transmitting the packets to the PTM-TC. See
    clause 61.1.4.1.2 of [IEEE 802.3]."
    IEEE Standard for Ethernet (802.3-2012 section 5)[https://standards.ieee.org/about/get/802/802.3.html]
    61.3 TC sublayer functional specifications
    61.3.2.1 α(β) data flow: reference G.993.1 section 7.1.1
    "PMA_PMD_type 8 bit Signal indicating PMA/PMD mode of operation."
    61.3.3.1 TC encapsulation and coding
    "A TC fragment consists of a fragment, followed by a 16- or 32-bit CRC (referred to as the TC-CRC) as defined in 61.3.3.3."
    61.3.3.3 TC-CRC functions
    "The first 32 bits (in the case of 2BASE-TL) or the first 16 bits (in the case of 10PASS-TS) of the payload are complemented."
  4. Betrachtung Overhead Schicht 2 Paket bezogen auf VDSL2 Leitung
    64/65-octet encapsulation = 1 Byte SyncOctet + 64 Codewords
    64 Codewords = max. 62 Byte Idle/Nutzlast + 2 Bytes TC-CRC
    PTM-TC + 64/65 Overhead durch Transport eines Schicht 2 Pakets mit min. Nutzlast (64 Bytes Ethernet frame):
    Code:
     2x 1 Byte Sync Octet (PMA_PMD_type)
     2x 2 Bytes TC-CRC (16-Bit CRC aka 10PASS-TS)
     =  6 Bytes Overhead
    PTM-TC + 64/65 Overhead durch Transport eines Schicht 2 Pakets mit max. Nutzlast (1522 Bytes Ethernet frame):
    Code:
    25x 1 Byte Sync Octet (PMA_PMD_type)
    25x 2 Bytes TC-CRC (16-Bit CRC aka 10PASS-TS)
     = 75 Bytes Overhead
  5. Betrachtung Overhead Schicht 3 Paket bezogen auf VDSL2 Leitung

    Overhead durch Transport eines Schicht 3 Pakets mit 0 Byte Nutzlast:
    Code:
       8 Bytes PPPoE
      22 Bytes Ethernet frame header (mit VLAN [802.1Q])
       6 Bytes Overhead nach 64/65 Kodierung (min. Nutzlast Schicht 2)
    = 36 Bytes Overhead
    Overhead durch Transport eines Schicht 3 Paket mit max. 1492 Bytes Nutzlast:
    Code:
       8 Bytes PPPoE
      22 Bytes Ethernet frame header (mit VLAN [802.1Q])
      75 Bytes Overhead nach 64/65 Kodierung (max. Nutzlast Schicht 2)
    =105 Bytes Overhead
  6. Zusammenfassung
    Für die Übertragung eines maximal großen Schicht 3 Pakets (z.B. IP/TCP Paket) fallen 105 Bytes Overhead an den unteren Schichten an.

Geändert von user (24.05.2015 um 15:01 Uhr)
Mit Zitat antworten
  #2  (Permalink
Alt 24.05.2015, 15:04
Benutzerbild von robert_s
robert_s robert_s ist gerade online
Senior Mitglied
 
Registriert seit: 17.03.2003
Ort: Berlin
Beiträge: 15.626
Provider: Vodafone Kabel
Bandbreite: 1,150/0,05671 Gbit/s
Standard AW: VDSL2 Overhead Berechnung

Zitat:
Zitat von user Beitrag anzeigen
[*]Betrachtung Overhead Schicht 2 Paket bezogen auf VDSL2 Leitung
64/65-octet encapsulation = 1 Byte SyncOctet + 64 Codewords
64 Codewords = max. 62 Byte Idle/Nutzlast + 2 Bytes TC-CRC
Nee, das ist falsch. Ein Paket der nächsthöheren Schicht kann sich über mehrere 64/65-Worte erstrecken, und dabei fallen Start und Stop nur einmal an, d.h. es gibt auch 64/65-Worte, in denen 64 Bytes nur Nutzdaten der nächsthöheren Schicht enthalten.

Meine Rechnung:

Maximal großer Ethernet-Frame mit FCS und VLAN-Tag = 1522 Bytes + Start + TM-CRC + Stop = 1526 Bytes * 65 / 64 = ~1550 Bytes.

-> Overhead bezogen auf PPP-Payload (IP-Paket) = 58 Bytes
-> Overhead bezogen auf TCPv4-Payload = 98 Bytes
-> Overhead bezogen auf TCPv6-Payload = 118 Bytes

Zum Vergleich: ATM-Overhead (alte ADSL/ADSL2+ Anschlüsse): Ein maximal großer Ethernet-Frame benötigt 32 ATM-Zellen = 1696 Bytes.

-> Overhead bezogen auf PPP-Payload (IP-Paket) = 204 Bytes
-> Overhead bezogen auf TCPv4-Payload = 244 Bytes
-> Overhead bezogen auf TCPv6-Payload = 264 Bytes

Man sieht also, dass der Wechsel von ATM auf PTM den Overhead um über 50% reduziert hat...

Geändert von robert_s (24.05.2015 um 15:09 Uhr)
Mit Zitat antworten
  #3  (Permalink
Alt 24.05.2015, 21:03
user user ist offline
Mitglied
 
Registriert seit: 31.07.2005
Beiträge: 77
Standard AW: VDSL2 Overhead Berechnung

Danke dir robert_s
61.3.3.1 TC encapsulation and coding
"... The end of a TC fragment is always marked with an “end of frame” or “start of frame while transmitting” codeword ..."
61.3.3.3 TC-CRC functions
"... The TC-CRC is added to the data stream after the end of the fragment in the transmitdirection. ..."


TC-CRC also nur einmal je überliegender Nutzlast Einheit punkt ein Stop Byte

@Mod
Ich würde gerne den ersten Beitrag noch einmal bearbeiten dürfen, damit andere Leser nicht blind das Unrichtige kopieren.
Mit Zitat antworten
  #4  (Permalink
Alt 24.05.2015, 22:50
user user ist offline
Mitglied
 
Registriert seit: 31.07.2005
Beiträge: 77
Standard AW: VDSL2 Overhead Berechnung

Ich gehe davon aus das _ein_ Schicht 2 Paket immer in _ein_ TC Fragment abgetragen wird.
61.3.3.1 TC encapsulation and coding
"all data: all of the octets in the codeword belong to the same TC fragment."
"end of frame (go to idle): up to 63 octets in the codeword belong to the same TC fragment, the rest of the codeword consists of Idle octets"
"end of frame (start new frame): up to 62 octets in the codeword belong to the same TC fragment, a number of Idle octets and a single Start of Frame octet precede the first data octets of the next TC fragment"
"idle: all of the octets in the codeword are Idle octets"
"idle (start new frame): a number of Idle octets and a single Start of Frame octet precede up to 63 data octets of the next TC fragment"
"out-of-sync idle: all of the octets in the codeword are idle octets and the 64/65-octet receive state diagram is out-of-sync (TC_synchronized = FALSE)."
Wir nehmen durchgehend Sync Octet "end of frame (start new frame)" in der Betrachtung an.

PTM-TC + 64/65 Overhead durch Transport eines Schicht 2 Pakets mit min. Nutzlast (64 Bytes Ethernet frame):
Code:
  1 Byte  "Start of Frame" Octet (in vorherigen TC Fragment)
  1 Byte  Sync Octet" end of frame (start new frame)"
  2 Bytes TC-CRC
  1 Byte  Idle Octet (Annahme: immer nur ein Idle Octet das dem nächsten "Start of Frame" Octet vorrangeht)
= 5 Bytes Overhead
Wenn das "Start of Frame" Octet unglücklich im vorherigen TC Fragment beginnt, kommt ein zusätzliches ein Byte Sync Octet "all data" zum Overhead dazu.

PTM-TC + 64/65 Overhead durch Transport eines Schicht 2 Pakets mit min. Nutzlast (1522 Bytes Ethernet frame):
Code:
  1 Byte  "Start of Frame" Octet (in vorherigen TC Fragment)
 23 Bytes Sync Octet "all data"
  1 Byte  Sync Octet "end of frame (start new frame)"
  2 Bytes TC-CRC
  1 Byte  Idle Octet (Annahme: immer nur ein Idle Octet das dem nächsten "Start of Frame" Octet vorrangeht)
=28 Bytes Overhead
Wenn bereits 62 Nutzlast Bytes in vorherigen TC Fragment abgetragen sind, reduziert sich der Overhead um ein Byte Sync Octet "all data".

Bleibt die Frage, ob ein "End of frame (start new frame)" auch ohne Idle Octet erlaubt ist?
"... The Start of Frame octet S is distinct from the Idle octet Z. ..."

Geändert von user (24.05.2015 um 23:00 Uhr)
Mit Zitat antworten
  #5  (Permalink
Alt 25.05.2015, 00:52
Benutzerbild von robert_s
robert_s robert_s ist gerade online
Senior Mitglied
 
Registriert seit: 17.03.2003
Ort: Berlin
Beiträge: 15.626
Provider: Vodafone Kabel
Bandbreite: 1,150/0,05671 Gbit/s
Standard AW: VDSL2 Overhead Berechnung

Zitat:
Zitat von user Beitrag anzeigen
Bleibt die Frage, ob ein "End of frame (start new frame)" auch ohne Idle Octet erlaubt ist?
Ja, natürlich. Siehe Tabelle N.1 in G.992.5, da steht, dass 0 bis 62 Bytes des letzten Frames, oder bis 0 bis 62-k desn neuen Frames enthalten sein können. Zzgl. Ck + S sind das 64 Bytes, da ist also kein Idle Byte mehr drin.

Ich finde Du rechnest das etwas unanschaulich. Betrachte "Sync Octet" doch einfach eine Protokollebene tiefer als die "Octet Fields". Dann kommen in den "Octet Fields" auf jeden Ethernet-Frame immer erst mal 4 zusätzliche Bytes drauf (S(1) + Frame(x) + TC-CRC(2) + Ck(1)). Und das Ergebnis wird dann in 64-Bytes Häppchen zerhackt und vor jedes ein "Sync Octet" gesetzt. Also:

(Ethernet-Framegröße + 4) * 65 / 64

Gibt natürlich krumme Werte, wenn der Ausdruck in den Klammern nicht glatt durch 64 teilbar ist - dann stehen eben noch weitere Bytes im ersten und/oder letzten "Octet Field" zur Verfügung. Deshalb gibt es eben keinen aufs Byte genauen Overhead für einen Ethernet-Frame maximaler Größe. Der Overhead ist 27,84375 Bytes, oder für 32 aufeinanderfolgendes Ethernet-Frames maximaler Größe 891 Bytes, wenn man unbedingt ganze Zahlen haben will...
Mit Zitat antworten
  #6  (Permalink
Alt 25.05.2015, 01:17
pufferueberlauf pufferueberlauf ist offline
Senior Mitglied
 
Registriert seit: 20.06.2013
Beiträge: 7.020
Standard AW: VDSL2 Overhead Berechnung

Zitat:
Zitat von robert_s Beitrag anzeigen
Ja, natürlich. Siehe Tabelle N.1 in G.992.5, da steht, dass 0 bis 62 Bytes des letzten Frames, oder bis 0 bis 62-k desn neuen Frames enthalten sein können. Zzgl. Ck + S sind das 64 Bytes, da ist also kein Idle Byte mehr drin.

Ich finde Du rechnest das etwas unanschaulich. Betrachte "Sync Octet" doch einfach eine Protokollebene tiefer als die "Octet Fields". Dann kommen in den "Octet Fields" auf jeden Ethernet-Frame immer erst mal 4 zusätzliche Bytes drauf (S(1) + Frame(x) + TC-CRC(2) + Ck(1)). Und das Ergebnis wird dann in 64-Bytes Häppchen zerhackt und vor jedes ein "Sync Octet" gesetzt. Also:

(Ethernet-Framegröße + 4) * 65 / 64

Gibt natürlich krumme Werte, wenn der Ausdruck in den Klammern nicht glatt durch 64 teilbar ist - dann stehen eben noch weitere Bytes im ersten und/oder letzten "Octet Field" zur Verfügung. Deshalb gibt es eben keinen aufs Byte genauen Overhead für einen Ethernet-Frame maximaler Größe. Der Overhead ist 27,84375 Bytes, oder für 32 aufeinanderfolgendes Ethernet-Frames maximaler Größe 891 Bytes, wenn man unbedingt ganze Zahlen haben will...
Zustimmendes Kopfnicken , Bei ATM (eigentlich AAL5) war es daemlicherweise so dass jedes Ethernet/IP Paket eine ganzzahlige Anzahl von ATM Zellen füllen müsste, so dass die letzte (oft stattdessen auch die vorletzte) Zelle ausgepadded werden musste, quasi mit erzwungen idle-Octets. VDSL2s PTM ist da cleverer und signalisiert die Zugehörigkeit der Daten-octets einer "64-Octet-Zelle" über das Sync-Octet und kann neben Start und Ende auch signalisieren dass die 64 Octets Daten von 2 Paketen enthalten; idle octets treten nur dann auf wenn keine "echten" Pakete zum übertragen im Puffer des Modems liegen. Und das führt effektiv dazu, dass man die 64/65 Kodierung einfach als Größen-Expansion des Gesamtdatenstroms interpretieren kann: ( Nutzlast + alle Header ) * (65/64) = Packetgroesse die auf die Synch-Rate anzurechnen ist. Oder anders effektive Synch-Rate = rohe Synch-Rate * (64/65).
Man kann natürlich auch einen virtuellen Overhead berechnen:
((Nutzlast + alle Header ) * (65/64)) - Nutzlast
aber das ist dann halt abhängig von der Größe der Nutzlast...

Gruss
P.
Mit Zitat antworten
  #7  (Permalink
Alt 25.05.2015, 01:23
Benutzerbild von robert_s
robert_s robert_s ist gerade online
Senior Mitglied
 
Registriert seit: 17.03.2003
Ort: Berlin
Beiträge: 15.626
Provider: Vodafone Kabel
Bandbreite: 1,150/0,05671 Gbit/s
Standard AW: VDSL2 Overhead Berechnung

Zitat:
Zitat von pufferueberlauf Beitrag anzeigen
idle octets treten nur dann auf wenn keine "echten" Pakete zum übertragen im Puffer des Modems liegen.
Ich hätte mir ja von AVM mal eine Funktion gewünscht, einfach die Idle-Octets pro Sekunde in jeder Richtung zu zählen und daraus die Auslastung der VDSL2-Strecke zu berechnen und anzuzeigen. Dann würde man vermutlich schön sehen, dass am Telekom-Anschluss nie 100% Auslastung erreicht werden können, sondern immer Idle-Octets bleiben. Von wegen "da die am Anschluss des Kunden konkret erreichbare Übertragungsgeschwindigkeit von den jeweiligen physikalischen Eigenschaften der Anschlussleitung abhängt, "...
Mit Zitat antworten
  #8  (Permalink
Alt 25.05.2015, 09:44
pufferueberlauf pufferueberlauf ist offline
Senior Mitglied
 
Registriert seit: 20.06.2013
Beiträge: 7.020
Standard AW: VDSL2 Overhead Berechnung

Zitat:
Zitat von robert_s Beitrag anzeigen
Ich hätte mir ja von AVM mal eine Funktion gewünscht, einfach die Idle-Octets pro Sekunde in jeder Richtung zu zählen und daraus die Auslastung der VDSL2-Strecke zu berechnen und anzuzeigen. Dann würde man vermutlich schön sehen, dass am Telekom-Anschluss nie 100% Auslastung erreicht werden können, sondern immer Idle-Octets bleiben. Von wegen "da die am Anschluss des Kunden konkret erreichbare Übertragungsgeschwindigkeit von den jeweiligen physikalischen Eigenschaften der Anschlussleitung abhängt, "...
Sollte AVM das implementieren, werde ich mir augenblicklich eine solche Fritzbox kaufen (@AVM hier könnt Ihr einen Kunden gewinnen ).

Gruss
P.
Mit Zitat antworten
  #9  (Permalink
Alt 25.05.2015, 23:59
user user ist offline
Mitglied
 
Registriert seit: 31.07.2005
Beiträge: 77
Standard AW: VDSL2 Overhead Berechnung

Zitat:
Zitat von robert_s Beitrag anzeigen
Ja, natürlich. Siehe Tabelle N.1 in G.992.5, da steht, dass 0 bis 62 Bytes des letzten Frames, oder bis 0 bis 62-k desn neuen Frames enthalten sein können. Zzgl. Ck + S sind das 64 Bytes, da ist also kein Idle Byte mehr drin.

Ich finde Du rechnest das etwas unanschaulich. Betrachte "Sync Octet" doch einfach eine Protokollebene tiefer als die "Octet Fields". Dann kommen in den "Octet Fields" auf jeden Ethernet-Frame immer erst mal 4 zusätzliche Bytes drauf (S(1) + Frame(x) + TC-CRC(2) + Ck(1)). Und das Ergebnis wird dann in 64-Bytes Häppchen zerhackt und vor jedes ein "Sync Octet" gesetzt. Also:

(Ethernet-Framegröße + 4) * 65 / 64

Gibt natürlich krumme Werte, wenn der Ausdruck in den Klammern nicht glatt durch 64 teilbar ist - dann stehen eben noch weitere Bytes im ersten und/oder letzten "Octet Field" zur Verfügung. Deshalb gibt es eben keinen aufs Byte genauen Overhead für einen Ethernet-Frame maximaler Größe. Der Overhead ist 27,84375 Bytes, oder für 32 aufeinanderfolgendes Ethernet-Frames maximaler Größe 891 Bytes, wenn man unbedingt ganze Zahlen haben will...
So eindeutig finde ich die Definition im Dokument nicht, zum einen wird geschrieben
"end of frame (start new frame): up to 62 octets in the codeword belong to the same TC fragment, a number of Idle octets and a single Start of Frame octet precede the first data octets of the next TC fragment"
zum anderen wird aber in "Table 61–11—Codeword formats" gesagt
"start of frame while transmitting: contains last k D’sof 1st frame, where k=0 to 62; & first j D’s of 2nd frame, where j=0 to 62-k"
sprich es sind 63 Bytes zulässig, welches auch Sinn macht, damit noch mindestens ein anzeigendes "Start of Frame" Octet in das aktuelle TC Fragment reinpasst.


Ähnlich verhält es sich mit
"end of frame (go to idle): up to 63 octets in the codeword belong to the same TC fragment, the rest of the codeword consists of Idle octets"
zu
"end of frame contains k D’s, where k = 0 to 63" im "Table 61–11—Codeword formats"


Aber wer weiß, vielleicht ist es den DSL Hardware Herstellern auch zu blöd und nutzen daher ein TC Fragment nicht optimal aus.
Mit Zitat antworten
  #10  (Permalink
Alt 26.05.2015, 01:47
Benutzerbild von robert_s
robert_s robert_s ist gerade online
Senior Mitglied
 
Registriert seit: 17.03.2003
Ort: Berlin
Beiträge: 15.626
Provider: Vodafone Kabel
Bandbreite: 1,150/0,05671 Gbit/s
Standard AW: VDSL2 Overhead Berechnung

Zitat:
Zitat von user Beitrag anzeigen
So eindeutig finde ich die Definition im Dokument nicht, zum einen wird geschrieben
"end of frame (start new frame): up to 62 octets in the codeword belong to the same TC fragment, a number of Idle octets and a single Start of Frame octet precede the first data octets of the next TC fragment"
zum anderen wird aber in "Table 61–11—Codeword formats" gesagt
"start of frame while transmitting: contains last k D’sof 1st frame, where k=0 to 62; & first j D’s of 2nd frame, where j=0 to 62-k"
sprich es sind 63 Bytes zulässig, welches auch Sinn macht, damit noch mindestens ein anzeigendes "Start of Frame" Octet in das aktuelle TC Fragment reinpasst.
62, nicht 63. Und dann passt kein einziges Idle Octet mehr rein. Was findest Du da nicht eindeutig?

Zitat:
Zitat von user Beitrag anzeigen
Ähnlich verhält es sich mit
"end of frame (go to idle): up to 63 octets in the codeword belong to the same TC fragment, the rest of the codeword consists of Idle octets"
zu
"end of frame contains k D’s, where k = 0 to 63" im "Table 61–11—Codeword formats"
Wo siehst Du das Problem? Beides sagt doch das gleiche aus!?
Mit Zitat antworten
 
Anzeige
Antwort

Stichworte
vdsl overhead berechnung


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.

Gehe zu

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
EWE VDSL2/NGN on TPLink 1043ND + Spaihron 1113 VDSL2 Modem Chris3000 Regionale Provider 35 31.08.2013 08:15
Overhead? toeroe Arcor [Archiv] 11 11.02.2005 16:36
DSL Overhead Frage Rob_2 Internet via Telefonkabel (ADSL, ADSL2+, VDSL2, SVDSL, G.FAST und SDSL) 0 10.09.2004 00:45
Bandbreitenerhöhung wegen overhead? Dilor Arcor [Archiv] 2 04.01.2004 16:39
overhead crazyhopp Internet via Glasfaser (AON, GPON und Ethernet) 44 28.02.2001 12:34


Alle Zeitangaben in WEZ +1. Es ist jetzt 10:23 Uhr.


Basiert auf vBulletin®
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.