Print

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

[Bald_Eagle1]

Just for interest (as I don't yet really understand what the new stats are telling us), I have attached 1 day stats for 2 separate users (Hitman & garypower)

2 sets of montages are now created by HG 612 Modem Stats.

One montage includes the Bearer independent data and Bearer 0 data & the other includes the new Bearer 1 data.

[Bald_Eagle1]

Here's the Bearer 1 data for each user.

[Bald_Eagle1]

Finally, I have attached a few days worth of garypower's stats, showing the changes from non-G.INP enabled data & G.INP enabled data.

The large gaps are from before he updated HG612 Modem Stats to the latest G.INP compatible version.




EDIT:

Would anyone like to take a stab at explaining what the stats actually mean?

[NewtronStar]

Will G.INP increase latency ?

[Chrysalis]

it increases temporarily when it has to correct an error, which is better than permanent increase from normal interleaving.

[NewtronStar]

it increases temporarily when it has to correct an error, which is better than permanent increase from normal interleaving.

I am trying to work which is the better for example say the stats show this for a line ->

EX1: Interleave: 16 DS 8 US INP: 48.00 DS 47.00 US

EX2: Interleave: 12 DS 6 US INP: 54.00 DS 51.00 US

[WWWombat]

I haven't yet managed to figure out what the new "huge" INP values are telling us.

However, I think the setup of G.INP is that the other parameter "INPrein" takes over the job of handling against REIN - the "repetitive electrically induced noise", which causes short, small levels of interference that re-occurs at 50Hz or 100Hz - from the old parameter "INP" that seemed to be used to do that job.

My old calculations, which may have been bogus, expected the old DLM designs (eg INP=3, delay=8) to protect against noise of 0.75ms happening every 8ms.

I think, with G.INP, that the "INP" parameter of the same name now does something completely different - that it is now focussed on SHINE (Single high impulse something-or-other). I think this protects against a big burst of noise that doesn't happen so often.

If FEC were used in the old way, protection of 46 or 48 symbols would be huge - and would consume a massive overhead. With Retransmission in place, the INP value obviously plays a totally different part in dimensioning the setup - as the concept of retransmission seems designed to cope with SHINE events. (Now into more speculative territory) ... I don't think the concept of re-transmission works too well for someone who really does suffer from REIN; for repetitive plain old FEC/interleaving is the best tool. So I *think* parameters "INPrein" and "delay" configure the minimalistic FEC/interleaving that we see (where D=4, for example) to give REIN protection, while "INP" configures the rest of the G.INP setup for SHINE protection.

If I'm right, then DLM has a two-dimensional task to tune G.INP in to the errors being experienced on one line, having to figure out how much of the problem is due to REIN and how much is due to SHINE, and independently set parameters for the two.

@Baldy

Thanks - seeing the graphs over time really help to give you an idea of what changes over time. Once you understand the size of the changes, then you can go back to look at each individual (human-readable) page of stats, before vs after, and try to interpret it.

I've tried doing this while reading the G.INP specs, but there are plenty of aspects that haven't gelled yet, and I don't think I'm close to understanding well.

So the graphs are a vital part of this ...

[NewtronStar]

I haven't yet managed to figure out what the new "huge" INP values are telling us.
However, I think the setup of G.INP is that the other parameter "INPrein" takes over the job of handling against REIN - the "repetitive electrically induced noise", which causes short, small levels of interference that re-occurs at 50Hz or 100Hz - from the old parameter "INP" that seemed to be used to do that job.

That's an honest answer WWWombat it's only if and when G.INP is activated on my line i'll get get some kind of feedback, as we know no two Broadband lines are the same even if the attenuation is the same.

[garypower]

What I do know is :

When my line had interleaving off (not very often) latency to bbc.co.uk was ~ 10ms
With interleaving on, that it had much of the time this was more like 20ms

With the g.inp it pretty much seems to be 10ms again - I have not looked too hard and there may be more small burst jumps but I am not noticing them.

[Bald_Eagle1]

There's a bit of explanation here:-

http://www2.alcatel-lucent.com/techzine/g-inp-secret-stable-100-mbps-copper/

It does include this text:-

The G.inp standard protects transmissions from impulse noise, improving line stability while reducing latency at the same time. By combining G.inp with vectoring, service providers can currently deliver 100 Mbps reliably over a single copper pair  reusing their existing copper infrastructure .

[splbound]

As well if anyone is interested. I was Just put on G.INP at 4:00am 18/03/2015.

Was syncing at about 56000 now syncing at 65813. Very healthy increase. Pings more than halved now.
Stats up on MDWS as my username here if anybody wants to peruse.

My QLT and Hlog look pretty much the same as usual so I believe these increases were due to G.INP being put into place.

Happy Days.. Hope it lasts.

[tommy45]

Code: [Select]

=~=~=~=~=~=~=~=~=~=~=~= Plink log 2015.03.18 10:28:15 =~=~=~=~=~=~=~=~=~=~=~=

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 32206 Kbps, Downstream rate = 85316 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 7.2 13.9
Attn(dB): 13.5 0.0
Pwr(dBm): 12.4 3.2
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 130 97
M: 1 1
T: 0 0
R: 8 8
S: 0.0518 0.1554
L: 21468 5457
D: 16 8
I: 139 106
N: 139 106
Q: 16 8
V: 14 2
RxQueue: 57 39
TxQueue: 19 13
G.INP Framing: 18 18
G.INP lookback: 19 13
RRC bits: 24 24
Bearer 1
MSGc: 186 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 5.3333 16.0000
L: 48 16
D: 3 1
I: 32 32
N: 32 32
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 0
OHFErr: 0 0
RS: 1485528144 3196410
RSCorr: 8790 671
RSUnCorr: 0 0
Bearer 1
OHF: 1202365 158489
OHFErr: 0 0
RS: 14427642 533292
RSCorr: 0 6
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 514 67
rtx_c: 397 67
rtx_uc: 0 0

G.INP Counters
LEFTRS: 7 1
minEFTR: 79982 19991
errFreeBits: 23564798 5890148

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2971153725 0
Data Cells: 6364912 0
Drop Cells: 0
Bit Errors: 0 0

Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0

ES: 11 1
SES: 10 0
UAS: 69 59
AS: 19314

Bearer 0
INP: 46.00 47.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 80614.82 20102.08

Bearer 1
INP: 4.00 4.00
INPRein: 4.00 4.00
delay: 3 0
PER: 16.06 16.06
OR: 95.62 31.87
AgR: 95.62 31.87

Bitswap: 1071/1071 2/2

Total time = 1 days 20 hours 30 min 46 sec
FEC: 80128 135410
CRC: 6848 2
ES: 11 1
SES: 10 0
UAS: 69 59
LOS: 1 0
LOF: 5 0
LOM: 0 0
Latest 15 minutes time = 46 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 101 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 20 hours 30 min 46 sec
FEC: 36684 44100
CRC: 6817 0
ES: 10 0
SES: 10 0
UAS: 32 22
LOS: 1 0
LOF: 5 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 43444 91310
CRC: 31 2
ES: 1 1
SES: 0 0
UAS: 37 37
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 5 hours 21 min 53 sec
FEC: 8790 671
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0


HELLO HG612
xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 32206 Kbps, Downstream rate = 85316 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
  VDSL Port Details   Upstream   Downstream
Attainable Net Data Rate:     32206 kbps     85316 kbps
Actual Aggregate Tx Power:        3.2 dBm      12.4 dBm
 =========================================================================================
  VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
  Line Attenuation(dB): 3.2 15.1 21.8   N/A   N/A 8.7 19.1 29.2
Signal Attenuation(dB): 3.2 14.1 21.0   N/A   N/A 11.5 18.9 29.2
SNR Margin(dB): 13.9 13.9 13.9   N/A   N/A 7.2 7.2 7.2
TX Power(dBm): -11.8 -27.9 3.1   N/A   N/A 8.0 7.9 7.0
As of 5am my connection went onto G inp, My IP profile is 77.35 instead of the normal 77.44 ? I'm also still using an older unlocked firmware Software version = V100R001C01B030SP06  Firmware version = A2pv6C038m.d24j which would appear to work with G.INP , no doubt some one will tell me if it isn't working as well as it should, I still have the ECI that i was issued with by by installing engineer, Which that was to fail to sync,  the DLM would require a reset, ?

[boost]

Can someone on a G.inp enabled line do the following, possibly?

xdslcmd profile --show
xdslcmd info --cfg

ta

[splbound]

Can someone on a G.inp enabled line do the following, possibly?

xdslcmd profile --show
xdslcmd info --cfg

ta

Just ran these for you:

# xdslcmd profile --show

Modulations:
        G.Dmt   Enabled
        G.lite  Enabled
        T1.413  Enabled
        ADSL2   Enabled
        AnnexL  Enabled
        ADSL2+  Enabled
        AnnexM  Disabled
        VDSL2   Enabled
Phone line pair:
        Inner pair
Capability:
        bitswap         On
        sra             On
        trellis         On
        sesdrop         Off
        CoMinMgn        Off
        24k             On
        phyReXmt(Us/Ds) Off/On
        TpsTc           AvPvAa
        monitorTone:    On
        dynamicD:       On
        dynamicF:       Off
        SOS:            On
        Training Margin(Q4 in dB):      -1(DEFAULT)
       
# xdslcmd info --cfg

xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status:   0
Max:    Upstream rate = 20539 Kbps, Downstream rate = 65084 Kbps
Bearer: 0, Upstream rate = 17000 Kbps, Downstream rate = 65813 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps

adslTrainingMarginQ4:   -1
adslShowtimeMarginQ4:   -1
adslLOMTimeThldSec:     -1
adslDemodCapMask:       0090447a
adslDemodCapValue:      0090447a
adsl2Param:             00000000
adslPwmSyncClockFreq:   0
adslHsModeSwitchTime:   0
adslDemodCap2Mask:      00500200
adslDemodCap2Value:     00500000
vdslParam:              007f00ff
vdslParam1:             00000000
xdslAuxFeaturesMask:    00060003
xdslAuxFeaturesValue:   00060003
vdslCfgFlagsMask:       00210400
vdslCfgFlagsValue:      00210400
xdslCfg1Mask:   00000000
xdslCfg1Value:  00000000
xdslCfg2Mask:   00000000
xdslCfg2Value:  00000000
xdslCfg3Mask:   00000000
xdslCfg3Value:  00000000
xdslCfg4Mask:   00000000
xdslCfg4Value:  00000000
maxDsDataRateKbps:      0
maxUsDataRateKbps:      0
maxAggrDataRateKbps:    0
xdslMiscCfgParam:       00000000
AFE_ID:                 10608100 00000000

[boost]

Brill, thanks

I was wondering whether upstream PhyR would be enabled; it's not. Also wondered whether G.inp would be displayed under capabililties; it's not!

The cfg output looks very similar to my own too, although I don't have it to hand. There may be something to be gleaned from vdslCfgFlagsValue:      00210400 but not sure!