Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: g3uiss on July 02, 2021, 10:37:50 AM
-
Zen regraded my ADSL2 to FTTC today. The task is closed but my upload is under 1mbps. Download is what’s expected and similar to my other VDSL line. Looking at the Stats this looks better than my older line. Any suggestions as to the low upload ? Stats are here, ignore the ADSL in the address I haven’t bothered to readdress that.
west-lodge.com/adsl/index.htm
-
I can't make that link work any way. Trying to ping west.lodge.com gets the response 'domain does not exist'. Removing the dot between west and lodge throws up security warnings and produces no output if I ignore them.
-
Sorry it’s west-Lodge.com/adsl/index.htm.
However I notice I’ve little tones on the US ?
-
Something certainly doesn't look right, 0.0 on line attenuation for upload.
Perhaps a fault somewhere?
-
That's just a bug in the modem firmware, not a real value.
-
The stats don't seem to be updating.
Stats recorded 02 Jul 2021 10:37:44
Looks like the cabinet is quite a distance away, its more like what you'd get on a really short ADSL2+ line. So I guess its still a huge improvement on what it was before?
-
Hopefully you get a better response than mine, I looked at your bitloading and the downstream almost dies out before the U1 band, and U1 carries that on with barely any usable bits.
The QLN seems ok for U1 same as downstream, hlog doesnt have the weird pattern that my line had when faulty. So to me it simply looks like the line isnt good(short) enough to get a higher upload sync, but maybe someone else can give you a better opinion.
-
Zen regraded my ADSL2 to FTTC today. The task is closed but my upload is under 1mbps. Download is what’s expected and similar to my other VDSL line. Looking at the Stats this looks better than my older line. Any suggestions as to the low upload ? Stats are here, ignore the ADSL in the address I haven’t bothered to readdress that.
west-lodge.com/adsl/index.htm
Regrades can take up to midnight to complete on the communication providers end, have you seen an improvement yet?
-
DSLAM type / SW version: IFTN:0xd086
You have the IFTN:0xd086 line card firmware/version.
It gives very poor upstream on longer lines.
There's quite a few examples of this on the forums over the years.
-
@J0hn that’s likely the answer. I have an OR visit booked but not for 10 days due my availability. Would they change the card ? Or I would have been better on ADSL2. My other line is 23/3 which is about right for AL line and distance.
@Alex I turned off updating on purpose. The line is stable at those figures.
-
@g3uiss perhaps you can post the graphs for the other line so we can compare?
-
Both lines updating now. Will leave them updating for a couple of hours
west-lodge.com/adsl/index.htm new
west-lodge.com/vdsl/index.htm original FTTP
-
Thanks, I looked at the line health graphs and the bit loading graphs.
So as expected your older VDSL line has better bitloading not just on the upstream but also the downstream, so it is a better line, so then I looked at the line health graphs to try and find out why.
The new line seems to have less noise on it, but it is also higher attenuation. On the telnet it seems very similar 27.2 vs 27.0 but if you look at the hlog its more significant around the end of D0 and start of U1.
If you are using dslstats, you can click on telnet -> pbParams and it will provide more detailed attenuation thats measured at U0 U1 etc. There is also an attenuation log there as well which is useful for tracking it over time.
It could be I am wrong of course and even though it looks bigger on hlog it still might not be expected behaviour.
I did also check the dslam firmware version and your 2nd line is on a different one, which backs up what john was saying so it might be as simple as having it moved.
-
Thanks @Chrysalis I agree with the comments, particularly the new line seems quieter. As its a new provision its interleaved (ECI) I expect that will go shortly. There doesn't look or sound (17070) that there is an actual line fault, so hopefully the card is the answer.
Thanks for looking and all other input OR booked for 16th July will report back
-
Please keep us updated, hopefully whatever the cause it gets resolved.
-
west-lodge.com/adsl/index.htm new
west-lodge.com/vdsl/index.htm original FTTP
I think things are a little bit muddled on those two lines. The one annotated as "new" shows "adsl" and the one annotated as "original FTTP" shows "vdsl". :-\
-
They are both VDSL. the web address I haven’t changed and some of the page titles need updating, but the are two VDSL lines and the graphs correct. The ADSL address is the one recently migrated.
-
Thank you. :) But I think you see what you thought you had typed rather than what you have actually typed . . .
I see "original FTTP". ;) :angel:
-
In my dreams
-
The 0xd086 line card version/firmware isn't seen very often.
There have been 2 different members on these forums with 2 VDSL2 lines connected to the same ECI DSLAM.
1 of their lines was on 0xd086 and the other on the more common 0xb206.
So the DSLAM's either have different versions of line cards in them or they have the same line cards with different firmware on the line cards.
You could try asking for a port swap in the hope you end up on a different line card.
Edit: just read your original post again.
You have exactly what I describe above. The line with the higher upstream is on v0xb206 firmware.
-
Thanks J0hn . I will see what I can get OR to do on the visit
-
As expected the line has gone to fast path with associated slight improvements in DS. US remains at 770. OR booked for Thursday PM, not sure how they diagnose this type of fault as the metallic pathway looks fine and DS is fine. :-\
-
>>> So the DSLAM's either have different versions of line cards in them or they have the same line cards with different firmware on the line cards.
They certainly do use 2 different types of line card on the ECI's. I tried to do some digging into this many years ago.
Bearing in mind we are going back probably 8 years, my memory is hazy... ECI manufactured 2 different 64 port vdsl2 linecards. The newer of which were specifically designed to work with the V41 (Vectored) MSANS but are backwards compatible and also work in the M41's.
What Openreach call in some of their documentation the VTU-C64P V3 card contains the Lantiq Vinax V3 chipset. The older VTU-C64 contains a Lantiq Vinax 2.2 chip.
FYI my stats identifies as IFTN:0xb206 (178.6) / v0xb206
From a photo taken inside my DSLAM I can see there's a bar code & sticky label on the linecard which says VTU-C64P
Both versions may be embossed with VTU-C64 so its not possible to tell from normal photos which is which and I'm not sure how significant the 'P' is when it comes to identification. There are other numbers on the sticky label but they relate to 'BT' and a Serial No
-
. . . and also work in the E41's.
Not E41 but M41. :)
-
ack - typo edited - thanks :)
-
@kitz thanks for background not sure if this will be useful for OR visit
-
No news as OR never turned up for the appointment. Zen trying to reschedule :no:
-
@kitz thanks for background not sure if this will be useful for OR visit
Not really :( It was just more of a follow up on J0hn's post and confirming that there are 2 different line cards in use by Openreach, opposed to it being just f/w.
The visiting OR engineer won't be able to swap you over to a different line card. BUT he may be able to put in a request if all else fails.
If the engineer didnt show, you should be entitled to compensation.
https://www.ofcom.org.uk/phones-telecoms-and-internet/advice-for-consumers/costs-and-billing/automatic-compensation-need-know
-
No news as OR never turned up for the appointment. Zen trying to reschedule :no:
I know your pain, same happened to me, I suggest getting a morning appointment even if its a later day, logic suggests they less likely to bounce it.
-
Not really :( It was just more of a follow up on J0hn's post and confirming that there are 2 different line cards in use by Openreach, opposed to it being just f/w.
The visiting OR engineer won't be able to swap you over to a different line card. BUT he may be able to put in a request if all else fails.
If the engineer didnt show, you should be entitled to compensation.
https://www.ofcom.org.uk/phones-telecoms-and-internet/advice-for-consumers/costs-and-billing/automatic-compensation-need-know
@Kitz Zen have passed a credit for this now without being asked so that’s positive and in the amount quoted in the link. Would the engineer know about that need I wonder ?
-
Really great engineer. No issues with the line as anticipated. He was going to do a port swap but there are no spare ports, which I sort of suspected. He was very open to me mentioning the card issue and agrees it’s a sensible next step and is contacting appropriate team to do this. Not sure how long that would take.
-
The very helpful engineer after spending 3hrs at the cab advised me he was able to try two other ports, neither of which were any better. He did say he thought they would be on the same card. He said the unloaded US at the cabinet was poor and loaded at 400m was very low. So he confirmed it’s a issue with the card and has now passed up the chain. He didn’t have any idea of timescales so not sure what and when something will happen
However I’ve noticed g.inp is now active on DS and US is interleaved. Not sure how that’s occurring on an ECI cab ???
-
g.inp removed early hours and DS interleaved US interleaved ( high). Think from memory that’s what happens. Have 24ms delay in total now 😢. Still awaiting update from OR or Zen.
-
Interesting about seeing the g.inp in what traditionally would have been 'open profile' period. It's the first time I've seen that occur either on ECI or Huawei.
afaik from an engineer reset it would be open for up to 24hrs, then move to 'default'. Default being the same as the profile used after an ISP requested 'remote reset' that involves interleaving.
Wonder if anyone else has seen that on their travels? @J0hn?
-
>> So he confirmed it’s a issue with the card and has now passed up the chain.
Hope that he has and that something can be done about that.
They don't seem to like changing the line cards in the DSLAM, but you may be lucky and get a lift and shift to a different card*.
*Correct me if I'm wrong as I haven't checked your live stats, but I think you said your other line showed the different f/w version indicating that there is at least one of the other line cards in your cab.... so hoping there is a spare port available. :fingers:
-
@kitz Yes that's right, the other circuit is on the more common card / software. The engineer confirmed the speed at the cab was poor he did try another port but it was on the same card so NO difference was seen. I assume if they will not change the card, as you suggest, I just have to live with this performance, or go back to ADSL2+ which performed much better
-
In a way its a good thing that you were able to point out the difference to him, and that he took that onboard and has passed it higher. I really hope that someone takes note.
No disrespect to OR engineers, but not all would be aware of anything DSLAM related as their training is just related to the wires. In the past I've had an engineer who didn't even properly understand SNR and another who thought FEC was worse than CRC. Conversely I've also had some very good ones who attempt to go the extra mile for a fix. Thankfully you seem to have got a decent one. :)
Swapping out the line card involves a different team and a small amount of downtime for everyone attached to the line card. I'm not saying they don't do so. I guess it will depend on how service impacting it is for those on the particular card. BS may know more about trying to push for a line card swap out.
-
In a way its a good thing that you were able to point out the difference to him, and that he took that onboard and has passed it higher. I really hope that someone takes note.
He was very interested to see and listen, although I was very cautious as its their job not mine. He was grateful for the "steer" so yes a good engineer. Not sure how or what happens now, Zen dodnt seem to see anything and are wanting to send another engineer, I would have expected this would be visible on his notes. Hopefully @BS might see this and advise4 :P
-
In a way its a good thing that you were able to point out the difference to him, and that he took that onboard and has passed it higher. I really hope that someone takes note.
No disrespect to OR engineers, but not all would be aware of anything DSLAM related as their training is just related to the wires. In the past I've had an engineer who didn't even properly understand SNR and another who thought FEC was worse than CRC. Conversely I've also had some very good ones who attempt to go the extra mile for a fix. Thankfully you seem to have got a decent one. :)
Swapping out the line card involves a different team and a small amount of downtime for everyone attached to the line card. I'm not saying they don't do so. I guess it will depend on how service impacting it is for those on the particular card. BS may know more about trying to push for a line card swap out.
Yeah my engineer listened to me and I got lucky in that respect.
On the DLM reset thing, after my engineer left, I noticed I was back on fast path, however I did not go back to interleaving after 24 hours, I have just stayed on fast path since. So maybe open somehow is the default on engineer resets without it reverting to isp reset default?
-
Wonder if anyone else has seen that on their travels? @J0hn?
Nope it's a new one for me too.
Strange that it was added straight away on ECI, and strange again that it has since been removed.
-
The engineer never did a reset as at that time the line was on fast path( having gone fast path 3 days after but was commissioned .
When he changed ports the second time it came up with g.inp the line stayed that way until Sunday AM and went interleaved with US as well which I didn’t understand as there were minimal errors.
-
4th engineer been here, and at cab today. He advises that a LUNNS task needs to be completed, as the output from cab is still very low when loaded. He thinks this will take about 2 weeks. Not sure if anyone might suggest if this is correct, and if there is anything I can ask to speed up the process
-
Swapping out the line card involves a different team and a small amount of downtime for everyone attached to the line card. I'm not saying they don't do so. I guess it will depend on how service impacting it is for those on the particular card. BS may know more about trying to push for a line card swap out.
Generally, the process for a faulty port (lift & shift) would be to liaise with the helpdesk advisor, in order for them to test the spare ports available in the Cab, to see if a L&S would cure the customers issue.
Hard to put a nationwide percentage on it, but experience would tell me this is successful 80-90% of the time.
From time-to-time though, as part of this liaising procedure, it will be found that any number of the spare ports that exist also have faulty issues. The advisor has full access to the full cards performance and will scrutinise said card before making their next decision. It may simply require a full-card reset, but these things aren't done lightly for the obvious reason.
The advisor also has the ability to mark any spare ports as 'faulty', which can then 'force' the system into looking for a spare port on another card ... but only if one is available. If the Cab is at capacity, then there is nowhere left to go other than to raise a 'LLUMS Case' for one of the other BT departments (I forget now, BT Operate or something like that ??) to carry out a card change.
I can't comment on the turn-round time on these, at it is varied. Can you speed the process up ?? Not a cat in hell's chance, I'm afraid.
-
Thanks for that @bs and sorry for the misspelling of the process. So just sit and wait. Fortunately is US which isn’t quite as critical as the DS which is the same on both circuits. Interested if the time required is lack of engineering or disruption to other users. (I understand they tried the only other spare port but it was on the same card and gave the same results).
-
Thanks for that @bs and sorry for the misspelling of the process. So just sit and wait. Fortunately is US which isn’t quite as critical as the DS which is the same on both circuits. Interested if the time required is lack of engineering or disruption to other users. (I understand they tried the only other spare port but it was on the same card and gave the same results).
Don't worry about the spelling, mate ... took me 3yrs to understand what the advisors were saying !!. Looms, Lambs, Limbs - depends on the country dealing with you and their local accent ;D
It's very hard to give a definite answer as to why they arrived at this decision, but I can tell you the process is all flow-charted to eliminate faux-pas.
They may well have looked at the cards performance across the board and decided it was operating within the 'cone of acceptance' requirements, for that particular instance ??
All pure guesswork.
-
Don't forget our Glossary (https://forum.kitz.co.uk/index.php?topic=4620.msg108498#msg108498)!
I have a recollection of being told, way back when FTTC was being rolled out as a new system nation-wide, that the DSLAMs in the fibre cabinets were specified as being part of the BT Operate domain.
-
Don't forget our Glossary (https://forum.kitz.co.uk/index.php?topic=4620.msg108498#msg108498)!
I have a recollection of being told, way back when FTTC was being rolled out as a new system nation-wide, that the DSLAMs in the fibre cabinets were specified as being part of the BT Operate domain.
Wasn't that before Openreach were spun-off as their own company though?
-
Wasn't that before Openreach were spun-off as their own company though?
Sorry, I'm not sure what it is that you are trying to query. :-\
Operate ("BT Operate") exists and has nothing to do with Openreach.
-
Wasn't that before Openreach were spun-off as their own company though?
http://www.pnsol.com/public/CS-PNS-2012-08.pdf
BT Operate (BTO) is the operating division of British Telecom (one of the world’s
leading communications services companies) that is responsible for the service
fulfilment of BT’s products and services globally; establishment of security policy
and processes; and monitoring the reliability of BT’s networks and systems. BTO
employs over 13,500 world-class professionals in more than 20 countries, with
expertise across a broad range of IT and web-based disciplines. It manages over
5,500 UK exchanges supplying over 26m premises, and provides over 12m DSL
connections (both business and domestic) of which BT’s Retail division delivers
approximately 50%.
Sounds different
-
Sorry, I'm not sure what it is that you are trying to query. :-\
Operate ("BT Operate") exists and has nothing to do with Openreach.
Its just constantly confusing the line between what Openreach own and what BT own.
-
I find the best way is to not worry about it, Alex ..... it's waaaay above any of us on here and not worth the time and effort trying to pin it down .... unless you're obsessed with it.
;) ;D
-
The LLUMS case has been closed with no changes seen ( card or speed). Zen say we have to start a new fault. I think that’s probably a waste of time and I will mange with the 800k upload.
-
The LLUMS case has been closed with no changes seen ( card or speed). Zen say we have to start a new fault. I think that’s probably a waste of time and I will mange with the 800k upload.
Will ZEN log it as a repeat fault and escalate to care level 4?
-
I have no idea ! Zen have been quite disappointing, not the Zen I recall from a few years ago. Their emails are quite confused and not really moving the issue forwards. I have a new anointment (number 6) on Wednesday
-
I have no idea ! Zen have been quite disappointing, not the Zen I recall from a few years ago. Their emails are quite confused and not really moving the issue forwards. I have a new anointment (number 6) on Wednesday
This comes to mind: https://www.theregister.com/2021/07/26/zen_broadband_complaint_still_unresolved/
-
This comes to mind: https://www.theregister.com/2021/07/26/zen_broadband_complaint_still_unresolved/
Kinda silly to say "whats the point" to contact their MP though.
I get some MPs are bad, but I know mine is VERY proactive and shes chased a lot of issues I've had, though mostly regarding the council. Either way, saying "whats the point" is foolish, what have you got to lose?
-
The MP that covers my work address is excellent, but my local MP covering our home is just about useless. The former really acts for his constituency the latter just expects his constituency to give him a job. Still not a route I favour
-
Zen have now said 800k is the max upload I can achieve ( dsl checker 1.9-3.1) options are to revert to ADSL2, accept this speed or cancel with no cost.
No idea what to do :(
-
Lengthy email from Zen explaining why there was no further options. However it might be amusing for others to read this part of the email. Zen's technical knowledge might now be questionable !
"I understand that when Openreach attended the property on the 16th July 2021, they advised that there was a fault and that possibly changing the line card could rectify the issue. The engineer advised on their notes that they had rectified the issue by completing a lift and shift; meaning that they have replaced or moved the socket within the property". :lol:
-
I would raise a formal complaint with Zen saying they have no idea what they are talking about and have not progressed the fault investigation to a satisfactory resolution, the LLUMS case was not completed or just ignored. Overall it gives a very poor impression of Zen support. Have you considered emailing the Openreach CEO (email address has been posted on various forums) giving a brief description of the problem. This has been known to get results when other routes have got nowhere.
-
Ive actually done that, but they just referred me back to Zen. Next is an email to Zens CEO. It’s appalling really, just imagine what how a less experienced EU might be left. Just paying for poor service and information.
-
Zen I expect are growing rapidly, and with that comes a larger tech support team which I expect has a consequence of been less skill focused.
I dont know what I would do in your shoes, all it does is remind me that I wish EU's could deal with openreach directly.
-
Yes I couldn’t agree more. I feel in the communication between Zen and OR the lack of technical knowledge leads to confusion. Yesterday I asked Zen to suggest a way forward, another advisor suggested another OR visit ! Now booked for next week. If that fails I’m going to leave as is. It’s a second service and I can route all services needing upload capability via the good line.
-
Great OR engineer today. Confirmed issue is with line card, but there are no spare ports on other cards so nothing can be done. I assume they wont replace a card due inconvenience and cost.
At least a definitive answer
-
Great OR engineer today. Confirmed issue is with line card, but there are no spare ports on other cards so nothing can be done. I assume they wont replace a card due inconvenience and cost.
At least a definitive answer
If the card is faulty - it will get replaced.
As with all things though, a priority will be placed upon it. An analogy, may be to compare it to D-Poles that are found to have decay/rot - like DSLAM cards, there are thousands out there - so a priority system is placed upon them.
Is it a PIDOC (Pole In Danger Of Collapse), is it a customer awaiting installation, is a customer out of service awaiting for it to be changed to regain service, is it a high fault volume node, is it part of an FTTP programme .....
Same with cards - if most of the card is performing within the cone of acceptance - it would quite rightly take a lower priority to a card that sees all customers without service.
-
The engineer suggested that I would get FTTP before the card was replaced!
It’s not I think within the cone of acceptance, but not really sure as it only affects uploads. Which are 50% of minimum projections on the dsl checker.
-
@BS. I think in this particular case it is not so much that the line card is faulty, but it of a different model than some of the others. It uses different f/w and as far as OR seem to be concerned they work well enough - except they give a poor upstream.
The topic has been done many times over the years that OR don't seem too concerned about under performance with upstream speeds. TBH most people wouldnt have noticed nor known but g3uiss is in a situation where he has 2 lines to be able to compare with and able to point and say "look this is what it should be acheiving". I hate to sound pessimistic and I agree that its unfair, but OR dont seem to be in any hurry at replacing the 0xd086 line cards that are in service :(
About the only thing I can think is that if g3uiss now takes this further up the ladder himself. Ideally Zen should attempt to push it first.
@g3uiss I started a post the other day about something I'd observed on your bit load which I never got to finish, it was more of a ramble rather than anything that use as ammunition and I couldn't think how you may use the info to your advantage.
-
Thanks @bs and @kitz. Unfortunately I don’t think Zen have a understanding or desire to push further and FTTP is coming. They have offered to revert me back to ADSL2 which will improve the US by 25% for little loss of DS or I can route my US over the other circuit.
However the reason I have two circuits is to get a acceptable performance, given I’m at the end of a 1000m aluminium wire.
I think the key is the fact that this card works in most situations and as @j0hn has pointed out it’s over longer lines it fails.
I think it’s a dead end for now :no:
[Moderator edited: FTTC -> FTTP]
-
>> as @j0hn has pointed out it’s over longer lines it fails
This may tie in with the post I started to make the other day that I started, but didn't know how to conclude. As I still have it in notepad I'll post the unfinished item warts and all.
Its difficult to say with absolute certainty, but the new vdsl line looks to have a different PSD mask.
The clue is how bit load slightly increases after tone 500 (end of adsl frequency range).
In theory. as they are on the same DSLAM and have the same attenuation both lines should have the same spectral mask. Each DSLAM is given a specific set of masks to use which are based upon the cab's distance to the exchange. The DSM (Dynamic Spectral Management system) then allocates one of these masks based upon the the line's distance between home and the cab & performance.
DSM analyses the line during the sync up phase, one of the key parameters is attenuation but it can take other factors into account such as crosstalk or a poorly performing line in an attempt to boost SNR at various tones. Whilst there are many different masks available, they narrow down considerably based upon the DSLAM location.
After a considerable period of looking at many stats, the naked eye can tend to spot patterns from the plotted bit load graph to be able to tell the difference between long & short D sides and also if the cab is close or far from the exchange.
As I say, naked eye is no exact science - you'd need something like a JDSU to analyise each individual tone - its just something that you can spot and get a feel for when you see bit load patterns at certain tones. It's not something I could put in writing, but the main tone shapes I look out for are: any U0 bitload, patterns in the D1 bandset based at tone 250, 500 and the general shape of the U1 bandset due to PCB.
I started to say something about the even stepping and 6 bits.... but I've forgotten now where I was going with that without reopening the graphs and looking again.
The reason it ties in with j0hn's comment is that it's almost like it's selected a psd mask that reduces your available bit load in the U1 region. Bearing in mind that because its a long line DSM will allocate you a different mask than shorter lines. The long and short of what I'm trying to say is that its possibly the PSD Mask and PCB that is causing the reduced upstream. The more I looked at your 2 lines, the more convinced I became that you had been allocated a different PSD Mask.
-
@kitz. I understand your train of thought. However as you said in an earlier post, what I could do with this is very limited! It seems to me the expertise of the field engineers doesn’t go this far, more todo with the physical pathway which is fine on every test. Can that “mask” be associated with that card version I wonder.
Bottom line I think there is little I can do. I did approach Clive Selly’s team but they politely referred me back to Zen. I didn’t want to do this as the engineers had been helpful, but felt they might probe further. Zen simply say it’s the max the line is capable of.
-
It seems to me the expertise of the field engineers doesn’t go this far, more todo with the physical pathway which is fine on every test. Can that “mask” be associated with that card version I wonder.
That basically is it in a nutshell.
We are responsible for the metallic path facility and its capabilities. If a card is faulty, or running a different f/w (thanks kitz for educating me on that one), then the OR engineers influence is minimal to non-existant.
We can simply liaise with the relevant helpdesk and hope to have a LLUMS case raised. From that point forth, we have no sight or feedback of its progression - it may very well be due to have a new card replaced today, conversely ... it might be penciled in for the 12th of never ??
-
Thanks @bs. So my understanding was correct. So as a end user there is no way forward for any potential resolution?
-
Personally I'd be surprised if the card ever got replaced.
They have pretty much stopped increasing capacity of full FTTC cabinets.
The focus is all on FTTP.
Waiting lists are so high due to full FTTC cabinets that OpenReach have suspended the waiting list system.
OpenReach are telling both customers and providers that capacity will become available on cabinets as and when local FTTP deployments come around to take pressure off the cabinet.
https://forums.thinkbroadband.com/notspot/t/4689745-no-fttc-available-but-neighbour-has-it.html
That all makes sense to me. There's little point adding new DSLAM's/pods to increase capacity if FTTP is expected within a few years.
The line card firmware causing the low upload speed had been around for years now.
As discussed it only seems to affect the upstream on very long lines, so I don't see them replacing those either.
-
Thanks @j0hn. I’m lucky FTTP is being rolled out in my town and the walking survey just done on our road.
-
Personally I'd be surprised if the card ever got replaced.
They have pretty much stopped increasing capacity of full FTTC cabinets.
The focus is all on FTTP.
Waiting lists are so high due to full FTTC cabinets that OpenReach have suspended the waiting list system.
OpenReach are telling both customers and providers that capacity will become available on cabinets as and when local FTTP deployments come around to take pressure off the cabinet.
https://forums.thinkbroadband.com/notspot/t/4689745-no-fttc-available-but-neighbour-has-it.html
That all makes sense to me. There's little point adding new DSLAM's/pods to increase capacity if FTTP is expected within a few years.
The line card firmware causing the low upload speed had been around for years now.
As discussed it only seems to affect the upstream on very long lines, so I don't see them replacing those either.
How does that work for areas where openreach FTTP isnt planned though or is several years away?
I do understand that FTTP is where the focus should be, but it is a gamble on openreach's part to leave some areas in limbo for potentially years to come.
-
Latest from Zen. Taken me out of contract as unable to help further with fault. :no:
-
Not sure what to suggest now, bearing in mind your last response from Clive Selly.
It's annoying in that we know what the problem is, and know what its potential could be on another line card. It's sad that Zen have taken the easy way out. AAISP is about the only ISP I can think of now who might fight your corner... but even if you move to them they wont have the advantage of the other line and being able to compare and see the difference :(
btw.. just in case it wasnt clear about my musings about the PSD masks... was I wondered if for some reason those particular line cards were allocated a different set of masks that were available. Being that DSM selects masks from a range based upon your distance it would explain why it only affecs the longer lines. It's the mask that affects PCB and available bit load. If your line was shorter it would in all probability have a totally different mask and possibly not be as restrictive at certain tones. I said much earlier in this post that Openreach seem reluctant to change line cards so I doubt they would swap out the whole line card if its only affecting one (longer) line. Openreach have always paid less important on the upstream and never seem to make any guarantees about the upstream speed performance.
It's so damn annoying for you to know what it could perform better on one of the other line cards.
Few consumers have 2 lines on the DSLAM to compare with and the since the 0xd086 line card performance only affects the longer lines very, very few people would be in your situation. We all know what the solution would be, but if there are no free ports on the other line cards then its difficult. In an ideal world Openreach would swap places with a shorter line but I cant ever see them doing that :( I think about your best chance of getting anything done is trying Clive Selly again.
Do you know how along you are with FTTP? Things seemed to move really quickly here once they'd started.
-
Thanks @kitz. All agreed my options are to do nothing and manage, or swap back to ADSL2 on that line. The FTTP is now live in some parts, one of my colleagues has it working about 3 miles from me. Apparently mine is one of the last PON,s to be done, although they have done the” walking” survey about a week ago, so it’s moving. The main Rd at the end had had activity, with ropes etc, but nothing down the sides near me yet.
Frustrating as you say, but also there isn’t much incentive for anyone to do anything about it. One point one of the last engineers mentioned it wasn’t a OR issue and needed BT not sure if that’s right and if so would Clive Sellys team have any interest ?
I think I was unlucky with the person that picked up my first approach and really didn’t want to get involved
-
Out of the Blue call from customer services manager at Zen. Not sure what prompted this, maybe they review all accounts taken out of contract. Very helpful and certainly more interested in getting a resolution. Left them to escalate but as @kitz mentions they will have to work hard to get resolution. I assume from what @j0hn has said they are aware of this card issue ? :-\
-
I've absolutely no idea if they would be aware of it.
We don't even know if it's 2 different hardware revisions of line cards (we know they use/used 2 different kinds) or if it's just the firmware loaded to the card.
The "bad" firmware seems to work perfectly normal on shorter lines.
Ixel had 2 short circuits, 1 connected to each line card firmware, and both worked fine.
It's on longer lines that the upstream seems to completely collapse.
It would not surprise me if OpenReach weren't aware of the upstream issue with these cards on longer lines.
Unfortunately the engineers who work inside the DSLAM's almost never interact with customers.
That means you can't even find out if the cards are different.
The engineer who comes to see the customer only touches the tie cables in the PCP that then link to the DSLAM.
Nice to see Zen giving it another go anyway.
-
Do we know 100% it is the firmware causing it, his signal seems slightly weaker on the problem line and can see on the downstream tones immediately before the upstream that it is not just the upstream affected.
Openreach may not even consider this firmware a problem, so from their perspective why change a working line card? The quality assurance is low due to all the cost pressures so they not going to be switching out kit for what they see as very minor problems, kitz even said herself they dont really care about the upstream much.
Contacting the CEO seems the only hope at this point, as its this type of thing where they can authorise work to be carried out, the CEO has a lot more clout than any ISP would.
-
@chrys yes I think your right. However FTTP is coming making the chance of involving additional costs even more unlikely. I have been down the CEO route but the agent assigned just constantly referred me back to Zen. I guess trying again might get another agent.
Somewhere here I saw a rough timetable on FTTP rollouts. I’ve had the manual survey not sure what the timeframe is after that. :(
-
Do we know 100% it is the firmware causing it, his signal seems slightly weaker on the problem line and can see on the downstream tones immediately before the upstream that it is not just the upstream affected.
Yes. It's the line card version or the firmware it runs on. It's known to cause very low upstream on longer lines.
There's a couple other threads where the users upstream has crashed after the DSLAM firmware changing to the 086 version.
https://forum.kitz.co.uk/index.php/topic,18140.msg329379.html#msg329379
-
The link was interesting! I posted on that thread but long gone out of my mind :no:
One wonders how many end users actually have this issue.
-
@g3uiss
I made a reply earlier to your post at 9:44 but had to go out. My lift turned up a little earlier than expected and although I'd finished the post, in my rush to get out I'd not hit the post button so it never sent. I'll post it now but I see there have been other replies since which I will deal with in turn asand when I read through them.
The FTTC DSLAM is Openreach's domain, so not quite sure why BT was mentioned for vdsl.
BTw is responsible for adsl MSANs in the exchange for any BTw based ISPs, but when it comes to FTTC anything between the L2Switch at the OLT to the SSFP in the home belongs to Openreach.
Not necessarily unlucky. I doubt that most engineers would be aware of the different line cards or firmware. Most engineers don't actually know much about actual DSL technology. They don't really need to as they just deal with the copper. Knowledge of DSL knowledge helps when it comes to fault finding that isn't so much visible like an oxidised joint or damaged cable is. They have tools such as the JDSU which interprets all the DSL stats for them and gives them the pointers where the problem lies. Some of the topics we talk about here on the forum is beyond what your average engineer Openreach knows. I'm not saying this in a derogatory manner, it's just a fact that first and foremost they are telephony engineers. I've had broadband fault engineers who didnt know what SNR or CRC/FECs are.
TBH if you hadn't got the other line to compare with then it would be a case of nothing you can do and the line just is too long enough to be able to load any bits at the higher frequencies used by the U1 tones. I haven't come across a case before where a cab has the 2 different line cards in them.
We've known for a several years that there are 2 different line cards but it's a slightly newer observation that the 0xd086 cards don't perform so well on longer lines. Yours is the first case I have seen where we are able to directly see how much of a difference side by side for 2 lines which in theory should be the same length and on the same PSD profile. I've seen several cases where lines don't perform well in the U1 range and their upstream bit load is so poor that its worse than adsl and I myself have written it off as unable to do anything because the line is just incapable of loading many bits in the U1 band.
Seeing your stats and looking at both of them side by side has made me strongly suspect that the 0xd086 card is selecting a much harsher mak and higher PCB for longer lines. It's made me wonder just how of those lines I've seen in the past could perhaps do better if they were using a different PSD mask that perhaps could be available to them. Why those line cards select a harsher mask I don't know, but it will probably be something to do with crosstalk. Whether they generate more NeXT or have a harder time with FeXT I don't know. I've no proof, but all my gut instincts are screaming at me those 2 lines are on different PSD profiles. I bet that coffee and carrot cake that I'm right.
-
Do we know 100% it is the firmware causing it,
See my post July 14th here (https://forum.kitz.co.uk/index.php/topic,26130.msg438934.html#msg438934).
There's 2 different line cards which have different chipsets. The newer one of them is 'vectoring ready' and compatible with both the ECI M41 and V41 DsLAMs. Bearing that in mind I would think they have different f/w.
his signal seems slightly weaker on the problem line and can see on the downstream tones immediately before the upstream that it is not just the upstream affected.
See my post Aug 4th here (https://forum.kitz.co.uk/index.php/topic,26130.msg439625.html#msg439625)
Although I admitted at the time that my post was more of a ramble because I couldn't see how it could help g3uiss, but I thought it was important enough to be relevant and worth mentioning. I'll eat my hat if the 2nd line is not on a different PSD profile. Its highly likely that its the mask and its PCB that is causing the line to look 'weaker'.
- Different mask > Increased PCB > lower power output > less SNR > less bit load.
I spent a wee bit of time looking & comparing the 2 line stats. I explained what I was looking for in the other post, but I will attach the 2 bit loads side by side. Even naked eye and some one used to looking at line stat graphs should recognise the nice even stepping and the dipped area at around tone 500 and which then goes back up again is indicative of spectral shaping. Tone ~500 is an important marker point for spectral shaping as its where adsl(2+) frequencies ends.
-
Yes. It's the line card version or the firmware it runs on. It's known to cause very low upstream on longer lines.
There's a couple other threads where the users upstream has crashed after the DSLAM firmware changing to the 086 version.
https://forum.kitz.co.uk/index.php/topic,18140.msg329379.html#msg329379
Thanks for the linky, I was reading it and then started following up on the backlinks. My memory is like a sieve these days and I ended up on search-a-thon which was a nice refresher:(
This one is quite interesting which is the supposed reason for the f/w update
Ethernet OAM 802.3ah Loopback: Timer not getting updated when the same timer value is
set again.
Silent Stuck Ports
VTUC v3 fails to accept profiles following upgrade
V3 Config and software load on first install issues
Power Status reporting in 15-min DLM file
EOPs GUI – Margin & Attenuation information missing from Broadcom modems on long
lines
The number of profiles shows wrong number in dropdown at “select DSL VOP profiles” page
V21 failures when sending parallel profile to multiple ports on same ECI DSLAM
Time Errors in PM Data
PM Data Missing
Increased Upstream FEC Count
VTUC v3 fails to accept profiles following upgrade
VTUC are the line cards. v3 are the ones containing the Lantiq Vinax V3 chipset.
The number of profiles shows wrong number in dropdown at “select DSL VOP profiles” page
VOP profiles are Vector of Profiles - Which according to TR-165 specifications (https://www.broadband-forum.org/download/TR-165.pdf) includes:
Line Sprectum Profile
PSD Profile
UPBO Profile
xDSL Channel configuration
xDSL Line Spectrum Profile
xDSL Line Service Profile
I've got the feeling I'm missing a hidden link somewhere. Unfort I'm really tired and in pain so my brain cant cope with anything more tonight Ls. do anything else tonight. I'll have a look tomorrow.
-
@kitz thanks for all that interesting information. Your understanding is quite remarkable ! Yet another engineer is booked for Wednesday, I can’t really see the point, but I’m not sure if an ISP can do anything more. As everyone points out, these engineers don’t have access to the likely card and hence report no fault found.
-
Yes. It's the line card version or the firmware it runs on. It's known to cause very low upstream on longer lines.
There's a couple other threads where the users upstream has crashed after the DSLAM firmware changing to the 086 version.
https://forum.kitz.co.uk/index.php/topic,18140.msg329379.html#msg329379
Sorry to hijack a thread somewhat but I believe this may have affected me as well. Back in September/October of 2020 my upload speed on a Zen 80/20 FTTC circuit completely collapsed to less than 1-2Mbps from the full 20Mbps I was obtaining before. After multiple tickets with Zen we ended up simply leaving Zen and moving to Virgin Media who offered us an FTTP (RFoG) connection and higher speed for a lower price. The DSLAM in use was in a Huawei 288 cabinet and was a recent install as part of BDUK, line length I'd estimate at less than 800m. It's unfortunate that I can't test this as we don't have the line anymore but I find it interesting that someone else has experienced a similar issue.
I should note we had this issue twice, with one time turning out to be a faulty modem causing problems. The first time we also had an Openreach engineer attend who did a pair swap at the jointing box and replaced our NTE5 with a new NTE5C with filtered faceplate.
-
Yes. It's the line card version or the firmware it runs on. It's known to cause very low upstream on longer lines.
There's a couple other threads where the users upstream has crashed after the DSLAM firmware changing to the 086 version.
https://forum.kitz.co.uk/index.php/topic,18140.msg329379.html#msg329379
Given kitz explanation of the mask been used been different, I do accept it is the likely cause, just not necessarily 100% chance. A different mask could cause the weaker output on those tones. Although from openreach point of view I expect they dont see this as something that would put a card into needs replacing category hence me agreeing with kitz as well to go down the CEO route.
-
Sorry to hijack a thread somewhat but I believe this may have affected me as well. Back in September/October of 2020 my upload speed on a Zen 80/20 FTTC circuit completely collapsed to less than 1-2Mbps from the full 20Mbps I was obtaining before. After multiple tickets with Zen we ended up simply leaving Zen and moving to Virgin Media who offered us an FTTP (RFoG) connection and higher speed for a lower price. The DSLAM in use was in a Huawei 288 cabinet and was a recent install as part of BDUK, line length I'd estimate at less than 800m. It's unfortunate that I can't test this as we don't have the line anymore but I find it interesting that someone else has experienced a similar issue.
I should note we had this issue twice, with one time turning out to be a faulty modem causing problems. The first time we also had an Openreach engineer attend who did a pair swap at the jointing box and replaced our NTE5 with a new NTE5C with filtered faceplate.
I don't think so, this specific issue is to do with different ECI firmwares/cards. Huawei is a completely different ball game.
-
So another very helpful and frustrated engineer as he couldn’t do anything but agreed the US is much less than should be available. He offered to escalate to his manager who is currently off but will persue on her return tomorrow. However he returned a fault not found to Zen.
-
Hopefully he did escalate even with the no fault status.
-
Nothing changed. Now Zen have arranged for the backhaul provider to be changed so both services are on the same supplier. They say that will fix the issue ! Not sure how that affects the sync between me and the cabinet. The level of Tecnical knowledge is worrisome especially as this is been handled by there complaints department!😢
-
They say that will fix the issue !
Oh dear.
-
Perhaps I’m being unfair. Zen actually might not need Tecnical expertise other than booking a OR engineer? I suppose they have their tests which need little interpretation and leave the rest to OR. If this is the case how would a user get a resolution to a more obscure fault I wonder
-
So the change in backhaul was done in the early hours and surprisingly it didn’t change the sync speed. !!!!!!
Zen are very surprised however and now want to arrange another OR visit number 11. I think it’s an waste of everyone’s time and are going to decline, however I might write to Clive Sellys office again.
-
if it's over 8 weeks, it may be worth going the deadlock letter route: https://www.ofcom.org.uk/phones-telecoms-and-internet/advice-for-consumers/problems/broadband-landline-faults
I would not cancel the engineers, someone less technical would be completely at a loss if they were going through the same issue.
-
The dead lock only helps if I wanted out. Moving ISP is possible as I’m out of contact but I doubt that would resolve the issue. I’m not optimistic that this would ever get fixed from the comments in the thread.
-
Help * Back on topic,
Zen tell me I'm now on TT backhaul so a different supplier will look at the fault ! In my mind I'm still connected to the same PCP and DSLAM so how could TTB change my sync speed. I'm at loss how to explain this to Zen
-
Help * Back on topic,
Zen tell me I'm now on TT backhaul so a different supplier will look at the fault ! In my mind I'm still connected to the same PCP and DSLAM so how could TTB change my sync speed. I'm at loss how to explain this to Zen
Same IP Address?
What profile do Zen have you on, will they hand out that information?
-
Same IP Address?
What profile do Zen have you on, will they hand out that information?
Same IP
Speed
-
Zen tell me I'm now on TT backhaul so a different supplier will look at the fault ! In my mind I'm still connected to the same PCP and DSLAM so how could TTB change my sync speed. I'm at loss how to explain this to Zen
Was it BTW backhaul before the change?
Zen might be more confident in TTB pushing OpenReach for a resolution.
-
Yes it was before. Do the backhaul provider create the faults, or is it the ISP direct to OR, the latter I thought ?
-
Help * Back on topic,
Zen tell me I'm now on TT backhaul so a different supplier will look at the fault ! In my mind I'm still connected to the same PCP and DSLAM so how could TTB change my sync speed. I'm at loss how to explain this to Zen
If its same as AAISP, then basically engineer callouts are arranged via the "supplier" which in your case is now TT, so it is actually possible you could get a better result if TT handle the fault better with openreach.
-
@chrysalis that's interesting and maybe worth another shot. Although I expect its like working back to zero with the call outs.
-
@chrysalis that's interesting and maybe worth another shot. Although I expect its like working back to zero with the call outs.
Hopefully Zen have detailed notes of previous faults on BTW to hand to TTB.
(@Alex Atkin UK, that's British Telecom Wholesale and Talk Talk Business :P)
To TTB it will look like a new fault, but if Zen report it early enough, it becomes an Early Life Fault on Talk Talk's systems.
This should give it a higher priority with TTB and more weight on their systems to be fixed.
-
Thanks. I will let them book another OR engineer. However it might be one of the three already been twice each ???