Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: mnotgninnep on February 16, 2021, 04:59:08 PM
-
Argh! I was happily working from home, line speeds have been superb (77/20) since my last openreach visit, then suddenly everything cut out. Rebooted the modem(vmg8924-b10a), now getting the following and speeds are dire...
Help!
> adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 200000
Last initialization procedure status: 0
Max: Upstream rate = 483 Kbps, Downstream rate = 3078 Kbps
Bearer: 0, Upstream rate = 479 Kbps, Downstream rate = 1607 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): 7.1 8.3
Attn(dB): 14.7 0.0
Pwr(dBm): 7.9 10.4
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 49 30
M: 1 1
T: 0 19
R: 12 0
S: 0.0000 2.0157
L: 513 127
D: 4 1
I: 62 32
N: 62 32
Q: 4 0
V: 3 0
RxQueue: 12 0
TxQueue: 6 0
G.INP Framing: 18 0
G.INP lookback: 6 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 51502
OHFErr: 0 0
RS: 2023412 978298
RSCorr: 252 0
RSUnCorr: 0 0
Bearer 1
OHF: 30630 0
OHFErr: 1263 0
RS: 183409 0
RSCorr: 44400 0
RSUnCorr: 1171 0
Retransmit Counters
rtx_tx: 70928 0
rtx_c: 25 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 2 0
minEFTR: 1606 0
errFreeBits: 11808 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 1520568 0
Data Cells: 201705 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: 74 74
AS: 493
Bearer 0
INP: 42.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 9.61
OR: 0.01 26.63
AgR: 1648.39 506.02
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: 101/101 0/0
Total time = 9 min 27 sec
FEC: 252 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 74 74
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 9 min 27 sec
FEC: 252 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 74 74
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 27 sec
FEC: 252 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 74 74
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 = 8 min 13 sec
FEC: 252 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
-
From a wired telephone, perform a Quiet Line test. (Call 17070 (or 020 8759 9036) and take the option for "Quiet Line".) If the end result is anything but quiet, report a noisy line fault to your telephony service provider.
If you are unable to make any telephone calls, report a service failure to your telephony service provider.
I suspect that your circuit could be suffering from a "one leg dis" fault. If that is the case, your Internet service will just about work but will be heavily degraded and the telephony service will be non-existent.
-
Thank you. Just got off the phone with Plusnet. It's a fault between the cabinet and the exchange. Battery contact fault apparently, not one leg dis. He says it's weird how it's limiting my speed. Logged with OR and SLA is 24-72H.
-
Thank you. Just got off the phone with Plusnet. It's a fault between the cabinet and the exchange.
I'm not convinced at that.
The xDSL link is only been your home and the cabinet.
Only voice runs between the exchange and the cabinet.
-
The remote tests they perform are pretty wonderous, but not 100% accurate .... and, they tend to report what they suspect to be the greater fault.
For example, the 'battery contact' fault report could well be masking a high-resistance fault on one of the legs (as B*Cat mentioned). I would be very surprised if a battery contact fault on the E-side cable (Exchange to Cabinet) would cause so much damage to your circuit. If it is on the D-side cable (Cabinet to Premises), then absolutely it could.
Very hard trying to give a definite over the ether, but there is one saving grace .... a fault of that magnitude should be relatively easy to identify in the network, ergo a quick resolution (barring safety issues).
-
Logged with OR and SLA is 24-72H.
In due course, please provide an update and let us know what remedial action was taken . . .
-
Thank you. Just got off the phone with Plusnet. It's a fault between the cabinet and the exchange. Battery contact fault apparently, not one leg dis. He says it's weird how it's limiting my speed. Logged with OR and SLA is 24-72H.
My brother had a fault a few weeks ago with his partners VDSL connection - it completely lost connection, he phoned Plus Net and they told him the exact same thing - a fault between the cabinet and exchange. It was fixed the same day, and my brother spoke to the engineer who he spotted at the cabinet as he drove past - turned out someone had disconnected his line IIRC.
-
Cheers guys, as always, this is a great forum. :)
I will of course return to let you know how things turn out.
I just tried powering the modem off, replugging all the connections between it and the master socket, figuring at this point it can't hurt.
I've doubled my line speed to 3Mbps! :D
> adsl info
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 200000
Last initialization procedure status: 0
Max: Upstream rate = 439 Kbps, Downstream rate = 4580 Kbps
Bearer: 0, Upstream rate = 439 Kbps, Downstream rate = 2953 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
-
OpenReach guy arrived, appeared to be standing at the bottom of and testing the telegraph pole outside. He disappeared again and about 45 minutes later I dropped again and resynced as below. Not sure if it'll hold yet or had any report on the cause. Will update you when I do.
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 26021 Kbps, Downstream rate = 84634 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 80000 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): 3.7 15.4
Attn(dB): 13.2 0.0
Pwr(dBm): 13.7 2.2
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 203 237
M: 1 1
T: 0 42
R: 10 16
S: 0.0000 0.3781
L: 21153 5374
D: 8 1
I: 214 127
N: 214 254
Q: 8 0
V: 5 0
RxQueue: 78 0
TxQueue: 26 0
G.INP Framing: 18 0
G.INP lookback: 26 0
RRC bits: 0 24
Bearer 1
MSGc: 186 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 5.3333 0.0000
L: 48 0
D: 3 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 34537
OHFErr: 0 1
RS: 6744592 1449926
RSCorr: 0 2
RSUnCorr: 0 0
Bearer 1
OHF: 8591 0
OHFErr: 0 0
RS: 102350 0
RSCorr: 0 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 192824 0
rtx_c: 88616 0
rtx_uc: 77758 0
G.INP Counters
LEFTRS: 9354 0
minEFTR: 79996 0
errFreeBits: 20653530 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 21230597 0
Data Cells: 375072 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: 1613 5
SES: 22 0
UAS: 256 235
AS: 138
Bearer 0
INP: 49.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 3.98
OR: 0.01 64.22
AgR: 80344.32 20063.54
Bearer 1
INP: 4.00 0.00
INPRein: 4.00 0.00
delay: 3 0
PER: 16.06 0.01
OR: 95.62 0.01
AgR: 95.62 0.01
Bitswap: 33/33 0/0
Total time = 1 days 17 hours 42 min 31 sec
FEC: 703347 2
CRC: 3369 29
ES: 1613 5
SES: 22 0
UAS: 256 235
LOS: 2 0
LOF: 14 0
LOM: 0 0
Latest 15 minutes time = 12 min 31 sec
FEC: 2561 2
CRC: 1164 3
ES: 21 3
SES: 21 0
UAS: 183 162
LOS: 2 0
LOF: 14 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 95 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 = 17 hours 42 min 31 sec
FEC: 30347 2
CRC: 1169 3
ES: 25 3
SES: 21 0
UAS: 183 162
LOS: 2 0
LOF: 14 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 673000 0
CRC: 2200 26
ES: 1588 2
SES: 1 0
UAS: 73 73
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 2 min 17 sec
FEC: 0 2
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
-
The remote tests they perform are pretty wonderous, but not 100% accurate .... and, they tend to report what they suspect to be the greater fault.
For example, the 'battery contact' fault report could well be masking a high-resistance fault on one of the legs (as B*Cat mentioned). I would be very surprised if a battery contact fault on the E-side cable (Exchange to Cabinet) would cause so much damage to your circuit. If it is on the D-side cable (Cabinet to Premises), then absolutely it could.
Very hard trying to give a definite over the ether, but there is one saving grace .... a fault of that magnitude should be relatively easy to identify in the network, ergo a quick resolution (barring safety issues).
yep if its going to fail, its best to do it in spectacular fashion. Easier to prove, Easier to track down.
-
OpenReach guy arrived, appeared to be standing at the bottom of and testing the telegraph pole outside. He disappeared again and about 45 minutes later I dropped again and resynced as below. Not sure if it'll hold yet or had any report on the cause. Will update you when I do.
Your circuit will undergo a period of stabilisation now, as it appears the engineer has performed a DLM reset ??
So, the odd loss of link is to be expected ... but for minutes only.
-
Can anyone explain this speed test please? (attached) (stats below)
Thank you
> adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 25898 Kbps, Downstream rate = 84356 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 80000 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): 3.6 15.3
Attn(dB): 13.2 0.0
Pwr(dBm): 13.7 2.3
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 203 237
M: 1 1
T: 0 42
R: 10 16
S: 0.0000 0.3781
L: 21153 5374
D: 8 1
I: 214 127
N: 214 254
Q: 8 0
V: 5 0
RxQueue: 78 0
TxQueue: 26 0
G.INP Framing: 18 0
G.INP lookback: 26 0
RRC bits: 0 24
Bearer 1
MSGc: 186 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 5.3333 0.0000
L: 48 0
D: 3 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 3565657
OHFErr: 0 24
RS: 696465160 3662526
RSCorr: 620 94
RSUnCorr: 0 0
Bearer 1
OHF: 880809 0
OHFErr: 0 0
RS: 10568965 0
RSCorr: 3 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 192838 0
rtx_c: 88630 0
rtx_uc: 77758 0
G.INP Counters
LEFTRS: 9354 0
minEFTR: 79983 0
errFreeBits: 37745729 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2176606810 0
Data Cells: 16078083 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: 1613 24
SES: 22 0
UAS: 256 235
AS: 14152
Bearer 0
INP: 49.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 3.98
OR: 0.01 64.22
AgR: 80344.32 20063.54
Bearer 1
INP: 4.00 0.00
INPRein: 4.00 0.00
delay: 3 0
PER: 16.06 0.01
OR: 95.62 0.01
AgR: 95.62 0.01
Bitswap: 2354/2354 392/392
Total time = 1 days 21 hours 36 min 5 sec
FEC: 703967 94
CRC: 3369 52
ES: 1613 24
SES: 22 0
UAS: 256 235
LOS: 2 0
LOF: 14 0
LOM: 0 0
Latest 15 minutes time = 6 min 5 sec
FEC: 22 4
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: 140 10
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 = 21 hours 36 min 5 sec
FEC: 30967 94
CRC: 1169 26
ES: 25 22
SES: 21 0
UAS: 183 162
LOS: 2 0
LOF: 14 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 673000 0
CRC: 2200 26
ES: 1588 2
SES: 1 0
UAS: 73 73
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 3 hours 55 min 51 sec
FEC: 620 94
CRC: 0 24
ES: 0 20
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
-
Is it an anomaly ... or is it a repeated result ??
-
Repeatable on any device, wired or wireless.
-
Probably a case where the Plusnet IP Profile hasn't caught up with the changes yet. It should fix itself pretty soon, but if it's not working by tomorrow then I'd advise contacting them.
I haven't had access to a Plusnet connection for quite some time, but you might need to drop and restart the PPP session to get it to trigger an update.
-
Probably a case where the Plusnet IP Profile hasn't caught up with the changes yet. It should fix itself pretty soon, but if it's not working by tomorrow then I'd advise contacting them.
I haven't had access to a Plusnet connection for quite some time, but you might need to drop and restart the PPP session to get it to trigger an update.
Thank you! That was it! Rebooted the UniFi USG without rebooting the modem so I didn’t drop the dsl connection.
-
Their forum might be a place to get it updated.
-
I'm curious, when I synced at 80 I used to pull around 74 down on plain fastpath. Does G.INP limit the downstream bandwidth more or would the Plusnet profile do so?
-
Does G.INP limit the downstream bandwidth more or would the Plusnet profile do so?
Fastpath gives an IP profile 96.79% of the sync speed.
G.INP Retx Low gives 96.69%
Retx High gives around 91-92%
Those exact figures given above are with Broadcom chipsets and the percentage varies slightly with other chipsets but roughly the same.
For some reason BT Wholesale have been limiting some lines to an IP Profile roughly 88% if the sync speed but i have no idea why this happens.
-
I'm not sure about broadband (not my area of expertise) but I'm guessing it could be anything from reliability to management. On any network, when you truly saturate a link you start to get some weird behaviour, degradation of service and time-critical things stop working. Latency and ping go through the roof as minor examples. At a guess, to keep the ppp session alive, a small amount of bandwidth should be reserved to guarantee those packets always get through. In schools it's normal to reserve 1Mb on core links for management, that way we're guaranteed remote access even if they're hammering the connection, backup is running or worst case, someone has put an unmanaged switch in, created a network loop and created a broadcast storm the managed switches can't shut down.
Overheads and hardware limitations will also play a factor. On a home network, on a 1Gb link you'll never see a transfer of 128MB/s, it's always around the 900Mb mark because overheads will consume the rest of the bandwidth even though they're not measured. This is in a best case scenario of transferring one large file. Transfer many small ones and it only gets worse.
-
As promised, here's the OR report:
Personally identifiable details have been removed.
I should also mention that at no point did anyone from OR contact me or enter my property. The engineer was seen testing the telegraph pole.
I'm not complaining by the way, just a point of observation.
18/02/2021 15:53:00
----------------------
Engineer details
Engineer name:
----------------------
Ring ahead information
Primary customer name:
Contact no:
Call outcome:No answer (VM left if available)
Call outcome to secondary contact no: Not able to ring ahead due to unusable contact details (missing / incorrect / faulty line)
-------------------------------
(No manually entered closure notes)
----------------------
Point Of Intervention notes
Between this point.
- Location: PCP
- Work Point: PCP25
And this point.
Plant details.
- Plant affected: BIX
- Plant type: JMP
Multiple Intervention?: N
=== QBC Summary Start ===
Customer Report: End customer advised of no dial tone / voice on the line.
Actions to resolve: Engineer has resolved the fault by changing the E-side pair or at PCP. The fault was fixed by removing double jumpering in PCP.
Final alternate test results: Final FastTest performed from the customer premise. The test passed on 18/02/2021 15:46:56.
=== QBC Summary End ===
-
Bix, Oxfordshire? ::)
Looks like a new pair from the Exchange to the PCP street cabinet
-
Bix, Oxfordshire? ::)
Looks like a new pair from the Exchange to the PCP street cabinet
Whetstone, Leicestershire.
This'll be my 3rd pair.
The chap from Plusnet was very keen to point out the double jumpering, whatever that is...
Still perfect sync by the way. Very happy. ;D
-
'Double jumpering' is where an engineer has accidentally terminated another working line on top of your own connection. That is where the 'battery contact' would come from on the test result and the severe disruption to your circuit.
As mooted, the harsher the fault, the easier it is to locate and repair.
PS - the terminating strips in our Cabinets are on the whole BICS (bix) or KRONE, as mentioned in the report. He hasn't done an E-side pair change as mentioned in the wording, that won't have affected your circuit, these things just auto-populate as the drop-down menu's are filled in by the engineer. :)
-
He hasn't done an E-side pair change as mentioned in the wording, . . . , these things just auto-populate as the drop-down menu's are filled in by the engineer. :)
Thank you for the explanation. Many a time I have reviewed the notes regarding repairs to one of Weaver's circuits and have seen sections of, quite obviously, nonsense.
-
As promised, here's the OR report:
Personally identifiable details have been removed.
I should also mention that at no point did anyone from OR contact me or enter my property. The engineer was seen testing the telegraph pole.
I'm not complaining by the way, just a point of observation.
I'm hoping that's all they have to do to fix mine tomorrow, but I fear the drop cable might need replacing as a few years back the council contractors put scaffold OVER the drop wire pulling it down tightly. I was amazed it didn't break (those steel wires along the length sure do a good job) but I wouldn't be surprised if its finally cause a break. The second line is crackling like crazy, cant even hear the dial tone any more.
As its happened due to high winds, it seems less likely to be the pole to me?
-
Thank you for the explanation. Many a time I have reviewed the notes regarding repairs to one of Weaver's circuits and have seen sections of, quite obviously, nonsense.
Ha ha, indeed so, Mr Cat.
Sometimes the engineer will have to enter what he/she/non-binary person, thinks best suits the activity they've performed. Sometimes they may have performed a plethora of fixes, but can only enter the one primary clear-code (they can of course follow up with good notes in the comments box).
Tech was supposed to make the job easier, but in this case my own personal opinion is that it has muddied the waters for everyone that's concerned.
-
I'm hoping that's all they have to do to fix mine tomorrow, but I fear the drop cable might need replacing as a few years back the council contractors put scaffold OVER the drop wire pulling it down tightly. I was amazed it didn't break (those steel wires along the length sure do a good job) but I wouldn't be surprised if its finally cause a break. The second line is crackling like crazy, cant even hear the dial tone any more.
As its happened due to high winds, it seems less likely to be the pole to me?
The 'steely's' don't last forever though, I'm afraid ... and coupled with the scaffers not giving a cr5p about the flying wires, it sounds like there's every chance it's the wire !!
Do yourself a favour and if there is no noise on the line, or they get a good test result back, ask them to whack the wire with their 'Test Rods Telescopic'* then listen for noise again. Or, you whack the wire whilst they try and measure to a 'dis' on their TDR.
*For measuring the height of wires.
-
The 'steely's' don't last forever though, I'm afraid ... and coupled with the scaffers not giving a cr5p about the flying wires, it sounds like there's every chance it's the wire !!
Do yourself a favour and if there is no noise on the line, or they get a good test result back, ask them to whack the wire with their 'Test Rods Telescopic'* then listen for noise again. Or, you whack the wire whilst they try and measure to a 'dis' on their TDR.
*For measuring the height of wires.
Thankfully there's LOTS of noise on the line, can't even hear a dial tone any more.
Test showed 26m but the killer could be risk assessment as its still windy.
-
Can't remember where you're based AA ... but the weather looks to calm down from tomorrow, onwards ??
https://www.bbc.co.uk/weather/forecast-video/21416743
-
One of the hills of Sheffield, but I mentioned it as they were here at the time and I could hear the wind.
They tried shortening the drop but noise was still there so they replaced the whole thing. Apparently there had been damage from a tree that's been gone for over a decade.
Line attenuation seems slightly improved but strangely Plusnet line is syncing a bit slower than before, probably due to the weather getting warmer. I assume they must have put a junction on the outside wall as they didn't rewire the sockets indoors.
Gotta admit it was a bit nerve racking that they only tested the Plusnet line despite effectively rewiring both lines, but I totally appreciate the bureaucracy of why that was the case, even if it does seem short sighted.
Nothing they did really came as a surprise obviously considering how much time I spend on here. Was easy to be all relaxed about it when I was getting 100Mbit off Vodafone while I left both lines turned off so the line replacement wouldn't upset DLM.
I did discover some quirks with pfSense, apparently having the default gateway group with DSL as tier 1 and Voda as tier 2, wouldn't work. I had to set it to a gateway group where they all are tier 1 before it would allow pfSense itself to send DNS queries over Voda.
So overall a satisfactory solution. Its a shame due to covid we couldn't offer tea and biscuits.
[EDIT]
Actually strike that, its resynced faster than it ever has before although Plusnet profile not caught up yet.
That could be good or bad, as may mean the HH5A OpenWRT is still unstable with G.INP. But then again, maybe it will sync higher on the Zyxel now anyway.
-
If you have a static IP, you will need to call and ask them to put the profile up manually to 80000 as you're "on the old system".
Also, as I disovered above, if you have a separate router/modem, restart the router (not the modem) to re-establish the ppp session to get the new speed. Simply restarting the modem won't do it for some reason.
-
If you have a static IP, you will need to call and ask them to put the profile up manually to 80000 as you're "on the old system".
My profile tends to update okay on its own, but yes it may get stuck at some point. However as my connection dropped to 20Mbit during the fault but my "current line speed " is showing as 64.2 which matches the initial sync rate AFTER the fault was fixed, no point rushing to get it reset until I know how stable the sync is.