Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Hitman on March 25, 2021, 09:53:38 PM
-
Hi Guys,
Had a pretty great line since BT fixed it 18months ago, but over 6 months last year it dropped and looking at the Bitload graph, definately a change in the graph, is this a result of crosstalk or do i have an internal/closer issue or external copper/joint issue going on?
Before
(http://Bitloading-2020-04-11-17.41.28.png)
(https://i.ibb.co/tXFZCJF/Bitloading-2020-04-11-17-41-28.png) (https://ibb.co/BNF4sCF)
More Recent
(http://Bitloading-2020-12-10-04.35.31)
(https://i.ibb.co/sVshR3S/Bitloading-2020-12-10-04-35-31.png) (https://ibb.co/TgPZ2hX)
-
Looking at those bit loading plots doesn't really tell me anything. Do you have the Hlog and QLN plots available? They are the ones that would show if any significant metallic pathway defect or cross-talk is present.
-
Looking at those bit loading plots doesn't really tell me anything. Do you have the Hlog and QLN plots available? They are the ones that would show if any significant metallic pathway defect or cross-talk is present.
The auto snapshot has those unticked, bummer :/
I may have some manual snapshot backups elsewhere i took, which will have those and post up later, cheers....
-
To be honest, don't think there's a drastic variation in the bit loading graphs, April to December 2020 you have posted but I could be wrong!
Obviously the "X" axis (width) variations are due to the different tone ranges plotted, 0-6300 April & 0-5250 December.
The "U0" tone band loading looks identical, very little difference in the "U1" band loading and slightly more variation in the "U2" band loading.
Very slight loss of bit loading apparent on the "D2" and "D3" tone bands.
The auto snapshot has those unticked, bummer :/
If you are currently running DSLStats you can snapshot HLog & QLN graphs at any time, doesn't really matter if the graphs are "ticked" to auto-save or not.
I'am sure you are aware that HLog & QLN are representative of the last modem/DLM synch and won't change until the next re-synch.
Any archived HLog/QLN graphs you may have will only represent the line state at the previous modem/DLM synch before they were snapped.
-
Thanks tiffy and all,
Ok i think the drop i would now put down to subsciber additions as the graphs look near, had 74 meg initial sync which has dropped to 72 then 70, i've just changed isp and that has placed me from a 3.3snr up to a 6.3snr.
Don't think the ISP can do anything with this or OR?, line has been running now for just over 48hrs and no change, i think i might have to try the manual line capping to try and nudge dlm to apply back to a 3.3 profile?
Any suggestions here? wait, contact isp (ZEN) for help or try a cap, Edit:whoops i presume i may have interleaving applied due to the change over, how can i tell as the stats look pretty much the same apart from the lower 60meg and 6.3snr sync rate i'm now on and if so, how long does interleaving usually last for?
Thanks,
-
Completely to expectation, a change in ISP will have caused a DLM reset and started your line off with default 6dB DS SNRM, this should change back to 3dB DS SNRM in 1dB steps with a minimum of 48 hrs between changes provided your line is stable, don't re-synch, let DLM do it's business.
DLM intervention usually occurs during the early hours.
I changed from Plusnet to Zen last December and this is exactly what happened at 48 hour intervals.
Once 3dB DS SNRM was achieved had to carry out some modem DS speed capping in order to acieve DS G.Inp re-tx low profile once again, the saga is listed in this post which may be of interest.
https://forum.kitz.co.uk/index.php/topic,25387.msg427464.html#msg427464
-
Completely to expectation, a change in ISP will have caused a DLM reset and started your line off with default 6dB DS SNRM, this should change back to 3dB DS SNRM in 1dB steps with a minimum of 48 hrs between changes provided your line is stable, don't re-synch, let DLM do it's business.
DLM intervention usually occurs during the early hours.
I changed from Plusnet to Zen last December and this is exactly what happened at 48 hour intervals.
Once 3dB DS SNRM was achieved had to carry out some modem DS speed capping in order to acieve DS G.Inp re-tx low profile once again, the saga is listed in this post which may be of interest.
https://forum.kitz.co.uk/index.php/topic,25387.msg427464.html#msg427464
Yeah, pretty much did the same back then, when the capping hack was found and got myself that low re-tx profile, that has stuck with this changeover and still shows as low, although i did do a reboot/refresh on the day of swapover but today i did power off for 35 minutes having spotted my nte5 clip on front face plate had been knocked/dislodged and had come away slightly off the master socket behind (although the connection was still running) these are crap design TBH, I decided to ditch the front crappy clip on and plugged in a filter i got with the new fritzbox instead, those graphs impoved slighlty as well but stats now show 2 resyncs.
I'll leave it now until hopefully i eventually get back down to the 3db profile (Using a Zyxel B10a modem to a Pfsense machine).
Cheers!
-
Yes, agree with the reservations expressed regarding the current OR NTE5C Faceplate, apart from the very poor clip attachment used have never liked the idea of the internal components not being soldered to the PCB!
I have stuck with the much more robust Mk3 vDSL/ADSL Interstitial Faceplate with NTE5A Master Socket as I still use a land line phone.
Have never utilised the Zen supplied Fritzbox 7530 modem/router to date, my ZyXEL separate modem/router combination has always worked very well on my rather long line which only supports 40/10 max VDSL-2 service.
I also adopt the principle of a minimum of 30 minutes between modem re-synch's to cover at least 2 consecutive DLM sample periods.
As my area has recently been upgraded for FTTP (UG cabeling) I hope to migrate service with Zen if the price is right, after 6 weeks, still awaiting an e-mail response for quotation.
-
As my area has recently been upgraded for FTTP (UG cabeling) I hope to migrate service with Zen if the price is right, after 6 weeks, still awaiting an e-mail response for quotation.
Surely you don't need a quotation, can't it just be ordered normally if its actually live in your area?
-
I rang and got a very helpful and detailed quote on the various bandwidth levels. The conundrum is if to stick with a copper phone or go SIP. Think it’s a no brainier really.
As ever Zen very helpful to me.
-
Surely you don't need a quotation, can't it just be ordered normally if its actually live in your area?
Of course that's the case but I would like to know how much it's going to cost, phone options and implications on moving from a current VDSL FTTC contract, surely that's not unreasonable?
I rang and got a very helpful and detailed quote on the various bandwidth levels. The conundrum is if to stick with a copper phone or go SIP. Think it’s a no brainier really.
Yes, I could ring and enquire, just disappointed at the lack of response to my e-mail and probably being a wee bit "thick" which is stopping me phoning.
Could you possibly elaborate on the phone options offered, not familiar with this aspect, hence the original inquiry to Zen?
Edit: Apologies to "Hitman" for drifting somewhat off topic.
-
All Zen FTTP services come with copper line included. Published call charges
Or
1) Transfer to Zen VOIP, reduced cost of FTTP, but unable to port existing number at present)
2) Transfer to 3rd party, further reduction on FTTP cost, to reflect no copper or VOIP, port number (subject supplier - Sipgate can)
I think during covid-19 they are much better placed to handle calls than email, not sure why, but other users report similar. My call was answered in less than 3 minutes.
To port number it must be active (obviously) so careful plann8ing needed I think !
-
@g3uiss:
Many thanks for the additional information, much appreciated.
I am happy with Zen to date, such a contrast from my previous ISP, Plusnet, certainly would like to remain with Zen and I probably will get around to making phone contact soon accepting that the lack of e-mail response may well be due to Covid staffing issues.
I appreciate that a lot of forum patrons would dearly love to have FTTP option available but to be honest my meager 40/10 FTTC service is sufficient for my current requirements and the hassle involved in getting the fibre from footway chamber to house with no current UG ducting installed is putting me off at present.
Again, apologies to "Hitman" for straying off topic and somewhat hijacking his post.
-
DSLAM adjustment this morning -SNR 5.3 :) although along with it comes the Re-tx high Inprein 1.00 ::), so will manually cap once at 3.3 to get that little DS Re-tx low back.
-
All Zen FTTP services come with copper line included. Published call charges
Or
1) Transfer to Zen VOIP, reduced cost of FTTP, but unable to port existing number at present)
2) Transfer to 3rd party, further reduction on FTTP cost, to reflect no copper or VOIP, port number (subject supplier - Sipgate can)
You've confused me as surely that's a contradiction as not ALL packages include copper line if those "or" options exist? Did you mean "as standard"?
-
DSLAM adjustment this morning -SNR 5.3 :) although along with it comes the Re-tx high Inprein 1.00 ::), so will manually cap once at 3.3 to get that little DS Re-tx low back.
Yes, more or less my experience on Zen migration, likely more of a product of DLM reset which would have occured with migration to any ISP.
Had expected your line would end up on DS G.Inp re-tx high profile if not on the initial DLM reset then at one of the later DS SNRM downward migration steps.
Still, easily fixed by modem speed capping once 3dB DS SNRM is achieved, have found that once re-tx low profile is achieved there is greater tolerance to DS FEC error rate which is believed to be one of the factors monitored by DLM governing re-tx profile selection, I was able to increase modem caps to max available on my line with DS FEC error rates averaging between 10,000 to 12,000 "FEC errors/hour, daily rate" as monitored by DSLStats.