Strange TalkTalk Fibre Issue

I'm currently on Fibre Large but only able to get around 40mbps and i've been on fibre for about a week now.
TalkTalk sent one of their Huawei SuperRouters and it was a self install with no engineer visit and there is no OpenReach modem.

I was doing a "chat" with a TalkTalk rep as i said the line wasn't getting the Fibre Large speeds and they've said there is a fault on the line.
My wiring in the house is pretty straight forward and the cable comes in and goes straight to the NTE with no extensions.

The TalkTalk rep said there was a fault and said and i quote "there appears to be a fault with the battery in the DSLAM".

Any thoughts from people in "the know"?

A fault with the battery backup in the DSLAM won't affect sync speed.

A battery contact between the two wires of your phone line may be causing problems. What was the sales estimate given to you when you signed up

well, here's the thing

The sales rubbish says "39 Mbps - 40 Mbps"
The Wholesale Checker says 80Mbps which i posted about and you and i both exchanged emails and identified a fault with the checker.

However they let me order fibre large and are convinced i should be able to go faster (which will be based on the wholesale checker).

Either way they've still identified a fault on the line but i was somewhat sceptical when they went on about the battery!

I seem to be on an interleaved profile at the moment even though the first sync on Fibre was on the Fast profile so i guess DLM is all over my line at the moment. From what i can see on the TalkTalk Router (which is limited information) the line was stable and i'm not getting drop outs and couldn't see a load of errors!

What is your upstream sync right now? This will tell you whether it is line conditions or an incorrect profile with Talktalk (the 40mbit product is capped at 2mbit upstream).

If it is indeed the profile, then as a self install will likely have been initially configured as a 40mbit connection and then regraded - thats how mine worked. I found that i was stuck on the 40/2 profile with Talktalk post regrade until i turned off my router and left it switched off for a good hour or so before restarting it. This was something to do with the profile settings being carried within the DHCP service which needs to cycle and re-issue.

I am not sure technically beyond this, but that was certainly the case for me with TT Fibre Large. This obviously assumes that actually you are graded correctly at talktalks end.

The term 'battery fault' usually applies to an underground problem with your line. Your pair is picking up the voltage from another working circuit(s).There is a fair chance if you do have a battery contact fault that it is affecting sync rates.

However, if when you spoke with TT and the recorded a battery fault on the remote line test why have they not reported it to Openreach for repair ?

I believe they are in the process of escalating and asked me a bunch of questions about availability for an engineer should one be required to visit.

re: sync rate now.
I don't know as i'm at work but when i get home i'll let you know! I seem to recall the upstream being around 8-10mb!

overall the downstream sync speed has dropped 4mbps since it first sync'd.

Something i've noticed on the TalkTalk router is that is has a max sync rate (up & down) and sync rate (up & down) so i'm not actually sure what the difference is between the two other than there being a difference!

I'm also plugged directly into the master socket not that i would think that makes much difference tbh as i don't have any wired extensions off the NTE.

Post the figures from the router for the max sync rate and sync rate.

Here are the stats as of right now!

DSL synchronization status:
Up
Connection status:
Showtime
Upstream line rate (kbit/s):
9180
Downstream line rate (kbit/s):
33947
Maximum upstream rate (kbit/s):
8893
Maximum downstream rate (kbit/s):
44860
Upstream noise safety coefficient (dB):
4.4
Downstream noise safety coefficient (dB):
4.6
Upstream interleave depth:
1
Downstream interleave depth:
1967
Line standard:
VDSL2
Upstream line attenuation (dB):
8.1
Downstream line attenuation (dB):
19.5
Upstream output power (dBm):
2.6
Downstream output power (dBm):
9.9
Channel type:
Interleaved
DSL up-time:


TalkTalk came back to me and seem to think the issue is resolved.

I do have a Billion 8800NL and a Openreach Mk3 faceplate which i had ordered anyway. Is it woth continuing with the setup for that?

I decided to connect the Billion 8800NL and the MK3 faceplate anyways and here are the current line stats

xDSL
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0

Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 6.2 6.1
Attenuation (dB) 24.0 0.0
Output Power (dBm) 12.9 3.0
Attainable Rate (Kbps) 42707 8454

Rate (Kbps) 35779 8454

B (# of bytes in Mux Data Frame) 51 239
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 64 45
R (# of redundancy bytes in the RS codeword) 12 0
S (# of data symbols over which the RS code word spans) 0.0462 0.9023
L (# of bits transmitted in each data symbol) 11072 2128
D (interleaver depth) 701 1
I (interleaver block size in bytes) 64 120
N (RS codeword size) 64 240
Delay (msec) 8 0
INP (DMT symbol) 3.00 0.00

OH Frames 13943325 4042275
OH Frame Errors 99 88
RS Words 3569406000 3279593
RS Correctable Errors 896448 0
RS Uncorrectable Errors 2709 0

HEC Errors 594 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 2850444111 0
Data Cells 117161335 0
Bit Errors 0 0

Total ES 29 60
Total SES 0 0
Total UAS 31 31

There's something of a jump in attenuation from the TT modem to the Billion - 20dB to 24dB. That can happen between modems with different chipsets. I'm not sure what is in the TT modem.

The Billion normally produces attenuation figures comparable to the HG612, with the same family of Broadcom chip set. A value of 24dB probably equates to a distance of 600m of standard 0.5mm copper; speeds of 80/20 aren't likely there. Something like 50/12 seems more likely.

Otherwise, DLM has intervened, so is eating a chunk of bandwidth, and adding 8ms latency.

thanks very much for the reply!

With the jump in attenuation is that a good or bad thing?
When i put in the Billion Router i did fit a Openreach Mk3 faceplate, where was the talktalk was connected using the supplied microfilter.

As far as the chipset in the TalkTalk SuperRouter, i think it's a broadcom chipset. The router model is a Huawei HG635.

I would say my distance from the cab following the road (which lines up with the ground junction boxes is more like 800mtrs. So 40mbps is about what i would expect tbh. Eitherway there is some weirdness on my line or at the DSLAM according to TalkTalk.

Attenuation shouldn't change under normal circumstances, but changing the faceplate could make a fractional change. If the actual attenuation figure has really changed, then something has gone wrong in wiring the new faceplate, or it is faulty.

However, we have seen different modems report different attenuation values with FTTC, especially now more non-broadcom chipsets are being seen. The variations seem to be bigger than we saw in ADSL, suggesting there is some differences to the way the modems measure.

The best you can do is to go back to the previous modem, and check that it still reports 19.5dB with the new faceplate. If it does, then the different values come from different measurement techniques, rather than a change to the line.

But you're right - the HG635 is likely to be Broadcom-based too. Perhaps the faceplate has made things worse.

Thanks! I think i got the model wrong, It's a HG633, the 635 had gigabit ports. I think both these were still broadcom chipsets though.

I contacted TalkTalk this morning who did some more diagnostics and the line fault they reported seemed to be down to my phone being connected via an extension lead. The router was/is plugged directly into the NTE not plugged in via the extension.
Without the phone+extension plugged in it doesn't report a line fault.
They still think there is an issue with the sync speed so they are investigating that.

What is curious to me is my line never retrains/drops unless i've changed the router/filter. So stability in terms of retrains it seems pretty solid so i suspect DLM stepping in is down to errors being reported?

I'll swap out the router again later with the same mk3 plate as you've suggested to see how the attenuation is with the TT Router.

The only thing that worries me is messing around like this is likely going to make DLM go nuts!

I have a similar issue, I have recently moved house and taken up the same Talktalk fibre package, estimated sales speed is 69.6 - 76Mb/s. with the supplied 'super router', it has failed to go above 49Mb/s and 17Mb/s upload. Replacing it with a unlocked HG612 (firmware ver. B030SP08) this has increased to 52and 18Mb/s respectively, line attenuation is 11.4dB and a 6.2dB margin, I have yet to contact Talktalk as I'm still within the ten day training period. Speed tests are consistent at varying times of day and night so it's unlikely to be a congestion issue.
BTW, this was also a technician-less install....

Edited by deleted (Sun 18-Oct-15 20:34:04)

Ten day training is a BT Wholesale thing. You aren't on a BT Wholesale circuit.

I'd be very surprised if TalkTalk have the same thing.

I contacted TalkTalk this morning who did some more diagnostics and the line fault they reported seemed to be down to my phone being connected via an extension lead. The router was/is plugged directly into the NTE not plugged in via the extension.
Without the phone+extension plugged in it doesn't report a line fault.
They still think there is an issue with the sync speed so they are investigating that.

SO there's the truth behind what was being said, the original set up would have given a 'bridge tap' test result on the GEA test, using the new faceplate will have corrected that.

"and the line fault they reported seemed to be down to my phone being connected via an extension lead. " Unless the line tested loop, which you haven't mentioned at any point, so I guess not, they are talking out of their elbows.

The extension lead i'm/was using goes like this

NTE
|
Microfilter ------- \
| |
vDSL Router Extension lead
|
Phone

excuse my [censored] ASCII drawing! The current setup has just replaced the microfilter dongle with a Mk3 Openreach facia.

I did used to have (12 months a go) my ADSL over the extension lead but that ruined sync speed (from 2.5 to 1.8), probably due to this earthing/contact issue. I guess the extension lead is poor quality...


Either way still waiting to here from the TT engineers!

Well Talktalk think there is a ten day 'training period' on my connection....As I understand it, BT Openreach has jurisdiction over the connection as far back as the breakout in the exchange, I would expect the 'training' to be related to the copper connection from the fibre cabinet to the property, Talktalk only take over the connection in the exchange and port it onto their own network at that point, so there wouldn't be any functional difference regardless of ISP with regard to line training? i'm sure someone will correct me if i'm wrong...
Anyhow, I contacted Talktalk earlier, (they mentioned that I was in the 'training period' so slower than expected speeds don't necessarily mean a fault!) while they were prevaricating as to whether there was an actual fault, the line started crackling (it's not helpful that Talktalk don't have an equivalent 'quiet line' function), the agent on the phone tried ignoring it at first, until I pointed out that it was maybe the reason he had to keep repeating his words to me!.
Anyway, despite a line test showing no problems, a fault has been logged and i'm awaiting a date for the technician to call.
What I find odd is that there are few broadband errors logged, my previous ADSL performed perfectly at ~5.2Mb/s for months at a time but the Cisco 887VA it was connected to logged 10 - 15 faults (CRC & FEC) per minute, the current VDSL shows only 3 - 5 faults per minute.

Edited by deleted (Mon 19-Oct-15 20:23:39)

No such 10 day period exists on FTTC reality in short is http://www.thinkbroadband.com/news/5929-reminder-abo...

Thanks for that info, if that's (still) the case, then someone needs to tell whoever compiles Talktalk's user guides, the booklet supplied with their 'super router' - which is admittedly a multi-modal device - states in the fibre connection section "Make sure you leave your router turned on. We'll be gradually adjusting your speed until it is as fast as possible over the next 10 days."
The only retrain i've seen was earlier today when they ran a line test, once the testing was over, the rate and noise margin reverted to their previous values after about 90s flapping.
The remote end is identified as Infineon, is the Broadcom chipset the best match?

In reply to a post by 10forcash:

"Make sure you leave your router turned on. We'll be gradually adjusting your speed until it is as fast as possible over the next 10 days."

They can't do that

MrSaffron gave it in short, or to be more precise wrote in English what Openreach say in their definition of FTTC. Specifically Section 2.2.1 of this document.

See this page about the BT Wholesale 10-day period on ADSLx. Note what actually happens at the end of the ten days.

That doesn't apply on Sky, who do start ADSL2+ LLU line at normally 4Mbps then ramp them up over a few days. TalkTalk I don't know, but have never heard it mentioned in relation to ADSL2+.

Nor, fairly obviously, can it really apply on FTTC, over which BT Wholesale have little control. The fault reporting speeds on FTTC are also determined by Openreach and are not set in any 10-day period.

I think you have been told this by someone at TalkTwaddle.

Re your error counts, remember on ADSLx the copper is used all the way from the exchange to you, with all the scope for problems that entails. On FTTC only the distance from the FTTC cabinet, (through the PCP), to you is copper.

This is FTTC

Thanks for the info - it's only 'fairly obvious' once i'd speed - read the document! I'd made the (reasonable IMO) assumption that the local copper was treated in the same way as an ADSL circuit, maybe Talktalk also assume that!
Interesting that a retrain can be initiated by a user initiated power cycle, although i'd be tempted to leave it off for >30mins, urban myth or not.

As I said, in order to show how the 10-day period so beloved of BTW could not possibly apply to FTTC, nor to any TalkTalk LLU or GEA circuit.

Thanks

In reply to a post by WWWombat:

But you're right - the HG635 is likely to be Broadcom-based too. Perhaps the faceplate has made things worse.

I can confirm that the HG635 is indeed Broadcom. Not 100% sure, but I think the HG633 is too.

FWIW, I am currently working on getting HG612 Modem Stats to work with a HG635.

It is being tested on an ADSL connection at the moment, so once it's all working properly, it would probably need tweaking for VDSL.use.

Some data I haven't seen previously is reported for the test G.DMT connection:-

Text

1 23 45 67 89 1011 1213 1415 1617 1819 2021 2223 2425 2627

SF:             89002974                89019132 SFErr:          7081            608RS:             89002974                89019132 RSCorr:         9358722         15897RSUnCorr:       143742          0  LinkRetrain:    0 InitErrors:     0InitTimeouts:   0 LossOfFraming:  0  ;; ;; ;Bitswap:        270703          119     UPBOkle:        7738 actualCE:       0SNRmode:        0 AtucPhys SNRmode:       0  Total time = 1 days 12 hours 30 min 22 secFEC:            17689015                0

Line 27 seems to have the same iffiness as in this thread.

I assume it's 20-24 you are referring to?

In reply to a post by Bald_Eagle1:

FWIW, I am currently working on getting HG612 Modem Stats to work with a HG635.

It is being tested on an ADSL connection at the moment, so once it's all working properly, it would probably need tweaking for VDSL.use.

Am I right in getting from this that you may get the HG612 modem stats working with a TalkTalk HG635 or have I completely missed the point?

In reply to a post by RobertoS:

I assume it's 20-24 you are referring to?

Yes it is.

In reply to a post by solchain:

Am I right in getting from this that you may get the HG612 modem stats working with a TalkTalk HG635 or have I completely missed the point?

Yes, that's right.

My program already obtains the raw data & I'm working on getting it formatted to use with the existing graphing programs etc.

I don't have a HG635 here, so it's taking a while to tweak the programs, send them for testing & work out what else to adjust, but I'll get there in due course.

In reply to a post by Bald_Eagle1:

In reply to a post by solchain:

Am I right in getting from this that you may get the HG612 modem stats working with a TalkTalk HG635 or have I completely missed the point?

Yes, that's right.

My program already obtains the raw data & I'm working on getting it formatted to use with the existing graphing programs etc.

I don't have a HG635 here, so it's taking a while to tweak the programs, send them for testing & work out what else to adjust, but I'll get there in due course.

Not wanting to hijack this thread, but bald_eagle if it's any use I have a spare talktalk 633 if it might help, what you are doing would be of interest to me (if it works with the 633 as that is my main modem) so would be happy to help.

I have a customer who has a spare hg612 which I can have if I collect it, but what you are doing would suit me more.

Talktalk only supply the hg633 now.

In reply to a post by solchain:

Not wanting to hijack this thread, but bald_eagle if it's any use I have a spare talktalk 633 if it might help, what you are doing would be of interest to me (if it works with the 633 as that is my main modem) so would be happy to help.

I have a customer who has a spare hg612 which I can have if I collect it, but what you are doing would suit me more.

Talktalk only supply the hg633 now.

I'm sorry. I don't know if the programs will work with a HG633.
Can you access it to get the stats via telnet or like a HG612, does it need unlocking or the firmware updating first?

I have also asked this elsewhere.

In reply to a post by RobertoS:

Line 27 seems to have the same iffiness as in this thread.

I don't think so. The number 17689015 doesn't fit the right format; the best way to check is to put the number into a calculator with a binary mode - the one in Windows 7 has a "programmer mode", with a radio button that allows you to enter in decimal, then swap to binary, and includes an extra binary display.

If it shows with all the high-end bits as "1", then it is a candidate. The highest bit absolutely *must* be "1" (it signifies a negative number, in signed integers).

By "all high-end bits", I mean up to a nice byte boundary - so to bit 15, or bit 31 in most cases.

17689015 = 00000001000011011110100110110111

From the other thread,
4294967290 = 11111111111111111111111111111010

For me, Line 27 is of the right kind of order as Line 4 downstream, with the difference explainable with 1 resync while the box has been up.

The first hint of something wrong is that Line 4 downstream is relatively large compared to Line 3 downstream, suggesting a lot of noise.

What looks "off" is that Line 3 downstream shouldn't hold the same value as Line 1 downstream, and neither should be the same as upstream.

In reply to a post by RobertoS:

I assume it's 20-24 you are referring to?

I've never seen these lines before.

UPBOkle appears to stand for "Upstream Power Backoff" "electrical loop length" "estimated"

UPBO = Upstream Power Backoff
KL = electrical loop length
E = estimated

Going well off-topic:
I've certainly seen "kl₀" used to represent electrical loop length before, in some graphs for vectoring; I think it is measured in dB, and is a form of attenuation ... but it usually comes with a specification of what frequency is being measured. For example, "a kl₀ of 20db @ 1MHz".

One interesting document that shows actual trial results for VDSL2 Vectoring comes from Denmark, but their graphs for rate vs reach are done using "kl₀ @ 1MHz" values...
https://erhvervsstyrelsen.dk/sites/default/files/pun...

From BT's SIN 498, it appears that they think 500m of 0.5mm copper is "(equivalent to an electrical loss of 10dB measured at 1MHz)" which I guess makes it easy to compare the Danish results.

That SIN also tells us that the CAL value for each cabinet is calculated from the loss at 300kHz; my rule of thumb for *that* kind of loss is that 10dB represents 1km, so scales differently from that measured at 1MHz.

The Danish document has this factor: "dB[150 kHz] = 0,38* dB[1 MHz]"

From all that, I reach the conclusion that we can't know what a value of 7738 means for UPBOkle, without knowing what frequency it is measured at.

So things where ongoing and i came home yesterday to find interference/crackling on the phone side and intermittant sync'ing and the line dropping out all over the place.

I removed the openreach mk3 faceplate, put the talktalk router and microfilter back and replaced my cordless phones with a corded phone and still no difference.
After speaking to TalkTalk 3 times last night they are saying it's a "battery" or contact issue outside the property.

Needless to say DLM has gone mental trying to stabilise the line from what was a solid 37mbps for the last 7 days (no drop outs) to a pitiful 15mbps overnight last night and dropping packets left right and center.
I did tidy up all my cabling around the router and remove any things that i thought could affect the line but this made no difference to the interference but it sync'd up at 35mbps before i left for work this morning. I won't know what it's like until i get in later.

I'm just hoping TT will get just get openreach out and make sure everything is as it should be and hopefully reset DLM as yesterdays antics is probably not going to help!