Register (or login) on our website and you will not see this ad.
|
|
Hi All,
So I had various latency problem with my line in last month. BTOR attended
Today and found "tiny" fault on my line. As it was third time BTOR is attending to reported "fault" on my line he decided to swap wire pair going from green cabinet to man whole outside my house. He then told me he will reset DLM via phone call.
The new line has same speed as it was before I've noticed fault, but now it's stable.
However the latency has significantly increased. I remember back in August 2014
ping to certain BBC IP was around 11ms, yesterday before reporting fault it was already at high 20ms, Today is at 27ms.
In total I've restarted my modem three times Today each time getting different plus.net gw, all with this high latency.
Up till Today the modem I've used was ECI. However when I've noticed latency I've
put on recently purchased HG612 which I've unlocked. The latency remained as high.
Any idea, what's going on and why ping to be so high?
Below are some stats
ThinkBroadband Stats
# 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 Off
trellis On
sesdrop Off
CoMinMgn Off
24k On
phyReXmt(Us/Ds) On/On
TpsTc AvPvAa
monitorTone: On
dynamicD: On
dynamicF: Off
SOS: On
Training Margin(Q4 in dB): -1(DEFAULT)
#
# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 14900 Kbps, Downstream rate = 49348 Kbps
Bearer: 0, Upstream rate = 12381 Kbps, Downstream rate = 43463 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): 6.3 6.0
Attn(dB): 19.3 0.0
Pwr(dBm): 12.5 6.5
VDSL2 framing
Bearer 0
MSGc: 18 26
B: 43 47
M: 1 1
T: 64 64
R: 10 16
S: 0.0322 0.1233
L: 13416 4154
D: 1009 261
I: 54 64
N: 54 64
Counters
Bearer 0
OHF: 1104461 289737
OHFErr: 3 0
RS: 282619562 1143094
RSCorr: 11611 1060
RSUnCorr: 8 0
Bearer 0
HEC: 2 0
OCD: 0 0
LCD: 0 0
Total Cells: 190944437 0
Data Cells: 7810820 0
Drop Cells: 0
Bit Errors: 0 0
ES: 2 0
SES: 0 0
UAS: 151 151
AS: 2286
Bearer 0
INP: 3.00 4.00
INPRein: 0.00 0.00
delay: 8 8
PER: 2.06 7.91
OR: 92.80 32.32
AgR: 43556.08 12413.50
Bitswap: 1107/1107 11/11
#
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 14713 Kbps, Downstream rate = 49132 Kbps
Bearer: 0, Upstream rate = 12381 Kbps, Downstream rate = 43463 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): 6.2 5.9
Attn(dB): 19.3 0.0
Pwr(dBm): 12.5 6.5
VDSL2 framing
Bearer 0
MSGc: 18 26
B: 43 47
M: 1 1
T: 64 64
R: 10 16
S: 0.0322 0.1233
L: 13416 4154
D: 1009 261
I: 54 64
N: 54 64
Counters
Bearer 0
OHF: 1120895 294044
OHFErr: 3 0
RS: 286826689 2245685
RSCorr: 11666 1060
RSUnCorr: 8 0
Bearer 0
HEC: 2 0
OCD: 0 0
LCD: 0 0
Total Cells: 193785948 0
Data Cells: 7811349 0
Drop Cells: 0
Bit Errors: 0 0
ES: 2 0
SES: 0 0
UAS: 151 151
AS: 2320
Bearer 0
INP: 3.00 4.00
INPRein: 0.00 0.00
delay: 8 8
PER: 2.06 7.91
OR: 92.80 32.32
AgR: 43556.08 12413.50
Bitswap: 1127/1127 12/12
Total time = 2 hours 15 min 14 sec
FEC: 29696 1626
CRC: 6 0
ES: 2 0
SES: 0 0
UAS: 151 151
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 14 sec
FEC: 25 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: 5750 795
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 = 2 hours 15 min 14 sec
FEC: 29696 1626
CRC: 6 0
ES: 2 0
SES: 0 0
UAS: 151 151
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 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
Since Link time = 38 min 39 sec
FEC: 11666 1060
CRC: 3 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
#
# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 14780 Kbps, Downstream rate = 49348 Kbps
Bearer: 0, Upstream rate = 12381 Kbps, Downstream rate = 43463 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: 14780 kbps 49348 kbps
Actual Aggregate Tx Power: 6.5 dBm 12.5 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 5.2 29.3 45.0 N/A N/A 14.1 37.0 58.9
Signal Attenuation(dB): N/A 28.3 43.9 N/A N/A 19.5 36.7 59.0
SNR Margin(dB): N/A 6.0 5.9 N/A N/A 6.2 6.2 6.3
TX Power(dBm): -128.0 -13.8 6.5 N/A N/A 8.5 8.1 6.4
#
#
|
|
|
If G.INP is enabled you will see references to bearer 1 and also the G.INP values shown in the telnet output will be non-zero.
In my experience it took a couple of days between replacing the OR-supplied ECI modem with an unlocked HG612 before the G.INP was enabled (I think the cabinet itself was enabled for G.INP a week or so earlier). When this happened the latency reduced from ~28ms (with both ECI and HG612) to ~18ms, the line has been synced at 80/20 since then and has been very solid and stable.
--
Brian
Zen Fibre 2
|
|
|
|
Your line doesn't yet have G.INP enabled, and is still under the effects of old-style DLM: a delay of 16ms has been specified (8ms downstream, 8ms upstream)).
It looks like a DLM reset has not been ordered (probable), or your line proved so bad, that DLM re-intervened immediately (possible, but unlikely).
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
What software version do you have in the HG612? (Easiest seen in the GUI). It should be V100R001C01B030SP08, but many are ...28SP10 which is earlier and not G.INP enabled.
|
|
|
Hi,
I have installed SP08 ( Software version V100R001C01B030SP08 ) so it
should be G.INP enabled.
What software version do you have in the HG612? (Easiest seen in the GUI). It should be V100R001C01B030SP08, but many are ...28SP10 which is earlier and not G.INP enabled.
Thanks, I can see now where 8ms is listed ( under delay ).
I guess the engineer made mistake and didn't complete request or it didn't go through.
In either scenario if the line doesn't come back to normal in couple days I will ask plus.net
to report this problem to them.
Your line doesn't yet have G.INP enabled, and is still under the effects of old-style DLM: a delay of 16ms has been specified (8ms downstream, 8ms upstream)).
It looks like a DLM reset has not been ordered (probable), or your line proved so bad, that DLM re-intervened immediately (possible, but unlikely).
|
|
|
|
Just to make sure, can you post the result of this telnet command in sh(ell) please?
xdslcmd info --vendor
|
|
|
|
Hi,
What are the odds of DLM going back to clean state like the fault was never here?
Also, is there a list of planned G.IMP roll outs ?
Perhaps when they put new equipment in, the DLM would be reset for everyone
connected to that cabinet?
# xdslcmd info --vendor #
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 15949 Kbps, Downstream rate = 48868 Kbps
Bearer: 0, Upstream rate = 13275 Kbps, Downstream rate = 44504 Kbps
ChipSet Vendor Id: BDCM:0xa44f
ChipSet VersionNumber: 0xa44f
ChipSet SerialNumber:
|
|
|
|
You need a DLM reset for a clean state.
I'm thinking that Openreach have suspended G.Inp activations for the time being, such is the scale of the ECI problem.
The Chipset vendor id is BroaDCoM, so it supports G.Inp properly.
|
|
|
You need a DLM reset for a clean state.
I'm thinking that Openreach have suspended G.Inp activations for the time being, such is the scale of the ECI problem.
The Chipset vendor id is BroaDCoM, so it supports G.Inp properly.
I guess my problem was faulty line and not G.INP, it's just coincident that the
roll out was around the same time I've noticed the problem.
However I wouldn't mind it being enabled here, probably would help since I've got Huwai modem.
|
|
|
When plus.net support was dealing with my support query, they've posted various stats.
What is interesting that before the same stats had line "interleaving low", now it says "retransmission". However the delay of 8ms up/down seems to be more inline with interleaving tech.
Test Outcome Pass
Test Outcome Code GTC_FTTC_SERVICE_0003
Description No problem found, OAM test is not currently supported on this line.
Main Fault Location OK
Appointment Required N
NTE Power Status PowerOn
Sync Status In Sync
Downstream Speed 46.9
Upstream Speed 12.6
Profile Name 0.128M-49M Downstream, Retransmission High - 0.128M-17M Upstream, Retransmission Low
Copper Line Test Pass
Bridge Tap Not Detected
Radio Frequency Ingress Not Detected
REIN Not Detected
Cross Talk Not Detected
You need a DLM reset for a clean state.
I'm thinking that Openreach have suspended G.Inp activations for the time being, such is the scale of the ECI problem.
The Chipset vendor id is BroaDCoM, so it supports G.Inp properly.
Edited by deleted (Tue 28-Apr-15 22:22:12)
|
|
|
Profile Name 0.128M-49M Downstream, Retransmission High - 0.128M-17M Upstream, Retransmission Low That suggests Openreach are saying G.INP is enabled on the line.
|
|
|
|
Those line checks are not that reliable, the last test run on my line doesnt show and re transmition profile but the connection is definately G.inp ed
|
|
|
Those line checks are not that reliable, the last test run on my line doesnt show and re transmition profile but the connection is definately G.inp ed
I see, good to know. Will wait few days and see what will happen.
**** Update to below: scrap it, people with G.INP enabled see it the same way it's on my system and no need to tinker with it to get G.INP working ****
I've noticed that xdslcmd has --phyReXmt <0xBitMap-UsDs> configuration.
Anyone know whether touching this is required and what value should be used?
I can see with profile --show that it's only enabled for Ds:
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)
Edited by deleted (Wed 29-Apr-15 06:44:19)
|
|
|
This post suggests upstream needs to be ON.
|
|
|
Your line doesn't yet have G.INP enabled, and is still under the effects of old-style DLM: a delay of 16ms has been specified (8ms downstream, 8ms upstream)).
It looks like a DLM reset has not been ordered (probable), or your line proved so bad, that DLM re-intervened immediately (possible, but unlikely).
Plus.net support confirmed to me that the profile was reset. The support person worked it
out based on fact that the profile name content is untouched and speed and interleaving is as on fresh line. I've also been told that DLM will now decide whether G.IMP is required and might enable it at later date.
If above is true, the things has changed, since I had another fault removed two months ago and when profile was reset I was on fast path, ping to BBC was 11ms and that only lasted one day. Now it's 28ms and upstream/downstream interleaving default is low.
--incoming call--
Test Outcome Code GTC_FTTC_SERVICE_0001
Description GEA service test completed and no fault found but unable to check for customer equipment connected to modem.
Main Fault Location OK
Sync Status In Sync
Downstream Speed 43.3 Mbps
Upstream Speed 12.8 Mbps
Appointment Required N
Fault Report Advised N
NTE Power Status PowerOn
Voice Line Test Result Not Run - Unable to run
Bridge Tap Not Detected
Radio Frequency Ingress Not Detected
Repetitive Electrical Impulse Noise Not Detected
Cross Talk Not Detected
Profile Name 0.128M-80M Downstream, Interleaving Low - 0.128M-20M Upstream, Interleaving On
Time Stamp 2015-04-28T11:45:00
Confirmed that the line has been reset, also notes show that a batter contact fault was identified and addressed as well. Confirmed that line data will be added to the ticket shortly.
Dear Mr Sobieski,
Thank you for contacting us this afternoon. As discussed here is the current live data for your line, as you can see the profile has changed and your line no longer has g.ipm enabled. Interleaving is set as low following the reset and it'll now be up to DLM to review this over time and then determine if it can remove it. Your not going to see this disappear in the short term so it's best to monitor the line over the next few weeks.
Kind regards,
|
|
|
Just an aside. It is G.INP, not G.IMP.
I was trying to ignore it hoping in time you would realise, but what appears to be a copy and paste from Plusnet disturbs me considerably. It contains "g.ipm". Is that what they sent, or have you typed the quotation rather than copy and paste, and made a typo?
|
|
|
Just an aside. It is G.INP, not G.IMP.
I was trying to ignore it hoping in time you would realise, but what appears to be a copy and paste from Plusnet disturbs me considerably. It contains "g.ipm". Is that what they sent, or have you typed the quotation rather than copy and paste, and made a typo?
Thanks for the correction and I'm also in need to rehabilitate on plus.net, they've used proper term G.INP, and G.IMP comes from me.
I guess I was exposed for too long to Gimp's, whether I heard in Pulp fiction, read in Doom 2 manual or finally installed on Linux to get some graphics done  It's clearly deeply rooted in me
|
|
|
Thanks for clearing that up . I was quite worried that their support had it wrong.
|
|
|
Profile Name 0.128M-49M Downstream, Retransmission High - 0.128M-17M Upstream, Retransmission Low That suggests Openreach are saying G.INP is enabled on the line.
As well as indicating that DLM has activated G.INP, it also tells us that DLM has banded the line too - setting top speeds of 49/17.
Now, this is the profile that DLM wants to be active, but we can't be sure that the modem has actually negotiated this setting into place. The line stats shown in the OP definitely do not have G.INP active.
What we need to see, together, is the profile (as provided by Plusnet) and the complete line stats from the *same time*.
|
|
|
I somehow failed to pick up the profile --show used to get those. I mistakenly thought some outher modem-router was giving it.
Mine gives the same "off" for upstream:-
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)
pbParams gives:-
Max: Upstream rate = 16047 Kbps, Downstream rate = 56996 Kbps
Bearer: 0, Upstream rate = 16961 Kbps, Downstream rate = 60000 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
|
|
|
**** Update to below: scrap it, people with G.INP enabled see it the same way it's on my system and no need to tinker with it to get G.INP working ****
I've noticed that xdslcmd has --phyReXmt <0xBitMap-UsDs> configuration.
Anyone know whether touching this is required and what value should be used?
I can see with profile --show that it's only enabled for Ds:
Remember that Broadcom has their own (older) proprietary re-transmit mechanism, known an PhyR. This is different from G.998.4 (the official ITU standard, aka G.INP).
It seems that there are other configuration settings that enable G.INP separately from PhyR - but the "profile --show" command only shows the PhyR settings.
So the PhyR settings have no impact on whether G.INP is allowed to be activated on the line.
This post suggests upstream needs to be ON.
I think that post relates to the fact that Openreach have reported that ECI (modems & DSLAMs) cannot support G.INP upstream.
Separately, however, TP-Link and Lantiq have updated firmware that allows one of the TP-Link modems to work correctly in both directions. As this uses the same chipset as the ECI modems, it leaves us wondering what Openreach really have issues with.
|
|
|
See the post I've just made about the off/on upstream/downstream.
|
|
|
Your line doesn't yet have G.INP enabled, and is still under the effects of old-style DLM: a delay of 16ms has been specified (8ms downstream, 8ms upstream)).
It looks like a DLM reset has not been ordered (probable), or your line proved so bad, that DLM re-intervened immediately (possible, but unlikely).
Plus.net support confirmed to me that the profile was reset. The support person worked it
out based on fact that the profile name content is untouched and speed and interleaving is as on fresh line. I've also been told that DLM will now decide whether G.IMP is required and might enable it at later date.
If above is true, the things has changed, since I had another fault removed two months ago and when profile was reset I was on fast path, ping to BBC was 11ms and that only lasted one day. Now it's 28ms and upstream/downstream interleaving default is low.
--incoming call--
Test Outcome Code GTC_FTTC_SERVICE_0001
Description GEA service test completed and no fault found but unable to check for customer equipment connected to modem.
Main Fault Location OK
Sync Status In Sync
Downstream Speed 43.3 Mbps
Upstream Speed 12.8 Mbps
Appointment Required N
Fault Report Advised N
NTE Power Status PowerOn
Voice Line Test Result Not Run - Unable to run
Bridge Tap Not Detected
Radio Frequency Ingress Not Detected
Repetitive Electrical Impulse Noise Not Detected
Cross Talk Not Detected
Profile Name 0.128M-80M Downstream, Interleaving Low - 0.128M-20M Upstream, Interleaving On
Time Stamp 2015-04-28T11:45:00
Confirmed that the line has been reset, also notes show that a batter contact fault was identified and addressed as well. Confirmed that line data will be added to the ticket shortly.
Dear Mr Sobieski,
Thank you for contacting us this afternoon. As discussed here is the current live data for your line, as you can see the profile has changed and your line no longer has g.ipm enabled. Interleaving is set as low following the reset and it'll now be up to DLM to review this over time and then determine if it can remove it. Your not going to see this disappear in the short term so it's best to monitor the line over the next few weeks.
Kind regards,
Sorry - but out of that post, I couldn't work out what was historical data related to an old fault, and what is current, fresh, up-to-date data about the line as it stands now.
I can see a timestamp in the test data (in the quoted post), and the profile settings there show old-style interleaving in place in both directions - matching my original post in this thread.
In an earlier post, you included test results from Plusnet that indicated Retransmission profiles were in use, but you cut the timestamp off that, making it impossible to see when it applied.
If a reset has happened to take you away from G.INP (and banding), then it has pretty rapidly put interleaving back on. That suggests you have high error rates on the line - which you ought to be able to see by monitoring the CRC and ES counters (after reset, but prior to DLM intervention) and the CRC, ES and FEC counters (after old-style intervention).
|
|
|
Mine gives the same "off" for upstream:-
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)
I'm currently using a Billion 8800NL, with a slightly newer Broadcom chipset. It uses the "adsl" command instead of "xdslcmd", but is otherwise the same...
This is what I get for the "adsl profile --show" command:
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)
The same, right? Like you, I have G.INP configured in both directions, which can be seen by the configuration of RRC bits in both directions, and queues in both directions.
RxQueue: 57 39
TxQueue: 19 13
G.INP Framing: 18 18
G.INP lookback: 19 13
RRC bits: 24 24
If I ask for help from the "adsl" command, I get:
# adsl --help
Usage: adsl start [--up] <configure command options>
adsl stop
adsl connection [--up] [--down] [--loopback] [--reverb]
[--medley] [--noretrain] [--L3] [--diagmode] [--L0]
[--tones <r1-r2,r3-r4,...>] [--normal] [--freezeReverb] [--freezeMedley]
adsl configure/configure1 [--mod <a|d|l|t|2|p|e|m|M3|M5|v>] [--lpair <(i)nner|(o)uter>]
[--trellis <on|off>] [--snr <snrQ4>] [--bitswap <on|off>] [--sesdrop <on|off>]
[--sra <on|off>] [--CoMinMgn <on|off>] [--i24k <on|off>] [--phyReXmt <0xBitMap-UsDs>]
[--Ginp <0xBitMap-UsDs>] [--TpsTc <0xBitMap-AvPvAaPa>] [--monitorTone <on|off>]
[--profile <0x00 - 0xFF>|<"8a |8b |8c |8d |12a |12b |17a">] [--us0 <on|off>]
[--dynamicD <on|off>] [--dynamicF <on|off>] [--SOS <on|off>] [--maxDataRate <maxDsDataRateKbps maxUsDataRateKbps maxAggrDataRateKbps>]
[--forceJ43 <on|off>] [--toggleJ43B43 <on|off>]
adsl bert [--start <#seconds>] [--stop] [--show]
adsl afelb [--time <sec>] [--tones] [--signal <1/2/8>]
adsl qlnmntr [--time <sec>] [--freq <msec>]
adsl inm [--start <INMIATO> <INMIATS><INMCC><INM_INPEQ_MODE><INM_INPEQ_FORMAT>] [--show]
adsl snrclamp [--shape <shapeId>] [--bpshape [bpIndex-bpLevel,]]
adsl nlnm [--show ] [--setThld <Thld_Num_Tones>]
adsl diag [--logstart <nBytes>] [--logpause] [--logstop] [--loguntilbufferfull <nBytes>] [--loguntilretrain <nBytes>] [--dumpBuf <sizeKb>]
adsl info [--state] [--show] [--stats] [--SNR] [--QLN] [--Hlog] [--Hlin] [--HlinS] [--Bits]
[--pbParams] [--linediag] [--linediag1] [--reset] [--vendor] [--cfg]
adsl profile [--show] [--save] [--restore]
adsl --version
adsl --help
Note that the "configure" part of the command includes an option for "--Ginp"
|
|
|
Your line doesn't yet have G.INP enabled, and is still under the effects of old-style DLM: a delay of 16ms has been specified (8ms downstream, 8ms upstream)).
It looks like a DLM reset has not been ordered (probable), or your line proved so bad, that DLM re-intervened immediately (possible, but unlikely).
Plus.net support confirmed to me that the profile was reset. The support person worked it
out based on fact that the profile name content is untouched and speed and interleaving is as on fresh line. I've also been told that DLM will now decide whether G.IMP is required and might enable it at later date.
If above is true, the things has changed, since I had another fault removed two months ago and when profile was reset I was on fast path, ping to BBC was 11ms and that only lasted one day. Now it's 28ms and upstream/downstream interleaving default is low.
--incoming call--
Test Outcome Code GTC_FTTC_SERVICE_0001
Description GEA service test completed and no fault found but unable to check for customer equipment connected to modem.
Main Fault Location OK
Sync Status In Sync
Downstream Speed 43.3 Mbps
Upstream Speed 12.8 Mbps
Appointment Required N
Fault Report Advised N
NTE Power Status PowerOn
Voice Line Test Result Not Run - Unable to run
Bridge Tap Not Detected
Radio Frequency Ingress Not Detected
Repetitive Electrical Impulse Noise Not Detected
Cross Talk Not Detected
Profile Name 0.128M-80M Downstream, Interleaving Low - 0.128M-20M Upstream, Interleaving On
Time Stamp 2015-04-28T11:45:00
Confirmed that the line has been reset, also notes show that a batter contact fault was identified and addressed as well. Confirmed that line data will be added to the ticket shortly.
Dear Mr Sobieski,
Thank you for contacting us this afternoon. As discussed here is the current live data for your line, as you can see the profile has changed and your line no longer has g.ipm enabled. Interleaving is set as low following the reset and it'll now be up to DLM to review this over time and then determine if it can remove it. Your not going to see this disappear in the short term so it's best to monitor the line over the next few weeks.
Kind regards,
Sorry - but out of that post, I couldn't work out what was historical data related to an old fault, and what is current, fresh, up-to-date data about the line as it stands now.
I can see a timestamp in the test data (in the quoted post), and the profile settings there show old-style interleaving in place in both directions - matching my original post in this thread.
In an earlier post, you included test results from Plusnet that indicated Retransmission profiles were in use, but you cut the timestamp off that, making it impossible to see when it applied.
If a reset has happened to take you away from G.INP (and banding), then it has pretty rapidly put interleaving back on. That suggests you have high error rates on the line - which you ought to be able to see by monitoring the CRC and ES counters (after reset, but prior to DLM intervention) and the CRC, ES and FEC counters (after old-style intervention).
Profile with Retransmission indicated was before the fault was removed, I had ECI modem then. At that time the line stats were really bad ( see first post ). The BT engineer found fault on line and swapped it. Next thing the engineer has reset the DLM profile for me.
From what plus.net tells me, it's default to have interleaving on both ways now and then DLM will make decisions what next.
Also something you might find interesting. Plus.net indicated in the ticket that I might have problem with my line because of G.INP and that they're going to book BT engineer.
The BT engineer that came didn't know what retransmission or G.INP is. As far as he was concerned he came to fix a faulty line. He seemed to be interested what the tech was, so I explained :/
|
|
|
Profile with Retransmission indicated was before the fault was removed, I had ECI modem then. At that time the line stats were really bad ( see first post ). The BT engineer found fault on line and swapped it. Next thing the engineer has reset the DLM profile for me.
From what plus.net tells me, it's default to have interleaving on both ways now and then DLM will make decisions what next.
Also something you might find interesting. Plus.net indicated in the ticket that I might have problem with my line because of G.INP and that they're going to book BT engineer.
The BT engineer that came didn't know what retransmission or G.INP is. As far as he was concerned he came to fix a faulty line. He seemed to be interested what the tech was, so I explained :/
Ok, here we go. As you can see on the screenshot, DLM kicked in Today around 8:50am, the latency was removed and G.INP enabled. The sync speed was never that high (12mbps up ). Ping is back to normal (10ms to bbc ).
Thinkbroadband stats - G.INP Enabled
New stats:
# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 16110 Kbps, Downstream rate = 48916 Kbps
Bearer: 0, Upstream rate = 16163 Kbps, Downstream rate = 50053 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): 6.0 6.0
Attn(dB): 19.3 0.0
Pwr(dBm): 12.5 7.4
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 235 227
M: 1 1
T: 0 0
R: 12 14
S: 0.1501 0.4487
L: 13222 4315
D: 8 4
I: 248 242
N: 248 242
Q: 8 4
V: 1 0
RxQueue: 42 27
TxQueue: 14 9
G.INP Framing: 18 18
G.INP lookback: 14 9
RRC bits: 24 24
Bearer 1
MSGc: 122 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 8.0000 16.0000
L: 32 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: 75544808 3889140
RSCorr: 3669 10529
RSUnCorr: 0 0
Bearer 1
OHF: 177182 177818
OHFErr: 0 0
RS: 1416965 711272
RSCorr: 0 14
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 238953161 217
rtx_c: 24 217
rtx_uc: 0 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 50061 16167
errFreeBits: 2171498 699870
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 273915872 0
Data Cells: 4177782 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: 103 0
SES: 14 0
UAS: 55 45
AS: 2847
Bearer 0
INP: 49.00 46.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 50133.07 16198.21
Bearer 1
INP: 2.00 4.00
INPRein: 2.00 4.00
delay: 0 0
PER: 16.06 16.06
OR: 63.75 31.87
AgR: 63.75 31.87
Bitswap: 1564/1564 17/17
TX Power(dBm): 0.7 -13.7 6.4 N/A N/A 8.5 8.1 6.3
# xdslcmd profile --show
Modulations:
G.Dmt Enabled
G.lite Disabled
T1.413 Enabled
ADSL2 Enabled
AnnexL Disabled
ADSL2+ Enabled
AnnexM Disabled
VDSL2 Enabled
VDSL2 profiles:
8a Enabled
8b Enabled
8c Enabled
8d Enabled
12a Enabled
12b Enabled
17a Enabled
30a Enabled
US0 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)
#
Edited by deleted (Thu 30-Apr-15 20:39:31)
|
|
|
|
Yup - that is indeed a G.INP configuration.
There are small amounts of FEC and interleaving configured on bearer 0, in addition to the G.INP re-transmission that is configured there. This is perfectly normal, and will only cause small delays to packets (I've calculated it, in the past, to be about 0.2ms)
|
|
|
Pages in this thread: 
Print Thread
