Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Author Topic: G.998.4 overheads  (Read 3047 times)

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
G.998.4 overheads
« on: June 24, 2018, 03:45:49 PM »

I have been struggling through G.998.4, section 8.1. I remember what Kitz wrote about overheads bringing G.993.2 throughput down to 91% in the worst case. It seems to me to that that could possibly correspond to DTU type 4 framing W = SEQ1 = 8, total overheads = 2 + 8 bytes total (ie 8 CRC bytes) per (maybe) a DTU = 2 × 64 bytes ie 2 units of PTM 64/65 payload. So that would be an efficiency of 2×64/(2×(64+1)+2+8) = 91.43% which would fit in with Kitz’s percentage. But then I know nothing at all about VDSL2.

Does that sound correct?

I would be interested to see some examples of the framing parameters from someone who has G.998.4 active. If that reasoning is correct then that would be a 1 byte CRC every 16 bytes of payload data - wow, someone is really struggling if they need such careful checks.

Perhaps some people have lines that are in one sense ok, but they have bad pulse noise / spikes, yet otherwise the attenuation is ok, hf is ok and the noise floor is not too bad. But they must be really in bad shape though if they need to sacrifice 1/11 of their throughput. I am kind-of surprised that this strategy is ever worth doing given the large performance losses due to all that completely unproductive bloat. I would have thought that a large interleave depth is the way to go because there is no throughput reduction overhead, no bloat. Although some people do get very fed up about a small amount of latency.
« Last Edit: June 24, 2018, 03:57:35 PM by Weaver »
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: G.998.4 overheads
« Reply #1 on: June 24, 2018, 04:31:12 PM »

No.

The IP Profile has nothing to do with any DSL framing numbers. All the DSL framing is already taken into account by the modem to give the net data rate a.k.a. the "sync speed". Remember that the IP profile percentage does not change depending on the level of FEC that a line might have. Nor does it change depending on the number of padding bytes in a DTU. These things would affect the net data rate.

Also take note of all those Cisco firmware release notes which state "G.INP supports DTU framing type 1 only." - which is probably a Broadcom limitation rather than something Cisco have altered.

I think the lower IP profile percentage on the Retransmission High profile is due to the SHINEratio. I think it's working with the ETR (expected throughput) rather than the NDR (net data rate). I think the idea of the SHINEratio is that it allows the operator to specify the expected loss of throughput from the retransmissions needed due to the expected amount of SHINE type noise. The SHINEratio might be set to indicate that 5% of the line's bandwidth is expected to be taken up by the retransmissions. And then the IP profile will be set based on that expected throughput (ETR).

It's not about adding some overhead bytes into the framing somewhere, it's taking into account the amount of retransmitting that's expected to happen.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: G.998.4 overheads
« Reply #2 on: June 24, 2018, 06:32:09 PM »

I think we are at cross purposes. I agree, you have to be right about the IP profile taking all of that into account already.

No I actually wasn't talking about IP profile at all. But now I realise that Kitz was in that article, no? So I got my wires crossed. Kitz will explain that percentage anyway.

So you are thinking that a certain level of retransmissions - which causes a loss of throughput of course - can be caused by a certain level of badness out there, and that particular environmental badness level is the threshold to justify going for this particular strategy.

Apologies for being thick, I am not following you with the reference to Cisco?

So Broadcom kit does not support stupid framing types anyway?

Thanks for straightening me out though. I definitely got myself confused with what is inside and what is outside IP profile.

Very very drugged up today, poor excuse I know, because the doctors have decided that enough is enough and have gone and bumped up my Fentanyl (an opioid, heroine-type painkiller) by 33% in one sudden jump, so it is quite a big shock.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: G.998.4 overheads
« Reply #3 on: June 24, 2018, 07:14:28 PM »

Cisco have published various detailed release notes such as:
https://www.cisco.com/c/en/us/td/docs/routers/access/800/firmware/release/notes/VDSL2/fwrn_a2pv6c039m.html

Which I assume are applicable to Broadcom in general. The point was, that DTU framing type 4 isn't what's being used.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: G.998.4 overheads
« Reply #4 on: June 26, 2018, 12:13:42 PM »

Perhaps someone might be kind enough to check my understanding?

Referring to some  stats posted which will serve as a concrete case. We have the framing parameters
Code: [Select]
VDSL2 framing
MSGc: -6 26
B: 227 237
M: 1 1
T: 0 34
R: 12 16
S: 0.1366 0.7732
L: 14052 2628
D: 4 1
I: 240 127
N: 240 254
Q: 4 0
V: 0 0
RxQueue: 128 0
TxQueue: 32 0
G.INP Framing: 18 0
G.INP lookback: 31 0
RRC bits: 0 24

So is that a DTU size of ( B * M + 1 + R ) * Q  =  ( 240 * 1 + 1 + 12 ) * 4  =  960 bytes?

If that is correct, quite large?
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: G.998.4 overheads
« Reply #5 on: June 26, 2018, 05:10:44 PM »

Code: [Select]
VDSL2 framing
MSGc: -6 26
B: 227 237
M: 1 1
T: 0 34
R: 12 16
S: 0.1366 0.7732
L: 14052 2628
D: 4 1
I: 240 127
N: 240 254
Q: 4 0
V: 0 0
RxQueue: 128 0
TxQueue: 32 0
G.INP Framing: 18 0
G.INP lookback: 31 0
RRC bits: 0 24

So is that a DTU size of ( B * M + 1 + R ) * Q  =  ( 240 * 1 + 1 + 12 ) * 4  =  960 bytes?

You do not appear to have used the value of B but that of either I or N in you calculation, above. <Puzzled!>  ???
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: G.998.4 overheads
« Reply #6 on: June 26, 2018, 05:34:18 PM »

Perhaps Figure 8-1 in G.998.4 might make it clearer.

A DTU is Q RS codewords, so it's size is Q * N. 240 * 4 = 960.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: G.998.4 overheads
« Reply #7 on: June 27, 2018, 04:25:29 PM »

Isn't N just a derived thing though? That’s why I did not use it.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: G.998.4 overheads
« Reply #8 on: September 26, 2020, 09:17:36 PM »

Where I first mentioned 240 + 1 + 12 it should have read 227 + 1 + 12 which equals 240, I had already performed the additions to the 227 and listed the result instead of the 227. Ejs agreed with my final result though.
Logged