Print

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

[simoncraddock]

What they should have done 'years ago' is look at how other countries were rolling it out and instead of the usual 'we at BT know best' attitude they should have watched and learnt.

So here we are 2015 several years down the road with a botched network made up of equipment from Huawei and ECI that is now out-dated and only part compatible with modern standards.

Way to go BT!!

[Chrysalis]

simon but they clever people and know what they doing

[simoncraddock]

simon but they clever people and know what they doing

They just don't seem to learn though ;-)

[tommy45]

Telling me i have just lost 7mbps off my US attainable for no apparent reason other than the incompetent fools at BT rolling out a fix that actually breaks  peoples connections ,and we are talking about connections that worked fine with Fast path or when fully G.inp ed

[simoncraddock]

Have you raised this with your ISP?
Surely a huge drop would be deemed a fault especially if you have lost more than 30% line speed (guessing you were 19mbps US).

[tommy45]

Have you raised this with your ISP?
Surely a huge drop would be deemed a fault especially if you have lost more than 30% line speed (guessing you were 19mbps US).

It was attainable speed , my sync is still 19999 (20mbps) as the attainable is still above now by only 2mbps But the point but never the less it is still of concern  it's like i have a malformed circuit in some way thanks to bt's meddling in things they know nothing about  I'm also seeing some SES seconds  and until this borked fix was rolled out the circuit hadn't generated any since the 18th march 2015,

[kitz]

Thanks for the stats guys, Ive not had chance to look at them and wont be able to tonight or tomorrow, but when I get time I'll have a look in detail.

kitz did you miss my post? you seem to have forgotten error correction has always been enabled on US FTTC.

I may have because I missed several posts the other day.  I think I replied to one, then it reloaded on the last past with the talk of modems and hence me splitting.   
But yes I did know.   I think its mentioned in one of my posts further up in the same thread... and this is why I wanted to compare the 'R' value..  which in itself is proof that Openreach has for a while been applying FEC on the upstream. - which we knew anyhow that theyve been doing this for at least 18months now.

What we do have to be really careful about now is stressing the difference between Error Correction (FEC) and Interleaving.. and yes they do appear to have ramped Error Correction up    We may also have to be careful about the definition of FAST path and Interleaved with depth of 1 even though the result for the EU is practically the same :/

[kitz]

yeah so imo tommy, your US is exactly back how it was before on fast path.  With D set to 1 and R set to 16.

So openreach did what I told them to do a month ago.  Leave US on fast path config.

Having just had a quick look at the R and N values, then yep.  Theyve rolled back on the upstream as to how things were before they applied g.inp.
The MSGc value has changed though (Number of bytes in the overhead channel message.) but Im not sure what impact that will have on the line.  Theres more overhead than with g.inp, but less than previous 

I value (Interleaver block size) is also less and its interesting that its now exactly half of the N value.  These are config params so not sure how or if it will make any difference because Interleaving depth is one so effectively non-interleaved.  But it certainly looks like theyve been tweaking some parameters so that if interleaving and RS is switched on it will have less impact.   WWwombat is best when it comes to working out how much of an impact.

No idea what RRC bits are.

[kitz]

>> No idea what RRC bits are.

To help control the retransmission operation, a Retransmission Request Channel (RRC) is
supported in the opposite direction of transmission. The RRC transfers information regarding the status of received DTUs and allows the transmitter to determine the DTUs that are acknowledged as correctly received and those that require retransmission.

So seems ok and expected if g.inp is enabled on the downstream.

[KIAB]

Had another resync this morning, Interleave has gone from 4 to 8 & now 16.

Code: [Select]

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 8571 Kbps, Downstream rate = 45184 Kbps
Bearer: 0, Upstream rate = 5000 Kbps, Downstream rate = 40000 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): 8.4 9.1
Attn(dB): 19.8 0.0
Pwr(dBm): 13.4 5.1
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 178 73
M: 1 1
T: 0 0
R: 12 14
S: 0.1424 0.4662
L: 10727 1510
D: 16 8
I: 191 88
N: 191 88
Q: 16 8
V: 2 5
RxQueue: 22 12
TxQueue: 11 6
G.INP Framing: 18 18
G.INP lookback: 11 6
RRC bits: 24 24
Bearer 1
MSGc: 90 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 10.6667 16.0000
L: 24 16
D: 1 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: 635773008 1719849
RSCorr: 2552 570
RSUnCorr: 0 0
Bearer 1
OHF: 1415097 371995
OHFErr: 0 0
RS: 8490210 1387320
RSCorr: 0 67
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 12625463 1373459
rtx_c: 9192298 444215
rtx_uc: 9673856 295831

G.INP Counters
LEFTRS: 6174 3167
minEFTR: 39991 4997
errFreeBits: 1621406120 291400781

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 1748404193 0
Data Cells: 6031039 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: 3234 1901
SES: 1855 769
UAS: 1077 776
AS: 22731

Bearer 0
INP: 47.00 41.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 40055.74 5059.32

Bearer 1
INP: 2.50 4.00
INPRein: 2.50 4.00
delay: 0 0
PER: 16.06 16.06
OR: 47.81 31.87
AgR: 47.81 31.87

Bitswap: 6497/6497 45/45

Total time = 1 days 56 min 23 sec
FEC: 156546764 4666304
CRC: 90405 7656
ES: 3234 1901
SES: 1855 769
UAS: 1077 776
LOS: 14 67
LOF: 117 67
LOM: 43 0
Latest 15 minutes time = 11 min 23 sec
FEC: 49 6
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: 50 44
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 = 56 min 23 sec
FEC: 269 70
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 14502 2907
CRC: 552 0
ES: 10 0
SES: 10 0
UAS: 33 23
LOS: 1 0
LOF: 7 0
LOM: 0 0
Since Link time = 6 hours 18 min 49 sec
FEC: 2552 570
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#

[Bald_Eagle1]

Hmmm.


Maybe as my connection is so slow in the upstream direction it doesn't actually need the updated profile?

Max:   Upstream rate = 4951 Kbps, Downstream rate = 21072 Kbps
Bearer:   0, Upstream rate = 5000 Kbps, Downstream rate = 21432 Kbps


(Possibly a slight chance that BT have actually got it right)?



It took a while for G.INP to be activated in the initial rollout, maybe it is also taking a while for the profile change to hit (despite the claims that all connections have been updated)?



Current Bearer 0:-

Code: [Select]

RxQueue: 18 15
TxQueue: 6 5
G.INP Framing: 18 18
G.INP lookback: 6 5
RRC bits: 24 24



[Bald_Eagle1]

Hmmm even more.............


For some unknown reason, my connection has just resynced.

I certainly didn't cause it intentionally as I was in the middle of a VPN session to the server at work.

Code: [Select]

Hi Bald_Eagle1,

This email is to alert you that the connection resynced at approximately Fri Jun 05 18:49:41 2015

                                Current Stats              Previous Stats
                                =============              ==============
Downstream Sync                   21454 Kbps                 21432 Kbps
Upstream Sync                      3826 Kbps                  5000 Kbps
Downstream Attainable Rate        21304 Kbps                 20864 Kbps
Upstream Attainable Rate           3879 Kbps                  4970 Kbps
Bearer 0 Downstream INP              47.00                      47.00
Bearer 0 Upstream INP                41.00                      46.00
Bearer 0 Downstream G.INP Framing     18                          18
Bearer 0 Downstream Interleaving       8                          8
Bearer 0 Upstream Interleaving         2                          4


Please see the attached xlogfile.txt file for ALL the current stats.


My US has indeed been clobbered, but G.INP still appears to be active.


It does 'appear' to have been some sort of DLM action:-

05/06/2015 18:50 - RESYNC detected (DS 21454 Kbps, US 3826 Kbps), AS = 23, Retrain Reason: 1)


18:49 does seem a very 'odd' time for DLM to take action.


The xlogfile.txt file referred to is attached for reference.


Perhaps it's a 'fault' as I seem to have completely lost all bitloading from the U0 band (see attached current & ongoing stats montages).

[GigabitEthernet]

Is G.INP likely to help my line?

[Bald_Eagle1]

Further to my previous post, also see the combined Bitloading & SNR graph.

I sense another 'epic' thread coming on 

[kitz]

BE can I see your stats please (xdslcmd info --stats) for prior to tonight, and also from pre- G.INP MKI.


The figures Im wanting to look at are those starting MSGc - specifically the R and N values