Print

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

[Bobsta]

Hi folks,

I'm in the unfortunate situation of living approximately 1.2km from my (Huawei) cabinet. I had a new line installed 2 years ago to give me the best chance of achieving decent speeds and using a Huawei HG612 was consistently able to achieve ~1.9-2.0Mbps up and 22-24Mbps down. It's the upstream I care about the most due to regularly working from home and being a heavy user of cloud backup and file sync solutions.

Over the past few months I've seen my upstream rate reduce quite significantly to the point it's now 1394kbps. Meanwhile downstream is happily running at 23709kbps. I'm currently with BT but planning on flipping to PlusNet next month.

I've had DSLstats running for a while but didn't have logging switched on for everything. What I do have are a few snapshots from various time periods, which show a few things.

 - My DSLAM used to be reported as: BDCM:0xa48c / v0xa48c         Now it's: BDCM:0xb12d (177.45) / v0xb12d
 - My SNR margin used to always hover around 6dB up and down. But in April/May this year it jumped down considerably to 3.5-4.0dB downstream (still 6dB up) and my sync speeds increased. (It's now around 5dB)
 - My bit loading used to look like this:
and now looks like this:
(see attachments - sorry, couldn't suss out how to embed)

If I call BT and have a moan about this I can imagine they're just going to laugh at me and tell me to go away. Is there anything I can do kit-wise to get this bandwidth back please?

Thanks,

Bobsta

[burakkucat]

Welcome to the Kitz forum. 

- My DSLAM used to be reported as: BDCM:0xa48c / v0xa48c         Now it's: BDCM:0xb12d (177.45) / v0xb12d

We can see that the line-card has been swapped out . . . possibly to fit a updated version with more ports per card.

- My SNR margin used to always hover around 6dB up and down. But in April/May this year it jumped down considerably to 3.5-4.0dB downstream (still 6dB up) and my sync speeds increased. (It's now around 5dB)

Possibly the effect of the staged incremental X dB decrease of the target SNRM.

- My bit loading used to look like this:
and now looks like this:
(see attachments - sorry, couldn't suss out how to embed)

Interestingly the US0 band shows no change between then (2017) and now (2018). There is a reduction seen in the US1 band . . . and that is what is depressing your US achieved throughput.

Let's see what other members have to say with regards to the information that we can currently see.

[re0]

Welcome to the forum!

I do not see anything too significant between the two graphs, at least in terms of upstream. While the previous year seems to be better, I can't see any obvious clues to why the upstream has decreased by about ~40%, unless there are some overheads because of redunant bits (though I am not experienced nor qualified enough to really comment in depth, but I may try later anyway).

What I really want to see are the full connection stats just for starters (we can look at the more in-depth stuff later). As you're using DSLstats, it'll be under Telnet Data and Connection Stats. If you could either upload it as an attachment or insert into a reply with code tags then we can take a look at those. Perhaps if you have historical connection stats from before the upstream decrease, it would certainly be handy to upload as well.

It may also be handy to see what the DSL checker (https://www.dslchecker.bt.com/) has estimated for your line. If you could enter your landline number there, crop out the estimates (less the landline number) and upload here then it will give an indication on what can be done from your side when contacting your ISP (BT).

As for what can be done kit wise, I cannot really comment at this stage. But I would like to ask on what your current setup is like at your phone socket:

• Are you using the master socket in the house (the main socket in the house and not an extension)?
• Are you using/have you tried the test socket? (Can be seen at https://kitz.co.uk/adsl/socket.htm) If so, does it make any difference to the sync?
• Which microfilter and RJ11 cable are you using? Have you tried a different microfilter and cable?
• What sort of devices are connected to your microfilter?

It doesn't seem like a fault from what I can see, so the above points probably won't relate to this situation. If you do make any changes where you have to disconnect your modem, try to avoid disconnecting it too many times in a short period of time as the Dynamic Line Management (DLM) may make changes to your connection that may reduce your sync speed.

[Bobsta]

Welcome to the Kitz forum. 

Welcome to the forum!

Thanks. Long time lurker, first time poster! 

What I really want to see are the full connection stats just for starters (we can look at the more in-depth stuff later). As you're using DSLstats, it'll be under Telnet Data and Connection Stats. If you could either upload it as an attachment or insert into a reply with code tags then we can take a look at those.

Sure, here's a set from earlier today:

Code: [Select]

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 1394 Kbps, Downstream rate = 23852 Kbps
Bearer: 0, Upstream rate = 1394 Kbps, Downstream rate = 22905 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): 5.3 6.2
Attn(dB): 29.8 0.0
Pwr(dBm): 8.9 4.4
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 227 31
M: 1 1
T: 0 50
R: 10 0
S: 0.3166 0.7171
L: 6014 357
D: 4 1
I: 238 32
N: 238 32
Q: 4 0
V: 0 0
RxQueue: 55 0
TxQueue: 11 0
G.INP Framing: 18 0
G.INP lookback: 11 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 98883
OHFErr: 101 98
RS: 2895211664 4204418
RSCorr: 5689067 0
RSUnCorr: 0 0
Bearer 1
OHF: 35568373 0
OHFErr: 0 0
RS: 213409868 0
RSCorr: 49225 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 9877972 0
rtx_c: 3065399 0
rtx_uc: 1503 0

G.INP Counters
LEFTRS: 72 0
minEFTR: 22901 0
errFreeBits: 199057054 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 3647354429 0
Data Cells: 960990044 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: 28 87
SES: 0 0
UAS: 24 24
AS: 571313

Bearer 0
INP: 54.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 8.99
OR: 0.01 28.44
AgR: 22955.57 1422.44

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: 391489/391513 4995/5000

Total time = 1 days 14 hours 42 min 17 sec
FEC: 5689067 0
CRC: 101 98
ES: 28 87
SES: 0 0
UAS: 24 24
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 12 min 17 sec
FEC: 760 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: 1278 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 = 14 hours 42 min 17 sec
FEC: 68799 0
CRC: 0 4
ES: 0 4
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 663976 0
CRC: 42 10
ES: 12 10
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 6 days 14 hours 41 min 51 sec
FEC: 5689067 0
CRC: 101 98
ES: 28 87
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#

Perhaps if you have historical connection stats from before the upstream decrease, it would certainly be handy to upload as well.

Unfortunately not, and I'm kicking myself for that. But I do now have it logging regularly.

It may also be handy to see what the DSL checker (https://www.dslchecker.bt.com/) has estimated for your line.

Done. Please see attached.

As for what can be done kit wise, I cannot really comment at this stage. But I would like to ask on what your current setup is like at your phone socket:

I'm using the master socket (no extensions wired into it) with an ADSL Nation faceplate splitter. The phone side is connected to a single DECT base unit and a Yale alarm system but nothing else.
I haven't messed with it as everything was working fine (achieving speeds above what I'd hoped) until recently. I'm wary of restarting the connection too frequently for fear of DLM kicking in but will trying swapping out the RJ11 cable and plugging directly into the master (pre-filter) socket.

Actually I've just found I have a reasonable subset of DSLStats data (SNRM, FEC, CRC, ConSpeed & Bitswaps) from the end of May/early June when it was syncing at over 2Mbps, and a set from August when it's down to 1.5Mbps - I've uploaded the files here: https://www.dropbox.com/sh/rim08dgcym1vnbb/AAB240qqPwtG_mrjCJaY_cqea?dl=0.

Thanks - appreciate the help.

[j0hn]

Have you tried connecting only the modem, to the test socket of the master socket, using a "rat tail" filter that comes with the modem

That will rule out both the alarm system and the DECT phone, both of which can cause issues.

Your attenuation suggests your line is considerably longer than 1.2km and your sync suggests this also.
I'm exactly 1km from my cabinet and sync at 45/7.

[Bobsta]

Have you tried connecting only the modem, to the test socket of the master socket, using a "rat tail" filter that comes with the modem

Yup, tried that and upstream sync bumped up from 1394 kbps to 1430 kbps .... so a *slight* improvement but clearly not getting back to the 2000 kbps I used to get.

Your attenuation suggests your line is considerably longer than 1.2km and your sync suggests this also.
I'm exactly 1km from my cabinet and sync at 45/7.

Yup, we're 1100-1200m from the cabinet in a straight line (down a straight road) but I know our line goes further up the road via poles and then hairpins back underground - so the line length itself may well be 1500m or so. And notoriously old and crap, judging by the issues that we (both us and our neighbours) have experienced over the years.

Question: If I look at this:

... it looks as though I should be able to squeeze a few more bits out of U1 if I could get the modem to sync with a slightly reduced SNR margin.
Is there an xdslcmd configure option to force the upstream SNR margin? From my previous experimentation "xdslcmd configure --SNR xx" seems to only operate on the downstream SNR margin.

Thanks,

Bobsta

[re0]

... it looks as though I should be able to squeeze a few more bits out of U1 if I could get the modem to sync with a slightly reduced SNR margin.
Is there an xdslcmd configure option to force the upstream SNR margin? From my previous experimentation "xdslcmd configure --SNR xx" seems to only operate on the downstream SNR margin.

Nope. Unlike downstream SNRM, upstream SNRM is set at the "far end" (i.e. at the DSLAM).

I have looked at your stats and unfortunately I can't say that I have spotted anything in particular (I am not too familiar with all of the stats). Perhaps an increase in crosstalk has degraded the sync speed.

Maybe you could upload the bitloading as a text file? You should be able to find it under Telnet Data in DSLstats. I may have a little nosy, but can't promise anything.