One problem is that VDSL is still new, so how it performs is a big unknown to lots of ISP support.

Also a lot of the time slow throughput is nothing to do with the VDSL component but more to do with the way the WBC backhaul some providers use (the majority of FTTC, until TalkTalk and Sky get their numbers up).

I would say that expecting a wider speed swing at peak times is to be expected on FTTC and FTTP. Logic and evidence from other countries suggests this is the norm.

In terms of drop outs/resyncs, should be no worse than ADSL, my guide is one or two a day (no matter how annoying with their timing) is OK, 10 to 20 a day and you are in fault investigation area.

The phone rining/picking up causing drops is sign of dodgy install, perhaps an engineer missed a star wire config so the abliet filtered phone) is causing problems. or a pre-existing HR fault is more evident at the VDSL2 frequencies.

FTTP would remove the resync/noise issues, but would do nothing for throughput, as backhaul issues would remain, and possibly be worse.

For my connection, the drop wire comes from the DP at the top of the pole across the road from my house to another pole on my side of the road & then straight into the master socket.

When FTTC was first installed the drop wire came in upstairs at the front of the house.

The installing engineer re-used my existing high speed braided data extension cable to reposition the master socket downstairs, near my P.C.

He then used a spare pair in the braided cable to back-wire to what was the original master socket upstairs, making it an extension.

A number of other phone extensions run from that socket, some plugged in & one hard wired in a daisy chain sort of configuration.

It all worked perfectly for around a month, giving me 33 Mb steady throughput download speeds (which must have meant a sync speed of around 35Mb on the original 8c profile - I didn't have access to any modem stats back then, June 2011).

Come near the end of July, my telephone & FTTC services were completely cut off for 4 days. I believe it was some sort of earth fault somewhere external to my house, but I have no idea exactly where.
My wife who was at home at the time the engineers visited told me it took at least 3 of them them a few hours to restore services.

Ever since then, my connection has been rather unstable (almost unuseable at times) with sync speeds as low as 7Mb or 8Mb.

Back in November, the drop wire was replaced from the DP at the top of the 2nd pole & rerouted to make the downstairs socket at the rear of the house a true master socket (the whole socket was also replaced), again re-using my braided cable to make upstairs the first extension socket.

I have tried a few 2 week periods of running the connection with everything else disconnected by removing the faceplate, both from when the drop wire came in upstairs at the front & more recently since it came directly in directly to the downstairs master socket.

I could cope with occasional slow throughput at congested periods.
However, I don't really see any congestion on my connection, usually achieving throughput of around 97% of IP Profile (regardless of the time of day), IP Profile usually being 96.79% of sync speed.

I suspect that an intermittent D-side HR fault was introduced at the time my 4 day loss of service was restored.

An engineer once used a 'Hawk' to run a TDR test on my connection from the end of the drop wire (when it came in upstairs at the front of the house), stating that he had found "something" near the cabinet.

On his return from his trip to the cabinet, he said he had found that someone had "absolutely stupidly" double-jumpered my connection, actually inside the cabinet, which must have been the cause of my connection's problems.

This engineer would not run another TDR test to confirm he had located & fixed the one & only fault as he said "it wasn't necessary".

Unfortunately, the removal of the double-jumpering appeared to have no lasting effect whatsoever on the performance & stability of my connection.
That was back in August 2011.

Despite being requested (by me), not one of the other visiting engineers have been prepared/willing to run a TDR test on my connection

I have tried to purchase a 'Mole' 301C tester on Ebay a few times, just so that I could run a TDR test myself, but was outbid in the closing seconds each time.

I have never achieved much in the way of bit-loading in the D2 frequency band & have never achieved anything at all from the higher D3 frequency band.

However, today I see that my Line & Signal attenuation have increase a little & I am achieving nothing at all from the D2 band:-

Text

1 23 45 67 89 1011 1213 1415 1617 1819 2021 22

# xdslcmd info --pbParams xdslcmd: ADSL driver and PHY statusStatus: Showtime Retrain Reason: 2Max:    Upstream rate = 6015 Kbps, Downstream rate = 29240 Kbps Path:   0, Upstream rate = 6004 Kbps, Downstream rate = 21172 Kbps  Discovery Phase (Initial) Band PlanUS: (0,95) (868,1207) (1972,2783) DS: (32,859) (1216,1963) (2792,3939) Medley Phase (Final) Band Plan US: (0,95) (868,1207) DS: (32,859)        VDSL Port Details       Upstream        DownstreamAttainable Net Data Rate:       6015 kbps         29240 kbps Actual Aggregate Tx Power:        6.3 dBm          10.9 dBm============================================================================   VDSL Band Status        U0      U1      U2      U3      D1      D2      D3  Line Attenuation(dB):  8.4     54.0    64.0     N/A    22.1    64.1    0.1    Signal Attenuation(dB):  10.7    53.3     N/A     N/A    22.1     N/A     N/A           SNR Margin(dB):  6.0     6.1      N/A     N/A    10.3     N/A     N/A            TX Power(dBm): -4.1     5.8      N/A     N/A    10.9     N/A     N/A

Along with US attenuation looking rather high in comparison with other users' stats, fluctuating SNRM levels when the phone is used, fluctuating power levels most of the time (unlike other users' "straight line" power levels, regular re-syncs & low speeds, what else can I do to provide evidence that there is a physical fault - probably intermittent - somewhere between my home & the cabinet (or even inside the cabinet itself) to get this fixed once & for all?

My connection is probably only 800m or so in length.

I'd be creating merry hell with your ISP. That does sound a bit HR-ish to me.

Hi Zarjaz,

In reply to a post by Zarjaz:

I'd be creating merry hell with your ISP. That does sound a bit HR-ish to me.

It's taken from Sunday until this morning of constant stats updates to my ISP, but it appears they are planning to arrange an engineer's visit.

Apparently most ISPs don't see all the FTTC re-syncs as they are simply too quick (16 seconds or so) to be detected by the ISP & thus a new PPP session that an ISP would see is not initiated.

BT's reported IP Profile from their tester doesn't update until a new PPP session is initiated either.

I wonder how many users & ISPs have been confused by a high BT IP Profile, simply not being aware that the modem may well have re-synced very quickly at a much lower speed?

I have mentioned PQT/Eclipse tests tending to return a LTOK result & have also mentioned TDR tests.

I know it's almost impossible to diagnose unless actually on site, but do you have any suggestions as to what I should say, or ask of the engineer?

This does appear to be an "intermittent" fault where major symptoms, such as disconnections & large SNRM drops when the phone is being used, only last for a few days at a time.

Indeed, from around 8:30 this morning I can now use the phone with only a 0.1dB drop in SNRM.
I suppose that is normal?

Following more disconnections yesterday, the connection had re-synced yet again at only 24999 k in the early hours of this morning.
That looks suspiciously like a capped DLM sync speed profile that now needs to be reset to me.

Any thoughts?

The weather is much cooler & slightly damp today (quite misty), unlike it being very warm & dry over the last few days.

The last time I had this exact same issue, the weather had been very cold & very wet for quite a few days.

Is that probably just a red herring that could mis-lead everyone?


Cheers,


Paul.


EDIT:

I could now almost write a book about my various connection issues.

Oh, it looks like I already have done (32 forum pages so far anyway) :-

Topic: FTTC - Distance from the Cabinet - Realistic speed estimate (Read 16110 times)

Edited by Bald_Eagle1 (Fri 30-Mar-12 11:23:10)

I'd be explaining to the engineer that you have an intermittent issue, mention the drop outs when the phone is used, mention the SNR dips in association with phone use.

Politely ask the the engineer if you can see the test results from the mandatory pair quality test, examine the difference in leg resistance figures. I would be looking for a difference of no more than 5 between A to earth and B to earth, the tester will often show a pass right up to 15 difference, but that can mask an HR. Ask what the TDR function shows, 'auto ID' may help if using a JDSU. You should be able to clearly see the DSLAM cab 'spiking' up on the TDR, that will give you the distance to cab.

Ask the engineer if the Boost of FTTC helpdesk (depends what type of fault has been raised) can see any issues on the RRTC data for your circuit.

On a manual (non scripted) test, check for ANY errors, also does the error count increment more when the phone is used at the same time....

If it is a JDSU, then you can ask to see the band statistics, that way you can compare them with yours !

When finished, and the engineer is telling you it's all fixed, ask if they can get a sync recalc done.

Happy hunting.

In reply to a post by Zarjaz:

I'd be explaining to the engineer that you have an intermittent issue, mention the drop outs when the phone is used, mention the SNR dips in association with phone use.

Politely ask the the engineer if you can see the test results from the mandatory pair quality test, examine the difference in leg resistance figures. I would be looking for a difference of no more than 5 between A to earth and B to earth, the tester will often show a pass right up to 15 difference, but that can mask an HR.

Hmmm.
When an engineer requested a DLM reset (I take it that's the same thing as a sync recalc?) 9th March, he told me the result from the PQT was 61 whick looked O.K.
Could he have actually said 6 to 1 (meaning a ratio)?

He also mentioned AC balance, but I have to admit I wasn't sure what he meant by that.

Ask what the TDR function shows, 'auto ID' may help if using a JDSU. You should be able to clearly see the DSLAM cab 'spiking' up on the TDR, that will give you the distance to cab.

I seem to be having great difficulty in getting a TDR test carried out.
I have asked each visiting engineer to conduct one, explaining a suspected HR issue, but they always politely decline (apart from one who used a 'Hawk' from my master socket's incoming feed directly from the drop wire (no external junction boxes) & then identified & removed a double-jumpered connection at the cabinet).

He didn't retest the line though as he was convinced the double-jumpering must have been the cause.
Unfortunately it made very little (if any) difference.
Perhaps a retest MIGHT have detected another issue, possibly the real/main issue that has been causing the problems?

Are the wrong types of engineer being sent for the task (maybe PSTN engineers rather than broadband/fibre engineers?), or are they restricted to time, or given insufficient information via my ISP's notes I wonder?

Ask the engineer if the Boost of FTTC helpdesk (depends what type of fault has been raised) can see any issues on the RRTC data for your circuit.

Just so I "appear" to know what I'm on about, could you please confirm what RRTC stands for?

On a manual (non scripted) test, check for ANY errors, also does the error count increment more when the phone is used at the same time....

When SNRM drops to zero while using the phone (sometimes minus values) & the connection re-syncs, I see massive error counts in my graphs, but not when SNRM doesn't drop quite enough to cause a re-sync.

I'm not quite sure what you mean by a manual (non scripted) test???

If it is a JDSU, then you can ask to see the band statistics, that way you can compare them with yours !

When finished, and the engineer is telling you it's all fixed, ask if they can get a sync recalc done.

Happy hunting.

Thanks for the advice.

Frustratingly my ISP hasn't confirmed the visit date yet.

I hope the issue is still present when the engineer arrives.
It had disappeared for the last 2 days, until I used the phone this evening which caused a re-sync, now at only 18199 k.

On re-syncing at such a low speed, SNRM ended up at over 13dB.
When my connection is "behaving", SNRM is usually around 6dB

Subsequent dialing out & dialing in caused SNRM to drop by 7dB.
This continued for about 1/2 hour, with the drops in SNRM getting less each time.

Now, I can use the phone with only 0.2dB drop in SNRM, which I suppose is normal?

I have tried different handsets in the test socket (with & without dangly filters while the FTTC is still plugged into its dedicated socket) throughout these issues with the same results.

Mrs. eagle is now playing merry hell with me as all the other internal wiring has been disconnected for a week & she has to get up & walk at least 15 feet to use the phone.

It must be a real P.I.T.A. to track down intermittent faults, probably a case of needing to be in the right place at the right time.

Hopefully, I'll be updating things next week to say I am achieving at least 40Mb, with a completely stable connection.

Mrs. eagle is now playing merry hell with me as all the other internal wiring has been disconnected for a week & she has to get up & walk at least 15 feet to use the phone.
...
Hopefully, I'll be updating things next week to say I am achieving at least 40Mb, with a completely stable connection.

Or else arranging a kennel connection as that's where you will be.

When an engineer requested a DLM reset (I take it that's the same thing as a sync recalc?) 9th March, he told me the result from the PQT was 61 whick looked O.K.
Could he have actually said 6 to 1 (meaning a ratio)?

He also mentioned AC balance, but I have to admit I wasn't sure what he meant by that.

Yes that's a sync recalc.
I'm guessing 61 was the AC balance. A 'mythical' overall test result, you can only raise an REIN fault if the AC balance is over 50.

So ask again, for a TDR test.

Are the wrong types of engineer being sent for the task (maybe PSTN engineers rather than broadband/fibre engineers?), or are they restricted to time, or given insufficient information via my ISP's notes I wonder?

No they will be FTTC trained, but there are 'engineers' and 'engineers' if you get my drift.

RRTC is the data helc on BTw's remote monitoring system, see's stability and the like, and gives results per day in a green yellow or red format.

Scripted tests on a JDSU, not worth a [censored] IMHO. Running a live manual test is the way to go.

Hope this makes sense, more than a little tipsy.... will check again in the a.m.

In reply to a post by Zarjaz:

.... will check again in the a.m.

It is "the a.m." .

In reply to a post by RobertoS:

Or else arranging a kennel connection as that's where you will be.