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]

Author Topic: Observations moving from poor ASDL to FTTC  (Read 7298 times)

mikeh

  • Member
  • **
  • Posts: 70
Re: Observations moving from poor ASDL to FTTC
« Reply #15 on: June 01, 2016, 08:48:37 AM »

The errored seconds for the last 24hrs were about 1200 but I reset the Billion router stats not realising it would reset the telnet data so cannot post them. Anyway It's below 2880 and the DLM hasn't intervened since it enabled G.INP and the connection hasn't dropped after 3 days. So changing from the Hub One to the 8800NL has improved the speed and the stability  :)

Only adverse weather conditions left to test. 
Logged

WWWombat

  • Kitizen
  • ****
  • Posts: 1674
Re: Observations moving from poor ASDL to FTTC
« Reply #16 on: June 01, 2016, 05:58:02 PM »

I had a laptop running DSLstats overnight showing the errors and snrm. The errors increase about 9pm and tail off about 4am. The connection has held. On ASDL the connection would drop at the start of incoming phone calls and during heavy showers where as with the fibre there is a 2db noise margin drop at the end of a call. Still a massive improvement as far as speed goes over the 2mb ASDL. :)

Definitely an improvement.

I'm also concerned about the ES count reaching as high as 2,000 in a 24 hour period. It won't take much of an extra "blip" for DLM to think that something further is needed.

On the positive side, DLM has only put an INP value of 43 in place so far. I suspect that, if it thinks you need it, it will change this value to something higher - we've seen it reach into the low 50's.

If we take the line length of 1.8Km into consideration then I suppose it's doing the best it can

It is doing surprisingly well for that distance. There must be a good portion of thicker copper involved in this connection...

I did read somewhere about a Billion 88ooNL syncing higher but with a higher error rate than an Openreach modem.

I was helping a guy on the TBB forums a week ago with an issue like this; the 8800NL gave better sync speeds, but a much worse error rate. He currently has an HG612 in place, which syncs at a lower speed, but gives him much fewer errors (including the all-important ES rate).

In that case, the high error rate was originally masked by the fact that G.INP was activated before the noise started. It only became apparent when the user swapped to a new ISP, which triggered a DLM reset.

After the reset, DLM *really* didn't like the errors, and put "old-style" intervention in place instead of G.INP retransmission; presumably it thought G.INP wouldn't cope. Once he put the HG612 in place, errors reduced, DLM relented its intervention, and then allowed retransmission to be re-activated. All is pretty quiet at present.

His stats can be seen on MyDslWebStats, where he has accumulated over a year of data. I've attached one snapshot as an example, where you can see the errors start up in November, and the switch of ISP near the end of April.

From the glimpses of graphs, your line isn't suffering anywhere near as badly. It would be good to see the graphs for rtx_tx, rtx_c and rtx_uc alongside the CRC and FEC graphs, as those should demonstrate the same kind of pattern.

One thing which I've just read in ~ Data Analysis [Step 1]

"Each of the 96 bins are checked to see if there has been user activity and marked active or dormant."

That's interesting. I'm not sure how much of an effect this has, but we will find out one day...

The errored seconds for the last 24hrs were about 1200 but I reset the Billion router stats not realising it would reset the telnet data so cannot post them. Anyway It's below 2880 and the DLM hasn't intervened since it enabled G.INP and the connection hasn't dropped after 3 days. So changing from the Hub One to the 8800NL has improved the speed and the stability  :)

As I said above, I'm still worried that it won't take much of a nasty day to send your stats over the edge.

If you resync the line at a time of day when your SNRM is at its lowest (any time between 11pm and 3am looks OK), then you'll likely sync at a slightly lower speed but will probably get fewer errors.

If the error rate looks like it is increasing too much, remember that you have this tool in your arsenal. However, I suspect DLM might try increasing the INP value before attempting anything more drastic.
Logged

mikeh

  • Member
  • **
  • Posts: 70
Re: Observations moving from poor ASDL to FTTC
« Reply #17 on: June 02, 2016, 08:48:54 AM »

I am expecting some things to happen when the weather gets unsettled again. If it does re-sync lower I will leave it as is as my needs could be managed with a decent 3mb+ asdl service which I didn't have. The extra speed is handy though for the odd big file updates etc.

As far as the line goes I have a fairly unique situation. It is all rural from the cab with just a B&B business with 4 lines and a farm with 2 lines before it goes to a very small village my line diverts down a 1km lane to our property alone, before the village. It does however come over a rail crossing next to the property, which had new poles installed 5 years ago. The fault engineer did say the newer cable was thinner than the older cable it was joined to.
 
Errors not too bad now.
Total time = 1 days 8 min 2 sec
FEC:            3323884         0
CRC:            984             1
ES:             360             1
SES:            5               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0   

I just have one query regarding the dips in snrm when the phone ends is this OK?
I did record the graphs as there were 2 short calls and it shows how the G.INP reacts to the errors. I'm not concerned about fault finding, just curious, as you say this line is doing very well for its' length.
 
Logged

mikeh

  • Member
  • **
  • Posts: 70
Re: Observations moving from poor ASDL to FTTC
« Reply #18 on: June 02, 2016, 08:50:11 AM »

The other graphs.
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: Observations moving from poor ASDL to FTTC
« Reply #19 on: June 02, 2016, 07:52:45 PM »

Thanks for the graphs mikeh G.INP is definately working very hard on your line the graph showing RTX_UC uncorrected errors I would like to see.

Now its very common on longer lines to see RTX_UC errors like my own line gets 23 on a good day (see my graph below) and your line is 0.8Km longer than mine is that reason or have you some other issues  :-\

« Last Edit: June 02, 2016, 07:56:28 PM by NewtronStar »
Logged

mikeh

  • Member
  • **
  • Posts: 70
Re: Observations moving from poor ASDL to FTTC
« Reply #20 on: June 03, 2016, 07:22:54 AM »

Thanks for all the interest and help with my FTTC queries. I've learned much this week and will try to sum it up as follows.

Moving to FTTC has not only improved the speed but also the stability with G.INP enabled. My line is working very well for its length but the higher sync speeds generate more errors which the G.INP is coping with at the moment. There is more noise on the line overnight but as I'm not online at theses times  any instability is ignored by the DLM because the user activity is recorded as dormant. I'm happy to continue using the 8800NL as my connection is still holding after 5 days.

I've got into the habit of checking the line status every time I go online.

Cheers

Mike

 
Logged

William Grimsley

  • Kitizen
  • ****
  • Posts: 1489
    • Newton Poppleford Weather
Re: Observations moving from poor ASDL to FTTC
« Reply #21 on: June 03, 2016, 08:46:12 AM »

There is more noise on the line overnight but as I'm not online at theses times  any instability is ignored by the DLM because the user activity is recorded as dormant.

Sorry Mike, but that's not correct. DLM will make changes to your line whether or not there is bandwidth being used on the connection. DLM and bandwidth are very different things. :)
Logged

PhilipD

  • Reg Member
  • ***
  • Posts: 591
Re: Observations moving from poor ASDL to FTTC
« Reply #22 on: June 03, 2016, 10:08:33 AM »

Hi

As I understand it, xDSL runs like a scheduled train service, even if their are no passengers, the trains still run with empty carriages, and xDSL is the same but using ATM cells.  The vast majority of the time it is just empty ATM cells going backwards and forwards, but these cells are still error checked etc before looking into to so if they are empty or not, and statistics are recorded.

It is something like 70,000 or more ATM cells a second being transferred depending on line speed, so in 24 hours of your stats, you had 3323884 FEC errors (these were errors that were corrected).  In 24 hours you had a total of 6,048,000,000 ATM packets transferred, so overall your percentage FEC correction rate is 0.05%, this is absolutely fine, and xDSL is designed to run with errors, it's one way they pack so much data down decades old telephone cable, by not being too precious about errors. 

These errors were corrected, so no data was lost if those cells happened to be carrying any data, and even if data is lost, your devices higher up detect this and request the data again, or G.Inp if your line has it, requests the packets again at a much lower level which is more efficient.

So given the huge numbers of cells transferred, you can see how errors reported in the stats can become very big numbers in little time and look quite alarming, but in context to the total numbers involved, they aren't that big at all.

Regards

Phil

Logged

mikeh

  • Member
  • **
  • Posts: 70
Re: Observations moving from poor ASDL to FTTC
« Reply #23 on: June 03, 2016, 10:24:43 AM »

Just to clear things up, what I said about ignoring instability during periods of user inactivity was my interpretation of the section of Data Analysis found in the DLM Process section on this site. I don't know how to do a quote so I'll just paste it below. It may just refer to a re-sync event?

Quote
~ Data Analysis [Step 1]

Each of the 96 bins are checked to see if there has been user activity and marked active or dormant. Any instability during inactive or dormant periods is ignored as the end-user will have been unlikely to have been affected by this.

Uptime is calculated from the active bins and any data indicative of instability during these periods is normalised.

Errors and resyncs are normalised to the uptime.  This is calculated by dividing the total time in seconds which the respective line has been in synchronisation and in active use over the past 24 hour period of the monitoring by the number of re-trains or errors recorded in that period.  The two algorithms used are:

    MTBE (Mean Time Between Errors) = Connection uptime / Code Violations (Errors)
    MTBR (Mean Time Between Retrains) = Connection uptime / No of retrains

This step is done by the element manager with data obtained from the Data Collectors and the information passed to the Management Device RAMBo each day.

As well as MTBE & MTBR line data, the element manager also produces an event data file which is used to monitor for Wide Area Events and forced retrains.  This event data is recorded as an array of each 15 min period in binary format [Uptime, Retrains, Errors]. For example a line which has uptime and errors but no retrains will record [1,0,1].

Quotation taken from http://www.kitz.co.uk/adsl/DLM.htm#dlm_data_analysis

[Moderator edited to insert the URL for the quotation, above, and to wrap the quotation in [quote][/quote] tags.]
« Last Edit: June 03, 2016, 03:50:57 PM by burakkucat »
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: Observations moving from poor ASDL to FTTC
« Reply #24 on: June 03, 2016, 02:26:48 PM »

my experience with the 3 devices are as follows.

hg612 lowest error rate but also lowest sync.
8800nl about 30% more errors than the hg612 with a sync about 1-1.5mbit/sec higher
zyxel about 200-300% the error rate of the hg612 but syncs about 3mbit/sec higher.

My advice, only use one of the optional devices if your line can still be ok with the extra ES, e.g. no visible affect and no DLM intervention, if either occurs go for the more stable modem.
Logged

mikeh

  • Member
  • **
  • Posts: 70
Re: Observations moving from poor ASDL to FTTC
« Reply #25 on: June 03, 2016, 04:51:45 PM »

Thanks I've noted your advice. The only alternative modem I have is the Plusnet Hub One which despite syncing 6mb lower around 14mb was loosing connection just about once a day so I decided to try the 8800NL to check the line error rates.

I will continue to monitor the connection which is still holding sync after 5 days. If needed I will get a HG612.
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: Observations moving from poor ASDL to FTTC
« Reply #26 on: June 03, 2016, 05:39:44 PM »

Cheers Chry for the 8800NL 30% extra ES info was not sure how much extra would be added when migrating from HG612 to Billion 8800NL
Logged
Pages: 1 [2]