Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: mikeh on May 29, 2016, 08:39:31 AM
-
I've recently moved to FTTC with Plusnet after my long line 2mb ASDL connection was loosing sync with incoming calls and heavy showers. I had a SFI engineer fault finding for a day but in the end the stability was no better and a line swap increased the attn from 55db to 67db. I was still in contract with Plusnet but we agreed a new 2year fibre contract. My fibre estimates were as below with a distance about 1.8km from the cab.
The first fibre connection, with the Hub One synced at 15200 and was stable for 6 days. The weather was fine and there was just a 1db dip in the DS snrm when a phone call ended. Throughput was about 14mb. After a week the line was loosing sync more often about once a day and the line stats as below.
3. Firmware version:Software version 4.7.5.1.83.8.217.1.1 Last updated Unknown
4. Board version:Plusnet Hub One
5. DSL uptime:0 days, 17:26:16
6. Data rate:1229 / 14150
7. Maximum data rate:1229 / 14612
8. Noise margin:6.1 / 6.8
9. Line attenuation:10.2 / 32.1
10. Signal attenuation:10.2 / 26.9
Yesterday I tried a Billion 8800nl router and was surprised to see it sync at 20000 so a 6mb gain but with line stats showing a high CRC error rate. There was no interleaving applied. I checked this morning and I now have interleaving, the connection had re-synced earlier this morning.
Stats recorded 29 May 2016 08:32:02
DSLAM/MSAN type: BDCM:0xa48c / v0xa48c
Modem/router firmware: AnnexA version - A2pv6F039g1.d24m
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 1 hours 50 min 19 sec
Resyncs: 0 (since 29 May 2016 07:46:59)
Downstream Upstream
Line attenuation (dB): 30.9 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 21393 1165
SNR margin (dB): 6.9 6.6
Power (dBm): 10.8 10.5
Interleave depth: 8 1
INP: 43.00 0
G.INP: Enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
RSCorr/RS (%): 0.0715 0.0000
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0
Any thoughts on using the Billion as opposed to the Hub One? and just one more query on the Tones graph gap between 150 and 250. Does that indicate a fault on the line?
-
The tones dropping down is due to them not wanting to kill the ADSL signals so they cutback the signal on FTTC.
You have G.INP which results in the inteleave depth 8 but it doesn't introduce a significant delay, and is perfect for a line of your length.
Basically IMO line is looking great you might want to force a resync when the Noise margin is at 6.9 as it may get you a tiny bit more speed.
-
I wouldn't advise forcing a resync before you know what the error rates are. Continue to monitor the connection with DSLstats to accumulate some data for 24 hours or more, and then have a look at the CRCs and errored seconds. Without that information, you would be risking the stability of the connection if you tried squeezing a bit more out.
-
Thanks for your replies.
I don't need any more speed so I wouldn't be forcing a re-sync. I was just concerned the higher sync speed of the Billion would incur more errors, increase instability and make the DLM increase the TSNR etc as it used to do with ASDL. So far so good in daytime and good weather.
Since Link time = 3 hours 57 sec
FEC: 37724 0
CRC: 22 0
ES: 3 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
-
Welcome to the world of DLM on FTTC.
The intervention today was benign, turning on the latest error protection mechanism - retransmission aka G.INP.
Activation of retransmission also comes with very low levels of FEC protection and interleaving, giving your line 3 tools to help protect your data, but with a very small impact to bandwidth and latency. It is generally considered the best state for your line to be in.
That means the modem generates lots of stats while working, so it is worth following @roseway's recommendations.
The stats you give us in the latest post are fine. The FEC count is an indication that there is some noise on the line. The CRC count shows that between FEC, interleaving and retransmission, they are coping. DLM mostly cares about the ES rate - and 3 is low. Running at a few hundred per 24 hours will stay below thresholds.
The 8800NL likely did increase the error rate, but it also looks like it enabled G.INP activation - which is coping. A win-win.
-
On checking the telnet data this morning many errors have been recorded overnight but no re-syncs have occurred. The throughput is just under 19mb so that's good. I will see how things develop.
Total time = 23 hours 2 min 17 sec
FEC: 3837516 0
CRC: 6501 1
ES: 1840 1
SES: 31 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 2 min 17 sec
FEC: 194 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 1390 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 23 hours 2 min 17 sec
FEC: 3837516 0
CRC: 6501 1
ES: 1840 1
SES: 31 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
G.INP
Downstream Upstream
General
rtx_tx 191845 0
rtx_c 127288 0
rtx_uc 116542 0
LEFTRS 6888 0
minEFTR 21386 0
errFreeBits 26996968 0
Bearer 0
RxQueue 16 0
TxQueue 8 0
G.INP Framing 18 0
G.INP Lookback 8 0
RRC Bits 0 24
Interleave depth 8 1
INP 43.00 0.00
INPRein 0.00 0.00
Delay 0 0
Bearer 1
Interleave depth 1 0
INP 2.50 0.00
INPRein 2.50 0.00
Delay 0 0
[Moderator edited to wrap all statistics blocks in [code][/code] tags.]
-
Not very happy with your current 24 hour ES rate of 1840 are you sure G.INP is enabled on your line yes it shows all the stats that it is enabled but it's just not doing the job that it's supposed to :-\
-
Here are the latest stats from DSLstats and it shows G.INP enabled.
Stats recorded 31 May 2016 09:06:41
DSLAM/MSAN type: BDCM:0xa48c / v0xa48c
Modem/router firmware: AnnexA version - A2pv6F039g1.d24m
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 2 days 10 min 39 sec
Resyncs: 0 (since 31 May 2016 08:06:08)
Downstream Upstream
Line attenuation (dB): 30.9 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 21393 1165
SNR margin (dB): 6.9 7.0
Power (dBm): 10.8 10.5
Interleave depth: 8 1
INP: 43.00 0
G.INP: Enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
RSCorr/RS (%): 0.4255 0.0000
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 10.8 0
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. :)
Previous 1 day time = 24 hours 0 sec
FEC: 4217824 0
CRC: 9997 17
ES: 1928 18
SES: 86 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 2 0
Since Link time = 2 days 6 min 39 sec
FEC: 8094894 0
CRC: 16523 18
ES: 3771 19
SES: 117 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 2 0
[Moderator edited to wrap all statistics blocks with [code][/code] blocks.]
-
Yeah... That line is not in a good state...
Are you connected to the test socket and if so can you complete a line test (if you have not done so already)? Thanks.
-
If we take the line length of 1.8Km into consideration then I suppose it's doing the best it can, hopefully i'll get my hands on a 8800NL and see if the ES rate does increase on my line which is 1Km at the moment using a HG612
-
I'm not looking at any fault finding ATM just trying to understand more about how FTTC operates on my line. I am connected only by the master socket with no internal wiring. I am about 1.8km from the cab so my 19mb throughput is good though I am concerned more about stability and will see how the DLM will handle the errors.
I've started to look at the detailed info on this site so I'm picking up any relevant info about my particular circumstances. Interesting to read the HH5A suffers a downstream speed penalty with G.INP which matches what I have found with a 6mb gain in speed with the Billon 8800NL over the Plusnet Hub One. Now I'm reading about the DLM process.
-
I did read somewhere about a Billion 88ooNL syncing higher but with a higher error rate than an Openreach modem.
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. Any instability during inactive or dormant periods is ignored as the end-user will have been unlikely to have been affected by this." Brilliant :)
As the majority of the errors on my line occur between 9pm and 4am they should be ignored by the DLM because I only am online only in daytime and early evening. I will not be monitoring the line stats overnight now :no:
-
As the majority of the errors on my line occur between 9pm and 4am
The noise level must be increasing during those times as shown by the SNRm gradually lowering could be RFI and also some shine getting through as well with sudden dips of SNRm values.
Your sitting around the standard DLM profile which would be red at the moment you will on the Speed profile which allows up to 2880 ES per a 24 hour period
-
Thanks for that so if things stay as they are there should be no further DLM intervention as my daytime active use show a lot less ES.
Latest 1 day time = 9 hours 48 min 8 sec
FEC: 80422 0
CRC: 288 4
ES: 29 4
SES: 5 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
-
Mikeh the DLM as we know it works on a 24 hour period, it's the total errored seconds ranked up during that time if it's below 2880 then no DLM intervention ;)
-
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.
-
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.
-
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.
-
The other graphs.
-
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 :-\
-
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
-
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. :)
-
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
-
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?
~ 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.]
-
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.
-
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.
-
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