Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: Mick on August 20, 2016, 03:50:02 PM
-
I am really perplexed with my observations ...
A couple of weeks ago I got a HG612 3B to see if it will hold my ADSL2+ line any better than a 2WIRE 2700HGV I have been using for a long time. I flashed the HG612 and used DSLstats to find out that it was able to connect at slightly higher speeds than the 2700HGV, but would also drop the line more frequently.
So, today I removed it and reconnected the 2700HGV. I was surprised to see that it would not finish training, or obtain a DSL connection. Looking at its admin GUI I found out that it was 'searching for DSL signal' but not finding any. I went through a whole process of replacing the 2700HGV for another 2700HGV with older firmware, swapping PSUs, etc. but neither of the 2WIREs was able to get a DSL signal and establish a connection.
Putting back the HG612 3B I was able to get a connection straight away!
So. I am completely at loss why this is so. Could connecting to the exchange with a flashed HG612 3B have cause a change of any settings at the exchange? Why aren't the 2WIRE modems connect to the exchange as they were previously perfectly capable of doing? Has anything changed BT-wise over the last couple of weeks?
I attach a screenshot of the 2WIRE settings. All devices are used in bridged mode.
PS. This is not relevant to my problem, but I noticed on the HG612 sshd is running:
649 0 292 S sshd -E but I am unable to connect to it ... any idea what it is used for?
-
It's been a long while since I last used a 2Wire device . . .
However I notice that your screenshot shows --
ATM Encapsulation: Bridged LLC
Is there an option to set it to VC Mux ? :-\
-
Thank you burakkucat,
For more than a year since BT changed their kit at the exchange I had to run the 2WIRE with Bridged LLC, or I wouldn't connect with PPPoE to the ISP. Have a look at this old post (http://forum.kitz.co.uk/index.php?topic=14509.new;topicseen#new) of mine with a link to BT's technical notice on this topic. The HG612 has the same setting and connects fine.
I just can't understand how this is happening, when two weeks ago the 2WIRE could connect and hold the line better than the HG612. I have now also replaced the telephone cable to the BT socket faceplate, and factory reset one of the 2WIREs, before then re-configured it in bridged mode. I've run out of ideas for things to try. BTW, the 2WIRE wouldn't achieve a DSL connection whether in bridged on non-bridged mode. This is what it's been reporting:DSL Synchronization: No DSL signal was found
G. DMT ATM Signal: No DSL signal was found
Has there been a change at BT's kit to only allow connections from more modern modems? (clutching at straws)
-
>> RAS RADIUS in Milton Keynes
Are you 21CN, if so then you may not longer have MK as your RAS. BTw started rolling out MSE bRAS (http://www.kitz.co.uk/adsl/MSE_BRAS.htm) about a year or so ago. However most exchanges were complete last year - unless your exchange has more recently gone 21CN.
I doubt this is the cause though for within the past couple of weeks.
-
I know it may not help with Mick's issue, but I was just wondering if there are a list of exchanges which have moved ADSL products onto MSE bRAS? I recently rung Zen after I was suffering some contention issues and they informed me I was on the Sheffield 'interconnect' by which I can only assume they meant the old bRAS system. I am the Kiveton (SLKIV) exchange if that is of any help.
-
PS. This is not relevant to my problem, but I noticed on the HG612 sshd is running:
649 0 292 S sshd -E but I am unable to connect to it ... any idea what it is used for?
It is just the ssh daemon process.
I suspect that you are unable to establish a ssh connection to the HG612 because you have not allowed such connections in the ACL.
Try going to Advanced --> Firewall --> ACL and adding a rule to allow a ssh connection from the LAN.
-
>> RAS RADIUS in Milton Keynes
Are you 21CN, if so then you may not longer have MK as your RAS.
Yes, you're right, I noticed this is now reported on my ISP's control panel for my connection:
21CN-ACC-ALN20-2401-L-NWS
However, I haven't noticed when the switch from the MK BRAS happened. Even if it happened in the last two weeks, would this be related to my trusted 2700HGV no longer being able to perform ATM encapsulation?
-
I suspect that you are unable to establish a ssh connection to the HG612 because you have not allowed such connections in the ACL.
Try going to Advanced --> Firewall --> ACL and adding a rule to allow a ssh connection from the LAN.
Thank you burakkucat, I'll try what you suggest because I can't connect with telnet from Linux/AppleMac, the login hangs once I enter username/passwd. Only netcat works (on Linux).
-
This morning I had another go troubleshooting this problem. I tried an old DG834v2 router with the DGTeam firmware. In bridged mode. It wouldn't connect. Then burakkucat's observation made me think to change the ATM encapsulation. I set it to VCMux and guess what? It connected!
So, the previous change in BT's kit which required LLC to be able to use a modem plus router with PPPoE, seems to have been reversed? o_O
With renewed enthusiasm I plugged in one of the 2WIREs changed the encapsulation to VCMux and for good measure rebooted it. Still no connection.
This is what I have a the moment in terms of results:
| MODEM | LLC | VCMUX | RESULT |
| 2WIRE | Yes | No | FAILS |
| 2WIRE | No | Yes | FAILS |
| DG834v2 | Yes | No | FAILS |
| DG834v2 | No | Yes | CONNECTS |
| HG612 | Yes | No | CONNECTS |
| HG612 | No | Yes | CONNECTS |
My (potentially incorrect) conclusions are:
- BT's SIN 482v1p13.pdf no longer applies, now that MSE RAS are being deployed.
- The HG612 must have some other feature, missing from the 2WIRE and missing from the Netgear, which allows it to connect to the exchange regardless of its ATM encapsulation, LLC or VCMux.
- Unlike Netgear, the 2WIRE is also missing some feature, which allows Netgear to connect with VCMux
What do you make of all this? What could be causing these differences between devices? Is it time to put my 2WIREs on ebay? :(
-
I think that if it doesn't find a DSL signal, then any PPP layer PPPoE LLC or PPPoA VCMUX settings are not relevant.
As you are ADSL2+, that's WBC, not IPStream Connect, so you're not looking at the applicable BT SIN document. But I think that doesn't matter. Even if the PPP layer settings were wrong, I'd still expect the DSL to complete training and enter showtime.
Could you post the full set of DSL stats from a connected HG612? I suppose it's plausible that the DSLAM is trying to use some INP level or interleaving/framing parameters that aren't supported by the 2WIRE, and the attempt to use them is confusing the 2WIRE so that the DSL fails to connect at all. The DG834v2 is pretty old, e.g. there's some tweak if you want to enable INP > 2 support, but it might not get confused and manages to negotiate some parameters that it does support.
-
Thank you ejs,
A couple of days after I started using the HG612 I noticed a message in my ISP's control panel logs. It said:8 Aug 18:37:46 8 Aug 18:37:52 BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=10031kb/s FTR=5913kb/s MSR=7392kb/s ServOpt=1 I/L=I
A SERVICE OPTION CHANGE ORDER IS IN PROGRESS ON THIS LINE
Up Sync=886kb/s LoopLoss=23.6dB SNR=15.5dB ErrSec=0 HECErr=0 Cells=0
Down Sync=10068kb/s LoopLoss=41.9dB SNR=6.1dB ErrSec=0 HECErr=N/A Cells=0
I hadn't triggered this test from the control panel, so I'm guessing the frequent line disconnections with the HG612 may have done it. Interleaving has always been switched on for my line because of the distance from the exchange and cross talk I get from the near by village (I found this out during a power cut which only affected them). The modem stats obtained since this morning, are as below:# xdslcmd info --stats
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 1013 Kbps, Downstream rate = 13708 Kbps
Bearer: 0, Upstream rate = 1068 Kbps, Downstream rate = 12014 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.4
Attn(dB): 42.0 23.7
Pwr(dBm): 19.6 12.1
ADSL2 framing
Bearer 0
MSGc: 63 12
B: 58 62
M: 4 1
T: 6 2
R: 12 10
S: 0.6243 1.8718
L: 3178 312
D: 2 16
Counters
Bearer 0
SF: 1149256 110295
SFErr: 3 0
RS: 118948028 1149675
RSCorr: 669 622
RSUnCorr: 11 0
ReXmt: 1814 0
ReXmtCorr: 1729 0
ReXmtUnCorr: 12 0
Bearer 0
HEC: 32 0
OCD: 0 0
LCD: 0 0
Total Cells: 528150255 46961012
Data Cells: 424788 104599
Drop Cells: 0
Bit Errors: 666 0
ES: 3 0
SES: 0 0
UAS: 51 51
AS: 18636
Bearer 0
INP: 29.00 2.00
INPRein: 0.00 0.00
delay: 8 7
PER: 16.15 16.84
OR: 34.17 8.54
AgR: 11998.77 1072.85
Bitswap: 3953/3953 397/397
Total time = 5 hours 11 min 27 sec
FEC: 669 622
CRC: 3 0
ES: 3 0
SES: 0 0
UAS: 51 51
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 11 min 27 sec
FEC: 31 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: 13 104
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 5 hours 11 min 27 sec
FEC: 669 622
CRC: 3 0
ES: 3 0
SES: 0 0
UAS: 51 51
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 = 5 hours 10 min 35 sec
FEC: 669 622
CRC: 3 0
ES: 3 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
I don't think I can tweak the interleaving at my end and in any case I wouldn't know what to set up without advice. ;)
-
How very strange. Could you give us the output of xdslcmd info --vendor also please. INP of 29 is an enormous value, and I believe the ReXmt counts indicate Broadcom PhyR (not G.INP) is actually in use on the downstream, and I didn't think BT enabled that, most BT DSLAMs/MSANs aren't even Broadcom based.
I suspect then that the 2WIRE is getting confused by the apparently active PhyR, the old DG834v2 won't support PhyR either, but presumably manages to not get confused and negotiate a working connection.
-
Here you go:
# xdslcmd info --vendor
xdslcmd info --vendor
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 1013 Kbps, Downstream rate = 13176 Kbps
Bearer: 0, Upstream rate = 1068 Kbps, Downstream rate = 10322 Kbps
ChipSet Vendor Id: BDCM:0xa3a7
ChipSet VersionNumber: 0xa3a7
ChipSet SerialNumber:
As well as my modem settings:# xdslcmd profile --show
xdslcmd profile --show
Modulations:
G.Dmt Enabled
G.lite Disabled
T1.413 Disabled
ADSL2 Enabled
AnnexL Disabled
ADSL2+ Enabled
AnnexM Disabled
VDSL2 Disabled
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)
Oops! I just noticed I had a retrain (again). :(
-
I noticed BT installed equipment that gave a Broadcom vendor code in the more recently (2015) upgraded to ADSL2+ exchanges, but Kiveton (SLKIV) was listed as having WBC ADSL2+ in the August 2014 list and also in another spreadsheet from January 2014. Of course BT may have installed another MSAN or new line cards at any time.
Presuming the PhyR enabling process works in a similar way to G.INP with the FTTC DLM, I suppose what you could do is disable PhyR on the HG612, note any differences in the stats, and leave it connected like that for a few days. After that time, hopefully the DLM will have noticed you are using a modem which doesn't support PhyR, and then it will stop trying to use PhyR on your line, and then the 2WIRE will be able to connect again. That's assuming the DLM has deliberately activated PhyR for your line, rather than it's been left enabled accidentally or is being tested or something like that.
Or just keep using the HG612 with PhyR, it should be making things much better than what interleaving can do.
-
I suppose it's plausible that the DSLAM is trying to use some INP level or interleaving/framing parameters that aren't supported by the 2WIRE, and the attempt to use them is confusing the 2WIRE so that the DSL fails to connect at all.
Actually you may be on to something there.
The 2 wire is very old and doesnt support some of the newer technologies. It was useless for me on Be about 8yrs ago as it couldnt support annex-m.
20CN DLM doesnt use INP. 21CN does.
Last supplied stats show DLM profile with INP although 29 is very high. Should be about 3/4 unless you have G.INP.
8 Aug 18:37:46
A SERVICE OPTION CHANGE ORDER IS IN PROGRESS ON THIS LINE
This isnt anything you could have started. Service option change could imply IPSC (IPstream connect) to WBC/WBMC.
Its to the ISPs advantage to move as many accounts over to WBC (21CN) from IPSC as soon as they can.
Moving from IPSC to WBC doesnt happen at the same time as the 21CN upgrade, the ISP decides when to do that.
I know it may not help with Mick's issue, but I was just wondering if there are a list of exchanges which have moved ADSL products onto MSE bRAS? I recently rung Zen after I was suffering some contention issues and they informed me I was on the Sheffield 'interconnect' by which I can only assume they meant the old bRAS system. I am the Kiveton (SLKIV) exchange if that is of any help.
Thinking about it.. although MSE bRAS started well over a year ago, FTTC was the first to start to use it. I may be imagining it, * but now you mention it, something rings a bell that ADSL would be done afterwards.
However.. being on 21CN doesnt necessarily mean MSE bRAS, as 21CN was around first and the upgrades are separate.
"Sheffield interconnect (http://www.kitz.co.uk/adsl/wbc_wbmc.htm#WBC_Interconnects)" is more likely to imply 21CN, although saying that IPSC will also aggregate at the interconnects. 20CN still uses the old bRAS system for authentication. Its only 21CN that is being upgraded to MSE bRAS.
-----
ETA was looking for something about MSE bras, and whilst I was I note ejs has also commented about the high INP value.
Warning - while you were reading 2 new replies have been posted. You may wish to review your post.... but here you go.
*No Im not imagining
"Users on FMSANs (Fibre) will be the first to be migrated to the new system. "
-
Thank you one and all, the esoteric knowledge of members to this forum always amazes me! :thumbs:
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:
$ 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.
-
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.
-
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.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.kitz.co.uk%2Fadsl%2Fimages%2FDLM_algorithm_adsl.png&hash=77ea97c70815b8c9e41e6011bd89761452b3d01c)
@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.
-
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.
-
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:
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.
-
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?
-
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:
$ 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.
-
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:# 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.
-
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
-
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.
# 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
-
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.
-
Yep,
$ 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:~ $
-
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?
-
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. :-\
-
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 ?
-
Nothing, because it's a different command to enable/disable G.INP.
To re-enable PhyR, the commands are:
enable on DS, disable on US:
xdslcmd configure --phyReXmt 0x1
disable on DS, enable on US:
xdslcmd configure --phyReXmt 0x2
enable on DS and US:
xdslcmd configure --phyReXmt 0x3
I am totally guessing about why PhyR is enabled on your line, but one possibility is that it's been switched on (or not switched off) accidentally. If BT were trialling anything, I would have expected them to be trialling G.INP on ADSL2+. I think a line profile specifies a minimum INP level, and a maximum delay, and then it's up to the DSLAM and modem to work out the exact framing parameters, which could result in an INP level higher than the minimum, and possibly a delay less than the maximum. And so the DSLAM may have decided that using retransmission is the best way to, in this case, massively exceed the minimum INP specified, while minimizing the delay.
A DLM reset to fast path (interleaving off) might get rid of it and allow the 2WIRE to connect.
-
I'm holding my breath to see what the current set up may afford me in terms of stable sync speeds. The 2WIRE was pretty stable, but usually at weekends it would resync typically at lunch time and then tea time. I'm guessing that some neighbour's kitchen hob, oven, or extractor fan is causing this problem and they only turn it on during those times, but I don't know really. The noise on the line at all other times is low and the errors even lower.
When I connected the DG834v2 it was able to connect, but it was ridiculously unstable. Since the 2WIRE would not sync under any circumstances, on Monday evening I gave up on the DG834v2 and its DG-Team firmware and replaced it with the HG612. I left PhyR on and so far it has only resync'ed once on Tue at 17:23. Thankfully, it resync'ed at a respectable 11.4Mbps. Unlike the 2WIRE the HG216 would initially sync at a marginally higher rate, but after a few resyncs it would drop lower. We'll see what happens in the future. If it stays at this level I will not bother with the 2WIRE again.
Thank you for your advice and guidance. :)