Print

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

[Mick]

Thank you one and all, the esoteric knowledge of members to this forum always amazes me!   

ADSL2 was only enabled in our local exchange just recently (Feb 2016).  FTTC cabinets were being installed in advance of this and I think I am the only person in the village who migrated to ADSL2 instead of FTTC.  I must have been the first person for sure, because the BT man wired my connection wrongly on the card and I was without broadband for the best part of a week until a more 'experienced' engineer was sent out.    The reason I didn't jump onto FTTC is because the green cabinet is a km away, rather than the 300 yards needed to achieve 80-100Mbps.  Some neighboors are struggling to even get 15Mbps on their FTTC.  Also, FTTC would cost me an extra £150 or so a year, which although I could use for faster uploads, from a business perspective alone I am not sure I can justify.

I am on the SMCHY exchange in case it helps to know what has been installed and running there.  In any case, two weeks ago the 2WIRE was running without problem.  Therefore, it is fair to assume whatever changed must have been recently, either as a result of the DSLAM interacting with the HG612, or as a result of changes implemented at the exchange.

I don't know if I have G.INP on my line, but I thought this technology was only being rolled out on VDSL2.  I attach an older screenshot from one of my 2WIREs which shows INP of 1.11 - 1.13 and a Broadcom chipset at the exchange.  Now, I don't wish to contradict kitz and I don't have a similar capture from my previous 20CN G.dmt connection, but I recall INP figures reported by the 2WIRE on G.dmt too.  Either way, the 2WIRE INP readings do not align with the HG612 ... could it be they are using different units of measurement?  Or is it that G.INP is now being rolled out on ADSL2 too?  :-/

My ISP's control panel shows that Interleaving is switched on (Auto).  However, my ping rtt appear to be pleasantly short:

Code: [Select]

$ ping -c 3 -n www.google.co.uk
PING www.google.co.uk (216.58.210.35) 56(84) bytes of data.
64 bytes from 216.58.210.35: icmp_seq=1 ttl=57 time=22.0 ms
64 bytes from 216.58.210.35: icmp_seq=2 ttl=57 time=18.9 ms
64 bytes from 216.58.210.35: icmp_seq=3 ttl=57 time=17.9 ms

--- www.google.co.uk ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2005ms
rtt min/avg/max/mdev = 17.936/19.648/22.092/1.773 ms
I guess if the 2WIREs have outlived their usefulness I can punt them on ebay and carry on using the HG612.

[ejs]

Right, I mixed up NEXUS2345's exchange with Mick's exchange. Exchange SMCHY was indeed upgraded much more recently and so does not surprise me that it's using Broadcom based ADSL2+ equipment.

The presence of those ReXmt, ReXmtCorr and ReXmtUnCorr counts in your stats indicate that it's using PhyR, not G.INP. PhyR and G.INP are not exactly the same thing. They are the same kind of thing, but G.INP would have different counters displayed (such as rtx_c, LEFTRS, minEFTR). G.INP is standardised whereas PhyR is a Broadcom proprietary system.

Perhaps what happened is shortly after you started using the HG612, something at the exchange detected the HG612 with PhyR enabled, and so decided to use PhyR. Perhaps it was a bit like how the FTTC DLM will only switch on upstream G.INP a little while after it detects you are using a compatible modem. That's why I suggested you might be able to get rid of it by leaving an incompatible modem connected for a while. After all, the DG834v2 is also pretty old and doesn't support PhyR, yet it managed to establish a connection. Or perhaps some software at the exchange was updated or some configuration changed and PhyR has been activated completely by accident.

There are probably three different types of 21CN exchange equipment identifiable by the differing vendor codes, yet you don't hear people complaining about a three tier system, most BT ADSL2+ exchange equipment probably isn't even capable of using PhyR. So BT probably wouldn't be able to roll out G.INP or PhyR to most ADSL2+ exchanges, and I can't really imagine them spending a lot of money on replacing lots of exchange ADSL2+ equipment.

[kitz]

This is the ADSL DLM algorithm, as you can see its pretty basic without any INP.   
Impulse Noise Protection was only introduced with ADSL2(+) as an amendment to ITU G.992.5.
iirc ADSL1 doesn't have sufficient parameters (INPmin) to be able to support INP for DLM management.



@Mick.

However, that's not to say there may have been some proprietary form of doing this on the modem in a similar way to PhyR could for G.INP if both the modem and DSLAM support it.   I don't know and haven't checked. But it is the only plausible explanation I can think of if you say youve seen it on adsl1.

Whilst it may not be an adsl1 standard, my mind goes back to the days of MaxDSL which is ADSL1... which also supposedly doesn't support S=1/2 mode to reduce RS overheads.   However there were indeed a few people who did see the reduced overheads if 1)They were using particular BCM based modems AND 2) The DSLAM at the exchange was of a particular make.  Unfortunately I cant recall manufacturer off the top of my head  -  too long ago - but they were actually brand new ADSL2+ MSANs, running as ADSL1 over a 20CN backhaul which would only support ADSL1.


Thanks for supplying the pdf.   I can see on there the INP, but also note line rate in excess of 10Mbps which would also imply adsl2+ and therefore 21CN. 

Noted the INP values of 1.11 and 1.13.   
The usual INP parameters that we see are 3, 3.5 & 4 for NGA.....
and 0, 1 or 2 for 21CN WBC. Admittedly Ive not looked closely at adsl2+ stats recently.

There are probably three different types of 21CN exchange equipment identifiable by the differing vendor codes, yet you don't hear people complaining about a three tier system, most BT ADSL2+ exchange equipment probably isn't even capable of using PhyR. So BT probably wouldn't be able to roll out G.INP or PhyR to most ADSL2+ exchanges, and I can't really imagine them spending a lot of money on replacing lots of exchange ADSL2+ equipment.

How true!
G.INP is definitely not enabled nationwide on ADSL2+.  In fact I haven't even heard any rumours about it.   However that's not to say they aren't undertaking silent trials on a few select exchanges. I'm also beginning to suspect, as you say, that something proprietary may be going on. 

[kitz]

btw.   I just checked out Micks IP for the ISP.   
Just for the sake of elimination and to satisfy myself,  I wanted to rule out LLU as I know sky definitely use G.INP on ADSL2+.
I'm not sure about TT.   Does AAISP make it clear if they are using TT or BTw for your backhaul?

8 Aug 18:37:46
A SERVICE OPTION CHANGE ORDER IS IN PROGRESS ON THIS LINE

^ This is still playing on my mind..  although I would guess its far more likely to be migration from IPSC to WMBC.

[Mick]

Thank you both,

Perhaps what happened is shortly after you started using the HG612, something at the exchange detected the HG612 with PhyR enabled, and so decided to use PhyR. Perhaps it was a bit like how the FTTC DLM will only switch on upstream G.INP a little while after it detects you are using a compatible modem. That's why I suggested you might be able to get rid of it by leaving an incompatible modem connected for a while. After all, the DG834v2 is also pretty old and doesn't support PhyR, yet it managed to establish a connection. Or perhaps some software at the exchange was updated or some configuration changed and PhyR has been activated completely by accident.

This can make sense to me:  If I recall right the DG834v2 doesn't do INP, so it is not processing any headers/code that the DLM is sending over, doesn't get confused and manages to pick up a DSL connection.  The 2WIRE is doing some kind of INP, so it tries to process whatever proprietary code the exchange Broadcom chipset is sending, but it chokes at it and can't establish a DLM handshake successfully.

While I was fighting with the 2WIRE I left it online for more than 30 minutes, but it was not able to connect.  Perhaps I should have first shut down the HG612, wait for an hour or more and then try to connect with the 2WIRE.  What I also did not try is to start a line retraining period, which would probably flush any settings out of DLM's memory and start afresh with whichever CPE would be online at the time.

I am unsure what happens with Interleaving and if it is switched off when the Broadcom PhyR has been enabled.  As I mentioned Interleaving is shown set as auto in the ISP's control panel and also the HG612 shows:

Code: [Select]

MSGc: 52 12
B: 118 62
M: 2 1
T: 3 2
R: 14 10
S: 0.7328 1.8718
L: 2751 312
D: 2 16Where I understand "D" is for Interleaving?

However, when the 2WIRE was in use I would used to have double the RTT when I pinged a target or pinged my IP remotely.  With the HG612 the latency is significantly lower.  I am guessing therefore that the Interleaving has been switched off, or how else would I be getting reduced ping times?

Does AAISP make it clear if they are using TT or BTw for your backhaul?

There's only BTw up here, a small Market 1 exchange.  I checked with the ISP too and they confirmed it.

^ This is still playing on my mind..  although I would guess its far more likely to be migration from IPSC to WMBC.

Well, when a test is triggered by user or tech staff action, a bubble shows up on the graphs of the control panel, indicating the timeline when test was executed and who triggered it.  When I asked my ISP I was told that it is probably related to BT testing and I could ignore it.

Regarding INP on 2WIRE modems, I vaguely recall INP also showing on ADSLMax, but I can't recall what the values were.

I'm going to leave the HG612 on for now and not interfere with it, to see at what speed it settles and if disconnections reduce.

[WWWombat]

I am unsure what happens with Interleaving and if it is switched off when the Broadcom PhyR has been enabled.

With the HG612 the latency is significantly lower.  I am guessing therefore that the Interleaving has been switched off, or how else would I be getting reduced ping times?

I've been looking semi-interested at this, with the apparent mention of PhyR being turned on. But more from my interest in FTTC settings, so I'm afraid I can't add a lot.

However, I can say:
- Yes, D stands for the interleaving depth
- When the G.INP variant of interleaving is active on FTTC, we have found that it comes with a small amount of interleaving present - depths of 16 or less, in powers of 2 (where we think of numbers in the high hundreds or low thousands as large). The corresponding latency delay is usually set to zero, and any actual change in latency is almost immeasurable (I calculate it to be around 0.2ms). That is in comparison to when "full interleaving" is in use on FTTC, when it is easy to see the increase in latency to be 8ms or more.

However, your framing parameters show something different: alongside INP=29 for downstream, there is a delay of 8. There is also INP=2 upstream and a delay of 7.

In FTTC, those "delay" values would mean that 15ms of delay was allowed for interleaving, round trip. The HG612 produced these figures, right? If that HG612 gives faster ping times, then either the 2WIRE must be really slow, or these parameters don't work the same way in ADSL. What actual RTT times do you get when pinging, say, the BBC?

[Mick]

I often connect to my router remotely with VPN and ping a server within my LAN to establish the tunnel.  Typically it would take me 53ms or so, but now using the HG612 it only takes 23ms or less.  For BBC I get:

Code: [Select]

$ ping -c 4 www.bbc.co.uk
PING www.bbc.net.uk (212.58.244.69) 56(84) bytes of data.
64 bytes from bbc-vip114.telhc.bbc.co.uk (212.58.244.69): icmp_seq=1 ttl=56 time=22.7 ms
64 bytes from bbc-vip114.telhc.bbc.co.uk (212.58.244.69): icmp_seq=2 ttl=56 time=18.9 ms
64 bytes from bbc-vip114.telhc.bbc.co.uk (212.58.244.69): icmp_seq=3 ttl=56 time=19.5 ms
64 bytes from bbc-vip114.telhc.bbc.co.uk (212.58.244.69): icmp_seq=4 ttl=56 time=18.7 ms

--- www.bbc.net.uk ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3015ms
rtt min/avg/max/mdev = 18.754/19.985/22.728/1.614 ms
I get frame delay between 7 to 8 for downstream, on both 2WIRE and HG612.

[Mick]

I've left the HG612 off all night to see if the DLM will reset the configuration of my line and this morning I tried again to start a connection with 2WIRE.  No success.  10 minutes later I gave up and reconnected the HG612 after I pre-emptively changed a 470μF 16V cap which tends to blow, with a new 470μF 25V I had availalble.  I also placed it on an upright position on a stand, so as to allow better cooling.

When it connected the INP on downstream was showing 30!  At lunch time it resync'ed as expected due to noise on the line and it now shows 29 again:

Code: [Select]

# xdslcmd info --show
xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 1013 Kbps, Downstream rate = 13568 Kbps
Bearer: 0, Upstream rate = 1068 Kbps, Downstream rate = 11894 Kbps

Link Power State: L0
Mode: ADSL2+ Annex A
TPS-TC: ATM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 3.3 7.7
Attn(dB): 42.0 23.8
Pwr(dBm): 19.7 12.1
ADSL2 framing
Bearer 0
MSGc: 60 12
B: 120 62
M: 2 1
T: 3 2
R: 12 10
S: 0.6467 1.8718
L: 3142 312
D: 2 16
Counters
Bearer 0
SF: 49933 47675
SFErr: 0 0
RS: 4943462 1715282
RSCorr: 14 37
RSUnCorr: 0 0

ReXmt: 52 0
ReXmtCorr: 51 0
ReXmtUnCorr: 0 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 22500712 2010892
Data Cells: 51690 8336
Drop Cells: 0
Bit Errors: 0 0

ES: 84 2
SES: 82 0
UAS: 228 155
AS: 803

Bearer 0
INP: 29.00 2.00
INPRein: 0.00 0.00
delay: 8 7
PER: 16.00 16.84
OR: 32.98 8.54
AgR: 11878.35 1072.85

Bitswap: 188/188 109/109
Short of starting retraining on my line I don't know if there is any other way to connect to the exchange with 2WIRE.

[ejs]

I suggested disabling PhyR on the HG612 and leaving the HG612 connected like that for a couple of days. Then trying the 2WIRE.

xdslcmd configure --phyReXmt 0x0

[Mick]

Thanks ejs, I wasn't sure of the command and didn't make time to look into it further until now.  The line resync'ed after I ran it and the difference in interleave and INP are significant.  Interleave shows 64 instead of 2.  INP shows 1, instead of 29.

Code: [Select]

# xdslcmd info --stats
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 1083 Kbps, Downstream rate = 13796 Kbps
Bearer: 0, Upstream rate = 1083 Kbps, Downstream rate = 11886 Kbps

Link Power State: L0
Mode: ADSL2+ Annex A
TPS-TC: ATM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 3.2 7.1
Attn(dB): 42.5 23.8
Pwr(dBm): 19.6 12.1
ADSL2 framing
Bearer 0
MSGc: 59 12
B: 185 62
M: 1 1
T: 2 2
R: 14 12
S: 0.4994 1.8462
L: 3204 325
D: 64 16
Counters
Bearer 0
SF: 2842 2713
SFErr: 0 0
RS: 369237 97643
RSCorr: 0 0
RSUnCorr: 0 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 1286227 108297
Data Cells: 86 101
Drop Cells: 0
Bit Errors: 0 0

ES: 133 2
SES: 131 0
UAS: 433 311
AS: 46

Bearer 0
INP: 1.00 2.00
INPRein: 0.00 0.00
delay: 8 7
PER: 16.22 16.61
OR: 32.04 8.66
AgR: 11872.50 1087.75

Bitswap: 6/7 1/1

Total time = 5 hours 45 min 0 sec
FEC: 72019 2752
CRC: 6578 2
ES: 133 2
SES: 131 0
UAS: 433 311
LOS: 8 0
LOF: 35 0
LOM: 75 0
Latest 15 minutes 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
Previous 15 minutes time = 15 min 0 sec
FEC: 8 352
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 80 80
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 5 hours 45 min 0 sec
FEC: 72019 2752
CRC: 6578 2
ES: 133 2
SES: 131 0
UAS: 433 311
LOS: 8 0
LOF: 35 0
LOM: 75 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 = 45 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 1 0
LOS: 0 0
LOF: 0 0
LOM: 0 0

[ejs]

That's entirely expected, switching off PhyR has reverted the line to using conventional FEC+interleaving. Downstream INP=1 is the usual level for ADSL2+. Your ping times will very likely have increased.

[Mick]

Yep,

Code: [Select]

$ ping -n -c 4 bbc.co.uk
PING bbc.co.uk (212.58.244.22) 56(84) bytes of data.
64 bytes from 212.58.244.22: icmp_seq=1 ttl=56 time=28.0 ms
64 bytes from 212.58.244.22: icmp_seq=2 ttl=56 time=25.5 ms
64 bytes from 212.58.244.22: icmp_seq=3 ttl=56 time=24.9 ms
64 bytes from 212.58.244.22: icmp_seq=4 ttl=56 time=24.8 ms

--- bbc.co.uk ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3015ms
rtt min/avg/max/mdev = 24.884/25.859/28.083/1.305 ms
[15:34:29]michael@dell_xps:~ $

[Mick]

I've waited for just over 7 days running HG612 with PhyR switched off and then changed the modem to 2WIRE, but it wouldn't sync.  So I changed it to DG834v2 which sync'ed fine, but it proved to be terribly unstable.  So 3 days later I gave up and restored HG612 with PhyR.

Is this some broadcom conspiracy to stop me from using another chipset? LOL!

What does it take to move away from HG612?  Starting a retraining period on the line?

[burakkucat]

Is this some broadcom conspiracy to stop me from using another chipset? LOL!

Most peculiar. 

What does it take to move away from HG612?  Starting a retraining period on the line?

Quite possibly. 

[NewtronStar]

I suggested disabling PhyR on the HG612 and leaving the HG612 connected like that for a couple of days. Then trying the 2WIRE.

xdslcmd configure --phyReXmt 0x0

What would happen to an active G.INP line if you entered that command ?