Kitz Forum
Broadband Related => ADSL Issues => Topic started by: Weaver on February 04, 2019, 09:04:09 PM
-
On Saturday afternoon, my line #3 was unusable for three hours, constantly resynching with crazy rate changes and catastrophic packet loss. The modem is a ZyXEL VMG1312-B10A with the latest our kitizen Johnson firmware in it, the version that contains a continuous SNRM recording and graphical display via http feature. See enclosed a 24-hour picture of SNRM vs time (https://ibb.co/4fQ6kc7). In a sense, the graph is upside-down, lower values mean higher noise. A forest of downward-going, so high, noise spikes can be seen, and these are overwhelming the modem.
Questions: Do you think this is the correct interpretation? Are these spikes real?
AA recommended that we try banding the downstream to 1-3Mbps sync rate. Recently it has been running at ~3.15Mbps downstream. But I’m not sure that that is enough. Engaging this banding mechanism dropped the sync rate too much, to ~2.858Mbps downstream and also not enough because the downstream SNRM after applying this feature was only 6.1dB and three of those spikes look taller than 7dB high to me. So that would require 9dB target SNRM but that would require sacrificing a vast amount of speed, maybe nearly a whole Mbps, I don’t know, for some very rare event which might only happen once a week or once a month.
Am I missing the point about banding?
When the graph was taken, the target SNRM downstream was actually set to 6dB even though it looks like 3dB. I am aware that I cannot necessarily expect any of the lines to run reliably at 3dB downstream, so 3dB has just been an experiment, but a very successful one, with all lines running very well for two years at 3dB downstream unless there has been a copper line fault.
Today 20:28:28 Today 20:28:36 BT Test xDSL Status Check:Pass Standalone sub test passed successfully. Pass OK.
Circuit In Sync BRAS=2802kb/s FTR=2278kb/s MSR=2848kb/s ServOpt=1 I/L=I
Up Sync=406kb/s LoopLoss=39.9dB SNR=6.1dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2858kb/s LoopLoss=64dB SNR=5.6dB ErrSec=0 HECErr=N/A Cells=0 weaver@a
Today 14:34:32 Update Update AutoTestUntil=0000-00-00 00:00:00-> weaver@a
Today 14:28:34 Today 14:28:57 Test SNR reset: RateBandDS=1472-3072 InterleaveLevelDS=On TargetMarginDS=6dB RateBandUS=32-Uncapped InterleaveLevelUS=On TargetMarginUS=6dB:SNR Recalculation initiated which will enable the line to reach optimum speed, stabilization retrains can be expected over the next couple of days. weaver@a
Today 14:15:58 Tx rate (adjusted) 2737428 to 2462561 (rx 406000) -Auto-
Today 14:14:15 Today 14:14:27 Test SNR reset: RateBandDS=1472-3072 InterleaveLevelDS=On TargetMarginDS=6dB RateBandUS=32-Uncapped InterleaveLevelUS=On TargetMarginUS=6dB:SNR Recalculation initiated which will enable the line to reach optimum speed, stabilization retrains can be expected over the next couple of days. weaver@a
Today 14:12:30 Update Update AutoTestUntil=0000-00-00 00:00:00-> RateBandDS=160-24384.6dB->1472-3072.6dB weaver@a
Yesterday 11:45:57 Yesterday 11:47:01 BT Test xDSL Copper Test:Pass Standalone sub test passed successfully. Pass Copper Line Test Successful DS01:Line Test OK weaver@a
Saturday 17:25:08 Tx rate (adjusted) 2380447 to 2737428 (rx 402000) -Auto-
Saturday 16:29:30 Tx rate (adjusted) 2560234 to 2380447 (rx 355000) -Auto-
Saturday 16:09:04 Tx rate (adjusted) 1624132 to 2560234 (rx 396000) -Auto-
Saturday 15:42:18 Tx rate (adjusted) 2453053 to 1624132 (rx 190000) -Auto-
Saturday 15:28:30 Tx rate (adjusted) 2418479 to 2453053 (rx 376000) -Auto-
Saturday 15:24:53 Tx rate (adjusted) 2503186 to 2418479 (rx 358000) -Auto-
Saturday 15:21:04 Tx rate (adjusted) 2209304 to 2503186 (rx 379000) -Auto-
Saturday 15:19:05 Tx rate (adjusted) 2585300 to 2209304 (rx 358000) -Auto-
Saturday 15:01:45 Tx rate (adjusted) 2364024 to 2585300 (rx 379000) -Auto-
Saturday 14:57:22 Tx rate (adjusted) 2297468 to 2364024 (rx 355000) -Auto-
Saturday 14:49:50 Tx rate (adjusted) 2487628 to 2297468 (rx 355000) -Auto-
Saturday 14:46:35 Tx rate (adjusted) 2510101 to 2487628 (rx 358000) -Auto-
Saturday 14:43:57 Tx rate (adjusted) 2097801 to 2510101 (rx 382000) -Auto-
Saturday 14:40:53 Tx rate (adjusted) 2475527 to 2097801 (rx 341000) -Auto-
Saturday 14:36:14 Tx rate (adjusted) 2239556 to 2475527 (rx 379000) -Auto-
Saturday 14:29:25 Tx rate (adjusted) 2373532 to 2239556 (rx 358000) -Auto-
Saturday 14:25:32 Tx rate (adjusted) 2424529 to 2373532 (rx 358000) -Auto-
Saturday 14:23:53 Tx rate (adjusted) 2500593 to 2424529 (rx 355000) -Auto-
Saturday 14:07:06 Tx rate (adjusted) 2367482 to 2500593 (rx 379000) -Auto-
Saturday 14:04:58 Tx rate (adjusted) 2399463 to 2367482 (rx 379000) -Auto-
Saturday 14:03:13 Tx rate (adjusted) 2421072 to 2399463 (rx 355000) -Auto-
Saturday 14:01:30 Tx rate (adjusted) 2380447 to 2421072 (rx 352000) -Auto-
Saturday 13:59:00 Tx rate (adjusted) 2560234 to 2380447 (rx 358000) -Auto-
Saturday 13:50:32 Tx rate (adjusted) 2341551 to 2560234 (rx 382000) -Auto-
Saturday 13:48:34 Tx rate (adjusted) 1810834 to 2341551 (rx 358000) -Auto-
Saturday 13:46:31 Tx rate (adjusted) 2164357 to 1810834 (rx 376000) -Auto-
Saturday 13:45:03 Tx rate (adjusted) 2385633 to 2164357 (rx 331000) -Auto-
Saturday 13:42:11 Tx rate (adjusted) 1878254 to 2385633 (rx 352000) -Auto-
Saturday 13:35:23 Tx rate (adjusted) 2449596 to 1878254 (rx 289000) -Auto-
Saturday 13:31:13 Tx rate (adjusted) 2260301 to 2449596 (rx 376000) -Auto-
Saturday 13:26:53 Tx rate (adjusted) 2279317 to 2260301 (rx 352000) -Auto-
Saturday 13:22:26 Tx rate (adjusted) 2430580 to 2279317 (rx 358000) -Auto-
Saturday 13:19:14 Tx rate (adjusted) 1637097 to 2430580 (rx 382000) -Auto-
Saturday 11:38:30 Tx rate (adjusted) 2689888 to 1637097 (rx 184000)
-
On Saturday afternoon, my line #3 was unusable for three hours, constantly resynching with crazy rate changes and catastrophic packet loss. The modem is a ZyXEL VMG1312-B10A with the latest our kitizen Johnson firmware in it, the version that contains a continuous SNRM recording and graphical display via http feature. See enclosed a 24-hour picture of SNRM vs time (https://ibb.co/4fQ6kc7). In a sense, the graph is upside-down, lower values mean higher noise. A forest of downward-going, so high, noise spikes can be seen, and these are overwhelming the modem.
Questions: Do you think this is the correct interpretation? Are these spikes real?
That plot is showing the SNR Margin versus time. There is nothing "upside-down" about it. That change in the margin could be caused by --
- The signal remaining constant and the noise increasing.
- The signal decreasing and the noise remaining constant.
- The signal decreasing and the noise increasing.
We have no way of knowing, by viewing the plot, which scenario out of the above three possibilities is the truth.
Today 20:28:28 Today 20:28:36 BT Test xDSL Status Check:Pass Standalone sub test passed successfully. Pass OK.
Circuit In Sync BRAS=2802kb/s FTR=2278kb/s MSR=2848kb/s ServOpt=1 I/L=I
Up Sync=406kb/s LoopLoss=39.9dB SNR=6.1dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2858kb/s LoopLoss=64dB SNR=5.6dB ErrSec=0 HECErr=N/A Cells=0 weaver@a
Today 14:34:32 Update Update AutoTestUntil=0000-00-00 00:00:00-> weaver@a
Today 14:28:34 Today 14:28:57 Test SNR reset: RateBandDS=1472-3072 InterleaveLevelDS=On TargetMarginDS=6dB RateBandUS=32-Uncapped InterleaveLevelUS=On TargetMarginUS=6dB:SNR Recalculation initiated which will enable the line to reach optimum speed, stabilization retrains can be expected over the next couple of days. weaver@a
Today 14:15:58 Tx rate (adjusted) 2737428 to 2462561 (rx 406000) -Auto-
Today 14:14:15 Today 14:14:27 Test SNR reset: RateBandDS=1472-3072 InterleaveLevelDS=On TargetMarginDS=6dB RateBandUS=32-Uncapped InterleaveLevelUS=On TargetMarginUS=6dB:SNR Recalculation initiated which will enable the line to reach optimum speed, stabilization retrains can be expected over the next couple of days. weaver@a
Today 14:12:30 Update Update AutoTestUntil=0000-00-00 00:00:00-> RateBandDS=160-24384.6dB->1472-3072.6dB weaver@a
Yesterday 11:45:57 Yesterday 11:47:01 BT Test xDSL Copper Test:Pass Standalone sub test passed successfully. Pass Copper Line Test Successful DS01:Line Test OK weaver@a
Saturday 17:25:08 Tx rate (adjusted) 2380447 to 2737428 (rx 402000) -Auto-
Saturday 16:29:30 Tx rate (adjusted) 2560234 to 2380447 (rx 355000) -Auto-
Saturday 16:09:04 Tx rate (adjusted) 1624132 to 2560234 (rx 396000) -Auto-
Saturday 15:42:18 Tx rate (adjusted) 2453053 to 1624132 (rx 190000) -Auto-
Saturday 15:28:30 Tx rate (adjusted) 2418479 to 2453053 (rx 376000) -Auto-
Saturday 15:24:53 Tx rate (adjusted) 2503186 to 2418479 (rx 358000) -Auto-
Saturday 15:21:04 Tx rate (adjusted) 2209304 to 2503186 (rx 379000) -Auto-
Saturday 15:19:05 Tx rate (adjusted) 2585300 to 2209304 (rx 358000) -Auto-
Saturday 15:01:45 Tx rate (adjusted) 2364024 to 2585300 (rx 379000) -Auto-
Saturday 14:57:22 Tx rate (adjusted) 2297468 to 2364024 (rx 355000) -Auto-
Saturday 14:49:50 Tx rate (adjusted) 2487628 to 2297468 (rx 355000) -Auto-
Saturday 14:46:35 Tx rate (adjusted) 2510101 to 2487628 (rx 358000) -Auto-
Saturday 14:43:57 Tx rate (adjusted) 2097801 to 2510101 (rx 382000) -Auto-
Saturday 14:40:53 Tx rate (adjusted) 2475527 to 2097801 (rx 341000) -Auto-
Saturday 14:36:14 Tx rate (adjusted) 2239556 to 2475527 (rx 379000) -Auto-
Saturday 14:29:25 Tx rate (adjusted) 2373532 to 2239556 (rx 358000) -Auto-
Saturday 14:25:32 Tx rate (adjusted) 2424529 to 2373532 (rx 358000) -Auto-
Saturday 14:23:53 Tx rate (adjusted) 2500593 to 2424529 (rx 355000) -Auto-
Saturday 14:07:06 Tx rate (adjusted) 2367482 to 2500593 (rx 379000) -Auto-
Saturday 14:04:58 Tx rate (adjusted) 2399463 to 2367482 (rx 379000) -Auto-
Saturday 14:03:13 Tx rate (adjusted) 2421072 to 2399463 (rx 355000) -Auto-
Saturday 14:01:30 Tx rate (adjusted) 2380447 to 2421072 (rx 352000) -Auto-
Saturday 13:59:00 Tx rate (adjusted) 2560234 to 2380447 (rx 358000) -Auto-
Saturday 13:50:32 Tx rate (adjusted) 2341551 to 2560234 (rx 382000) -Auto-
Saturday 13:48:34 Tx rate (adjusted) 1810834 to 2341551 (rx 358000) -Auto-
Saturday 13:46:31 Tx rate (adjusted) 2164357 to 1810834 (rx 376000) -Auto-
Saturday 13:45:03 Tx rate (adjusted) 2385633 to 2164357 (rx 331000) -Auto-
Saturday 13:42:11 Tx rate (adjusted) 1878254 to 2385633 (rx 352000) -Auto-
Saturday 13:35:23 Tx rate (adjusted) 2449596 to 1878254 (rx 289000) -Auto-
Saturday 13:31:13 Tx rate (adjusted) 2260301 to 2449596 (rx 376000) -Auto-
Saturday 13:26:53 Tx rate (adjusted) 2279317 to 2260301 (rx 352000) -Auto-
Saturday 13:22:26 Tx rate (adjusted) 2430580 to 2279317 (rx 358000) -Auto-
Saturday 13:19:14 Tx rate (adjusted) 1637097 to 2430580 (rx 382000) -Auto-
Saturday 11:38:30 Tx rate (adjusted) 2689888 to 1637097 (rx 184000)
I wish A&A would stop trying to be "clever" with the masses of output they produce. "Today" and "Yesterday" are idiotic markers for the date. All their report generation tools should be re-worked so that the output states the date, time and textual matter correctly formatted and with sane punctuation. I am sorry but I am unable to understand any of the above.
-
I only see those "Tx rate (adjusted)" entries when our line makes it's PPP connection. Are all those that you show the result of disconnection/reconnections?
-
@burakkucat iirc that snapshot of clueless log entries was taken on Monday last so yesterday=Sun and today=Monday
You are of course absolutely correct about SNRM having two inputs, being a ratio. I was aware of this. I was using loose (=inaccurate), poetic-licence language as a reminder to emphasise the fact that the graphs are SNRM not absolute noise, so that if one mistakenly thought they were of noise then they would look upside down. Absolute noise spikes would be upward-going. That explains my dubious thought processes. And you are of course correct in that the graphs do not tell you what is changing, whether it is signal level or noise level, since all we get is the ratio of the two.
I’m assuming it is safe to say that the signal level is not dropping? But mind you some fault that increases attenuation temporarily would do that. Has anyone any experience of exact that? Temporary resistance (or rather impedance) increase?
Subsequent copper line test passed.
@aesmith Yes it looks like all the crazy rate changes are modem resynched - disconnections/reconnections.
-
I'm reluctant to suggest it, but would you like more graphs to fret over? :D
Have been running what I think is a ready for consumption firmware with graphs for FEC CRC SNR Bitloading Hlog QLN etc, for a few weeks now on my 1312. Its probably unwise to beta test it when you are currently having issues already, but if more graphs to get annoyed with are your thing then you are welcome to Weaver.
-
The picture with this now troublesome line continues as before. Once it twice over week the line’s SNRMs both downstream and upstream drop suddenly by 8-10dB. The downstream attenuation goes from 64 to 73-74 dB and the upstream from 40 dB to 48 dB. It remains in this state with no major changes in attn or SNRM for a duration of anything between an hour and a day or so, something like a day or half a day being far more common.
Today I saw a one hour period 11:39-12:31. This one hour duration is really unusual but I really smell a rat for one much more significant reason: I executed a copper line test from AA’s clueless.aa.net.uk control server and for some unknown reason the modem reconnected and then the problem state was fixed, even more weirdness. I don’t know how the copper line test cured the problem, or why there was a resync. Does anyone have an idea about this?
The resync caused it to change from its earlier horrible slow speeds of 1.7Mbps/0.128Mbps sync rates back to quite normal speeds of 3.077/0.358 Mbps sync rates. At this present time we are in an upstream=bad part of the day. During the ‘good’ part of the day, upstream sync rates would be a lot higher, ~400-550kbps.
Does anyone have any ideas about what could be going on here with the jumps in attenuation?
I wish I had recorded the upstream/downstream power levels from the detailed stats too. I want to check where it is only increased attenuation that is ruining the SNRM. I will note these and get absolutely all the stats bedsides at some future opportunity.
[Moderator edited to correct the "oops", acknowledged in reply #7.]
-
The downstream attenuation goes from 64 dB to 64 dB and the upstream from 40 dB to 48 dB.
Would you be able to correct the information for the DS attenuation, please?
Either there is a change in the attenuation for the circuit -- perhaps a faulty joint has been provoked by a haggis -- or there is a defect in the device which measures and reports the information.
I executed a copper line test from AA’s clueless.aa.net.uk control server and for some unknown reason the modem reconnected and then the problem state was fixed, even more weirdness. I don’t know how the copper line test cured the problem, or why there was a resync. Does anyone have an idea about this?
The test is, of course, just the standard Openreach or BT Wholesale test (dependant upon the supplier to A&A). I'm uncertain of the test details but there is a possibility that an iffy joint could be forced out of a semi-conductive/HR state by the test. (I suspect that 4c and licorice will be familiar with the technique of "giving it a blast with the Megger".)
-
Oops 64 to 73-74 dB downstream.
As for the blast from the Megger, I had thought about that. Is that a bit similar in concept to wetting current? (Bias avoids a near-zero nonlinearity, but this is durative; it affects the properties of the system.)
-
As for the blast from the Megger, I had thought about that. Is that a bit similar in concept to wetting current? (Bias avoids a near-zero nonlinearity, but this is durative; it affects the properties of the system.)
Yes, it would just be putting a bigger than the normal PSTN voltage across the pair and sending a wetting current through them.
-
Once again. Same thing. Problem starts this afternoon, attn jumps up and stays bad all evening. I can now fix it myself [!!]. All I have to do is run a copper line test.
Fails about once per week due to a huge sudden increase in attenuation 8dB upstream and 10dB downstream.
The problem is presumably due to a bad joint, point contact that sometimes goes high resistance ? Is that right? Can we say anything more about this?
So we are saying that the reasoning behind that is that the copper line test blasts the joint with a high voltage as part of the test. This is presumed to be like ‘blasting it with a megger’ and is the equivalent of applying wetting current. The high voltage clears the state of the bad joint, but the effect doesn’t last forever.
As can be seen from the clueless log for Thursday 2019-03-07T22:08 the sync rate jumps up following the copper line test.
Resolution.
I don’t know what you all think, but the only thing I can think of is to wait until it fails again and then be careful not to touch it, not clear it with any line tests. Then we need to get OR out really quickly before it goes away again. The problem would be getting them out quickly enough when it happens. Could I get AA to pay OR for something ridiculous like 4 hour response or whatever, if that would help ?
I would think they should be able to find the fault but only if they _dont clear it accidentally themselves first_ by applying any kind of ‘destructive’ test which means they would have to be very careful and perhaps limits them a bit - I don’t know.
That would mean AA would have to talk to OR in advance so that our man knows what to do and what not to do. How could that be set up?
-
Once again. Same thing. Problem starts this afternoon, attn jumps up and stays bad all evening. I can now fix it myself [!!]. All I have to do is run a copper line test.
Fails about once per week due to a huge sudden increase in attenuation 8dB upstream and 10dB downstream.
The problem is presumably due to a bad joint, point contact that sometimes goes high resistance ? Is that right? Can we say anything more about this?
A high resistance and/or semi-conductive joint. Yes, that is my suspicion.
Exactly how the copper line test operates, I do not know. There might be an AC voltage applied, at one stage of the testing.
-
How would AA talk to the engineer or provide some info in advance ?
-
How would AA talk to the engineer or provide some info in advance ?
It is possible for the ISP/CP to request that a "co-op call" (co-operation call) be made to them by the on-site engineer. I'm sure that A&A will be familiar with the process.
-
AA has booked yet another engineer. A bit of a nightmare for them but I’m sure they’re used to this.
I had a thought. Is it possible that a non-linearity fault could increase the sensitivity to interference?
Some of the other lines have the same run I would think, but only line 3 has the weird upstream good-bad-good SNRM cycle problems.
If so, is it possible that detection could be stronger at upstream tones’ low frequencies than at higher frequencies?
-
If the AC balance of the pair is poor, then the coupling of external generated "noise" events (i.e. anything other than the wanted xDSL signal) will be significantly greater. A joint with semi-conductive tendencies will degrade the AC balance. There will also be a correlation between the amount of coupling and the frequency of the external "noise" source.
High resistance or semi-conductive joint faults are predominately noticeable in the US band(s). (I add the parenthesised "s" for the case of a VDSL2 service.)
-
Two local engineers came out yesterday (Tue). Found an intermittent high-resistance fault and fixed it by reworking a bad joint. They were real heroes out on the moor above the house working in vile weather where it was difficult to stand up. A friend of mine said the hail was stinging at one point when he was out walking.
The downstream attenuation has improved from 64.5 dB to 63.5 dB and upstream improved 40.3 dB to 40.1 dB.
For some reason, the upstream performance has vastly improved. Discussed in another thread.
I will post the notes up shortly.
-
Log from ISP AA (edited to remove some of the noise and names removed) showing Openreach notes:
2019-03-12 16:04:57 2019-03-12 16:38:47 BT Fault 4-780569644160 Please accept clear if fault resolved. If rejected fault will be returned to BT Wholesale
SFI Line tested ok by BT engineer at customer premises;Right When Tested by BT eng at customer premises AA_Escalations@a
2019-03-12 16:38:38 Note TR X19EK7 waiting on EU AA_Escalations@a
2019-03-12 16:04:26 2019-03-12 16:04:57 BT Fault 4-780569644160 Right When Tested; End User Equipment;IP session terminates on RAS, check cust logon
BT
2019-03-12 16:04:25 2019-03-12 16:04:26 BT Fault 4-780569644160 Right When Tested; End User Equipment;IP session terminates on RAS, check cust logon
What did the end customer describe as the primary issue ?: 3762.03-Customer Report: End customer informed us that broadband is not stable / intermittent.
Where did you perform initial DeltaR ?: 3743.01-/ Initial test results: DeltaR test performed at NTE back plate.
What was the leg difference ?: 3763.02-The test failed due to resistance outside permissible range for broadband on 2019-03-12T10:27:41.
Did you complete TDR to locate the fault ?: 3748.01-TDR completed.
Where was the fault located ?: 743.02-/ Actions to resolve: Fault located in the D side underground network.
Have you completed all the base module activities listed below ?: 755.01-/ Actions to Resolve: Base module checks completed.
What did you do to fix it ?: 745.11-Resolved issue in joint.
Why did you complete the Network module ?: 3767.02-Network module completed as sync / stability issues were identified.
Where have you checked the pair quality in the access network ?: 3768.03-Engineer checked the pair quality on D-side.
What main activity have you performed ?: 3769.09-D-side joint upgraded.
Have you observed any improvement in broadband stability / speed / sync or PQT parameters as part of your network intervention ?: 3770.01-PQT parameters were improved resulting in uplifted broadband stability / speed / sync.
Where did you perform the final DeltaR ?: 3837.01-/ Final Delta-R results: Final DeltaR performed at the NTE back plate.
What was the result ?: 3838.03-The test passed with resistance within permissible range for broadband on 2019-03-12T15:27:11.
Where did you perform the final PQT ?: 3835.01-/ Final test results: Final PQT performed at the NTE back plate.
What was the result ?: 3836.01-The test passed on 2019-03-12T15:27:11.
What was your final test (Eclipse / FastTest) ?: 3417.03-Final FastTest completed.
What was the result ?: 4000.01-The test passed on 12/03/2019 15:55:11. BT
2019-03-12 15:57:38 2019-03-12 16:04:25 BT Fault 4-780569644160 Notes as it is received from OR
Right When Tested; End User Equipment;IP session terminates on RAS, check cust logon BT
2019-03-12 09:56:47 2019-03-12 15:57:38 BT Fault 4-780569644160 Notes as it is received from OR
Right When Tested; End User Equipment;IP session terminates on RAS, check cust logon AA_Escalations@a
Monday 11:11:24 2019-03-12 15:57:30 Check 587D75CFR Did SFI make the appointment 2019-03-12 AM? If not then raise a Dispute Task. AA_Escalations@a
2019-03-12 15:55:02 Note engineer called who cleared a HR fault - we'll need to see how that behaves over the next few weeks AA_Escalations@a
2019-03-12 15:51:13 2019-03-12 15:51:20 BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2490kb/s FTR=2278kb/s MSR=2848kb/s ServOpt=1 I/L=I
A SERVICE OPTION CHANGE ORDER IS IN PROGRESS ON THIS LINE
Up Sync=379kb/s LoopLoss=40.1dB SNR=6.1dB ErrSec=1 HECErr=0 Cells=0
Down Sync=2821kb/s LoopLoss=64dB SNR=6.1dB ErrSec=1 HECErr=N/A Cells=0 AA_Escalations@a
2019-03-12 15:51:02 Note HR cleared AA_Escalations@a
2019-03-12 15:49:45 Sent KCI email weaver@weaver.com 2019-03-12 15:49:41 DSL line up (down 5 hours) KCI
2019-03-12 15:49:45 Sent KCI tweet weaver 2019-03-12 15:49:41 DSL line up (down 5 hours) KCI
2019-03-12 15:49:44 Tx rate (adjusted) 337100 to 2430580 (rx 379000) -Auto-
2019-03-12 14:59:01 2019-03-12 14:59:13 BT Test xDSL Copper Test:Pass Fault already reported to OpenReach. : AA_Escalations@a
2019-03-12 13:46:14 2019-03-12 13:46:20 BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass Line status not in sync Circuit Out of Sync
Up ErrSec=0 HECErr=0 Cells=0
Down ErrSec=0 HECErr=N/A Cells=0 AA_Escalations@a
2019-03-12 11:56:10 2019-03-12 11:56:21 BT Test xDSL Copper Test:Pass Fault already reported to OpenReach. : AA_Escalations@a
2019-03-12 10:31:06 2019-03-12 10:31:11 BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass Line status not in sync Circuit Out of Sync
Up ErrSec=0 HECErr=0 Cells=0
Down ErrSec=0 HECErr=N/A Cells=0 AA_Escalations@a
2019-03-12 09:42:01 2019-03-12 09:42:08 BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2329kb/s FTR=2278kb/s MSR=2848kb/s ServOpt=1 I/L=I
A SERVICE OPTION CHANGE ORDER IS IN PROGRESS ON THIS LINE
Up Sync=439kb/s LoopLoss=40.5dB SNR=6.4dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2648kb/s LoopLoss=64.5dB SNR=7.1dB ErrSec=0 HECErr=N/A Cells=0 AA_Escalations@a
2019-03-12 08:38:20 2019-03-12 09:20:14 BT Fault 4-780569644160 Engineer dispatched
Right When Tested; End User Equipment;IP session terminates on RAS, check cust logon BT
-
A "difficult" read but it appears to describe all the findings and actions. Hopefully the circuit will now be stable.
-
I really think that is the end of it. I’ll take the 1dB reduction in attenuation, received with gratitude.
-
I’ll take the 1dB reduction in attenuation . . .
That is, of course, a good indicator of successful remedial work. :)
-
2019-03-12 15:57:38 2019-03-12 16:04:25 BT Fault 4-780569644160 Notes as it is received from OR
Right When Tested; End User Equipment;IP session terminates on RAS, check cust logon BT
2019-03-12 09:56:47 2019-03-12 15:57:38 BT Fault 4-780569644160 Notes as it is received from OR
Right When Tested; End User Equipment;IP session terminates on RAS, check cust logon AA_Escalations@a
Answer. Request the div that you are talking to at AA does not do an 'intrusive' line test. Language.
-
AFAIK the KBD suite used by the ISP's are now classed as intrusive - certainly when it comes to GEA.
It would appear that as a result of in-equivalence of available tests between BTw based and the 'LLU' based SPs, the LLU type ISPs kicked up a bit of a fuss and as a result Openreach redesigned a lot of their tests. There was a stupid situation whereby for a short while that even OR Engineers as well as BTw ISPs were unable to perform any of the old WOOSH tests until the system was overhauled. :(
From what we can gather the old & non intrusive WOOSH (Wholesale Operative One Shot test)?, was replaced by 2 new systems:-
~ KBD for ISPs. Under the new system all GEA line tests run by ISPs are definitely considered intrusive.
~ WHOOSH for Engineers. Openreach engineers are still able to run the non-intrusive test via their WHOOSH system (Note the additional 'H' but we have no idea what the acronym stands for)
We had a conversation here (https://forum.kitz.co.uk/index.php/topic,17799.15.html) as to why line tests run by the ISP's suddenly started being intrusive. There are however strict instructions that the ISP must perform a KBD test before they can report a fault to Openreach. :(
-
Not much to go on in SIN351v1p9
-
No its not on SINET. It's in the KBD documentation issued to ISPs of which there was a copy floating around on the Internet for a while.
I quoted part of it in the thread I linked to earlier. I may still have a copy somewhere but if so its on another drive.
-
AFAIK the KBD suite used by the ISP's are now classed as intrusive - certainly when it comes to GEA.
Sorry for completely OT question, but this is the first time I have heard the term "intrusive" test. As I understand it intrusive just means it will cause a loss of sync, but can such tests actually be intrusive to your network? I ask as back in january a neighbour had Openreach out (and up and down our pole) and a strange device with a Juniper MAC address and IP in the same subnet as my modem appeared in the ARP tables of my router, see thread here (https://forum.kitz.co.uk/index.php/topic,22980.0.html). I hadnt put the two events together until now, so thought I'd ask. We certainly lost sync at least once.
-
90% available on the wayback mavhine./www.sinet.bt.com/sinet/SINs
9% available on https://www.btplc.com/sinet/SINs/
-
>>> but can such tests actually be intrusive to your network?
All they mean by that is that the tests will likely cause loss of synchronisation.