Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1] 2 3 ... 5

Author Topic: FTTC long line 2.6km - Stats check after problems  (Read 18424 times)

Crickers

  • Member
  • **
  • Posts: 36
FTTC long line 2.6km - Stats check after problems
« on: February 23, 2013, 09:46:23 AM »

Hi Everyone,

A bit of background information, recently moved into a new house and had FTTC installed.

This took 8 engineer visits over a month, the final one being a boost engineer. I have lost days on the phone to BT and waiting for enigineer visits.

Faults included 18v battery fault, humming noise on the line, total loss of connection for 3 days. Also had a lift and shift at the FTTC cab, which resolved noise so far.

No JDSU has ever managed to sync on my line and the only modem to sync is a Huawei. Have tried ECI and my draytek 2750n, which worked fine at old house on FTTC.

Have had the underground cable to my house replaced with an overhead cable, after testing with a direct cable through the window from the pole gained 1Mb

I realise I have a long line at around 2.6km, but would really appreciate if someone could check my stats and see if anything looks unusal.

Spend quite a bit of time reading this forum, which has been invaluable and very informative.

Have attached a few logs using Bald_Eagles excellent scripts. The very last re-sync was me resetting the modem this morning.

Logged

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: FTTC long line 2.6km - Stats check after problems
« Reply #1 on: February 23, 2013, 11:02:02 AM »

Hi Crickers & welcome to the forum.


I'm not at all sure what speeds you should expect from a 2.6km line, but my gut feeling is that it looks 'reasonable'.

However, a slight problem can be seen in your Hlog graph.
It should ideally have a smooth curve. The plot at around tone 200 (roughly 860KHz) suggests a physical problem. Maybe a poor joint or even a bridged tap (although more of a 'V' shape would be usually seen if it were a bridged tap).

This 'problem' can be seen to be affecting bitloading (a gap) & SNR (a flat line) at the same frequencies.

QLN looks good, although that data is only obtained during the training up period from a resync, as is Hlog data.

Bitloading & SNR will vary dynamically for the duration of the connection between resyncs.

Running the snapshot script (Teststats2.BAT) at different times of day/night may paint a better/worse picture.

Your DS SNRM & Attainable rate vary quite a lot from around 17:00 each day (looking at the limited data so far), suggesting additional 'noise' from other users' evening connections and/or electrical interference from appliances, central heating etc.

I see from your Discovery Phase (Initial) Band Plan that you are connected to a Huawei cabinet DSLAM.

I also see that DS Interleaving was applied by DLM at a low depth just after 06:00 yesterday.
The depth then increased at a resync before 04:00 this morning, assumed to have been a DLM induced resync.

It then increased further when you initiated a resync this morning.
It is still at a reasonably low level (375) for a FTTC connection though.


The fact that Interleaving was OFF at first suggests that your connection has only recently become live. Is that the case?

You will see that error types swapped around when Interleaving was applied.
That means that some errors are being forwardly corrected (FEC) rather than needing data to be retransmitted.

The HG612 modem does seem to be very good at working on 'poorer' connections, hanging on to a connection even when SNRM is very low, even at negative values for short periods.

I suggest that you try not to force any more resyncs, at least for a week or so.
That will enable you/us to see how the connection performs when left to DLM to manage it.

Your current sync speed of 5816Kbps looks like DLM has not applied a 'banded' speed cap (yet), but it may do if many resyncs/high error counts are seen.

With a great deal of programming help from Burakkucat & from RONSKI who has developed a Windows fron end to control everything, I hope to release a new set of programs (hopefully NEXT weekend) that provide much more detailed data/graphs & can be easily fully automated for completely unattended monitoring/logging/scheduled graphing over very long periods of time (probably indefinitely).

It should be noted that the FEC & CRC error graphs from the script version, using incorrect data (as also seen in the HG612's buggy GUI) are incorrect.
RSCorr should be considered for FEC errors & OHFErr should be considered for CRC errors.


Overall then, for the line length, I would say your connection looks O.K.(ish) at the moment.

How does it actually feel in use, compared to ADSL?

« Last Edit: February 23, 2013, 11:21:59 AM by Bald_Eagle1 »
Logged

Black Sheep

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5252
Re: FTTC long line 2.6km - Stats check after problems
« Reply #2 on: February 23, 2013, 11:05:20 AM »

FTTC will surely highlight line faults, as surely as a bear would visit the woods to ............  ;).

It sounds like you've had some good engineers on the job, to be fair. I won't bore you with our performance measures that dictate whether we get sacked or not.

As an aside, there's a little known function on the JDSU that most engineers will be unaware of. Whilst it is in 'boot mode' trying to handshake with the VDSL signal, the JDSU is auto-set to 'Annexe M'. By simply using the 'Action' key and from the drop down menu, 'Annexe A' can be selected which generally allows the JDSU to synch on very long D-side cable runs.
The only caveat I'll apply, is that I may have got the 'Annexes' the wrong way round, as I tend to be on auto-pilot when working on faults and don't take much notice of the wording.

Just out of interest, may I ask where you are in the UK ?? It sounds similar to a local fault around our way ?? :-) No problem at all if you don't wish to divulge any details.  :)
Logged

Crickers

  • Member
  • **
  • Posts: 36
Re: FTTC long line 2.6km - Stats check after problems
« Reply #3 on: February 23, 2013, 03:47:37 PM »

Thanks for responding so quickly guys.

Bald_Eagle,

The install was on the 23rd Jan, however it had ongoing issues.

The line had it's profile reset on the 19th Feb when the boost engineer came, installed new overhead cabling to the house and completed a lift and shift which had just been left by other engineer. So I'm guessing this is effectively the new install date, as all previous config/DLM stats would have been reset?

I have not resync'd since apart from this morning when I wanted to see if the sync speed would increase. Does the DLM process cause resync's?
I understand the DLM process needs to complete, so I will now leave it as you suggested for a week or so.

Interesting point regarding the Hlog graph, maybe not related but a TDR test showed a spike at around 60m, although this was not checked again after the overhead cable install. The engineer thought some of the issue may have been with the old underground cabling from the pole to my house, as we could not determine the entry point or even it's routing with in the house. Although I don't believe there could have possibly been 60m of cabling from pole to master socket, this has now been totally bypassed with the new cable straight to the master socket to which the modem is connected.

I will run some more snapshots over next few days.

I do understand the line length is the biggest limiting factor the speed of my connection, so I need to be realistic in my speed expectations.
However I want to ensure I get the best service possible that I'm a paying for, especially after the extremely poor overall customer experience I feel I have had so far from BT with myself chasing everything. Saying that a couple of engineers have been really great, going the extra mile to help out.

Black Sheep,

Interesting information about the JDSU as none of the engineers knew about that function, they all said it just wont sync under 15Mb.

My connection I believe is from the Braintree exchange EABNT cab P7.

The FTTC cab is located here https://maps.google.co.uk/maps?q=51.875859,0.513518&t=h&ie=UTF8&hl=en&view=map&ftid=0x47d8f1b7186fcd59:0x1a16bd8049cc3a5c&ftt=9&geocode=FTqQFwMd3dUHAA&split=0&sll=51.876200,0.516042&sspn=0.000653,0.005206&iwloc=A&ved=0CA8QpQY&sa=X&ei=H98oUfkfkdPxA47agNAG

Have also attached full stats to present from the 19th Feb and latest sanpshot

Thanks again guys.
« Last Edit: February 23, 2013, 03:50:16 PM by Crickers »
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 32378
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: FTTC long line 2.6km - Stats check after problems
« Reply #4 on: February 23, 2013, 07:09:06 PM »

Hello Crickers,

There is not a lot for me to say, as you have had replies from both the best data analyst and the best serving Openreach technician within the ranks of the Kitizens.

As Bald_Eagle1 has said there is, unfortunately, still a defect within your pair. I am, of course, referring to that spike (perhaps 'ringing' / oscillation) showing at around tone 180 (about 770 - 780 kHz) in the Hlog graph.

Just to clarify, was the spike at about 60 metres observed in the TDR trace before the new aerial feed was installed (replacing the old UG feed) and no TDR was subsequently performed on the newly provisioned drop-cable?

If that is the case, then the defect still present is somewhere from the pole-top DP outwards into the DP - PCP segment of the D-side.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Crickers

  • Member
  • **
  • Posts: 36
Re: FTTC long line 2.6km - Stats check after problems
« Reply #5 on: February 23, 2013, 07:26:00 PM »

Hi burakkucat,

Correct, totally forgot to ask the engineer to re-run the TDR after the UG cable was replaced with aerial.

One other question on stats collecting, are there any scripts to collect stats for linux?
I have a ubutnu server running 24/7 which uses far less power than leaving my windows pc on, although would still use pc for graphing.

Thanks
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 32378
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: FTTC long line 2.6km - Stats check after problems
« Reply #6 on: February 23, 2013, 10:58:11 PM »

Quote
One other question on stats collecting, are there any scripts to collect stats for linux?

Indeed, there is. As Baldy_Bird has previously mentioned, he is working on a utility for users of BGW, which has origins in some code that emanated from The Cattery.

If you would be happy compiling the code and creating a cron job to perform the scheduled sampling, then I can let you have a copy of the HG612_stats sources. That will then log the data into your /var/log/ directory and BE's original scripts should be able to produce the graphs.  :)

:hmm:  Thinking about it, I know that Mr Eagle has 'munged' the format of how the data is stored for his BGW code adoption, so before we go any further, perhaps we should 'whistle up' No-Feathers and see what he thinks will be the best way forward.  :-\
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: FTTC long line 2.6km - Stats check after problems
« Reply #7 on: February 24, 2013, 06:48:52 AM »

:hmm:  Thinking about it, I know that Mr Eagle has 'munged' the format of how the data is stored for his BGW code adoption, so before we go any further, perhaps we should 'whistle up' No-Feathers and see what he thinks will be the best way forward.  :-\

I am just adding the final touches to the code, ready for hopefully releasing the Windows version next weekend.

Although starting off as cross-platform compatible code, to get to the stage it's now at (manual or fully unattended logging/scheduled graphing/front end controlling GUI etc.) it has no doubt veered way off course in terms of Linux compatibility.

However, as the output logs are still plain space delimited text files (at the moment) it may be a reasonably simple matter to add the VDSL2 output format code to a version that still remains reasonably compatible.

Until the graphing elements have been added (for ongoing stats plotting) for Linux users, it would still be a case of graphing the output via a Windows system.

It has always been the intention to convert the code back to being compatible for use on Linux systems, once it's been fully tested and reliable.
I'm not the person with the knowledge of how to do that though.

So, in the short term I would stick with the Windows version when it's released.
Longer term, subject to sufficient interest, maybe you would fancy having a go at 'downgrading' the code for Linux users  ::)

The Windows programs MAY work in a Windows VM and/or by using Wine on a Linux box. That hasn't been fully tested.
They have been tested on Windows machines starting with XP Home Edition through to Windows 7 & related Home Server Editions.
Logged

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 40186
  • Penguins CAN fly
    • DSLstats
Re: FTTC long line 2.6km - Stats check after problems
« Reply #8 on: February 24, 2013, 07:42:11 AM »

[Humble mode]I hope you'll forgive me for mentioning an alternative means of collecting data on a Linux machine - rs-ux  (http://rsux.plainroad.me.uk ) [/Humble]
Logged
  Eric

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: FTTC long line 2.6km - Stats check after problems
« Reply #9 on: February 24, 2013, 08:28:42 AM »

[Humble mode]I hope you'll forgive me for mentioning an alternative means of collecting data on a Linux machine - rs-ux  (http://rsux.plainroad.me.uk ) [/Humble]

There's no need to be humble, Eric.

Your rs-ux program (& its partner rs-w for Windows) are excellent tools & the last time I checked, can run happily alongside my programs, as long as they are staggered by a few seconds - to avoid multiple attempts to access the modem's stats at the same time.

Our programs operate somewhat differently & are designed for slightly different purposes.
Together, they now seem to provide all the monitoring connection data & graphs necessary for general information purposes & for longer term trouble-shooting/fault reporting evidence (albeit mine are intentionally geared only for the HG612 modem - at the moment).

 
Logged

Crickers

  • Member
  • **
  • Posts: 36
Re: FTTC long line 2.6km - Stats check after problems
« Reply #10 on: February 24, 2013, 10:43:56 AM »

Thanks everyone for the replies about linux stats collecting.

I'm no linux programmer, compiling code would be about my limit I think.
My ubuntu server is headless so the aim to be to collect stats via linux then graph the data with windows.
Would be happy to help wherever I can though, windows or linux.

burakkucat, a copy of the HG612_stats sources would be great thanks.

roseway, thanks for link I'll check it out.

Bald_Eagle, I'm thinking if I can collect and format the output via linux, it should work with your existing and new graphing elements. Will also set up a windows VM and try that.

Have attached todays snapshot and ongoing stats.

One last question, the spike which is seen on the Hlog graph, is this something I should raise as a fault or just live with?
Logged

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2721
Re: FTTC long line 2.6km - Stats check after problems
« Reply #11 on: February 24, 2013, 12:40:51 PM »


Bald_Eagle, I'm thinking if I can collect and format the output via linux, it should work with your existing and new graphing elements. Will also set up a windows VM and try that.


If the new programs work reliably in VM, that would be the initial way to go as the Linux version doesn't yet calculate & store the error count differences between each one minute sample (unless burakkucat has been busy updating it), or create the output fileds in the logs in the same format as the Windows version.

However, once the Linux version produces ongoing & current logs in an identical format to the Windows version, they will indeed be able to be plotted using the Windows version.


Quote

One last question, the spike which is seen on the Hlog graph, is this something I should raise as a fault or just live with?


That's hard to say.
It certainly won't be helping matters, but on such a long line, who knows?

What were your estimated speeds pre-installation & have they now changed since your connection beaome live?
Logged

asbokid

  • Kitizen
  • ****
  • Posts: 1286
    • Hacking the 2Wire
Re: FTTC long line 2.6km - Stats check after problems
« Reply #12 on: February 24, 2013, 01:13:39 PM »

That's an interesting and unusual spike in the HLog (attenuation) graph.  It corresponds roughly to DMT#180.   It's actually a trough followed by a peak (or vice versa) which probably says more about its cause.
The QLN graph shows a moderate amount of frequency-specific noise, mostly in the AM broadcast radio band, but also at higher frequencies. There is RFI around the 7MHz range, which could correspond to the 40m ham radio band.   Is your line pole-strung for long distances, where it would act as an unwanted antenna for these signals?
The SNR graph is unusual, too.  Although you have an average SNR of some 6dB,  in practice, the SNRs on many DMTs are much higher, as high as 20dB or even 30dB.   The aggegrated SNR of 6dB masks that fact.
And yet Bit depth in Downstream band D1 - the most reliable downstream band for long-loops - is zero across DMT#120 - DMT#230 (approx). That's largely why your throughput is "pants".

A very unusual (and unwanted) set of characteristics!   As a rookie linesman, I would say it points to a line fault.  A time-domain reflectometer would soon reveal whether there's a bad joint, partial short from water ingress, etc..

cheers, a
« Last Edit: February 24, 2013, 01:41:04 PM by asbokid »
Logged

Crickers

  • Member
  • **
  • Posts: 36
Re: FTTC long line 2.6km - Stats check after problems
« Reply #13 on: February 24, 2013, 02:03:33 PM »

My pre-install speed estimate was 8.5Mb, checking http://www.dslchecker.bt.com today says upto 8.2Mb.

Have never seen over 6Mb, speed generally seems to be 5.0-5.7Mb over the last few days since the boost engineer visit.

I live in a rural location and can see line is pole-strung for at least 1.5km along the road, although I suspect it might be more.
Would RFI from ham radio be intermittent? i.e just during transmission?
Logged

asbokid

  • Kitizen
  • ****
  • Posts: 1286
    • Hacking the 2Wire
Re: FTTC long line 2.6km - Stats check after problems
« Reply #14 on: February 24, 2013, 03:04:44 PM »

How are the estimates calculated?  Possibly from Hlog. That is what is called "electrical loop length", not physical loop length.
The estimates can be quite wide of the mark.   BT estimates this ADSL2+ line can achieve just 5.5Mbps - 12Mbps. Yet there is a pleasant surprise:



True performance, albeit with a reduced SNRM of 3dB and with an LLU provider rather than with BT, is closer to 20Mbps:



cheers, a
Logged
Pages: [1] 2 3 ... 5