Kitz Forum
Broadband Related => ADSL Issues => Topic started by: Weaver on October 08, 2019, 07:20:14 AM
-
Lightning has wrecked equipment in some of the houses in the village. Three of my lines are down.
Line 2: WLR3Test WLR3_CIDT_Test dys00556app04:467688470: Fail FAULT - Battery Contact ServiceLevel:2.5, MainFaultLocation:LN, FaultReportAdvised:Y, AppointmentRequired:N, LineStability:, NetworkStability:, StabilityStatement:
Line 3: WLR3Test WLR3_CIDT_Test cbs00556dat03:182580312: Fail FAULT - Dis One Leg In Network ServiceLevel:2.5, MainFaultLocation:CE, FaultReportAdvised:Y, AppointmentRequired:N, LineStability:, NetworkStability:, StabilityStatement:
Line 4: WLR3Test WLR3_CIDT_Test rds00556app02:467066834: Fail FAULT - Dis one leg in network ServiceLevel:2.5, MainFaultLocation:LN, FaultReportAdvised:Y, AppointmentRequired:N, LineStability:, NetworkStability:, StabilityStatement:
-
Wow that doesn't sound good.
Hope they get on to fixing them asap.
-
AA has sent someone out and an engineer contacted Janet. An army of OR vans has descended on the NSBFD exchange. No working phone lines in the village apart from my one, apparently. Most lines out in Broadford and even in Kyle of Lochalsh too across the bridge on the mainland. All shops are cash only because they can’t take credit card payments. The mobile phone network is up. I was using 3G last night while my modems were unplugged for safety - Firebrick just went into artificially forced failover.
—
Line 2 is now up again.
-
Hmm . . . That reads like a major incident if the Broadford TE itself is affected. :o (I wonder if Black Sheep would like a trip north of the border?)
Those three reports are quite clear as to the problem but I am unable to interpret codes that specify the two separate locations, "MainFaultLocation:LN" and "MainFaultLocation:CE".
What is the status of your equipment, the four VMG1312-B10As and the small switch, the VLAN end-point?
-
All my hardware is fine, unplugged asap, even though one strike was heard before we had time to react.
—
Line 3 is up as of 17.05.
That leaves only line 4 down currently. The jobs were marked in the notes as part of a batch of three, thank goodness, so sensibly given to one engineer.
The inhabitants of Heasta were ‘whatsapping’ one another talking about the outage earlier. It’s by far the biggest incident I can remember. On the lightningmaps live strikes map it showed four strikes at least in and around Heasta, including one hit at Na Torran next door and one near Druim Fheàrna - or else in the bay - was seen by Janet - blinded her temporarily. Janet went to the mainland chemist’s phone line was out. I’m surprised that there has been so much damage yet I have had one line up. If the exchanges were taken out then I would expect a different story of course.
-
All my hardware is fine, unplugged asap, even though one strike was heard before we had time to react.
That's good to know.
. . . four strikes at least in and around Heasta, including one hit at Na Torran next door and one near Druim Fheàrna
Google Maps was quite helpful. I just entered the Scots Gaelic, exactly as you had typed, and it showed me the locations. I can now understand why you typed "next door"!
-
One hit was given as 1.1 miles away. It’s absolute chaos in the whole area. There were a couple of strikes to the north of here and in the Cuilfhionn mountains, in the Small Isles and as far south as the northern part of Eilean Mhuile (anglicised as Mull).
-
Hmm . . . That reads like a major incident if the Broadford TE itself is affected. :o (I wonder if Black Sheep would like a trip north of the border?)
Those three reports are quite clear as to the problem but I am unable to interpret codes that specify the two separate locations, "MainFaultLocation:LN" and "MainFaultLocation:CE".
What is the status of your equipment, the four VMG1312-B10As and the small switch, the VLAN end-point?
Ha ha .... not likely, Mr Cat .... those days are long gone. ;) ;D
FI - LN = Local Network or UG (Underground Network, more specifically) ..... CE = Customer Engineer (In other words a multi-skilled engineer as the remote test results can't fully determine if the fault is within the EU's curtilage, or in the OR network nearby the EU's curtilage. :)
-
Thank you. :) I had a suspicion that the "LN" referenced the local network but couldn't think of a meaning for the "CE".
-
Actually, I’m thinking the NTE5 or SSFP might have blown up on line 4. I haven’t got a spare mk 4 handy to swap out.
-
If the NTE5C is determined to be zapped, then the SSFP should also be regarded as dead and the complete set replaced as a whole.
-
> If the NTE5C is determined to be zapped, then the SSFP should also be regarded as dead and the complete set replaced as a whole.
Thanks for that. Good point.
I’m hoping the engineer will visit the house then. Perhaps if he or she doesn’t see any signal then they might want to confirm things are actually working.
:'( :'( :'(
Hang on - I’ve just realised, I told AA the wrong thing - line 2 is the latest line, not line 4; they’re not in chronological order. I feel sure the prior state of affairs was 1, 3, 4. So line 2 is the one with the SSFP, not line 4; I will double check with my beloved. But anyway, so much for that theory. Old threads in kitz should confirm this thinking from history.
So anyway, I was being mad. Line 4 is just down because it hasn’t been fixed yet and there is no SSFP surely.
-
I am being even more mad. Line 4 is actually up. An SMS was sent to Janet’s phone to tell her that line 4 but she never told me about it; also I subscribe to the the AA notification-by-Tweet system but it has not been working for a long time.
So that makes all lines now up.
Re line 2:
Yesterday 19:02:02 Track PSTN Fault 5-7-186085713512 Informational Message: 4150 Response Required - Fault Report Cleared bt
Yesterday 19:02:02 Track PSTN Fault 5-7-186085713512 Estimated Response Time: 2019-10-09T23:59:59 bt
Yesterday 19:02:02 Track PSTN Fault 5-7-186085713512 Clear: 82.2 In Joint AreaCable (Underground) bt
Yesterday 19:02:02 Track PSTN Fault 5-7-186085713512 Status: Open - Clear Unconfirmed bt
Yesterday 19:01:54 Track PSTN Fault 5-7-186085713512 Notes Field: 08/10/2019 19:01:00
===Point Of Intervention notes===
Between this point...
- Location: Joint on right 150m upheast rd
- Work Point: JB26
And this point...
Plant details...
- Plant affected: JNT100
- Plant type: MC32
Multiple Intervention?: N
===Point Of Intervention notes ends===
(No manually entered closure notes)
=== QBC Summary Start ===Customer Report: End customer advised of no dial tone / voice on the line.\n\n Actions to resolve: Engineer has resolved the fault located at the D-side including aerial cables / lead-in / block terminal.The fault was located outside the end customer's curtilage and shown by cut / damage to wire / cable. The fault was fixed by clearing in joint.\n\n Additional information: Engineer has not visited end customer premises.\n\n Final alternate test results: Final FastTest performed from the customer premise.The test passed on 08/10/2019 18:56:47.=== QBC Summary End === bt
Yesterday 19:01:54 Track PSTN Fault 5-7-186085713512 Informational Message: 4465 Please refer to the Notes field for the actual message bt
Yesterday 19:01:54 Track PSTN Fault 5-7-186085713512 Estimated Response Time: 2019-10-09T23:59:59 bt
Yesterday 19:01:54 Track PSTN Fault 5-7-186085713512 Clear: 82.2 In Joint AreaCable (Underground) bt
Yesterday 19:01:54 Track PSTN Fault 5-7-186085713512 Status: Open - Implementing Solution
Re line 3:
Yesterday 18:41:18 Track PSTN Fault 5-7-186085764565 Informational Message: 4150 Response Required - Fault Report Cleared bt
Yesterday 18:41:18 Track PSTN Fault 5-7-186085764565 Estimated Response Time: 2019-10-09T23:59:59 bt
Yesterday 18:41:18 Track PSTN Fault 5-7-186085764565 Clear: 82.2 In Joint AreaCable (Underground) bt
Yesterday 18:41:18 Track PSTN Fault 5-7-186085764565 Status: Open - Clear Unconfirmed bt
Yesterday 18:40:24 Track PSTN Fault 5-7-186085764565 Notes Field: 08/10/2019 18:27:00
===Point Of Intervention notes===
Between this point...
- Location: joint outside 3 school Croft
- Work Point: JB26
And this point...
Plant details...
- Plant affected: JNT100
- Plant type: MC32
Multiple Intervention?: N
===Point Of Intervention notes ends===
(No manually entered closure notes)
=== QBC Summary Start ===Customer Report: End customer advised of no dial tone / voice on the line.\n\n Actions to resolve: Engineer has resolved the fault located at the D-side including aerial cables / lead-in / block terminal.The fault was located outside the end customer's curtilage and shown by soot / blackened wire / cable. The fault was fixed by clearing in joint.\n\n Additional information: Engineer has not visited end customer premises.\n\n Final alternate test results: Final FastTest performed from the customer premise.The test passed on 08/10/2019 18:21:35.=== QBC Summary End === bt
Yesterday 18:40:24 Track PSTN Fault 5-7-186085764565 Informational Message: 4465 Please refer to the Notes field for the actual message bt
Yesterday 18:40:24 Track PSTN Fault 5-7-186085764565 Estimated Response Time: 2019-10-09T23:59:59 bt
Yesterday 18:40:24 Track PSTN Fault 5-7-186085764565 Clear: 82.2 In Joint AreaCable (Underground) bt
Yesterday 18:40:24 Track PSTN Fault 5-7-186085764565 Status: Open - Implementing Solution
Re line 4:
Track PSTN Fault 5-7-186085779396 Notes Field: 08/10/2019 19:09:00 -
===Point Of Intervention notes===
Between this point...
- Location: Jnt 150m on right up heast rd
- Work Point: JB26
And this point...
Plant details...
- Plant affected: JNT100
- Plant type: MC32
Multiple Intervention?: N
===Point Of Intervention notes ends===
(No manually entered closure notes)
=== QBC Summary Start ===Customer Report: End customer advised of no dial tone / voice on the line.\n\n Actions to resolve: Engineer has resolved the fault located at the D-side including aerial cables / lead-in / block terminal.The fault was located outside the end customer's curtilage and shown by cut / damage to wire / cable. The fault was fixed by clearing in joint.\n\n Additional information: Engineer has not visited end customer premises.\n\n Final alternate test results: Final FastTest performed from the customer premise.The test passed on 08/10/2019 19:06:04.=== QBC Summary End === bt
Yesterday 19:10:37 Track PSTN Fault 5-7-186085779396 Informational Message: 4465 Please refer to the Notes field for the actual message bt
Yesterday 19:10:37 Track PSTN Fault 5-7-186085779396 Estimated Response Time: 2019-10-09T23:59:59 bt
Yesterday 19:10:37 Track PSTN Fault 5-7-186085779396 Clear: 82.2 In Joint AreaCable (Underground) bt
Yesterday 19:10:37 Track PSTN Fault 5-7-186085779396 Status: Open - Clear Unconfirmed bt
Yesterday 19:10:33 Track PSTN Fault 5-7-186085779396 Informational Message: 4150 Response Required - Fault Report Cleared bt
Yesterday 19:10:33 Track PSTN Fault 5-7-186085779396 Estimated Response Time: 2019-10-09T23:59:59 bt
Yesterday 19:10:33 Track PSTN Fault 5-7-186085779396 Clear: 82.2 In Joint AreaCable (Underground) bt
Yesterday 19:10:33 Track PSTN Fault 5-7-186085779396 Status: Open - Clear Unconfirmed
Now that I’ve found out about OpenReach Thank an Engineer (https://www.formwize.openreach.co.uk/run/survey3.cfm?idx=505d040e0a0e0c) I submitted the engineer’s name in that form.
-
Our engineer was working away sorting out my lines until around 19:10 (presumably BST?) when a lot of people had gone home hours earlier. A long day and probably backlog of chaos continuing tomorrow for all I know.
A brilliant job by BTOR, and by AA who booked an engineer at 08:02 [!]; AA support leapt on it straight away, the moment they were open.
-
Lines dropped in the early hours of this morning. I don’t know if this could be due to BTOR working overnight ? Is that possible.
The line 4 sync rate which was bad last week went back to normal when the line was repaired; but last week its downstream had been down to 80% of what it had been before. Now following the blips it’s down to a bit below its normal downstream, as are all the three repaired lines now. Each of lines 2,3,4 should be around 2.8 - 2.9 Mbps downstream at least:
Live sync rates:
#1: down 2854 kbps, up 666 kbps
#2: down 2496 kbps, up 547 kbps
#3: down 2652 kbps, up 579 kbps
#4: down 2563 kbps, up 505 kbps
The upstream rates are miraculous though : by a mile higher than anything ever seen before at 666k (best prev 560k). And line 3 upstream is now cured, its upstream speed massively increased - from say 350k to 579k - which brings it level with the others. And that too is presumably going to bring an enormous improvement, so you would hope; more nearly level speeds without one causing problems for TCP because it is so much slower that the round trip times for that pipe are weird. The sum of the IP PDU rates upstream @ 96.5% modem loading factor and 0.884434 protocol efficiency is 1.96Mbps which is significantly higher than the highest ever seen before, around 1.6-1.7Mbps (depending on how sickly line 3 was). So if you correct that figure for TCP and IP header overheads that should give an idea for a maximum possible TCP combined throughput in an ideal world, and something line 97% of
However speedtest2.aa.net.uk does not give good results at @ 1.28 Mbps upstream.
Firebrick current upstream rate limiters' IP PDU tx rates (egress speeds), in-force right now ::
#1: 568416 bps
#2: 466852 bps
#3: 494164 bps
#4: 431006 bps
Total combined rate: 1.960438 Mbps
Fractional speed contributions:
#1: 28.994% [█████████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]
#2: 23.814% [███████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]
#3: 25.207% [███████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]
#4: 21.985% [██████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]
--
Obtained from live-querying the Firebrick.
So the speedtest result is pretty awful at only 68.6% of the expected throughput figure for IPv6+TCP+timestamps or 67% for IPv4+TCP no timestamps. I just don’t know why this is so at one time it was fine, then it wasn’t and now we don’t have the speed inequalities to blame. Earlier I was absolutely certain that data corruption was to blame, and I suppose that is possible, maybe the sync rates are incredibly high because some kit was turned off and that made an atypically quiet noise environment which - speculating further - was not sustainable because after the sync rate upstream had been established the noise sources came back leaving the links struggling to cope. So will need to look at stats.
| | TCP | | | TCP @ loading | TCP bps @ 100% | |
| TCP TS+IPv6 efficiency: | 95.200000% | of IP PDU |
| TCP+IPv6 efficiency: | 96.000000% | of IP PDU |
| TCP TS+IPv4 efficiency: | 96.533333% | of IP PDU |
| TCP+IPv4 efficiency: | 97.333333% | of IP PDU |
| TCP TS+IPv6 rate: | 84.198113% | of sync rate | | 1866337 bps | 1934031 bps | ; @1.27Mbps = 0.68584 |
| TCP+IPv6 rate: | 84.905660% | of sync rate | | 1882020 bps | 1950283 bps | ; @1.27 Mbps = 0.68012 |
| TCP TS+IPv4 rate: | 85.377358% | of sync rate | | 1892476 bps | 1961118 bps | ; @1.27 Mbps = 0.67636 |
| TCP+IPv4 rate: | 86.084906% | of sync rate | | 1908160 bps | 1977370 bps | ; @1.27Mbps = 0.67080 |
-
Looking at the stats for all the lines not just the repaired ones, I see a few ES and SES in the recent 15 min periods. Line 1 with it’s crazy upstream of 666k was achieving this at an upstream SNRM of only 2.5 dB not 6dB, so that explains the silly high figure and suggests my analysis was right: perhaps retraining during an artificially quiet time and then noise rockets up, but anyway a very high noise level now which presumably the modem cannot cope with therefore causing corruption and TCP retx which slows throughput down to a crawl in a TCP throughput based tester. This shows the advantages and disadvantages of such a tester design: it is real-world, but it isn’t measuring the line - it’s measuring the particular protocol and its implementation. Testers should test with both methods and report two numbers, and should also report corruption and packets dropped in transit.
So I forced a retrain on each of the lines and things looked rather a lot more normal; downstream speeds lifted to where they should be. Post forced retrain - Live sync rates:
#1: down 2990 kbps, up 560 kbps
#2: down 2880 kbps, up 547 kbps
#3: down 2998 kbps, up 512 kbps
#4: down 2949 kbps, up 502 kbps
Note line 3 upstream still very much cured, has not yet gone back to being sickly as before. And the upstream rates are fairly close, which is always good.
Firebrick current upstream rate limiters' IP PDU tx rates (egress speeds), in-force right now ::
#1: 477948 bps
#2: 466852 bps
#3: 436981 bps
#4: 428446 bps
Total combined rate: 1.810227 Mbps
Fractional speed contributions:
#1: 26.403% [████████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]
#2: 25.790% [████████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]
#3: 24.140% [███████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]
#4: 23.668% [███████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]
--
Obtained from live-querying the Firebrick.
Unfortunately the speedtest2.aa.net.uk upstream throughput test was still poor at 1.31 Mbps, so nothing seems to make sense. At one time it was 200k better, and so it is not the case that the bonding simply is inherently not that good; also the downstream bonding is very efficient.
-
AA told me that there was a near nationwide BTW outage at around 01:15 UTC.
Now for some unknown reason line 4 has dropped; went down at 07:18 UTC and is still down now. Don’t know what that’s all about. Reported line 4 to AA.
Who knows, maybe BT broke it while working on another line or in the exchange. It’s perhaps the right kind of time for them to start doing things.
-
AA has put line 4 back to BTOR as faulty
Today 08:38:05 WLR3Test WLR3_CIDT_Test dys00556app04:467897663: Fail FAULT - Dis One Leg In Network ServiceLevel:2.5, MainFaultLocation:CE, FaultReportAdvised:Y, AppointmentRequired:N, LineStability:, NetworkStability:, StabilityStatement:
Today 10:29:33 Track PSTN Fault 5-7-186085779396 Informational Message: 4058 Notification Only - Fault is assigned to Engineer. Fault status is now PONR. bt
Today 10:29:33 Track PSTN Fault 5-7-186085779396 Estimated Response Time: 2019-10-09T23:59:59 bt
Today 10:29:33 Track PSTN Fault 5-7-186085779396 Clear: 82.2 In Joint AreaCable (Underground) bt
Today 10:29:33 Track PSTN Fault 5-7-186085779396 Status: Open - Past PONR bt
Today 09:33:29 Track PSTN Fault 5-7-186085779396 Informational Message: 4212 Notification Only -Trouble Report Clear Reject Accepted. bt
Today 09:33:29 Track PSTN Fault 5-7-186085779396 Status: Open - In Progress
-
Line was fixed really quickly, by a different engineer. Back up at 10:46 UTC. I am unclear from the notes where the problem was, ‘Croft 3’ would be past me, further down the hill as the numbering is #1 = me = the highest / northernmost, so #3 is further away from the exchange. Perhaps it means ‘in Harapul’ not in Heasta, or something ? Or perhaps it is ‘between point x and point y’ and that is point y not the fault location itself.
-Auto-
Today 11:58:27 Track PSTN Fault 5-7-186085779396 Informational Message: 4150 Response Required - Fault Report Cleared bt
Today 11:58:27 Track PSTN Fault 5-7-186085779396 Estimated Response Time: 2019-10-09T23:59:59 bt
Today 11:58:27 Track PSTN Fault 5-7-186085779396 Clear: 82.2 In Joint AreaCable (Underground) bt
Today 11:58:27 Track PSTN Fault 5-7-186085779396 Status: Open - Clear Unconfirmed bt
Today 11:58:25 Track PSTN Fault 5-7-186085779396 Notes Field: 09/10/2019 11:57:00
===Point Of Intervention notes===
Between this point...
- Location: No. 3 Croft
- Work Point: JB26
And this point...
Plant details...
- Plant affected: JNT100
- Plant type: MC32
Multiple Intervention?: N
===Point Of Intervention notes ends===
(No manually entered closure notes)
=== QBC Summary Start ===Customer Report: End customer advised of no dial tone / voice on the line.\n\n Actions to resolve: Engineer has resolved the fault located at the D-side including aerial cables / lead-in / block terminal.The fault was located outside the end customer's curtilage and shown by soot / blackened wire / cable.The fault was fixed by clearing in joint.\n\n Additional information: Engineer has not visited end customer premises.\n\n Final alternate test results: Final FastTest performed from the customer premise.The test passed on 09/10/2019 11:51:58.=== QBC Summary End === bt
Today 11:58:25 Track PSTN Fault 5-7-186085779396 Informational Message: 4465 Please refer to the Notes field for the actual message bt
Today 11:58:25 Track PSTN Fault 5-7-186085779396 Estimated Response Time: 2019-10-09T23:59:59 bt
Today 11:58:25 Track PSTN Fault 5-7-186085779396 Clear: 82.2 In Joint AreaCable (Underground) bt
Today 11:58:25 Track PSTN Fault 5-7-186085779396 Status: Open - Implementing Solution
-
I don’t really understand why it worked for so many hours and then died again just like that. Unless BTOR broke it this morning when they were doing something else really.
They have fixed the speed droops of 20% in the downstream that I was complaining of last week it seems.
-
Could someone jog my failed memory?
A thought - I wonder what the surges did to the NTE5 + the stupid MK4 SSFP that OR fitted in line 2? I should perhaps get a spare. If the SSFP is knackered or were to get damaged some day then I could just plug directly into the test socket anyway of course - with the right cable, old-fashioned dialup modem style RJ11-to-BT-plug cable. It will just look ugly like that, that’s all.
I can’t remember - isn’t there something in the main back part of the NTE5 - some component that can get damaged, without the SSFP ? A surge protector - MOV ? Or a capacitor?
I rather wish I could put an NTE5A in, complete with an AA straight-through trivial front plate, like in the other lines. But that would be rather naughty, I believe.
In favour of the new-style NTE5C + SSFP: there’s the convenience of the easily removable SSFP - which may or may not be loose / wobbly, ease of getting to the test socket; will have to ask Janet to feel the unit and see what she thinks about the quality of the thing. But I don’t need an SSFP anyway and I certainly don’t need any performance loss that may come with it. I have my suspicions that something is just possibly slightly shaving a little bit of performance off line 2 in comparison with the other lines. I could do some with/without SSFP back-to back tests if I can find the energy and bribe my beloved to do the plugging unplugging, a job that she hates. I have ordered a suitable short 1m RJ11-to-BT-plug cable. Such tests would be very difficult to get right though because unplugging the cable obviously forces retrains, and so there are the problems associated with the whims of modems choosing sync rates and even DLM kicking in if you get it wrong and fiddle about plugging and unplugging too often.
So regarding the ugliness of going straight into the test socket, I could maybe get a telephony-only front for an NTE5C ?
-
Could someone jog my failed memory?
. . .
I can’t remember - isn’t there something in the main back part of the NTE5 - some component that can get damaged, without the SSFP ? A surge protector - MOV ?
The original NTE5, designed and constructed in the early 1980s, did indeed have both an over-voltage gas-discharge doings and an earth connection point on the network side. With the various re-designs over the years (and to eliminate the capacitive effect of the gas-discharge thingy on any possible broadband service) both have been discarded.
So regarding the ugliness of going straight into the test socket, I could maybe get a telephony-only front for an NTE5C ?
Yes, we reached that conclusion some months back. Ideally have all four NTE5s without any SSFPs and with the standard telephony face-plates fitted. Then your four VMG1312-B10As could be connected with short leads, 6P2C plugs (contacts 3 & 4) at the modem ends and a BS6312, BT431A/BT631A, plug (contacts 2 & 5) at the NTE5 ends.
(https://upload.wikimedia.org/wikipedia/commons/thumb/b/ba/British_Telephone_connector.jpg/800px-British_Telephone_connector.jpg)
-
I’m hoping I’ve bought the correct thing on ebay (https://www.ebay.co.uk/itm/BT-OPENREACH-MASTER-SOCKET-NTE5C-MK2-NTE5A-REPLACEMENT-TELEPHONE-LINEBOX-TOOLESS/264472599697?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649). I couldn’t see just a ‘telephony’ lower front half of an NTE5C alone, so I bought a whole unit, one which, according to the picture, includes the correct front half.
-
It’s odd that the upstream speeds have all been improved, either slightly or greatly. Maybe a lot of cleanup of joints was beneficial. Live sync rates:
#1: down 2990 kbps, up 560 kbps
#2: down 2880 kbps, up 547 kbps
#3: down 2998 kbps, up 512 kbps
#4: down 2799 kbps, up 502 kbps
Woolly, vague and ill-informed speculation: Is it possible that some unit - a connector or otherwise- exists that might in some circumstances need to be replaced due to the damage and which might have an effect on multiple copper pairs including mine ? I’m just wondering if it makes sense to think about other users’ fault repairs as well as my own, where in order to fix someone else’s problem something needed to be replaced that had a global beneficial effect; something that has to be replaced and requires all connections to be remade. But this speculation isn’t necessary - maybe just my own joint cleanups were enough, of course.
-
I’m hoping I’ve bought the correct thing on ebay (https://www.ebay.co.uk/itm/BT-OPENREACH-MASTER-SOCKET-NTE5C-MK2-NTE5A-REPLACEMENT-TELEPHONE-LINEBOX-TOOLESS/264472599697?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649).
That is, indeed, the correct front plate.
-
Four or five of my neighbours have had no internet access service over dsl ever since the strike; eta fix on Friday.
-
One neighbour got her phone line back today - so what’s that 11 days, since the Monday before last?
There were four BT vans in Harapul at the northern end of the Heasta road and two more vans at the exchange. The chaos that that storm caused is amazing.
-
Other neighbours were still out on Sunday, I believe, so that would be 12 days.
—
One good thing has come out of this. Maybe some joints were cleaned up or cable replaced, because I’m seeing some small but but significant improvements in performance since the outage
Live sync rates:
#1: down 2949 kbps, up 547 kbps
#2: down 2902 kbps, up 499 kbps
#3: ?, ? (modem is down/coming up) — was 2.87 Mbps downstream, upstream all over the place
#4: down 2968 kbps, up 512 kbps
These downstream rates are all 100k-200kbps better than they were a week or so earlier. I think however that the rates improved after the outage, not during it. So speculating it could be that a later BTOR repair was in fact effectively an upgrade. Neighbours told Janet that BTOR engineer had told them a cable was to be replaced somewhere between Heasta and the Broadford exchange - maybe in Harapul as that’s where there was a huge amount of activity.
There have also been more BTOR engineers at work in the village itself.
-
One good thing has come out of this. Maybe some joints were cleaned up or cable replaced, because I’m seeing some small but but significant improvements in performance since the outage
Or could it be that with your neighbours all off-line, when your modems re-synchronised they did so with even less cross-talk? Without a spectrum analyser permanently connected to each of your four circuits, we can only guess.
-
I suppose I should look back at records of attenuation figures more like and compare them?
-
Yes, that should give you a clue as to what has happened.