Print

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

[burakkucat]

Further to Bald_Eagle1's analysis, I would suggest that you access the on-line fault service and let it re-check your line.

If that automatic test then returns a LTOK (which it should, if the network [POTS] engineer has done a good job), I would urge you to do as he suggested and request a visit from a Broadband Boost Engineer.

That engineer will perform various tests and make any relevant optimisations. The last thing s/he should do would be to make a call to the appropriate department to have your line's profile reset. As for the latter, Baldy_bird can tell you all about it -- having had previous experience of profile resets of the line into "The Aerie". 

[Blackeagle]

Just to add my two cents FWIW.

I had a visit recently from a very helpful OR broadband engineer who diagnosed my issue as aluminium cabling - sync speed was down from 35+ to 25. On making the aforementioned call my line magically jumped back to 35meg sync for 30 minutes or so as the engineer did some more tests. The 'helpful' BTOR helpdesk that he was on the phone to, then decided that they would re-instate the DLM cap as 'this is all the line can handle'......Err, no, its just been running at 35meg so clearly it can !!

OR fed this back to my ISP (talktalk) who responded saying the sync was still too low, please reset the line.  OR engineer turns up following day to see if its worked. No, it hasn't so he goes off to the cab and doesn't return.  Two hours later, the line drops and comes back at the full 40Mbps (40/2 line). After a couple of days I decided that the throughput was a little (actually a lot) low because of errors as interleaving was off.  Dropped my line a couple of times on purpose to get DLM interested.  Its now synced at 37660, which is faster than the original install and appears to be stable, at least so far.

So, its well worth following b*cat's advice, especially if you have your ISP on side.

[Bald_Eagle1]

Dropped my line a couple of times on purpose to get DLM interested.  Its now synced at 37660, which is faster than the original install and appears to be stable, at least so far.

Just curious; did that turn interleaving, INP and delay on?

Also, are you able to post your continuous stats from before, during & after?
Either the graphs or the log files will do for me.

[Blackeagle]

Just curious; did that turn interleaving, INP and delay on?

Also, are you able to post your continuous stats from before, during & after?
Either the graphs or the log files will do for me.

Interleaving definitely, but I knew I needed it on, so that was fine.  Pings rose from 24ms to 30ms to bbc.co.uk.  T'others I'm not sure 

Have attached some stuff for your perusal Paul.

[Bald_Eagle1]

Let's hope you are able to maintain the speed of around 38Mb.
It looks like no physical works have been carried out as apart from SNRM levels lowering with the higher speeds, not much else looks to have changed in pbParams.

I'm sure you will keep us posted regarding your connection's stability over the next few weeks or so.
I for one will be very interested to see how it all pans out, as I'm sure, so will eliw.

[eliw]

Here are my stats - please tell me what you make of them. Notice that SNRM has been steadily dropping since yesterday to around 5.4 today (from around 6.6) and in the process shaving another meg or so from my DS attainable.

Btw the scripts did not work until I replaced the IP address of the router on the batch files from the default to whatever I have..(I changed mine cause I needed to keep it on the network at all times)

I have also managed to bribe BT to send us a Fibre Engineer (will be here this wednesday morning) - If you can give me a bullet of points about the tests and checks he should do, I will write them down and present them to him when he arrives 

[Bald_Eagle1]

Here are my stats - please tell me what you make of them. Notice that SNRM has been steadily dropping since yesterday to around 5.4 today (from around 6.6) and in the process shaving another meg or so from my DS attainable.

Well, the shape of the graphs is roughly in line with what I would expect from your previously posted pbParams values.

I'd be happy with 5.4dB SNRM. Mine's currently at only 2.3dB & I wouldn't be at all surprised if my connection re-synced overnight, at a much lower speed.

Earlier, I think you mentioned the appearance of the QLN graph.
If you were referring to all the red areas, that's how we first plotted QLN (& Hlog).
The attached GRAPH6.BAT is the current version (not uploaded to the public download site yet).

You could replace the existing version of GRAPH6.BAT with the new version & either re-run TestStats2.BAT to generate a new graph set, or drag the Plink log from your original graphs & drop it onto the new GRAPH6.BAT to generate graphs with the same appearance as my attached set.

The new graphs will be generated in the same folder as the Plink log, so would overwrite the existing graphs (unless you saved a copy of the Plink log into a different folder & dragged & dropped it from there).

Btw the scripts did not work until I replaced the IP address of the router on the batch files from the default to whatever I have..(I changed mine cause I needed to keep it on the network at all times)

The batch files use the modem's default address of 192.168.1.1 which works well with my network. My router is 192.168.1.254 & any other dynamically allocated devices fit nicely between the wide address range.

Quite a few users change the modem's default IP address & others change the router's IP address.
Same thing done differently I suppose.

I have also managed to bribe BT to send us a Fibre Engineer (will be here this wednesday morning) - If you can give me a bullet of points about the tests and checks he should do, I will write them down and present them to him when he arrives 

He/she should carry out all the standard tests as a matter of course (Pair Quality Test, Eclipse Test etc.).

If at all possible, try convincing the engineer to run a TDR test.

This could/should highlight any sections of cable between you and the cabinet that have issues such as High Resistance, Open Circuit, Bridged taps etc. All of which could/would have a negative effect upon your attenuation levels & therefore sync speeds.

Bit-loading tends to tail off when attenuation over frequency from the Hlog graph gets to around -70dB or so.
I see that SOME of your third (highest frequency) DS band (D3) appears to possibly have capacity for SOME bit-loading & therefore speed.

I wonder if DLM has already capped your sync speed to counter any "noise" induced instability.
I see your Interleaving depth (D:) is fairly high, a value of 1 being OFF.

I imagine INP (Impulse Noise Protection) & delay could have reasonably high values too.
These can be found lower down the Plink.log in the "xdslcmd info --stats" section.

Various error counts & errored seconds can also have a part to play.
You would need to monitor these over a period of time.

Now you have the tools, you could do that if another engineer visit may be required in say a few weeks time.

Ultimately, it could just be that the condition & materials (possibly ally) of your D-side cabling cannot be economically improved, but your speeds do seem low(ish) for 550m or so from the cabinet.
The "special" broadband engineer should be able to at least tell you what his JDSU, EXFO or any other tester reports as the "electrically" measured line length.

These are early days & you may need to gather a lot more statistical history before trying to push things along (unless it gets sorted during Wednesday's visit).

The engineer should also be able to report the single attenuation values for upstream & downstream, unlike the split attenuation values as reported via the HG612 modem.
We have recently got quite close, but have not yet finalised a formula to convert the HG612's split attenuation values into corresponding single values.

This makes it quite difficult to easily guesstimate/calculate theoretical speeds for given line length/attenuation values.

Good luck 

[eliw]

Thank you Sir.
I will do my best to get the TDR test done as I believe that is the key test for my particular case.

[burakkucat]

And here is a tip that Black Sheep (a serving Openreach engineer) recommends --

If there is a suspicious region of the TDR graph (when measuring from your end of the pair toward the FTTC DSLAM and, thus, the exchange battery), it is often helpful to call the line (from a mobile phone) whilst keeping careful watch on the TDR trace. The superimposition of the AC "ringing" voltage on top of the exchange battery's constant DC bias will often cause an "iffy" joint to become quite apparent. 

[Bald_Eagle1]

And here is a tip that Black Sheep (a serving Openreach engineer) recommends --

If there is a suspicious region of the TDR graph (when measuring from your end of the pair toward the FTTC DSLAM and, thus, the exchange battery), it is often helpful to call the line (from a mobile phone) whilst keeping careful watch on the TDR trace. The superimposition of the AC "ringing" voltage on top of the exchange battery's constant DC bias will often cause an "iffy" joint to become quite apparent. 

That is exactly what I hope Friday's engineer will do when he visits me (some engineers do appear to need prompting a little though).

FYI, my connection did re-sync at only 22677k, but not until 07:28 this morning.
SNRM started off at 8dB, went to 10.3dB, back down to 5.3dB & back up to 10.4dB within 15 minutes.

I am already late for a work appointment so unfortunately don't have time this morning to try my own TDR test.
I will do so tonight if the issue is still present though.

[eliw]

Bald_eagle

You say :

I wonder if DLM has already capped your sync speed to counter any "noise" induced instability.

I am a bit confused by this comment .. I thought DLM was only there to set a profile for your line and had nothing to do with Sync Speeds - which are fixed to the characteristics of your line at any moment in time - i.e sync speeds = attainable rates...

... and IP profile = line rate - which is obviously capped as it is at 46mbits as opposed to the sync speed which is 57mbits.

[Bald_Eagle1]

Bald_eagle

You say :

I wonder if DLM has already capped your sync speed to counter any "noise" induced instability.

I am a bit confused by this comment .. I thought DLM was only there to set a profile for your line and had nothing to do with Sync Speeds - which are fixed to the characteristics of your line at any moment in time - i.e sync speeds = attainable rates...

... and IP profile = line rate - which is obviously capped as it is at 46mbits as opposed to the sync speed which is 57mbits.

Attainable Rate as shown in the modem's GUI is also reported as Max in pbParams & other places.
This is the theoretical best rate that your connection could achieve based on current conditions.

Line Rate as shown in the modem's GUI is also reported as Path in pbParams.
This is the actual Sync speed.

IP Profile a.k.a. BRAS Rate (not reported anywhere by the modem) is always approximately 96.79% of sync speed for UK VDSL2 services.

When DLM encounters a "problematic" line, exhibiting a history of noise, high attenuation issues, high error rates etc. it takes action to provide stability in preference to speed.
DLM then sets a sync speed cap which is maintained until conditions improve for a sufficiently long enough period of stability combined with higher attainable rates for DLM to re-sync your connection at a higher speed (in theory).

In practice, we have seen DLM to be very intolerant of "problems" & quite aggressive & quick to take remedial action.
However, it can take many days or even weeks before DLM deigns to allow a higher speed.
Occasionally, DLM needs to be reset as it "sticks" at a permanently low speed.

My connection has required engineer initiated DLM resets when sync speeds have been "stuck" at values such as 24999k, 14999k, 12999k etc.
The engineer doesn't physically reset DLM, but requests the remote control centre to reset it back to a wide open profile.

The remote control centre agent once REFUSED to reset DLM as my connection was achieving 24999k & records confirmed it could not physically achieve any more than that!
This was despite the engineer having fixed a definite cabling problem & holding printouts in his hand of my speed tests (including BT's own test) where actual throughput speed was in excess of 32Mb.

I had weeks of battle to eventually get DLM reset following that refusal.

e.g. I have a problematic line. Hopefully Friday's engineer visit will fix it once & for all.
My line's problems have been intermittent which has made it difficult for emgineers to actually find the problem(s) & has a really negative effect upon DLM's decision making regarding my sync speeds.

My current Attainable Rate is 32896k. It has on occasions been higher than 36000k.

My current Sync speed is only 21167k following a re-sync caused by using the phone this morning.
Dialling in temporarily "fixes" the problem & currently I can use the phone again with no drops in SNRM, so I know a TDR test would NOT clearly identify the issue.

I also suspect that the electrical pulse from a TDR tester would also temporarily "fix" this particular fault, hence it never being picked up when engineers have run TDR tests.

I can & have run my own TDR tests & nothing obvious has been seen, even during aperiod of disconnections.
As soon as the modem is reconnected, the line remains stable for sometimes days at a time.

From my TRD traces, we do suspect an intermittently dodgy joint at the DP at the top of the pole across the road from my house.
The engineer Black Sheep has also confirmed the typical "unreliability" of this type of push fit connection, known as a coffin lid DP by engineers due to its coffin shape.

Apparently the connections need thicker wire to make a reliable connection.
His colleages crimp a short length of thicker guage cable to the thinner guage feed cable to ensure a snug fit.

I mentioned this to the latest visiting engineer, but his jumper recabling work inside the PCP genuinely appeared to have resolved all the issues, giving me one of the highest sync speeds I had seen for 8 months (following his requested DLM reset).

This unfortunately only lasted for a few days of stable, low error counts & higher speeds.

MY IP Profile/BRAS Rate is currently 20.49Mb (96.79% of Sync speed).

My SNRM is 11.8dB. Hence an Attainable Rate which is much higher than my sync speed.
No doubt a modem reboot would provide a higher sync speed, but too many reboots also has a negative effect upon DLM & I could end up with a stuck low sync profile & associated even lower IP Profile, despite having a high Attainable Rate.


Very occasionally, Attainable rates can be less than current sync speed. eg. the connection may have synced really close to its attainable rate when conditions were really good.
As conditions have gradually deteriorated, SNRM will have lowered, but not by enough to cause a re-sync & thus Attainable rate is less than sync speed.

Some users living close to the cabinet see Attainable Rates well above 100000k.
On a capped 40 Mb sync speed service their SNRM value is higher than 30dB.
When switching to the 80Mb service, Attainable rates stay roughly the same, but SNRM is reduced to much lower levels.

So, DLM actually sets the Sync rate, with everything else calculated from that.

The attached example is not the quietest line we have ever seen, but it is less than 100m from the cabinet, so signal to noise ratio is still really high, giving Attainable rates of 130Mb DS &  41Mb US against the service capped 40Mb & 10Mb Sync speeds.

[eliw]

Thanks for that Baldeagle.

Engineer been around this morning - not a "boost" engineer but just a normal telephony one although he was here to look at our broadband. Anyway hooked up his unit and done all the tests - would not do the TDR ... found another fault on the line which he described as another "battery".. so he went out to fix it.

He got the profile reset - which I thought was strange after reading all the reports from others saying how hard it was to get one.

Anyway at the moment my sync is 53/10 which is better than before - interleave is 1/1 now so pings are very low and so far after a 2 hours sync and quite a lot of net activity not a single CRC error 0-0 (but a few FEC and HEC), the SNRM is a bit higher as well... but DS attainable rates are like 3 or 4 megs lower now ?!!??! why oh why !

Latest stats :

[Bald_Eagle1]

Anyway at the moment my sync is 53/10 which is better than before - interleave is 1/1 now so pings are very low and so far after a 2 hours sync and quite a lot of net activity not a single CRC error 0-0 (but a few FEC and HEC), the SNRM is a bit higher as well... but DS attainable rates are like 3 or 4 megs lower now ?!!??! why oh why !

If you are getting the FEC, CRC & HEC errror count from the Hg612's GUI, be mindful that they are incorrect/mixed up.

With Interleaving at 1/1 (i.e. OFF) you shouldn't really see any FEC errors.

The better (more accurate/correct) details are RSCorr, RSunCorr etc. as stored in the Plink log in the xdslcmd info --stats section (near the bottom of the log).

[burakkucat]

I also suspect that the electrical pulse from a TDR tester would also temporarily "fix" this particular fault, hence it never being picked up when engineers have run TDR tests.

Bald_Eagle1,

I would like to use you in a "thought experiment" to show that your above suspicion is invalid.

For our experiment we shall require a battery of twenty five 2V lead-acid cells connected in series, an ex-GPO ringing converter capable of producing an output of 120V AC at 25 Hz, two reels of CW1308 cable and an ex-BT 301C Tester.

Prepare the two cables by stripping the insulation of each end of the (say) blue pair and connect the two cables together with a pair of twisted joints. Do not insulate those twisted joints, they need to be accessible.

At one end of that double length cable, connect the battery of cells to provide 50V DC -- thus mimicking the exchange battery. At the other end of that double length cable, connect the Tester 301C but do not turn it on.

Go to the mid-point of that double length cable, take hold of one twisted joint in one hand and touch the other twisted joint with a finger of the other hand. Feel anything? No, I didn't think you would. So you now grasp the second twisted joint with the second hand and confirm . . . nothing.

Having let go of those joints, now turn on the Tester 301C and try to if the twisted joints show up in the TDR trace. (It's not important if you can the presence of the joints, we just need the 301C powered on and connected to the cable.) Go back to those twisted joints and repeat the cautious "touch" testing. Feel anything? I very much doubt it.

Finally, connect the ex-GPO ringing converter in parallel with the battery of cells and turn it on. Look at the TDR trace. Repeat the cautious "touch" testing. I guess your feathers (those you have left) stood on end! 

It is the alternating "kick" of the ringing voltage that will "punch through" the corrosion / oxidation / minute air gap of a "manky" joint not the RF signal from a TDR tester.