Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: adslmax on September 26, 2014, 05:53:24 PM
-
The speed is unbelieved struggle when DLM was hit on my line yesterday. Today is much worsen. Does DLM on training period?
DLM making worse on my line now. Not happy at all.
http://www.thinkbroadband.com/speedtest/button/141175364343270749649.png
http://www.speedtest.net/my-result/3789458215
-
That TBB result doesnt look like DLM to me. More like congestion of some sort.
-
Look like my exchange got hit by congestion now! :( :-[ Are BT trying to make me slow and punishment me?
-
Are BT trying to make me slow and punishment me?
N0 it's more like a backhaul issue on the BT backbone, what I would do is check BT Website's database with your telephone number to see if your area is being effected with BroadBand issues.
-
I know that Max is connected via the Cuckoo Oak (WNCKO) exchange . . . ;)
So what would be an appropriate site to check for Beattie's problems?
-
This one's good
https://www.bt.com/consumerFaultTracking/public/faults/tracking.do?pageId=2&s_cid=con_FURL_faults&utm_source=ATL&utm_medium=FURL&utm_content=R&utm_campaign=faults (https://www.bt.com/consumerFaultTracking/public/faults/tracking.do?pageId=2&s_cid=con_FURL_faults&utm_source=ATL&utm_medium=FURL&utm_content=R&utm_campaign=faults)
this is better https://www.bt.com/consumerFaultTracking/public/faults/tracking.do?pageId=31 (https://www.bt.com/consumerFaultTracking/public/faults/tracking.do?pageId=31)
-
Ah, thank you. :)
Actually that link can be reduced in length and complexity --
https://www.bt.com/consumerFaultTracking/
-
Pointless as these only work if your phone line are with BT. If your phone line are with Plusnet. U cannot use it because of no account number to enter to check further details. Useless BT hidden it.
-
Pointless as these only work if your phone line are with BT. If your phone line are with Plusnet. U cannot use it because of no account number to enter to check further details. Useless BT hidden it.
In that case MAX you should of said "Are Plusnet trying to make me slow and punishment me? ;)
-
The congestion could either be at the exchange.. or at Plusnet.
We know that PN atm are having some issues with the BGNs so it could even be there. However in fairness the line on that graph doesnt quite look look what Id expect to see if it was PN. The ellacoyas are a bit cleverer than that... as you can bet your life that the TBB speedtester would be given priority. How are things now.
U cannot use it because of no account number to enter to check further details
Yes youre correct, it will only work if BT Retail is your phone provider. It wont work if youre with any of the other SPs.
-
my speed seem fine
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F14121258354965296029-mini.png&hash=7ba5fcd99c359fc24813fac7589bf3a83ce767da) (http://http:http://www.thinkbroadband.com/speedtest/results.html?id=14121258354965296029)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F3799627876.png&hash=388a4aaed038fc13145397f83f0f4da8d47b2251) (http://www.speedtest.net/my-result/3799627876)
-
Yep looks good now..
Hmmm I just had another thought.. BT have been undertaking a load of re-routing over the last couple of weeks. The end results have been good because Ive noticed my latency is better since theyve been doing this. But there have been warnings that things may be odd during the period 23-26 sept from the various 21CN nodes.. although I would have expected that to be night and not early eve.
I really dont know though what it could have been for sure or where the problem was. The main thing is that all is good now :)
-
The only congestion I had when BT DLM was on my line, the speed is awful all over the place but when DLM removed interleaving and my speed is spot on since. No problem with it all day.
Here is my latest stats:
=~=~=~=~=~=~=~=~=~=~=~= Plink log 2014.10.01 01:27:46 =~=~=~=~=~=~=~=~=~=~=~=
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 35346 Kbps, Downstream rate = 100016 Kbps
Path: 0, Upstream rate = 19999 Kbps, Downstream rate = 79999 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 11.5 22.8
Attn(dB): 0.0 0.0
Pwr(dBm): 12.6 0.0
VDSL2 framing
Path 0
B: 239 237
M: 1 1
T: 23 42
R: 0 16
S: 0.0955 0.3781
L: 20107 5374
D: 1 1
I: 240 127
N: 240 254
Counters
Path 0
OHF: 205767113 1190560
OHFErr: 82 80
RS: 0 186643
RSCorr: 0 979
RSUnCorr: 0 0
Path 0
HEC: 91 0
OCD: 0 0
LCD: 0 0
Total Cells: 783967586 0
Data Cells: 323007552 0
Drop Cells: 0
Bit Errors: 0 0
ES: 60 71
SES: 5 0
UAS: 33 33
AS: 340269
Path 0
INP: 0.00 0.00
PER: 1.64 3.97
delay: 0.00 0.00
OR: 116.56 64.47
Bitswap: 11 255
Total time = 1 days 14 hours 27 min 21 sec
FEC: 0 0
CRC: 82 0
ES: 60 71
SES: 5 0
UAS: 33 33
LOS: 5 0
LOF: 5 0
Latest 15 minutes time = 12 min 21 sec
FEC: 0 0
CRC: 1 0
ES: 1 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 14 hours 27 min 21 sec
FEC: 0 0
CRC: 17 0
ES: 10 11
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 0
CRC: 13 0
ES: 11 23
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Since Link time = 3 days 22 hours 31 min 9 sec
FEC: 0 979
CRC: 82 80
ES: 54 67
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 35346 Kbps, Downstream rate = 100016 Kbps
Path: 0, Upstream rate = 19999 Kbps, Downstream rate = 79999 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3971)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3971)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 35346 kbps 100016 kbps
Actual Aggregate Tx Power: 0.0 dBm 12.6 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 2.4 13.3 20.1 N/A 6.8 15.9 24.9
Signal Attenuation(dB): 2.4 12.4 19.1 N/A 6.8 15.9 24.9
SNR Margin(dB): 22.8 23.0 22.7 N/A 11.6 11.5 11.5
TX Power(dBm): -15.2 -30.7 -0.1 N/A 8.4 7.9 6.9
xdslcmd info --Bits
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 35346 Kbps, Downstream rate = 100016 Kbps
Path: 0, Upstream rate = 19999 Kbps, Downstream rate = 79999 Kbps
[attachment deleted by admin]
-
Are these look good or bad?
-
It may not be relevant as you do achieve the full 80/20 sync speeds, but it appears you are still using non-updated modem firmware (or that the update process didn't fully complete).
The updated version does appear to make better use of the bitloading tones & generally more bitswapping when some tones 'struggle' which means that more tones can be used rather than being marked as unusable.
Which version is reported in the pbParams chart shown in the montage of all the snapshot graphs?
It should also be reported at the bottom of Plink logs.
-
regarding congestion since last week or 2 there has been an increase which is either BTw or plusnet side.
I had yet another ppp drop last night so am on a different gateway and will find out tonight if I am congested again.
-
Plusnet have major issues still with the load balancing (amongst other things) of the new bgn's.
Its that much of an issue BT's network people are now lead. :o
-
Plusnet have major issues still with the load balancing (amongst other things) of the new bgn's.
Its that much of an issue BT's network people are now lead. :o
yeah and this came in earlier :(
Service: Broadband
Posted: Wed, Oct 01 2014 at 16:38:21
Subject: Emergency Broadband Network Maintenance - Wed 1st October 4.30pm - 6.00pm
-
some info here backing up the DLM using ES and it does match exactly to the 2880/day theory.
http://support.zen.co.uk/kb/KnowledgebaseArticle.aspx?articleid=11511
-
That's a very helpful one.
-
I don't get this part as it does not specify what type of error they are talking about is it CRC's ES or SES
The additional thresholds are:
Standard – allowing no more than 10 drops in a 24 hour period and no more than 1 error every minute.
Stable – allowing no more than 5 drops in a 24 hour period and no more than 1 error every 2 minutes.
-
You're right, it isn't clear. "One error" seems to imply one CRC, but I think it probably means one ES.
-
on a SES the ES also tallies, it will be talking about ES.
-
I find some aspects of this very odd, the standard ZEN connection is
"Zen Internet provides our Fibre Optic Broadband (FTTC) services on the “Speed” option. A connection should drop no more than 20 times in a 24 hour period, and should error no more than 2 times per minute."
This would mean that a resync would in effect only be noticed via the error count. Unless you have 20+ a day of course! However a line error caused resync event is what most would regard as the one event that the DLM really needs to avoid happening.
If they are intended to spot resyncs caused by errors, then I am not sure of the errors. 120 ses or es an hour can easily conceal a resync event whilst 2 per min is common. 120 CRC/hour (2/min) is possible but it does seem too strict. On the other hand I think it really is a big CRC event that is more associated with a resync than a big es and ses.
I have to say I feel as though were only being given a general idea and not the much needed detail that you need to make some value judgments.
-
I think resyncs are counted separately. The modem issues a "dying gasp" so DLM can tell the difference between a loss of power and a loss of sync.
-
"A connection should drop no more than 20 times in a 24 hour period"
If so which drops are you allowed 20 of?
-
I think that is 20 resyncs.
-
les you have lost me.
Of course they can detect resyncs :)
LOS UAS or they must log every new sync event and count that as a resync.
-
Sorry to loose you. When I said "This would mean that a resync would in effect only be noticed via the error count. Unless you have 20+ a day of course! " I am assuming that the resyncs are counted but that your allowed 20 a day. To me 20 day is like not really counting them. If I lost conection 5 times a day i would regard that as dreadful. I would go nuts before 20 a day!
-
yeah its leniant but remember it is the speed(standard) profile not stable.
yet some still get caught out by it which is odd, power cut, swapping modem then hit by DLM.
-
i guess thats why it is like that. If any of this is true then I still suspect that the DLM must hope to pick up real los and resync events via the "errors" that are counted. As N* said not telling us which sort of error is counted is far from helpful. i noticed when doing some severe things to my line that ES and SES are just not adequate to detect a resync. You need to also look at los lof and usually a really massive CRC. Whilst the ZEN statement is helpful re days to react but the rest is close to useless without these details.
-
To me, its quite simple. Errors are counted as ES and resyncs are counted as resyncs.
-
I am sure that resyncs are counted as just that but you can't be sure what the error measure is. ES seems a guess to me.
-
I think theres evidence that 2880 ES in 24hours will cause DLM to take action.
-
On the point about what constitutes "an error" in these discussions, I agree that it is the ES counter that is used.
A few years ago, I saw the same kind of thresholds as they applied to 21CN ADSL2+ (attached). However, in that picture, the threshold was termed "MTBE" (mean time between errors), and was set (on the speediest/least-stable option):
DLM intervened when MTBE was less than 60 seconds
DLM de-intervened when MTBE was greater than 600 seconds
DLM stayed put if MTBE was between these values.
An "MTBE of 60 seconds or less" is equivalent to the Zen page stating "no more than one error per minute".
When you look at the error thresholds in terms of "time between errors", you can see how the increments in ES are best used toward calculating the MTBE (by inverting), rather than using increments in the CRC counter.
Note that the BTW 21CN error thresholds are altered 10x between service options, but the Openreach GEA error thresholds only change by 2x.
Note too that the resyncs are handled on 21CN as MTBR.
-
yep openreach/BTw work on MTBE aka ES. I even seen a test result posted by plusnet staff yesterday showing MTBE stats.
-
I think that is 20 resyncs.
That's misleading. Because My DLM was hit after resync 3 times or 4 times. Not 20 times!
-
Standard maps to speed
Stable maps to standard
Super Stable maps to stable
for openreach FTTC
-
I think resyncs are counted separately. The modem issues a "dying gasp" so DLM can tell the difference between a loss of power and a loss of sync.
Whilst modems may issue a dying gasp, the evidence is that BToR would appear to ignore this.. instead using the 15 min cycle... which is why we always recommend if possible to leave the router powered down for >30mins, so the DLM sees at least one complete cycle without the router attempting to resync.
That's misleading. Because My DLM was hit after resync 3 times or 4 times. Not 20 times!
I agree.. theres way too many people that have been hit much sooner. iirc TT quote 5th resync will cause DLM interaction for FTTC
-
On the point about what constitutes "an error" in these discussions, I agree that it is the ES counter that is used.
A few years ago, I saw the same kind of thresholds as they applied to 21CN ADSL2+ (attached). However, in that picture, the threshold was termed "MTBE" (mean time between errors), and was set (on the speediest/least-stable option):
DLM intervened when MTBE was less than 60 seconds
/snip/
Note too that the resyncs are handled on 21CN as MTBR.
Last year we had a major discussion on here re the DLM and I started to put some notes together on what information we could find.
Ummm I kind of forgot about it.. and its been in its unaltered state now for months... waiting for me to find some time to research further and add some more info to it. I must stress that this is the draft form which has been sat around for ages waiting to be finished :-[ But the content so far was checked by one of the guys from PN who confirmed content as valid.
I dont want to publish it properly because its not finished and probably has typos and needs much more work .. but your welcome to look see at what info I do have so far
http://www.kitz.co.uk/adsl/DLM.htm
PS.. Im also of the opinion that it will be E/S
-
I agree.. theres way too many people that have been hit much sooner. iirc TT quote 5th resync will cause DLM interaction for FTTC
Is that because TT provision on the Stable profile?
-
One thing is regardless of which ISP we the end user really can't be 100% sure which DLM profile our connections are actually provisioned on, All we know is what info we are told be some ISP's ,But there's no evidence to back this up,
Do ISP's have any visibility within the BT wholesale systems of which DLM profile is in use for each connection ? or is it a case of them ordering with a certain dlm profile and assuming that this order has been correctly applied?
As with the exception of tt and sky who don't use BTwholesale and Zen who has it's own GEA cable links as well as buying from BTwholesale
They would i assume have visibility for connections that used their own GEA cable links, and be able to change the dlm profile as required
-
Yes I know that PlusNet have access to BT Wholesale site and hence the users profile data.
I have just transferred my Fibre to PlusNet and as part of the process the following
service event information was placed in my control panel
Provisioning of your ADSL Account Information
Install diary status changed from Realm configured to Awaiting submission to the DSL supplier
Automatically set supplier product to WBC FTTC Annex A 20Mbit/s Up, 80Mbit/s Down, Standard Stability
Showing that PlusNet use the FTTC wholesale Standard profile which is Openreach Speed profile for accounts
-
"A connection should drop no more than 20 times in a 24 hour period"
If so which drops are you allowed 20 of?
Its says 20 drops in a 24 hour period thats ok that works out at under 1 drop per hour close to what B*CAT has said in many posts the 30 minute wait.
Though if I did 10 drops in one hour the DLM would take action even though the remaining 23 hours saw no drops, very confused
-
DLM are indeed very confused and no ones will know when it will hit u!
-
DLM are indeed very confused and no ones will know when it will hit u!
It's more like ZEN has been misinformed on how the VDSL DLM works in real life situations rather than a clinical laboratory test ;)
-
What if you're on the Standard profile?
-
Plusnet staff say very soon that BT Openreach will let the isp's have their own control over DLM on their network system soon rather than control by the exchange itself.
-
Plusnet staff say very soon that BT Openreach will let the isp's have their own control over DLM on their network system soon rather than control by the exchange itself.
I hope not as when I think back to TalkTalk forums LLU ADSL/2 the ISP was able to control the SNRM and you would see a customer asking for a lower profile and this was granted and then 4 days down the line the DLM then took control because the customers line could not cope
That's real confusion :(
-
note during my last days on the dodgy pair, I had 8 drops in one hour and no interleaving.
As I said before if you swapping in a modem, and have it plugged in whilst configuring you are probably doing more sync attempts than realising. Also power cuts I guess play havoc somehow.
With my 700 ES in current 24 hour period and 6k CRC errors I shouldnt see interleaving tomorrow but will see.
-
Last year we had a major discussion on here re the DLM and I started to put some notes together on what information we could find.
Ummm I kind of forgot about it.. and its been in its unaltered state now for months... waiting for me to find some time to research further and add some more info to it. I must stress that this is the draft form which has been sat around for ages waiting to be finished :-[ But the content so far was checked by one of the guys from PN who confirmed content as valid.
I dont want to publish it properly because its not finished and probably has typos and needs much more work .. but your welcome to look see at what info I do have so far
http://www.kitz.co.uk/adsl/DLM.htm
Interesting, and I'll have to take a look... but perhaps not yet. I'm moving Friday, and still have sooooo much packing still to do - if you give me something interesting to read, I'll never finish!
-
Good luck with your move and I hope it all goes smoothly for you. I trust that before you placed an offer , you checked out the broadband availability of your new premises :D
-
With my 700 ES in current 24 hour period and 6k CRC errors I shouldnt see interleaving tomorrow but will see.
Those were the regular stats on my line for months on end, with no sign of DLM.
-
DLM and it's error rate thresholds are too low, and this 14 days or longer to re instate fast path and previous sync rate following the occasional burst of noise is way over the top and benefits no one other than BT IMO, The reason why dlm borked my connection i suspect a new line fault, as i have heard some clicking /popping noises during some of the QLT that i have performed, as well as the faint hum that has always been audible ,becoming more pronounced at times , But the last time i attempted to get bt to investigate the hum, i got a £130 bill as the engineer had a selective deafness disorder IMO,
-
Can anyone tell me why is upstream still interleaving even thought Interleave depth showing 1 on both downstream and upsteam but the RSCorr/RS (%) RSUnCorr/RS (%) still on the upstream 0.0509 while not available on downstream?
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 54 min 9 sec
Resyncs: 0 (since 09 Oct 2014 14:51:09)
Downstream Upstream
Line attenuation (dB): 0.0 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 79999 19999
SNR margin (dB): 9.7 15.1
Power (dBm): 12.4 0.7
Interleave depth: 1 1
INP: 0 0
RSCorr/RS (%): N/A 0.0509
RSUnCorr/RS (%): N/A 0.0000
ES/hour: 0 0
-
Upstream isn't interleaving. What you're seeing is a low level of FECs (RSCorr). It's possible to have FECs without interleaving.
-
Am I right DLM only looking at downstream ES/hour nothing else?
so far after one hour 11 minutes
Since Link time = 1 hours 11 min 11 sec
FEC: 0 6
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
-
I can confirm I am still on fast path after yesterday with 800 ES and almost 7k CRC, big relief its ES not CRC used :)
-
Since Link time = 6 hours 1 min 11 sec
FEC: 0 91
CRC: 4 2
ES: 3 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
3 ES and 4 CRC in 6 hours
-
yes we know you have an immaculate line max, how you ended up DLM'd I dont know :)
-
yes we know you have an immaculate line max, how you ended up DLM'd I dont know :)
Beat me, I dunno why! Stupid of DLM. I think it probably the work of openreach at my cabinet this week. I walk pass saw three openreach engineers work on the FTTC cabinet.
-
yes we know you have an immaculate line max, how you ended up DLM'd I dont know :)
His ErrSecs were extremely low so its not that. The only thing I can think is there were 5 definite re-syncs showing on the RADIUS report that PN produced for him.
There were also a couple of very quick d/cs from the PN RADIUS - so quick you could hardly spot them - but max said they were just PPP reconnects whilst he was gateway hopping and he didnt do a full resync for those.
-
It was PPP reconnect to different gateway (these shouldn't affect DLM) as I have done it many times from February until few weeks ago then DLM went BANG on my line. But, when I saw openreach engineers working on my cabinet - it probably the reason for this:
Last February my FTTC is maximum rate of 113136k / 38700 with snr of 15.1 / 23.2
Current now my FTTC is maximum rate of 93260k / 33562k with snr of 9.7 / 15.0 (possibility engineer work on cabinet cause this?)
Latest stats:
Since Link time = 7 hours 5 min 11 sec
FEC: 0 99
CRC: 7 4
ES: 6 4
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
-
The reduction in headline speed is more likely to be crosstalk.
Engineer was probably just adding another fttc line. Theres plenty of discussions about crosstalk on here
-
How far can downstream snr lower to for FTTC? I think it could be 6 and that's it. Can't go lower than that.
I think if it went down to 6 on snr (downstream) then maximum line rate could fall around 82000k, so I guess my 79999k will not be affecting?
-
max when you next see engineer tell him he not allowed to install new line :)
-
max when you next see engineer tell him he not allowed to install new line :)
No, I tell him to give me the cabinet key. So I will removed all 287 lines except my line!
-
I found the table of crosstalk. This one is 200m away from the Cabinet:
[attachment deleted by admin]
-
wow thats almost as brutal as my crosstalk got.
-
Ive lost a fair bit too although I didnt keep track of the days. I'd just pulled out one of my early stats for another post and noted I started off at
Max: Upstream rate = 35019 Kbps, Downstream rate = 107076 Kbps
Im now at
Max: Upstream rate = 30455 Kbps, Downstream rate = 88730 Kbps
So thats 18346.. then I have to add on 3.5Mb for the increase the Zyxel gave me... so my crosstalk loss is now running at circa 22Mbps
-
Interesting stuff. I am glad I kept my record of FTTC when first activated a week after my FTTC cabinet went live. Openreach Engineer told me I am the first person to have it connected. So, 113 / 38 Meg is about right for my 200m away from cabinet.
I wish BT Openreach hurry up bring out vectoring nationwide (I hope next year) ?
-
Bingo!
I know why the ES and CRC errors coming from....it was the kitchen long tubing light burst errors on FTTC. Every time I switch on, it will count 2 on ES and 4 on CRC.
Does any of you try this and see if I was right. I switch the light on after 11:30pm and I check with FTTC error and it spark a burst of error. So it was kitchen lighting cause it.
Latest 15 minutes time = 14 min 58 sec
FEC: 0 0
CRC: 19 0
ES: 10 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
[attachment deleted by admin]
[attachment deleted by admin]
-
Shall you get a new tube and starter?
-
I feel sorry for you guys/girls with crosstalk issues especially the users who have an attainable sync higher than Infinity 2 can provide ;)
-
kitchen lighting turned off. No ES / CRC error for 10 minutes now
-
Shall you get a new tube and starter?
he would maybe better off with a new light fitting as the emi will be most likely from the ballast, and not the tube ect,
better still replace the strip light with a different type of light fixing , If that is what only one can do, imagine what 20 of them would do , i know all too well, and the lights were not in my home, but a neighbouring property, the joys of the twisted pair copper ug cable bundles Especially if whatever is causing the emi is in close proximity to an internal extension , or the NTE is sited next to the electricity meter and incoming mains cable
-
Such a small number of errors is really of no significance at all. There's nothing that needs to be to be done.
-
Before:
Since Link time = 7 hours 5 min 11 sec
FEC: 0 99
CRC: 7 4
ES: 6 4
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Now:
Since Link time = 9 hours 28 min 31 sec
FEC: 0 63
CRC: 2 1
ES: 2 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Massive different of not using fluorescent lighting but my biggest fearsome is xmas tree flashing lights in all neighbours in December. Going to kept an eyes on it.
-
That's not a 'massive' difference. FECs are irrelevant, and the numbers of CRC and ES are tiny.
You're right about Christmas lights though, they can cause big trouble.
-
Latest stat from openreach modem as tomorrow I am going to try Billion 8800NL but I must remember to powered down for at least 32 minutes to be safeguard against DLM. I just wait for 24 hours completed on openreach modem, so I can keep on my record to compare Billion 8800NL later this weekend.
Since Link time = 17 hours 12 min 29 sec
FEC: 0 177
CRC: 6 3
ES: 6 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
It look like my cabinet is now under crosstalk see image below:
-
also make sure its preconfigured right, so it isnt retrying again and again with invalid settings.
-
also make sure its preconfigured right, so it isnt retrying again and again with invalid settings.
I forget the setting preconfigured for Billion 8800NL for VDSL2 setting. Don't mind post me screenshot so I will do it now on other pc but it won't be connected to DSL line until tomorrow.
22 hours ongoing stats from openreach modem. Much much better as I had removed fluorescent lighting driver.
Since Link time = 22 hours 2 min 1 sec
FEC: 0 333
CRC: 9 12
ES: 8 7
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
-
Openreach Modem stats completed after 24 hours:
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 33598 Kbps, Downstream rate = 92928 Kbps
Path: 0, Upstream rate = 19999 Kbps, Downstream rate = 79999 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 9.6 15.0
Attn(dB): 0.0 0.0
Pwr(dBm): 12.4 -0.7
VDSL2 framing
Path 0
B: 239 237
M: 1 1
T: 23 42
R: 0 16
S: 0.0955 0.3781
L: 20107 5374
D: 1 1
I: 240 127
N: 240 254
Counters
Path 0
OHF: 52427341 708274
OHFErr: 12 13
RS: 0 2253307
RSCorr: 0 349
RSUnCorr: 0 0
Path 0
HEC: 9 0
OCD: 0 0
LCD: 0 0
Total Cells: 446606342 0
Data Cells: 116022072 0
Drop Cells: 0
Bit Errors: 0 0
ES: 10 8
SES: 0 0
UAS: 15 15
AS: 86699
Path 0
INP: 0.00 0.00
PER: 1.64 3.97
delay: 0.00 0.00
OR: 116.56 64.47
Bitswap: 47 166
Total time = 1 days 5 min 14 sec
FEC: 0 0
CRC: 12 0
ES: 10 8
SES: 0 0
UAS: 15 15
LOS: 0 0
LOF: 0 0
Latest 15 minutes time = 5 min 14 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 5 min 14 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 0
CRC: 12 0
ES: 10 8
SES: 0 0
UAS: 15 15
LOS: 0 0
LOF: 0 0
Since Link time = 1 days 4 min 57 sec
FEC: 0 349
CRC: 12 13
ES: 10 8
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
#