Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: renluop on April 23, 2018, 05:13:11 PM
-
Well as per title
Featured Products Downstream Line Rate(Mbps) Upstream Line Rate(Mbps) Downstream Handback Threshold(Mbps) WBC FTTC Availability Date WBC SOGEA Availability Date Left in Jumper
High Low High Low
VDSL Range A (Clean) 40 27.4 7.8 5.3 22.4 Available -- --
VDSL Range B (Impacted) 30.1 16.5 7.2 3.6 13.1 Available -- --
Stats recorded 23 Apr 2018 16:35:01
DSLAM type / SW version: BDCM:0xa48c (164.140) / v0xa48c
Modem/router firmware: AnnexA version - A2pv6F039g1.d24m
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 0 hour 21 min 54 sec
Resyncs: 4 (since 23 Apr 2018 09:53:58)
Downstream Upstream
Line attenuation (dB): 26.4 0.0
Signal attenuation (dB): Not available on VDSL2
Connection speed (kbps): 18158 5642
SNR margin (dB): 6.0 6.5
Power (dBm): 11.8 6.3
Interleave depth: 355 1
INP: 3.00 0
G.INP: Not enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
RSCorr/RS (%): 0.0025 0.0001
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 56.3 5.70
I am only at half estimated speed and below MIGALS. Can I expect that to improve?
I hope the stats provided may be of assistance in your consideration of my connection, but will provide what others you need.
-
Although not an analysis, just an observation, I see your downstream is on traditional interleaving (INP 3, delay 8), that's going to reduce your downstream sync rate compared to fastpath or G.INP. Is this a new service or was a fault recently fixed?
-
FTTC is a new service connected today. FWIW recent report on ADSL connection (https://community.plus.net/t5/Broadband/A-gander-at-my-connection-please/m-p/1522418#M322141) Connection is by SSFP.
-
what was the estimate provided by plusnet?
-
"Estimated speed 24Mbps to 36Mbps"
BT Estimate as in OP
-
As a consumer the BTw estimate isnt relevant sadly, its informational purposes at best. Also that handback threshold is a complete joke, its about 20% of the upper estimate so BTw thinking its ok to provide a massive 80% acceptable performance swing of line capacity.
Lucky for you plusnet have at least decided to put bigger emphasis on the clean vs the impacted estimate and are nowhere near the handback threshold, but that is a very wide estimate covering 33% of the max potential speed, something I feel has got out of control on FTTC and needs cracking down on.
So you at 18mbit down, estimate of 24mbit down. Those are the two important figures, providing the line is stable the speed should increase on switch to g.inp but by how much I dont know, its a wait and see. There will also be possible further improvement after that if the target SNRM gets reduced. I feel after DLM has found where it wants to be you will either be above 24mbit, in which case the line is in its estimated performance window, or not much below it, and plusnet would probably need a big push to consider it worthy of action. Fingers crossed the line is stable enough for a DLM profile to get you above 24mbit.
-
You mention G-INP. So it's not on automatically then? have I drawn a short straw and been allocated the ECI cab rather than the Huawei? PCP has both.
-
. . . have I drawn a short straw and been allocated the ECI cab rather than the Huawei? PCP has both.
No, you have drawn the long straw! :)
In your opening post you showed --
DSLAM type / SW version: BDCM:0xa48c (164.140) / v0xa48c
BDCM is an abbreviation for Broadcom and with sight of that information we can say that your circuit is connected to the cabinet equipped with Huawei electronics.
-
G.INP can take a while to be enabled. Could be a month. Patience my friend.
-
Very low initial speeds.
I wouldn't wait for DLM, improvements won't be that much.
I'd be on the ball to Plusnet and arranging an engineer visit as you are below your quoted estimates.
I recall you had a non OpenReach approved person tinker with the internal wiring. Try connecting to the test socket on the master socket and see if that makes any difference.
My estimates are similar to yours, and I sync at above my high estimate (in the 40's). No way I would accept below 20Mb with those estimates, something is up.
-
The d/s attenuation 26.4; on average what distance does that suggest? My guesstimate based on Google is ~1250 to 1320 metres. The non approved person mentioned above was at least ex BT ( and once lived close by).
I've posted on PN Forum, which sometimes is more responsive than "official channels".
I noticed that my router WAN service had both PPPoA and PPPoE settings listed. I hope that it was OK to remove the former, at least doing no harm.
Slightly OT question: shortly after moving in, 2002, our line got cut, and the engineer told me most of the spares were bad, but he'd found the best. Since then it has been good for the attenuation. Do pairs get inadvertently changed on upgrade to fibre?
-
No, you have drawn the long straw! :)
In your opening post you showed --
BDCM is an abbreviation for Broadcom and with sight of that information we can say that your circuit is connected to the cabinet equipped with Huawei electronics.
Actually, I thought so, but with my noddle I never feel sure about much. ;)
-
As someone suggested, PN will want to get an engineer in after I've done some tests. I have been struggling this p.m. to get on line via that. It just wouldn't work, but attachment seems to show otherwise.
Does that suggest anything, like a wonky router?
-
I don't think the attachment shows that anything is wonky! It really shows nothing of great significance other than that you have a working WiFi connection to your modem/router, a Billion 8800NL, but there is no connection to the Internet.
My suspicion is that the 8800NL has been mis-configured. Perhaps someone who has experience with using a Billion 8800NL for a G.993.2 (a.k.a. FTTC) service will be able to assist you?
The key magic phrases are --
- G.993.2
- PTM
- VLAN tagged 101
- Your login credentials
-
I don't think the attachment shows that anything is wonky! It really shows nothing of great significance other than that you have a working WiFi connection to your modem/router, a Billion 8800NL, but there is no connection to the Internet.
My suspicion is that the 8800NL has been mis-configured. Perhaps someone who has experience with using a Billion 8800NL for a G.993.2 (a.k.a. FTTC) service will be able to assist you?
The key magic phrases are --
- G.993.2
- PTM
- VLAN tagged 101
- Your login credentials
I should know my log in credentials of both PN and Billion and from router config I get
B0 Traffic Type PTM
PTM Interface
Interface Description Type Vlan8021p VlanMuxId Igmp NAT Firewall IPv6 Mld Remove Edit
ppp1.1 pppoe_0_1_0.101 PPPoE 0 101 Disabled Enabled Enabled Disabled DisabledThere's no mention of G993.2, but in router config ticked are VDSL and 17a.
I realise I'm the dullest knife in the Kitz drawer :D, but surely nothing is wrong with config.
-
I should know my log in credentials of both PN and Billion and from router config I get
B0 Traffic Type PTM
PTM Interface
Interface Description Type Vlan8021p VlanMuxId Igmp NAT Firewall IPv6 Mld Remove Edit
ppp1.1 pppoe_0_1_0.101 PPPoE 0 101 Disabled Enabled Enabled Disabled DisabledThere's no mention of G993.2, but in router config ticked are VDSL and 17a.
VDSL2, profile 17a, is G.993.2 (profile 17a) and all the other settings look correct, to me. Perhaps a fellow Billion 8800NL user will please check and comment?
-
Link to my billion bridge stuff is in my sig.
What is the problem? is it the case there is DSL sync but all internet is dead? that wasnt the impression on the first posts, else how was the OP posting on the site, was it via an alternative connection or something? This is important as I want to know if it "was" working but now stopped or never was working at all on that setup.
-
First an update G-INP has been applied with a very modest speed increase, and interleaving depth is now 8/1.
G-INP and Connection Stats follow.
Downstream Upstream
General
rtx_tx 39 0
rtx_c 39 0
rtx_uc 0 0
LEFTRS 1 0
minEFTR 20733 0
errFreeBits 6330422 0
Bearer 0
RxQueue 16 0
TxQueue 8 0
G.INP Framing 18 0
G.INP Lookback 8 0
RRC Bits 0 24
Interleave depth 8 1
INP 43.00 0.00
INPRein 0.00 0.00
Delay 0 0
Bearer 1
Interleave depth 1 0
INP 2.50 0.00
INPRein 2.50 0.00
Delay 0 0
==============================================================
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 5594 Kbps, Downstream rate = 21183 Kbps
Bearer: 0, Upstream rate = 5594 Kbps, Downstream rate = 20737 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.4 6.3
Attn(dB): 26.4 0.0
Pwr(dBm): 11.8 6.3
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 235 175
M: 1 1
T: 0 38
R: 14 14
S: 0.3622 0.9980
L: 5522 1523
D: 8 1
I: 250 95
N: 250 190
Q: 8 0
V: 1 0
RxQueue: 16 0
TxQueue: 8 0
G.INP Framing: 18 0
G.INP lookback: 8 0
RRC bits: 0 24
Bearer 1
MSGc: 90 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 10.6667 0.0000
L: 24 0
D: 1 0
I: 32 0
N: 32 0
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 362628
OHFErr: 0 1
RS: 222352760 3692510
RSCorr: 463 2
RSUnCorr: 0 0
Bearer 1
OHF: 1258396 0
OHFErr: 0 0
RS: 7550008 0
RSCorr: 6 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 45 0
rtx_c: 45 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 1 0
minEFTR: 20733 0
errFreeBits: 6387300 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 806067206 0
Data Cells: 5836847 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: 13 6
SES: 10 0
UAS: 3428 3418
AS: 20216
Bearer 0
INP: 43.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 9.51
OR: 0.01 26.89
AgR: 20769.93 5621.15
Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01
Bitswap: 418/418 530/530
Total time = 16 hours 56 min 33 sec
FEC: 61869 15
CRC: 1790 7
ES: 13 6
SES: 10 0
UAS: 3428 3418
LOS: 1 0
LOF: 7 0
LOM: 0 0
Latest 15 minutes time = 11 min 33 sec
FEC: 68 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: 9 0
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 16 hours 56 min 33 sec
FEC: 61869 15
CRC: 1790 7
ES: 13 6
SES: 10 0
UAS: 3428 3418
LOS: 1 0
LOF: 7 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 36 min 55 sec
FEC: 463 2
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
>
As to yesterday's events, which are the, I think, the matters concerning Chrys, the problems arose when I tried to use the NTE5C Mk4 test socket in anticipation of the tests PN wants me to run.
I opened up the faceplate and inserted the RJ11- RJ11 cable in what thought was the test socket just below the lip of the split top/bottom halves. It was impossible to see whether it had to go in clip up or down, but seemed firmish. The router lights did show some activity, but never got to internet illuminating. Mostly it got to the WLAN light, which though lit was quite dull either way the cable was in the test socket.
I gave up then!. Doubtlessly I am
getting something wrong. :'( ::) :-[ Just wondering, if puting the RJ11 in the test socket is me being stupid. Maybe I should've used the filter I still have, then plugged RJ11 into that.
Or am I barking up wrong tree again?
-
I opened up the faceplate and inserted the RJ11- RJ11 cable in what thought was the test socket just below the lip of the split top/bottom halves. It was impossible to see whether it had to go in clip up or down, but seemed firmish. The router lights did show some activity, but never got to internet illuminating. Mostly it got to the WLAN light, which though lit was quite dull either way the cable was in the test socket.
I gave up then!. Doubtlessly I am
getting something wrong. :'( ::) :-[ Just wondering, if puting the RJ11 in the test socket is me being stupid. Maybe I should've used the filter I still have, then plugged RJ11 into that.
Or am I barking up wrong tree again?
You need to use the filter - the test socket is a BT phone socket, not RJ11 :)
-
Doh (but no ray, me.... :-X) why did I not think that in the beginning! I'll have to get on to a nursing home to take me in. ;)
Sorry folks.
-
Remove the lower faceplate, then remove the MK3 faceplate. What you see remaining on the master socket is the test socket.
Connect 1 of the rat-tail broadband filters to the test socket and connect your RJ11 - RJ11 cable to that.
Let the Billion sync and check the stats. If there is no significant improvement then you just rolled out the internal wiring.
-
First an update G-INP has been applied with a very modest speed increase, and interleaving depth is now 8/1.
G-INP and Connection Stats follow.
Downstream Upstream
General
rtx_tx 39 0
rtx_c 39 0
rtx_uc 0 0
LEFTRS 1 0
minEFTR 20733 0
errFreeBits 6330422 0
Bearer 0
RxQueue 16 0
TxQueue 8 0
G.INP Framing 18 0
G.INP Lookback 8 0
RRC Bits 0 24
Interleave depth 8 1
INP 43.00 0.00
INPRein 0.00 0.00
Delay 0 0
Bearer 1
Interleave depth 1 0
INP 2.50 0.00
INPRein 2.50 0.00
Delay 0 0
==============================================================
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 5594 Kbps, Downstream rate = 21183 Kbps
Bearer: 0, Upstream rate = 5594 Kbps, Downstream rate = 20737 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.4 6.3
Attn(dB): 26.4 0.0
Pwr(dBm): 11.8 6.3
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 235 175
M: 1 1
T: 0 38
R: 14 14
S: 0.3622 0.9980
L: 5522 1523
D: 8 1
I: 250 95
N: 250 190
Q: 8 0
V: 1 0
RxQueue: 16 0
TxQueue: 8 0
G.INP Framing: 18 0
G.INP lookback: 8 0
RRC bits: 0 24
Bearer 1
MSGc: 90 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 10.6667 0.0000
L: 24 0
D: 1 0
I: 32 0
N: 32 0
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 362628
OHFErr: 0 1
RS: 222352760 3692510
RSCorr: 463 2
RSUnCorr: 0 0
Bearer 1
OHF: 1258396 0
OHFErr: 0 0
RS: 7550008 0
RSCorr: 6 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 45 0
rtx_c: 45 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 1 0
minEFTR: 20733 0
errFreeBits: 6387300 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 806067206 0
Data Cells: 5836847 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: 13 6
SES: 10 0
UAS: 3428 3418
AS: 20216
Bearer 0
INP: 43.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 9.51
OR: 0.01 26.89
AgR: 20769.93 5621.15
Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01
Bitswap: 418/418 530/530
Total time = 16 hours 56 min 33 sec
FEC: 61869 15
CRC: 1790 7
ES: 13 6
SES: 10 0
UAS: 3428 3418
LOS: 1 0
LOF: 7 0
LOM: 0 0
Latest 15 minutes time = 11 min 33 sec
FEC: 68 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: 9 0
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 16 hours 56 min 33 sec
FEC: 61869 15
CRC: 1790 7
ES: 13 6
SES: 10 0
UAS: 3428 3418
LOS: 1 0
LOF: 7 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 36 min 55 sec
FEC: 463 2
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
>
As to yesterday's events, which are the, I think, the matters concerning Chrys, the problems arose when I tried to use the NTE5C Mk4 test socket in anticipation of the tests PN wants me to run.
I opened up the faceplate and inserted the RJ11- RJ11 cable in what thought was the test socket just below the lip of the split top/bottom halves. It was impossible to see whether it had to go in clip up or down, but seemed firmish. The router lights did show some activity, but never got to internet illuminating. Mostly it got to the WLAN light, which though lit was quite dull either way the cable was in the test socket.
I gave up then!. Doubtlessly I am
getting something wrong. :'( ::) :-[ Just wondering, if puting the RJ11 in the test socket is me being stupid. Maybe I should've used the filter I still have, then plugged RJ11 into that.
Or am I barking up wrong tree again?
up to 21meg still at 6db, I think you just need to get a lower SNRM, and you will reach your estimate. :) Dont know how quick DLM lowers the DB target.
Note that the first few days are important for DLM, I dont advise disconnecting the DSL cable, just leave it alone. DLM wants to see "stability".
I can understand the curiosity to see if the test socket helps, but I really think you should wait for DLM to settle first.
-
Chrys, now I'm using the test socket properly, I'd better leave it there then.
To all: if any other graphs etc would be useful, please tell me and I will post them.
-
Wife noticed phone not working just now, phone screen showing "check telephone line". It was working before started fiddling with thest sovket, but I'm not sure, if that was before I inserted the filter yesterday.
The phone base works on the extension (original master) socket when filtered, and the router in the DSL side of the faceplate.
However to continue with the router in the SSFP test socket I have to use a filter. With filters in both SSFP
and extension I get "check telephone line" again.
My brain is hurting. Why are these problems coming, and are they solvable? Did the guy who modified the wiring make an errot, or more likely YT?
I'm minded to reject VDSL service as it's below minimum. Life might be slow, but easier. :'(
help!
-
Whilst you are using the "test socket", the only telephone that will work would be one plugged into the telephone socket on the "rat's tail" microfilter.
-
Thank you, B'cat.
As a BTW to anyone interested, what do all those G-INP stats tell?
BTW test taken today
-
Being just a throughput test, it tells me very little. :(
My suggestion is that you do as Plusnet support ask, whilst also keeping this thread updated with the details.
-
What did plusnet advise?
-
@ B'cat and Chrys.
Yes, I shall start their faulting process soon, but we're away the forepart of next week. Overnight speed rose by ~1800kbps, and d/s interleaving went from 8 to 4, I think. (Can't find reference to yesterday's).
Should I leave router on while away? My guess is yes.
Going OT, before passing over i found that the usual recommended channels were popular, so chose 13 on which I was the sole user. I've rest to that now, and the router has accepted. Odd is that Billion channel checker only goes to 11.
-
Should I leave router on while away? My guess is yes.
That is the convention with a G.993.2 (VDSL2) based service.
Some people with a "two box" solution (i.e. a separate modem and router) will switch off the latter and just leave the former powered-on so as not to invoke the wrath of the DLM process.
If you are going to be away for a number of days, then switch it all off and make a new start upon your return. Ultimately it has to be your decision . . . based upon your own preferences.
-
I would switch the modem/router off while you are away. As I understand it if there is no data flowing the DLM counts each time period as null for calculation purposes and given the unsatisfactory nature of your line it would be better for you to monitor any changes as they happen.
To comment on your line, I would be miffed at even 25-30mbit given your estimate. Best to get an engineer out before making improvements yourself, but depending on your wiring as it is now there could be a decent improvement by moving the modem next to the socket and using the shortest (twisted) RJ11 cable etc... but I guess maybe thats already the case for you.
Are you running dslstats to monitor your line 24/7? If not I highly recommend it. Could be an intermittent noise source that you have been getting unlucky with during resyncs or some such. Even if not, the picture you have of the line will be so much more detailed with its data.
-
I am quite surprised that the estimate is seemingly so much higher than your line can actually support. Even with 3 dB SNRM profile (if your line can deal with such a small margin), it seems unlikely that you'd be able to meet the minimum speed defined in the "clean" range (though the lower end estimate of 24 Mbps from PN seems in reach). Though what I can say is that your sync speeds seem about right for your attenuation and parameters set by the DLM.
I think if you report this as a fault, the most that will happen is an OR engineer will come out, check the line, swap the pair and probably hand you the conclusion that there is no fault. Don't let this discourage you though since you are currently receiving under what the ISP estimated. In the case where no improvements can be made they will probably offer you the ability to leave with no penalty (though it's probably not the result you want).
To give a better insight, perhaps you could provide some graphs from HG612 Modem Stats or a similar program that shows Hlog, Bitloading (with SNR) and QLN?
-
It isnt surprising, the estimate from BTw is a very wide estimate because of the wide possible affects of crosstalk. Noone has a right to a crosstalk free line, so its a lottery which end of crosstalk severity you get, if you unlucky on the crosstalk lottery the line is going to be way way below the maximum estimate, yes in 10s of mbits.
The estimate provided by plusnet is not that far above his actual sync speed, on the original days of DLM when we had no g.inp and no xDB profiles, so lines basically started as fast as they could get, there would be immediate merit in raising a low speed fault, but now on hawei cabinets that is no longer the case and estimates will reflect that lines can run at lower margins and with g.inp activated.
It is unfortunate he was advised on here to fiddle with his line so early as I considered that not a good idea, the reason is that DLM will be more sensitive to changes in the first 1-2 days, for that reason alone I would not fiddle with a line at all in that period, and now knowing we have the enhanced DLM for hauwei cabinets, unless there was a very big problem I would not touch the line until the profile settles. Personally I would be keeping it powered up on your break. DSL is an always on technology and this becomes more important when DLM is used.
I am curious what plusnet advised as that hasnt been said yet.
re0 the BTw estimate has no relevance to his contract, only the plusnet estimate does.
He has no contract with BT wholesale. He is a customer of plusnet. So his estimate is 24Mbps to 36Mbps in terms of what his isp is willing to support.
-
It isnt surprising, the estimate from BTw is a very wide estimate because of the wide possible affects of crosstalk. Noone has a right to a crosstalk free line, so its a lottery which end of crosstalk severity you get, if you unlucky on the crosstalk lottery the line is going to be way way below the maximum estimate, yes in 10s of mbits.
Perhaps I should have worded my previous message differently. I probably should have said it would be surprising if these estimates were provided on a cabinet which had been activated for a while (so it would have more data to work on). I do not know exactly when his cabinet was enabled or how BTw collects stats for its estimates, but I know that estimates on the DSL Checker are changeable.
re0 the BTw estimate has no relevance to his contract, only the plusnet estimate does.
He has no contract with BT wholesale. He is a customer of plusnet. So his estimate is 24Mbps to 36Mbps in terms of what his isp is willing to support.
To defend myself, I never exclusively stated anywhere that the BTw estimates had relevance in his contract or that the his contract was with BTw:
... it seems unlikely that you'd be able to meet the minimum speed defined in the "clean" range (though the lower end estimate of 24 Mbps from PN seems in reach) ...
... you are currently receiving under what the ISP estimated. In the case where no improvements can be made they will probably offer you the ability to leave with no penalty ...
Where PN stands for Plusnet.
-
Hi again! :)
Here are the requested graphs taken this morning. I hope they're what is wanted. The cable in use is 3M Metre RJ11 to RJ11 High Speed ADSL BroadBand Cable Made Using Cat 5e Twisted Pair, bought from Techware Games via Amazon, when the SSFP was fitted. It replaced 2 metre ISP's flat.
Cabinets There are 2 serving my PCP- the original ECI and a newer Huawei From Code Look FTTC Available from 28th September 2011, expanded 19th January 2017 Phase 06a 2011 I am on the Huawei. Have I missed anything? If you want more info, let me know before Tuesday, or from Friday next.
OT I have been plotting a diagram of speed estimates of my and nearby roads. It's a hunch that the other side of the cul-de-sac takes the expected route, but my side comes from the opposite direction.
-
If you really want Plusnet to send an engineer to try get your speed up a bit then you need to do it fairly quickly.
DLM has already put you on a 5dB profile. It will drop to 4dB in the next day or 2.
By the time it gets to 3dB (4-6 days?) DLM will probably have squeezed you into the 24Mb estimate. Plusnet won't do anything after this.
-
My guesstimate based on Google is ~1250 to 1320 metres.
I would like renluop to find the metallic distance from his premises to PCP cabinet or at least an estimate and not as the crow fly's by taking a walk the BT joints covers on the footpath to the PCP cab will be visible, these attenuation numbers coming from the modem can be misleading as to the distance.
as a reference my attenuation of 24.8dB it's 1Km or 1000 meters to PCP cabinet downstream sync rate 39999 kbps with G.INP and 4dB on XdB
-
If you really want Plusnet to send an engineer to try get your speed up a bit then you need to do it fairly quickly.
DLM has already put you on a 5dB profile. It will drop to 4dB in the next day or 2.
By the time it gets to 3dB (4-6 days?) DLM will probably have squeezed you into the 24Mb estimate. Plusnet won't do anything after this.
Oh dear! We're away Tuesday morning to Thursday evening! :-\
Resync'd today.
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 5510 Kbps, Downstream rate = 24008 Kbps
Bearer: 0, Upstream rate = 5510 Kbps, Downstream rate = 23156 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): 4.5 6.2
Attn(dB): 26.2 0.0
Pwr(dBm): 11.7 6.1
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 227 159
M: 1 1
T: 0 40
R: 14 12
S: 0.3132 0.9210
L: 6182 1494
D: 4 1
I: 242 86
N: 242 172
Q: 4 0
V: 0 0
RxQueue: 56 0
TxQueue: 14 0
G.INP Framing: 18 0
G.INP lookback: 14 0
RRC bits: 0 24
Bearer 1
MSGc: 90 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 10.6667 0.0000
L: 24 0
D: 1 0
I: 32 0
N: 32 0
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 60714
OHFErr: 0 0
RS: 7099448 2427750
RSCorr: 34 0
RSUnCorr: 0 0
Bearer 1
OHF: 34801 0
OHFErr: 0 0
RS: 208436 0
RSCorr: 0 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 3097 0
rtx_c: 4 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 23148 0
errFreeBits: 197326 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 24892515 0
Data Cells: 8990 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: 0 0
SES: 0 0
UAS: 20 20
AS: 559
Bearer 0
INP: 51.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 9.24
OR: 0.01 27.68
AgR: 23206.80 5537.43
Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01
Bitswap: 61/61 22/22
Total time = 9 min 39 sec
FEC: 34 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 20 20
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 9 min 39 sec
FEC: 34 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 20 20
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 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
Latest 1 day time = 9 min 39 sec
FEC: 34 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 20 20
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 = 9 min 19 sec
FEC: 34 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
> Maybe with lack of time, I should reject service????
-
What speed service did you come from before FTTC?
It sounds like you seen the BTw estimate and not happy with not been near the upper part of it, if you consider that simply not good enough then by all means cancel, DLM by itself wont get you near 40mbit.
-
I would switch the modem/router off while you are away. As I understand it if there is no data flowing the DLM counts each time period as null for calculation purposes and given the unsatisfactory nature of your line it would be better for you to monitor any changes as they happen.
The chances of no data flowing with everything turned off except the router are close to zero. Just look at stats when you have been away and there are several MB each day from the internet background noise such as hackers polling IP ranges to find vulnerable connections. Also if you have something like the TBB broadband quality monitor running it will be pinging the line constantly. In fact I'd suspect that leaving it on might fool DLM in to thinking the line is better than it is: if the only packets are very small and low volume the chances of errors on them will be lower then when the connection is being used in anger.
-
As far as I know, the amount of errors at the DSL level is not affected by the amount of traffic going over the Internet connection.
-
What speed service did you come from before FTTC?
It sounds like you seen the BTw estimate and not happy with not been near the upper part of it, if you consider that simply not good enough then by all means cancel, DLM by itself wont get you near 40mbit.
The line could be capable of over 7000 kbps, somewhat more with 3 dB forced SNRM. Actual connection stats midday day before change
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 20
Last initialization procedure status: 0
Max: Upstream rate = 508 Kbps, Downstream rate = 6224 Kbps
Bearer: 0, Upstream rate = 451 Kbps, Downstream rate = 7247 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): 2.9 12.4
Attn(dB): 46.5 26.3
Pwr(dBm): 0.0 12.8
ADSL2 framing
Bearer 0
MSGc: 59 12
B: 226 13
M: 1 1
T: 1 4
R: 0 0
S: 0.9978 0.9739
L: 1820 115
D: 1 1
Counters
Bearer 0
SF: 21888268 150260
SFErr: 62711 184
RS: 0 1807080
RSCorr: 0 0
RSUnCorr: 0 0
Bearer 0
HEC: 330347 121
OCD: 8667 0
LCD: 8667 0
Total Cells: 1771470550 377572601
Data Cells: 121663673 6527451
Drop Cells: 0
Bit Errors: 12715225 11124
ES: 21966 1341
SES: 776 0
UAS: 477 424
AS: 354956
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 16.21 17.53
OR: 32.07 8.21
AgR: 7251.67 458.21
Bitswap: 98152/98157 342/342
Total time = 12 days 20 hours 22 min 11 sec
FEC: 0 0
CRC: 76597 1755
ES: 21966 1341
SES: 776 0
UAS: 477 424
LOS: 5 0
LOF: 41 0
LOM: 23 0
Latest 15 minutes time = 7 min 11 sec
FEC: 0 0
CRC: 16 0
ES: 8 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: 0 0
CRC: 15 0
ES: 14 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 20 hours 22 min 11 sec
FEC: 0 0
CRC: 58525 21
ES: 9620 11
SES: 719 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 23 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 0
CRC: 1400 63
ES: 1030 31
SES: 3 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 4 days 2 hours 35 min 55 sec
FEC: 0 0
CRC: 62711 184
ES: 12536 95
SES: 723 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 23 0
> I am not a heavy user either. PlusNet's somewhat unreliable meter suggests an average over last quarter <15Gb/ month. DSLStats traffic figures for previous months I cannot find.
@re0 Suggested I supply graphs, which I did. If anyone analysed them, was anything of interest revealed?
-
I would like renluop to find the metallic distance from his premises to PCP cabinet or at least an estimate and not as the crow fly's by taking a walk the BT joints covers on the footpath to the PCP cab will be visible, these attenuation numbers coming from the modem can be misleading as to the distance.
as a reference my attenuation of 24.8dB it's 1Km or 1000 meters to PCP cabinet downstream sync rate 39999 kbps with G.INP and 4dB on XdB
I think my previous statement of distance was erroneous. From info gleaned by walking the route I thought most likely, supported by BTw estimates of addresses ~ 870 metres. However, from the plots referred to above it is not unlikely that our later built part of the estate comes in from the opposite direction. That route, being more rural with private drives is not easy to walk. Googles Maps' guesstimate 850-980 metres.
Satellite map, FWLIW, shows the situation, brownish markings route #1, green the route #2 variant.
-
guesstimate 850-980 metres.
With that distance a circuit should at least be getting 35Mbps - 46Mbps with a Broadcom 63138 modem if the internal and external wiring is of good quality, The BT Broadband availability checker for me has always reasonably correct over the last 6 years close to VDSL Range A clean.
This is now up to you on how to proceed modem stats Graphs are just a useful guide into the circuits behavior.
-
With that distance a circuit should at least be getting 35Mbps - 46Mbps with a Broadcom 63138 modem if the internal and external wiring is of good quality, The BT Broadband availability checker for me has always reasonably correct over the last 6 years close to VDSL Range A clean.
This is now up to you on how to proceed modem stats Graphs are just a useful guide into the circuits behavior.
I agree, but the comments in the posts above do strongly suggest that for some reason my circuit is incapable of speeds toward high end of the estimate. This is despite upgraded wiring, and the private engineer's comment on line quality. Decision is not easy, and less so due to the nearness to the hand back, and our away days. :help::yuck:
-
This is just me get Plusnet to send out an OR Broadband Engineer let them run the tests at your Master Socket with this JDSU it will show up the correct loop length pair balance and a lot of other stuff on your circuit it should not cost you anything.
But your VDSL line looks way better than that old ADSL
-
Earlier today you posted the Hlog plot for your circuit and I have now examined it.
I see that --
- the US0, DS1, US1 & DS2 bands are in use. (Good.)
- from the overall shape of the curve that there is no obvious defect in the metallic pathway. (Good.)
- it hints the overall length is more towards "longer" rather than "shorter". (No problem.)
The questions I need to ask are: Why do you need a G.993.2 (VDSL2) based circuit? What does it allow you to do that was not possible with a G.992.5 (ADSL2+) based circuit?
-
I agree, but the comments in the posts above do strongly suggest that for some reason my circuit is incapable of speeds toward high end of the estimate. This is despite upgraded wiring, and the private engineer's comment on line quality. Decision is not easy, and less so due to the nearness to the hand back, and our away days. :help::yuck:
Well we know plusnet are erring on the side of a caution a little bit by not committing to the low clean estimate from BTw.
However the low clean estimate is only 3mbit higher at 27mbit.
Dont get me wrong I would be disappointed been outside of the BTw estimate, but I wouldnt be cancelling the service either, 7mbit to 24mbit is a nice jump. Although you can call their bluff, say you going to cancel and it may trigger an engineer visit, what the engineer would do at that point tho is not a certainty. They may just say the line is within spec and leave.
Its too easy for someone who has got lucky on crosstalk to just say to everyone else "that speed sucks get it fixed". There is going to be losers on the crosstalk lottery. Now with that said it doesnt mean this is all down to crosstalk and there is no technical fault somewhere affecting the sync speed.
How has the line length been determined? Anything other than BTs own figures is speculation really. Lines can rake odd routes, there can also be cable bundled up underground or something adding to length.
-
Well we know plusnet are erring on the side of a caution a little bit by not committing to the low clean estimate from BTw.
However the low clean estimate is only 3mbit higher at 27mbit.
Dont get me wrong I would be disappointed been outside of the BTw estimate, but I wouldnt be cancelling the service either, 7mbit to 24mbit is a nice jump. Although you can call their bluff, say you going to cancel and it may trigger an engineer visit, what the engineer would do at that point tho is not a certainty. They may just say the line is within spec and leave.
Its too easy for someone who has got lucky on crosstalk to just say to everyone else "that speed sucks get it fixed". There is going to be losers on the crosstalk lottery. Now with that said it doesnt mean this is all down to crosstalk and there is no technical fault somewhere affecting the sync speed.
How has the line length been determined? Anything other than BTs own figures is speculation really. Lines can rake odd routes, there can also be cable bundled up underground or something adding to length.
See Reply #42 on: Today at 05:01:46 PM ». I have walked the routes often over 16 years' residence, and have plotted estimates around me quite closely. Yes, it's not scientific, but it's the best I can do, and hopefully no that inaccurate. I take your points though!
[Moderator edited to interchange the two closing tags, thus fixing the minor mishap.]
-
Compared to historical data which assumes 6db target margin, the speed probably is low. If you do get an engineer ask him to give you line length data.
-
You mean the D side?
-
yeah, the length of the copper, so for FTTC just the D side.
-
Is it allowed to cancel due to low speeds, without paying the early termination charges, if you haven't given Plusnet the opportunity to fix it first?
-
I'm running speed tests for PN faulting, and accidentally ran one twice. The first reported ~20 Mbps and Ping ~35ms, the accidental ~80Mbps and ~20ms.
Is this the result of my ineptitude, or does it have significance? But what?
-
Is it allowed to cancel due to low speeds, without paying the early termination charges, if you haven't given Plusnet the opportunity to fix it first?
No. According to https://www.plus.net/help/broadband/broadband-speed-estimates/#i-think-i-want-to-leave--what-do-i-need-to-know (https://www.plus.net/help/broadband/broadband-speed-estimates/#i-think-i-want-to-leave--what-do-i-need-to-know) you have to let them try and resolve it first:
We'd be sad to see you go. But if you do decide to try another provider, we'll waive any early termination charges or cease fees as long as:
- you've spoken to us and a speed fault has been raised
- you've given us a chance to take a look into and resolve the problem, including letting an engineer come to your home to take a look
- your Broadband is slower than the Minimum Guaranteed Access Line Speed
- You have contacted our Customer Options Team to tell us you want to leave because we can't resolve your speed fault
This is pretty much alike BT's terms (http://bt.custhelp.com/app/answers/detail/a_id/35296/~/your-line-speed-explained (http://bt.custhelp.com/app/answers/detail/a_id/35296/~/your-line-speed-explained)) which are probably down to the Ofcom Voluntary Code of Practice: Broadband Speeds (though I can't say I have read into it).
-
I'm running speed tests for PN faulting, and accidentally ran one twice. The first reported ~20 Mbps and Ping ~35ms, the accidental ~80Mbps and ~20ms.
Is this the result of my ineptitude, or does it have significance? But what?
Where are you running the tests? BTW speed tester? If so, a wild variance, as many on the forum have noticed :giggle:, is not too unusual.
-
If the Plusnet Hub One syncs lower than your Billion, using that might keep you below Plusnets estimate after your line drops to a 3dB snrm target.
It will drop to 3dB today or tomorrow, and take you above 24Mb.
-
Tricky, as at 9 I'm off away to latish Thursday.
-
Back now!
PN have been in contact and suggest an engineer visit as speed below min (not hand back). GEA test and Radius are in att'd PDF, and line is longer than thought. (I know you told me so :-[ :D). There seems little of note in the test. Could there still be something in our wiring since the SSFP was fitted, and test socket moved from d/stairs to room above by my contractor? If he's done the job properly, I'd hope BT would not spot any thing. Thoughts?
I've left the Billion router on while away. Before going the FECs were quite low, but yesterday's (no activity by me, DSLStats recorded @ 14749443/hour, and today @ 49319738/hour.
Does anyone know what Sagemcom the HubOne is based on, and if DSLStats will yield any stats at all, should I need change to it?
-
Could there still be something in our wiring since the SSFP was fitted, and test socket moved from d/stairs to room above by my contractor? If he's done the job properly, I'd hope BT would not spot any thing. Thoughts?
I have every confidence that the work was done correctly. My advice is to forget that it took place and do not mention it to anyone! :-X
-
I've left the Billion router on while away. Before going the FECs were quite low, but yesterday's (no activity by me, DSLStats recorded @ 14749443/hour, and today @ 49319738/hour.
Suspect that will be down to XdB being active the lower the SNRM decreases from target margin of 6dB those FEC counts will increase dramatically.
-
History of readings a little before midnight
Average error rates by day
03 May 2018
CRC errors per hour: 0 Down, 0.84 Up
FEC errors per hour: 49409271 Down, 1.81 Up
HEC errors per hour: 0 Down, 0 Up
ES per hour: 0 Down, 0.76 Up
SES per hour: 0.25 Down, 0 Up
02 May 2018
CRC errors per hour: 29.4 Down, 1.13 Up
FEC errors per hour: 14749443 Down, 2.17 Up
HEC errors per hour: 0 Down, 0 Up
ES per hour: 0.83 Down, 1.13 Up
SES per hour: 0.42 Down, 0 Up
01 May 2018
CRC errors per hour: 0 Down, 0.75 Up
FEC errors per hour: 2637 Down, 2.72 Up
HEC errors per hour: 0 Down, 0 Up
ES per hour: 0 Down, 0.75 Up
SES per hour: 0 Down, 0 Up
30 Apr 2018
CRC errors per hour: 0.09 Down, 0.88 Up
FEC errors per hour: 584 Down, 1.67 Up
HEC errors per hour: 0 Down, 0 Up
ES per hour: 0.04 Down, 0.88 Up
SES per hour: 0 Down, 0 Up
29 Apr 2018
CRC errors per hour: 0.06 Down, 0.76 Up
FEC errors per hour: 3169 Down, 3.38 Up
HEC errors per hour: 0 Down, 0 Up
ES per hour: 0.06 Down, 0.76 Up
SES per hour: 0 Down, 0 Up
28 Apr 2018
CRC errors per hour: 0 Down, 0.82 Up
FEC errors per hour: 309 Down, 4.32 Up
HEC errors per hour: 0 Down, 0 Up
ES per hour: 0 Down, 0.73 Up
SES per hour: 0 Down, 0 Up
27 Apr 2018
CRC errors per hour: 22.4 Down, 0.92 Up
FEC errors per hour: 1437 Down, 1.13 Up
HEC errors per hour: 0 Down, 0 Up
ES per hour: 0.42 Down, 0.92 Up
SES per hour: 0 Down, 0 Up
26 Apr 2018
CRC errors per hour: 0.13 Down, 1.23 Up
FEC errors per hour: 391 Down, 1.65 Up
HEC errors per hour: 0 Down, 0 Up
ES per hour: 0.13 Down, 1.19 Up
SES per hour: 0 Down, 0 Up
25 Apr 2018
CRC errors per hour: 74.9 Down, 1.34 Up
FEC errors per hour: 2244 Down, 5.20 Up
HEC errors per hour: 0.04 Down, 0 Up
ES per hour: 1.05 Down, 1.13 Up
SES per hour: 0.59 Down, 0 Up
24 Apr 2018
CRC errors per hour: 19.4 Down, 0.42 Up
FEC errors per hour: 4515 Down, 1.22 Up
HEC errors per hour: 484 Down, 0 Up
ES per hour: 1.37 Down, 0.38 Up
SES per hour: 0.71 Down, 0 Up
23 Apr 2018
CRC errors per hour: 103 Down, 4.18 Up
FEC errors per hour: 767 Down, 0.16 Up
HEC errors per hour: 249 Down, 8.29 Up
ES per hour: 41.1 Down, 4.50 Up
SES per hour: 8.68 Down, 0 Up
I'm not disputing what you say, but doesn't the sudden 559300% jump from 1-2 May even so seem excessive? And there's the 300+% lift since. Is the %age increase I am seeing common?
-
It is a big jump when seeing it like that, are you going take up the offer for a engineer visit
-
We'll probably with less trepidation than before B'cat's reply.
From May 03, 2018, 06:26:36 PM Does anyone know what Sagemcom the HubOne is based on, and if DSLStats will yield any stats at all, should I need change to it
Is anyone able to answer, please?
-
The Plusnet Hub One will not work at all with DslStats.
It will provide the same basic stats via its web interface as the BT HomeHub 5A does.
-
I thought that was so, but had vague idea that Lantiq chipsets did sometimes work limitedly. Where from goodness knows! I wonder if I can persuade Lowen's Routerstats to yield SNRM live activity.
-
There's basic monitoring of a Plusnet Hub One available on RouterStatsHub (http://www.vwlowen.co.uk/RouterStatsHub/routerstatshub.htm).
-
Thank you! :)
I've managed the set up. For anyone interested here's the summary.
1. Product name:Plusnet Hub
2. Serial number
3. Firmware version:Software version 4.7.5.1.83.8.237.2.2 Last updated Unknown
4. Board version:Plusnet Hub One
5. DSL uptime:0 days, 13:08:09
6. Data rate:5358 / 22144
7. Maximum data rate:5358 / 23453
8. Noise margin:5.9 / 4.0
9. Line attenuation:29.2 / 26.0
10. Signal attenuation:29.0 / 22.0
11. Data sent/received:61.9 MB / 635.5 MB
12. Broadband username: @plusdsl.net
13. 2.4 GHz Wireless network/SSID:PLUSNET-****
14. 2.4 GHz Wireless connections:Enabled (802.11 b/g/n (up to 144 Mb/s))
15. 2.4 GHz Wireless security:WPA2
16. 2.4 GHz Wireless channel:11
17. 5 GHz Wireless network/SSID:PLUSNET-****
18. 5 GHz Wireless connections:Enabled (802.11 a/n/ac (up to 1300 Mb/s))
19. 5 GHz Wireless security:WPA2
20. 5 GHz Wireless channel:Automatic (Smart Wireless)
21. Firewall:Default
22. MAC Address:*
23. Modulation:G.993.2 Annex B
24. Software variant:AA
25. Boot loader:1.0.0
Plusnet Hub One | Software version 4.7.5.1.83.8.237.2.2 | Last updated Unknown
-
Engineer is booked for Wednesday p.m. :fingers:
I have changed to PN's Hub One to be "standard and innocent".
Hub connects lower, and with a near 3dB increase in attenuation. I know about how the calculation can vary, but does such a variation seem normal?
-
Since the last set of stats you posted your target snrm has dropped from 4dB to 3dB.
You're now above the 24Mb minimum Plusnet quoted.
The Plusnet Hub One syncs just under 24Mb, so leave that in place.
Hopefully the engineer can increase your speeds a little. Keep us updated.
-
Engineer is booked for Wednesday p.m. :fingers:
I have changed to PN's Hub One to be "standard and innocent".
Hub connects lower, and with a near 3dB increase in attenuation. I know about how the calculation can vary, but does such a variation seem normal?
I get similar behaviour with a HH5A versus Broadcom-based modems on my line. Billion 8900AX reports 27.6 db attenuation, Zyxel VMG8924 reports 28.2 dB, and HH5a reports 32.6 db! And this is reflected by sync speeds: Billion and Zyxel both hit the 15000 cap, but HH5a never gets much above 11000.
-
@j0hn
Actually PN suggested test as perf below the lower estimate rather than handback
-
Mind wandering/ mulling time! :: The ADSL rate was very good for distance, thought to be a little less than 3 km. The stated length from PCP to me is a little over 1 km. House was built c.1970, as part of an estate and phone cables are DIG. Could horrible ali in the line from PCP to house be the cause of my misfortune, but not cause such trouble with ADSL? Would complete or part of that length be needed to give result as is?.
-
Could horrible ali in the line from PCP to house be the cause of my misfortune, but not cause such trouble with ADSL? Would complete or part of that length be needed to give result as is?.
I can't see how the problem depends upon the xDSL type.
-
I got idea from https://community.plus.net/t5/Fibre-Broadband/Aluminium-Telephone-Line/td-p/1409961 where in the first of the posts OP seems to put his low speed vs estimate on ali. Are you saying that ali makes no difference whatever to sync speeds VDSL or ADSL?
-
I am unaware of how the metallic pathway will selectively penalise a VDSL2 based service (over an approximate distance of 1 km) more than an ADSL2+ based service (over the same approximate 1 km distance plus a further approximate 2 km distance)! :-\
-
Aluminum has about 60 percent of the conductivity of copper - so, other things being equal, which I don't know about, would have to ask Black Sheep, it ought to make a difference to attenuation surely?
-
You are quite correct in that respect.
We could also consider that aluminium, a highly reactive, amphoteric, metal, which pasivates rapidly in the presence of oxygen, will show greater attenuation as the frequency is raised due to the skin effect.
But in renluop's case, the D-side length of (presumed) aluminium cable remains the same. Hence my earlier musing . . .
-
Aluminium certainly does make a difference. Our estate was built in the seventies and we highly suspect there is aluminium in the circuit here. We're about 450 -500 meters and my sync has always been on the low side, down stream ranging from 60 at best very briefly to as low as 38 but generally been in the forties, upstream started out at 12 and has gradually dropped to at the lowest point just under 6, but has fluctuated between 6 & 8 recently. I was first on the cab in 2012, which is unfortunately an ECI which no doubt also played it's part in the low speeds.
-
@Ronski
How good was your old steam connection compared with BT estimates?
-
if equal size ali has worse loop loss, but if e.g. 0.6 ali compared to 0.2 copper, it wouldnt be inferior.
Another problem with ali is on the joints.
I think the most plausible explanation for your underwhelming sync speed is crosstalk, this can be to a degree be verified if you posted a QLN graph.
-
I got FTTC in August 2012, back then the estimates were not very accurate, I think mine were 66/12 but can't be sure. The estimates dropped as they gathered data from lines.
-
Chrys, I would, if i could, but am presently using the HubOne. Therefore here is one from the Billion just before I swapped. Also here is the GEA Test, in case that's of some value.
Ronski I was just curious, if, like me, your ADSL was better than expected.
-
As I expected it to be, the DLM profile listed on the GEA test is way out of date.
It shows the line as being interleaved, with no G.INP.
We know this to be incorrect.
-
Ronski I was just curious, if, like me, your ADSL was better than expected.
I think it was, but so long ago now can't really remember. The top end of my current estimate is what I used get IIRC
-
ADSL speeds back in 2011 was dependent on whiich ISP was being used at the time freeserve/wanadoo/orange 5Mbps , TalkTalk 4.5 Mbps , BT 6.1 Mbps the total loop length from premises to the exchange is 1.9km
The D-side on FTTC cabinet to premises is 1KM if that helps your nerves :-\
-
NS, you talking about yourself? At 1 km D side what do you get? I did mention that I thought route taken to our and nearby houses could have taken a different route, as houses were on last phase. (We have flues not chimneys. There's also a SCP at the estate entrance, so were we teed off from there and taken round the houses to serve into the country with us by the way? (musing again).
I await Chrys' opinion of QLN and crosstalk.
Had a speed reduction this evening to 19. My own blessed fault, it was my tidying the cable cats' cradle of wiring round my tower extension lead, that did it!
-
Definitely wait for Chrysalis he is the best broadband stats analyzer on these forums, hope all goes well during OR engineer visit tomorrow.
-
10th Thursday.
-
Engineer is booked for Wednesday p.m. :fingers:
An adjustment has been made
-
Definitely wait for Chrysalis he is the best broadband stats analyzer on these forums, hope all goes well during OR engineer visit tomorrow.
Dont think I am but I appreciate the good comment Newt. :)
-110 in my view is quite heavy crosstalk, is it possible to also post a SNR/bitloading graph?
-
Hi and thanks, Chrys, for replying. I'm unsure what you mean by-110 is quite heavy cross talk. Is that where the DS graph touches or does crosstalk affect further along. Sorry for being a rocking horse, and not understanding.
Graphs: I have limited time this evening, and Routerstats is set to record @ 10 secs, so for ~ @ 1 hour/graph is a lot to prepare and post. Except for a couple of v. early morning oddities that had no entries and clearly erroneous DS readings. the SNRM has been remarkably steady, as it was with the Billion.
AVERAGE 5.87 3.82
MAX 6.6 4.2
MIN 5.1 3
The PN router does not supply bitloading details. I can post some detail from Billion router, which does, if you want, hopefully, very late this evening.
-
With risk that it may be n.b.u. here's the latest (5/5) bit loading graph from the Billion.
-
Yeah on most of your useable tones it looks like you got fairly heavy crosstalk with very heavy crosstalk on the strongest tones.
The thing is QLN is not for sure crosstalk, it is just observed that as crosstalk increases then so does QLN.
-
Had visit: I'll post more when the report to PN is to hand. The engineer's equipment was predicting 26 Meg, which is below the lower clean estimate from PN, but router 21 Meg @~3dB. DLM reset @6dB brought predicted down to 21 with the router saying some 5 Meg lower. CRCs reported @ 3dB were 60/5 minutes- max acceptable 150. Line does contain some ali, and route is what I originally thought.
Disappointing, and mystifying why router is at odds with what engineer saw, and what the Billion gave was not too different from the HubOne.
Thoughts?
-
I hope the engineer did more than plug in his test equipment and say yes it is not working well!
I would expect at least an attempt to see if there is a better pair between cabinet and premises to solve the problem if no other faults were detected.
The last few engineers I had (to solve the same fault) did in their own way try their hardest to solve my problem. There were major communication issues that soured the experience quite significantly but the end result was a 20Mb uplift so I was pleased.
BT also haven't been back to properly fix the issue though so I suspect I may have trouble again at some point.
The engineers I have had previous to this wanted to be in and out as quick as possible, didn't want to fix the problem and told you a pack of lies to do this. This is proven by the fact if you get engineers who do care you can end up with a uplift.
-
He had suspected a battery fault somewhere, but couldn't locate it. His position was that PN's estimate was not not near to what his tool suggested.
As to a better pair, I'm not sure he'd've found any, for even 16 years back the engineer told me all in the road were bad, and I was given the best he had available.
-
I think someone more experienced needs to reply. I do not know what you can reasonably expect BT to do. If voice line isn't working well you may have more "rights" - is it very noisy? If there are no working pairs surely BT should put a new cable in?
Interestingly when my problems finally got me into handback territory the tests the ISP run detected a battery fault and that is what eventually got me on the road to being fixed after being fobbed off.
If the line shows an error it definitely gives you more power and the ISP is generally less arsey with you as there is less chance they will end up with a bill from BT for the engineer visit.
-
Its not far from what I warned about, line in spec, nothing to be done. BT now set very wide performance specs on each line so they can cover high levels of crosstalk as acceptable service. The reset will hurt your line as you lose g.inp and the lower noise margin target which now needs to come back.
-
But why is the router so at odds with what engineer saw? Sorry, I just can't get my head round that, and more so since both the ISP supplied and the Billion syncs were not unreasonably apart before.(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.free-smileys.com%2Ffiles%2Fthinking-smileys%2F878.gif&hash=9b4f73aaee206e9ebb41b7edec19b23389edbaf0)
-
Since about 2.30 I'm back using the Billion with a 4000 kbps increase in sync to current 19800 kbps with 6.8 dB SNRM. G-INP looks if it's back
Downstream Upstream
General
rtx_tx 915445 0
rtx_c 28 0
rtx_uc 0 0
LEFTRS 0 0
minEFTR 19798 0
errFreeBits 1920873 0
Bearer 0
RxQueue 16 0
TxQueue 8 0
G.INP Framing 18 0
G.INP Lookback 8 0
RRC Bits 0 24
Interleave depth 8 1
INP 45.00 0.00
INPRein 0.00 0.00
Delay 0 0
Bearer 1
Interleave depth 1 0
INP 2.50 0.00
INPRein 2.50 0.00
Delay 0 0
and all that's showing in DSLStats are 93 FECs/ hour.
-
Disappointing result after OR visit would have thought there may have been some kind of fault showing why your line is way below the impacted range.
-
Impacted range at the start of this thread was 30.1 - 16.5, it's not below that.
-
Suppose its not below when you look at the VDSl range B impacted Low Download 30.1 to 16.5 Mbps yet the Upload seems to be doing fine in the Range A Low.
-
Upstream is either barely within the A range, or well within the B range. There's a much larger overlap between the A and B upstream ranges.
-
Disappointing result after OR visit would have thought there may have been some kind of fault showing why your line is way below the impacted range.
But from my earliest postsHe had suspected a battery fault somewhere, but couldn't locate it.
-
Have never understood this battery fault and how it effects the broadband this is just a copy & paste ->
Re: What the heck is a battery fault ?
The Battery Contact can occur anywhere in the Network. The test system can see it because when the Test Head disconnects your line to test it theoretically there should be no DC Voltage, although you will get some leakage from other pairs but that should never really amount to anymore than a few volts.
Anything over 9v DC will be classed as a Battery Contact.
Openreach Engineers use a test called an RFL Bridge to locate the contact. Some can be straightforward to locate but some can be difficult.
If you have a Battery Contact it means it also has an Earth, to locate it via an RFL Bridge one leg of the pairs needs a resistance of at least 100 x ohms greater than the other leg. If both legs have a contact then you need to either run a 5 wire RFL Bridge or find a spare in the same cable length to test it against.
Also not all the Battery will necesarily be in one place, I've seen it before where there's say 35v DC but in one joint is a 10v contact and then the other 25v in another joint further up the line.
Either way it needs an Engineer to go and fix it. It's nothing you can do.
-
Impacted range at the start of this thread was 30.1 - 16.5, it's not below that.
Then, what I posted would have been from BTw ADSL checker. PN in their estimate did not refer to impacted range. This is what they said in their messages We estimate your broadband speed should be between 27Mbps and 40Mbps and your minimum guaranteed access line speed is 22.4Mbps.
Also from N'star's post Also not all the Battery will necesarily be in one place, I've seen it before where there's say 35v DC but in one joint is a 10v contact and then the other 25v in another joint further up the line.
Interesting, as he did say of the ali, that he knew it was there, but not how much and the joints were often the problem. Given the comment of the engineer in '02, mentioned somewhere above, that I can well believe.
-
Have never understood this battery fault and how it effects the broadband . . .
Remember that a broadband connection to the Internet being carried over an xDSL link consists of two (very low power) radio frequency transceivers (operating in differential mode) at either end of a metallic pathway. That metallic pathway, the telephony circuit, is coerced into operating as a radio frequency transmission line. The transmission line needs to have a good AC balance to reject any common-mode interference which may be coupled into the pair. With spurious contact(s) to the pair, either a battery contact or an earth contact or both faults, the transmission line becomes severely unbalanced. The end result is that the broadband service is degraded.
-
the transmission line becomes severely unbalanced. The end result is that the broadband service is degraded.
So I am guessing renluop will need further OR engineer visits to find and fix this, not something myself would like as I have some kind or Openreach Phobia but could endure if the end result means a less degraded broadband signal.
-
So I am guessing renluop will need further OR engineer visits to find and fix this, not something myself would like as I have some kind or Openreach Phobia but could endure if the end result means a less degraded broadband signal.
There are two factors to consider: (1) Hampshire is not Lancashire, so there is no chance that Black Sheep would attend. (2) The D-side is DIG, made of aluminium and, after many repairs to the various pairs that it contains, appears to consist more of joints than of cable!
Basically the cable needs to be replaced. It needs an Openreach technician to "fault it" and write out an "A1024". :-X
-
Basically the cable needs to be replaced. It needs an Openreach technician to "fault it" and write out an "A1024". :-X
Gezz a A1024 know what that is, can take many months for any work to be done unless you push someone :-X
-
Irrelevant comment.
It just so happens that Openreach are in our road in next door but one, outside which is a chamber constructed, when once they dealt with a voice fault on my line.
Of course coincidence.
-
Woe is me! For most of the day internet has been inaccessible. Billion has tried incessantly to get a connection. Bearer 0 has shown feasible values, but Bearer 1 nothing, inactive.
I thought better see it's not the Billion, so reinstalled the HomeHub 1. That was after 18:30. Then at 18:50 the internet connection resumed. Now was it mere coincidence that it resumed with the Hub in place, or is the Billion the cause of the troubles? Should I put the Billion back?
Also there was another Openreach in a nearby road, served by the same DP according to wifey, and even more peculiar is that she claims to have been using her IPad to browse and listen to IPlayer, when I was with problem.
I ran Windows Connection Diagnostics. Does it say anything unusual?
Diagnostics Information (Network Adapter)
Details about network adapter diagnosis:
Network adapter Wi-Fi driver information:
Description . . . . . . . . . . : Dell Wireless 1707 802.11b/g/n (2.4GHZ)
Manufacturer . . . . . . . . . : Qualcomm Atheros Communications Inc.
Provider . . . . . . . . . . . : Qualcomm Atheros Communications Inc.
Version . . . . . . . . . . . : 10.0.0.341
Inf File Name . . . . . . . . . : C:\WINDOWS\INF\oem5.inf
Inf File Date . . . . . . . . . : Friday, May 20, 2016 3:20:02 AM
Section Name . . . . . . . . . : ATHR_DEV_OS61_020E1028.ndi
Hardware ID . . . . . . . . . . : pci\ven_168c&dev_0036&subsys_020e1028
Instance Status Flags . . . . . : 0x180200a
Device Manager Status Code . . : 0
IfType . . . . . . . . . . . . : 71
Physical Media Type . . . . . . : 9
Diagnostics Information (Wireless Connectivity)
Details about wireless connectivity diagnosis:
Information for connection being diagnosed
Interface GUID: 899df3a3-3568-4f05-bf0e-9a821b443db7
Interface name: Dell Wireless 1707 802.11b/g/n (2.4GHZ)
Interface type: Native Wi-Fi
Connection incident diagnosed
Auto Configuration ID: 1
List of visible access point(s): 3 item(s) total, 3 item(s) displayed
BSSID BSS Type PHY Signal(dB) Chnl/freq SSID
-------------------------------------------------------------------------
34-97-F6-23-A4-28 Infra <unknown> -73 1 Omar_5G
60-03-47-00-2A-A1 Infra <unknown> -12 13 Billion-8800NL
C4-EA-1D-A3-49-39 Infra <unknown> -67 6 TNCAPA34939
Connection History
Information for Auto Configuration ID 1
List of visible networks: 3 item(s) total, 3 item(s) displayed
BSS Type PHY Security Signal(RSSI) Compatible SSID
------------------------------------------------------------------------------
Infra <unknown> Yes 54 Yes Omar_5G
Infra <unknown> Yes 100 Yes Billion-8800NL
Infra <unknown> Yes 66 Yes TNCAPA34939
List of preferred networks: 2 item(s)
Profile: PLUSNET-SXWQ
SSID: PLUSNET-SXWQ
SSID length: 12
Connection mode: Infra
Security: Yes
Set by group policy: No
Connect even if network is not broadcasting: No
Connectable: No
Reason: 0x00028002
Profile: Billion-8800NL
SSID: Billion-8800NL
SSID length: 14
Connection mode: Infra
Security: Yes
Set by group policy: No
Connect even if network is not broadcasting: No
Connectable: Yes
Diagnostics Information (Wireless Connectivity)
Details about wireless connectivity diagnosis:
For complete information about this session see the wireless connectivity information event.
Helper Class: Auto Configuration
Initialize status: Success
Information for connection being diagnosed
Interface GUID: 899df3a3-3568-4f05-bf0e-9a821b443db7
Interface name: Dell Wireless 1707 802.11b/g/n (2.4GHZ)
Interface type: Native Wi-Fi
Result of diagnosis: There may be problem
Root cause:
A wireless connection attempt is still in progress
Detailed root cause:
A wireless connection attempt is still in progress
Repair option:
Wait for the connection attempt to complete
Windows is currently attempting to connect to "Billion-8800NL". If the connection fails, start diagnostics again.
Network Diagnostics Log
File Name: 277274DC-CC5B-424E-B662-458AFCC938A4.Diagnose.0.etl
Other Networking Configuration and Logs
File Name: NetworkConfiguration.cab
Collection information
Computer Name: DESKTOP-8LLCCG2
Windows Version: 10.0
Architecture: x64
Time:
-
Woe is me! For most of the day internet has been inaccessible. Billion has tried incessantly to get a connection. Bearer 0 has shown feasible values, but Bearer 1 nothing, inactive.
That is correct. "Bearer 0" is the normal pathway for normal traffic. "Bearer 1" is only used when the retransmission of one or more packets is required.
I thought better see it's not the Billion, so reinstalled the HomeHub 1. That was after 18:30. Then at 18:50 the internet connection resumed. Now was it mere coincidence that it resumed with the Hub in place, or is the Billion the cause of the troubles? Should I put the Billion back?
My feeling is that it was pure coincidence. As to which device you use, choose which ever one you find more convenient. (In parenthesis, I would choose the Billion device.)
Also there was another Openreach in a nearby road, served by the same DP according to wifey, . . .
Ah, so perhaps there was some work in progress which may have been the cause of the outage.
. . . and even more peculiar is that she claims to have been using her IPad to browse and listen to IPlayer, when I was with problem.
Senior management has achieved such a feat in the past. If you look back through you posts, you will find a record of the incident. It turns out that your near neighbour is running an insecure WiFi network and Mrs. Ren's IPad was connected via that network, not your own! :D
I ran Windows Connection Diagnostics. Does it say anything unusual?
<snip>
None of that means anything to me, sorry. :no:
-
Thank you for your patient reply.
That is correct. "Bearer 0" is the normal pathway for normal traffic. "Bearer 1" is only used when the retransmission of one or more packets is required.
My feeling is that it was pure coincidence. As to which device you use, choose which ever one you find more convenient. (In parenthesis, I would choose the Billion device.)Much more informative
Ah, so perhaps there was some work in progress which may have been the cause of the outage.
Senior management has achieved such a feat in the past. If you look back through you posts, you will find a record of the incident. It turns out that your near neighbour is running an insecure WiFi network and Mrs. Ren's IPad was connected via that network, not your own! :DI do remember that, but was reminded that before when router was off, she failed to connect. That's puzzling!
None of that means anything to me, sorry. :no:
-
"Bearer 0" is the normal pathway for normal traffic. "Bearer 1" is only used when the retransmission of one or more packets is required.
This seems to be a common misconception, due to the fact that "Bearer 1" only appears with G.INP. With G.INP, "Bearer 0" is used for user data traffic, including retransmitted data, and "Bearer 1" is used for overhead/management traffic - things like organising bitswaps and exchanging stat values with the other end.
-
2.5 meg uplift early hours with lower up speed. As yet nothing from BTOR/PN. I can wait! ;D
-
Report of BTOR engineer visit etc.
see attachments for what they're worth!
There doesn't appear much to tell, unless you can see anything, but although I cannot find it now, an earlier GEA test had a shorter line length. Er, how?