Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[tommy45]

# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 37093 Kbps, Downstream rate = 98092 Kbps
Path: 0, Upstream rate = 19999 Kbps, Downstream rate = 79999 Kbps

Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3971)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3971)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 37093 kbps 98092 kbps
Actual Aggregate Tx Power: - 0.3 dBm 12.4 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 2.7 13.5 19.8 N/A 7.5 16.2 24.3

Signal Attenuation(dB): 2.7 12.6 18.7 N/A 7.5 16.2 24.3

SNR Margin(dB): 23.7 23.0 23.2 N/A 6.6 6.6 6.6

TX Power(dBm): -14.8 -30.2 -0.5 N/A 8.1 7.8 7.1

# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 37069 Kbps, Downstream rate = 98092 Kbps
Path: 0, Upstream rate = 19999 Kbps, Downstream rate = 79999 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.6 23.2
Attn(dB): 0.0 0.0
Pwr(dBm): 12.4 -0.3
VDSL2 framing
Path 0
B: 57 237
M: 1 1
T: 64 42
R: 16 16
S: 0.0231 0.3781
L: 25665 5374
D: 1339 1
I: 74 127
N: 74 254
Counters
Path 0
OHF: 1297322 363129
OHFErr: 0 0
RS: 249085501 2359794
RSCorr: 8183 0
RSUnCorr: 0 0

Path 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 221750189 0
Data Cells: 6251240 0
Drop Cells: 0
Bit Errors: 0 0

ES: 0 0
SES: 0 0
UAS: 19 19
AS: 1442

Path 0
INP: 3.00 0.00
PER: 1.10 3.97
delay: 8.00 0.00
OR: 151.73 64.47

Bitswap: 183 0

copied and pasted from another site, would you say they are ok or corrupt in some way ?

[kitz]

I cant particularly see anything strange.   The line is perhaps noisy re the RS, Interleaving and INP.  Has 0 E/s  but line has only been up for about 20mins so hard to judge.  You'd need to see how much the SNRm fluctuates and what type of noise its getting and to find out why its been interleaved.   

SNRm is 6.6dB so the max attainable is way out, but that often happens when a line is interleaved. I'd expect it to be nearer 85Mbish if the line wasn't interleaved,  but because it is, so Im not even going to hazard a guess for the Err Corr redundancy.  There's probably a formula somewhere that explains it what Im afraid I dont know what it is. 

[tommy45]

I did think think that despite interleaved it was odd that the connection was syncing at the full  downstream rate, but was informed that this is because of the max attainable rate
Personally i thought that the attainable rate was nothing more than what the modem estimates that it could sync at in perfect conditions and nothing more than that ?

each time my connection has been interleaved  max sync was reduced to below the max rate, and the attainable rate prior to interleave was higher than the max rate ,

[kitz]

Ahhh got you.

Yes the max attainable is supposed to just be an estimate, and for some reason it does tend to go a bit weird when interleaving has been applied.

However, if the line is good enough and conditions allow then it is possible to attain full sync and still be interleaved.   It also depends upon the dsl  technology and what restrictions are set at the dslam.   For example adsl1 uses older algorithms and many of us may recall that adsl1 was limited to 8128 kbps and if interleaving was applied then your max sync speed was 7616kbps.   When BT installed the 21CN MSANs (which were adsl2+ compatible) it was possible to be interleaved and still sync at 8128.

Error correction is turned on at the same time as Interleaving and its redundancy for error correction which can limit the sync speed.  I believe that data packets for these overheads are assigned to 'out of band' tones. - well at least according to Cisco for adsl they are and I cant seem to find anything that says otherwise for vdsl, and if there is insufficient capacity in the outofband tones then it can eat into 'normal' sync.   

It would appear that in the above case, then there is sufficient for it not to bother the actual sync.   Ive seen it myself on my own line whereby I was interleaved, yet was still able to attain the full sync.   You can see below that my upstream has both interleaving and INP applied, yet I was still able to sync at the full 20Mbps because there was sufficient SNRm capacity to carry the overheads.

Code: [Select]

Connection up time:  0 days  2 hours  49 minutes  & 13 seconds         Last Resync recorded at 18/10/2014 21:18
 Firmware version:  A2pv6F039i.d24e                                     Retrain Reason: 0
 ________________________________________________________________________________________________________________

                        Downstream      Upstream                                        Downstream      Upstream

 
            Sync (kbps)    79987         20000                           Interleaving          1           357
 Attainable rate (kbps)    88265         27146                                    INP       0.00          3.00
       Attenuation (dB)      0.0           0.0
        SNR Margin (dB)      8.1           6.9
           Power (dBmV)     14.3           4.9                            SES (total)          0             1
RSUnCorr errors (delta)        0             0                RSUnCorr errors (total)          0             0
Errored seconds (delta)        0             2                Errored seconds (total)         11           225
       Bitswaps (delta)        0             3                       Bitswaps (total)        259           269
     CRC errors (delta)        0            52                     CRC errors (total)         12          5478
     HEC errors (delta)        0             0                     HEC errors (total)         47             0
     FEC errors (delta)        0         16172                     FEC errors (total)          0        1675027
 ________________________________________________________________________________________________________________


[WWWombat]

Yes the max attainable is supposed to just be an estimate, and for some reason it does tend to go a bit weird when interleaving has been applied.

My own rule-of-thumb for the HG612 was that, upon standard DLM intervention, the max attainable went up by as much as the sync speed went down. Therefore, on DLM de-intervention, I'd expect the new max-attainabe to be halfway between the previous sync and the previous max attainable. That would be about 89Mbps.

The FEC overhead calculation is R parity bytes used in a block of size N; in this case 16 bytes out of 74 are overhead (21%) while the other 58 bytes are real ones.

That calculation would suggest you could regain over 16Mbps (21% of 80) when DLM is removed. I don't think you do ... and the real answer would be around 9Mbps.

However, if the line is good enough and conditions allow then it is possible to attain full sync and still be interleaved.

I'm the one who told Chrys this, as I've experienced it directly back when the 17a profile was introduced, but before the 80/20 packages were introduced.

However, I think there have been cases where the FEC overhead comes fully off the sync speed, even when capacity is available. I wonder if it a configuration issue, or a difference between DSLAM or CPE.

Error correction is turned on at the same time as Interleaving and its redundancy for error correction which can limit the sync speed.  I believe that data packets for these overheads are assigned to 'out of band' tones. - well at least according to Cisco for adsl they are and I cant seem to find anything that says otherwise for vdsl, and if there is insufficient capacity in the outofband tones then it can eat into 'normal' sync.   

I don't think the parity bytes are sent on any special tone; In a sense, there are no specific bytes that are *the* parity bytes. There are just extra bytes ... and the FEC process can fix a 1-bit error somewhere in the full RS block of bytes (in this case 74 bytes) without caring whether the bit was real data or parity data.

Thinking further, you probably want all 74 bytes to be properly interleaved as widely as possible, so that they gain the full scope of protection.

[kitz]

The FEC overhead calculation is R parity bytes used in a block of size N;

Thank you - that explanation makes it simple.  As soon as I see formulas such as this, then my brain just switches off 

That calculation would suggest you could regain over 16Mbps (21% of 80) when DLM is removed. I don't think you do ...  and the real answer would be around 9Mbps.

Just a thought - could s=1/2 mode have anything to do with this?  As implied, s=1/2 mode reduces RS overheads by up to 50% by mapping 2 RS codewords to a single FEC output data frame.  Ref

Code: [Select]

The limitation of maximum allowable Reed-Solomon codeword size can be overcome if the interleaved
data path is used (with S=1/2, where S is the number of data frames per RS codeword). Using the interleaved data
path, which will be discussed in detail later, two Reed-Solomon codewords can be mapped to a single FEC output
data frame.
DSL has two bearer channels (paths) that it can use: FAST and INTERLEAVED.   Traditionally with adsl1 everything was sent down the FAST path.  Interleaved path can still simulate fast path by using depth=1...  but if s=1/2 mode is used on this channel then overheads can be reduced by half.

I'm the one who told Chrys this, as I've experienced it directly back when the 17a profile was introduced, but before the 80/20 packages were introduced.

Its been clearly in evidence since adsl2+ ... and in fact its also been seen as far back as on adsl1 on some lines if you were attached to one of BTs Marconi or Fujitsu MSANs (adsl2+ capable) rather than the older DSLAMs and if you had an adsl2+ router capable of s=1/2 mode.

I think there have been cases where the FEC overhead comes fully off the sync speed, even when capacity is available. I wonder if it a configuration issue, or a difference between DSLAM or CPE.

Several years ago I searched and searched to find an explanation for how adsl FEC overhead is transported because I wanted to know.  I know from my various text books on compression & error correction (these are from my college days which I dont have to hand now and TBH I was far more interested in compression for my dissertation than I was in adsl back in those days) that there are 2 methods available for overhead transportation ie out of bands or reduction of payload.  When later researching specifically for adsl, the only thing I could come up with was a Cisco paper that said adsl & DMT uses the out of bounds method for FEC redundancy.
 
However like you I have also observed lines where it appears that the full overhead has been taken from the sync speed and why I was a bit fuzzy in my 3rd paragraph using the words 'believe' and 'cant seem to find anything that says otherwise'. On reflection you make an interesting point when you say difference in DSLAM - I got my info from a Cisco paper so it could be possible that other DSLAM makes may be configured differently?   As mentioned it was an area I searched extensively for, but drew a blank

[kitz]

I've found what appears to be a more updated version of the afore mentioned Cisco paper  which now specifically discusses vdsl

Forward Error Control FEC will no doubt use a form of Reed Soloman coding and optional interleaving to correct bursts of errors caused by impulse noise. The structure will be very similar to ADSL, as defined in T1.413. An outstanding question is whether FEC overhead (in the range of 8%) will be taken from the payload capacity or added as an out-of-band signal. The former reduces payload capacity but maintains nominal reach, whereas the latter retains the nominal payload but suffers a small reduction in reach. ADSL puts FEC overhead out of band.

So still quite wooly..  states adsl uses out of band - but doesn't say for certain if vdsl does.

[WWWombat]

I've paid more attention to how FEC and interleaving worked in VDSL2 than back in either of the ADSL specs.

I'll have to do a bit more reading before I can answer you sensibly