Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: BobC on November 04, 2021, 01:29:20 PM
-
Hello, I was here earlier this year complaining about gradual broadband speed declines over the years. After 5 years the issue was finally resolved at the telepole fixing the corroded wire. I then proceeded to switch from BT to Zen due to the 24 month contract requirements and costs.
The switchover was fine but I'm experiencing a few irritating issues. The first one is randomly losing connection to Zen's ISP. So we randomly lose connection to Zen the ISP provider but the dsl connection remains connected. So what happens when we lose connection to Zen? Well... a few things. Sometimes the connection re-establishes itself after 10-50 minutes. Another option is to clear the account information and resubmit the username and password and test a manual check through the router. The third option is restarting the router and doing approach 2 and hope it reconnects or phone Zen who have us doing the same thing time and time again. Restore to factory settings etc, use our test username+password etc. The connection finally re-establishes at some point. This can then be working from anywhere between 3 and 60 days then the same issue happens again... It's annoying because sometimes it doesn't automatically reset and requires some messing about, and there's no guarantee it resolves itself without a call.
The second issue is the line can randomly get flooded with errors. When this happens the corrected DTU's goes as high as 150,000+ with a build up of CRC, ES and SES errors before dlm intervenes and restarts the connection or I spot it and restart the router. If either are done the line miraculously fixes itself. No more packet loss, no more errors or anything... Normally the corrected DTU's is between 10 and 1k with a few ES errors here and there per month. This issue is just as weird as the first one because it happens totally out of the blue as in it isn't happening frequently. The only time I generally get an error build up otherwise is if there's thunder outside, but that never seems to spark 1000's of errors in the space of 30 minutes,
Post corrosion fix the random surge of errors wasn't happening with BT. Post or pre corrosion fix the connection being lost to BT never happened. The HUB went down for random reboots every 14 days but that took the dsl connection down with it.
Honestly why do I keep getting the most bizarre issues that are rarely reported.
My Mum's partner was given a fault reference code a few months ago after reporting the issue twice. It's happened quite a few times since then. I restarted the router 10 days ago to try and fix a loss of connection between me and Zen. 3 days ago the dlm intervened due to a high error build up overnight and then in the early hours of this morning the connection was lost for 20-30 minutes. This can happen at any time of the day but I have noticed the error build up does tend to occur mostly between 3 and 7am.
Any ideas what this could be? I don't think it's necessary but I will post a screenshot of my stats anyway.
-
Migrated my 40/10 VDSL service from Plusnet to Zen last December.
Have noted on very rare occasions my PPP session will drop while still maintaining line synch, has occured at most 4 times in the close to year BB provision with Zen, always occurs overnight.
As I prefer a separate modem/router setup I just unplug the modem/router WAN connection on the modem for a few seconds and the PPP session will re-establish very quickly on re-connecting the cable, never had to re-boot the router, modem remains in synch.
I run DSLStats 24/7 on a RPi, the modem stat's never indicate any major upsets which could be attributable to the PPP drop out.
With the infrequency of the events and the very easy fix have never reported anything to Zen, doesn't really bother me and remain happy with Zen's overall service after escaping from Plusnet.
-
Migrated my 40/10 VDSL service from Plusnet to Zen last December.
Have noted on very rare occasions my PPP session will drop while still maintaining line synch, has occured at most 4 times in the close to year BB provision with Zen, always occurs overnight.
As I prefer a separate modem/router setup I just unplug the modem/router WAN connection on the modem for a few seconds and the PPP session will re-establish very quickly on re-connecting the cable, never had to re-boot the router, modem remains in synch.
I run DSLStats 24/7 on a RPi, the modem stat's never indicate any major upsets which could be attributable to the PPP drop out.
With the infrequency of the events and the very easy fix have never reported anything to Zen, doesn't really bother me and remain happy with Zen's overall service after escaping from Plusnet.
It's happening a bit more frequently on my end and it doesn't always re-establish a connection with the ISP. It's happening enough times to warrant a problem. I'm using the router as an all in one so I can't do what you do. I don't want to use a combo of modem + router though due to inadequate spacing.
The only times the dsl connection as dropped since switching to Zen so far is when the router as been rebooted by myself, power cuts (A few occured in July back to back) or the dlm restarting the connection twice due to those random error builds up that are inconsistent then knock the connection out... I don't understand why this is happening either. It can be fine for a month then a random spike causes hundreds or thousands of errors in such a short space of time. This too as happened a few times but I caught some of them early on and restarted the router and everything was fixed. This is why I still have the 3db SNR because when the dlm kicks in it changes to 4 then finds it stable enough to go back to 3 after a couple of days.
-
I've migrated a couple lines away from Zen in the past 18 months.
The Zen and IDNet (a Zen reseller) sections on the ThinkBroadband forums have quite a few recent complaints about PPP sessions dropping/general downtime.
Email support is non existent. Backhaul choice flexibility is completely gone. Their control panel doesn't even tell your what backhaul you are on now.
Their Manchester/London peering/routing is broken for many. If the system picks the wrong 1 for your location, tough.
The final straw for me was an upstream fault on an FTTC line that reduced sync from 7Mb to 0.8Mb.
3 emails unanswered and 2 phone calls where the rep kept repeating that the downstream was within estimates so they wouldn't help.
They are not the company they used to be. Far from it.
-
I so agree. Really bad experience with one of my Zen circuits reported on another thread on this forum. After getting all the fault issues wrong the billing suddenly doubled my bill. Getting it resolved was a nightmare as they ask you to email billing, but never replied.
-
I've migrated a couple lines away from Zen in the past 18 months.
The Zen and IDNet (a Zen reseller) sections on the ThinkBroadband forums have quite a few recent complaints about PPP sessions dropping/general downtime.
Email support is non existent. Backhaul choice flexibility is completely gone. Their control panel doesn't even tell your what backhaul you are on now.
Their Manchester/London peering/routing is broken for many. If the system picks the wrong 1 for your location, tough.
The final straw for me was an upstream fault on an FTTC line that reduced sync from 7Mb to 0.8Mb.
3 emails unanswered and 2 phone calls where the rep kept repeating that the downstream was within estimates so they wouldn't help.
They are not the company they used to be. Far from it.
So I take it this is an issue with Zen directly? It as nothing to do with Openreach / cabinet? The dsl connection looks solid overall. I thought it may have been a faulty router but the cpu / power usage never spikes and the uptime is only resetting when I manually restart the router. What's annoying is I do have to restart the router at times when the connection drops as it seems to fair better with a router restart + manually inputting the details in again. A few months ago I did exactly this and the connection with Zen resumed but my details had changed to 1970 so the connection was still out. Restarted the router again, manually input the username+password into the account information and it reconnected with the current time and date but none of the little workarounds are guaranteed temp fixes. If I attempt this when the connection is lost without a router restart all I get is a message about blocked packets. I don't have the full sentence to paste at hand but if it happens again, which it will, I'll paste the error information when trying to establish a connection directly with Zen. This same error can also display upon router restarts but I do find that it as an easier time re-establishing a connection after a router restart. I would like a fix to this but I guess it's down to Zen to sort it out on their end.
If you're allowed to send direct links to these threads you're referring to could you please?
As for these random sudden build up of errors on the line is that normal with 3db and no manual router restarts? I noticed a pinned thread on one of the Kitz forums talking about interleaving and uncapped, fullspeed and them having these random outbursts of errors on the line. In the past I always had routers that forcefully rebooted every 14 to 21 days. The Fritzbox never seems to reboot unless I manually restart it. So I'm now wondering if this is normal behaviour, as I'm not on the shortest of lines either, still weird though because it's really random and just happens out of nowhere, when the rest of the time it's perfectly fine.
-
You need to talk to Zen about this. They used to be a good ISP and should in theory sort you out. The error counts that you’re seeing are the result of a fault in the line or interference (or increased vulnerability/susceptibility to interference due to a line fault). That’s down to Openreach not Zen. My guess about ‘losing the connection to Zen’ (not clear exactly what you’re seeing here) is tha the PPP session is dying for some reason. That is Zen’s problem most likely. If Zen can’t fix it, then I would have to do you-know-what (what does Weaver always say, like a cracked record?).
> As for these random sudden build up of errors on the line is that normal with 3db
Yes. That’s a very very slim margin, conditions have to be very good, but G.INP is incredibly effective and makes 3dB instead of 6 dB feasible when things are normal. But when things aren’t normal, a target SNRM needs to be 6dB or even 9dB.
-
@weaver has put that simply for you. The PPP drops, are perhaps routine Zen balancing their gateways. I do get these periodically on both circuits. I might have misread your post, but I don’t think these are very frequent and in the early hours indicating a maintenance event.
-
And thanks to J0hn for his revelation, something that I didn’t know. PM me if I can help.
-
The only time I've seen very high and seemingly random error counts on my line was when a modem/router was starting to die. It would be fine for days and then suddenly errored seconds would be racking up at a crazy rate. A reboot appeared to fix it but the time between incidents got shorter and shorter so I changed it out, at which point the issue stopped.
-
I wanted to chime in just to say I've never noticed PPP drop on Zen. That's not to say it doesn't, but pfSense has always reconnected.
Of course I probably wouldn't notice when it happens as I have fallback onto Plusnet and Three which means routing only fails if a connection is not coming back up correctly (eg OpenVPN clients can be fun if they suffer packet loss so keep dropping/reconnecting, restarting the firewall each time)
Of course as you seem to be using the Zen provided router, if PPP is not reconnecting properly I'd consider it a Zen problem.
As for the Manchester/London routing, I think I stopped going via Manchester when they moved me onto TTB backhaul.
-
I rarely get PPP drops with Zen and only become aware of overnight drops because I have https://f8lure.mouselike.org/auth.asp monitoring my NAS box (via IPv6). Last drop was Thursday around 2:30 a.m and it came back automatically 10 minutes later (I suspect BT as load balancing would have come back quicker). I can't remember when the last drop was.
-
Heaps of problems yet again today. Screenshot attached.
Only took about 1 hour to get the internet back on. Dsl connected. Connection to Zen lost. Waited about 25 minutes before restarting the router, router restarted and no connection as expected. Tried inputting the account details in like I always do then received as shown in the screenshot which is all too common when this happens. Restarted the router again same errors. Backed up my current settings and factory reset it, still the same errors. Then it just randomly comes back on 15 minutes later. This issue is really frustrating.
That was 3 router restarts and some messing around to get it back on. If it stays on and settles I will restore the settings prior to the factory reset, don't want dlm interfering with my line as it looks stable most of the time from a dsl connection perspective.
-
Sick and tired of problems with the internet. Why can't mine be reliable? I seem to be plagued with neverending problems all of the time.
So that original issue with the PPPoE disconnects with the ISP provider was resolved with a replacement FritzBox 7530. It isn't disconnecting in the same way anymore. A good thing right? Sort of...
So with the router replacement I swapped out everything including the original dsl cable supplied to me years ago with the BT HUB. With the first FritzBox install last year I didn't bother to change the dsl cable, just swapped over the routers and used the provided power adapter. With the recentish replacement router I changed the router, power adapters and the dsl cable. So one of these issues is the corrected DTU's reaching unbelievably high numbers and causing countless errors on the line. It was doing this like once every month of uptime previously. Now there's no pattern to the madness. It can be 0 ES, 0 SES and 0 CRC for a day, a week or two then in the space of an hour those error rates have shot up. Even if I leave it and continue to monitor the stats and the corrected dtu's fall from tens of thousands back down to the 100-500 per 15 minutes it's bound to happen again in the space of a few hours once those corrected DTU numbers begin to rise into the thousands until the dlm intervenes or I restart the router. Can someone please confirm whether this can be an internal wiring issue or is it something outside? Rebooting the router always fixes the high counts straight away but the times between it re-occuring are allover the place.
The second issue which I didn't mention in the thread earlier was relating to a faulty ethernet cable affecting one of the upstairs PC's. That too was causing PPPoE disconnects with our ISP provider every 30-40 minutes when downloading but that problematic ethernet cable was also disconnecting and reconnecting to the router every now and again, hard to notice because it woud drop the DHCP lease time and reconnect within seconds. As soon as we replaced the router and that issue continued to happen we quickly narrowed it down to that one device with that ethernet cable when downloading data. We ran a temporary cat6 cable up the stairs and that resolved it when downloading. Now onto currently. We bought a flat cat7 BUSQHE 10m cable. I know 24awg pure copper round cables are preferred but the Stepdad refused to fit a round cable due to the distance between the router and the upstairs PC. We stupidly wired it all up. I went to download something more recently through the Steam client and the PPP session between the router and our ISP was disconnecting and reconnecting every 2 minutes. Went on the downstairs PC and tried to download something else through Steam and the same issue. Just a week earlier everything was fine with the temp cable placement for the upstairs PC. The ethernet cable on the downstairs PC never caused this issue up until this point either. Everything else on the network is either over WIFI or never used for downloading purposes but streaming data instead. Does anybody have any idea what could have happened? We haven't had chance to mess around with the cabling yet to try and resolve this latest issue.
-
It kinda depends. If rebooting the router fixes it but you sync at more-or-less the same rate and configuration, I'd be thinking there is a problem with the line card.
However if rebooting fixes it and your sync rate is a lot lower, then its likely interference from something.
-
It kinda depends. If rebooting the router fixes it but you sync at more-or-less the same rate and configuration, I'd be thinking there is a problem with the line card.
However if rebooting fixes it and your sync rate is a lot lower, then its likely interference from something.
If I catch it in the moment when both the corrected DTU's and uncorrected DTU's are going wild causing these ES, SES and CRC errors to jump to crazy numbers and I restart the router it resolves it. The INP sometimes changes from 51 to 52 or vice versa and my gateway used to be cor1 Lon or something but in the past month the gateway as changed to Man-RE0 or the London equivalents. Sync rate remains the same and those correction numbers fall dramatically until the next encounter. The Fritz!Box 7530 router I had before the replacement arrived had the same issue but there seemed to be a very clear pattern to it with it happening once per month of uptime. With the replacement router it can be 0 errors for a day, a week, 2 weeks then a flood of errors come in due to the dramatic rise in corrections. The per minute corrected averages used to settle around about 18 on the old router until that monthly spike. Now though the Corrected DTU's are just bouncing allover the place with no clear pattern. I just took a look at the router stats right now and those corrections are rising once again. The last time I left it alone without rebooting the dlm intervened due to the error count exceeding the daily limit but 2 days later I was back from 4dB to 3dB. Should I just leave it alone and let these error counts rise? It hasn't completely fell of a cliff as of yet but with 32k corrections and some errors forming in the past 15 minutes alone it's only a matter of time. I guess the issue is outside and beyond my control because I changed the dsl cable, the router and the power adapter this time around and it still happens, admittedly much more often, but nothing looks out of the ordinary or changes by much when checking the limited stats provided by the router such as signal to noise ratio, the spectrum information, the Fritz!Box cpu usage and temps etc.
As for the router dropping the PPP session every 2 minutes when saturating the line since fitting this new cat7 cable, any idea what that issue could be? Everything seems to point to a faulty cat7 cable or some kind of interference knocking the connection out temporarily between the router and ISP. We will try removing that cable first of all and hopefully that resolves it. If not I have no idea how we'll go about fixing this new issue.
-
As for the router dropping the PPP session every 2 minutes when saturating the line since fitting this new cat7 cable, any idea what that issue could be? Everything seems to point to a faulty cat7 cable or some kind of interference knocking the connection out temporarily between the router and ISP. We will try removing that cable first of all and hopefully that resolves it. If not I have no idea how we'll go about fixing this new issue.
I would be very suspicious of any cable that is labelled CAT7, especially one with a flat profile. Proper CAT7 (and above) cables are really for data centre usage. In a typical domestic environment CAT5e or, if you must have a bigger number, CAT6 be perfectly adequate. I'll hazard a guess that our member "Reformed" will probably be able to state actual bandwidth v distance figures for the various category cables.
-
I would be very suspicious of any cable that is labelled CAT7, especially one with a flat profile. Proper CAT7 (and above) cables are really for data centre usage. In a typical domestic environment CAT5e or, if you must have a bigger number, CAT6 be perfectly adequate. I'll hazard a guess that our member "Reformed" will probably be able to state actual bandwidth v distance figures for the various category cables.
Yeah I only made that mistake once, it wouldn't even do 10Gbit.
I do have a CAT8 flat though, wanted to over-spec as its running from the PoE switch to an Ubiquiti PoE converter for my Litebeam WiFi link across the street. So wanted to be absolutely sure there was plenty of grounding on that cable in the hope a nearby lightening strike wouldn't take out the switch.
-
So I removed the cat7 cable from the router port tried to download something from Steam on the downstairs PC with a previously stable ethernet cable and I lost connection 3 times in a row with Zen. Event log attachment available below. I downloaded CyberPunk 2077 on it last month which was 64gb and all was good. I downloaded Mass Effect Legendary Edition on the upstairs PC which was like 105-110gb with that temporary cheap cat6 cable that was being ran up the stairs and that was fine.
So today I was downloading Prey on the downstairs PC which was like a 20gb file. 3 drops occured early doors then it was fine. Re-inserted the cat7 cable and things continued to look stable for the rest of the download. Went back upstairs and CyberPunk had a 4 or 5gb update so I started downloading that through the cat7 cable and the connection with the ISP provider remained stable, there was a slight wobble though. The connection speed dropped to 6kbs for a few seconds then shot back up to 66Mbps. I checked the dsl information tab and spotted this Min. effective data rate kbit/s 6. Was previously at 60Mbps. Never seen this issue before either... I think I need to get shut of FTTC the issues I have with it stresses me out. Unfortunately I didn't have a ThinkBroadbandMonitor running in the background to test the amount of packetloss...
The issue with the high rise in Corrected DTU's which in turn causes errors on the line until a router reboot definitely seems like something outside. I can't keep on blaming the FritzBox routers and the cables provided surely? It's a complete random occurence. Corrected DTU per minute average 10. Last 15 minutes 23 with a 2 day 7 hour uptime. I was going to switch back the FritzBox provided dsl cable back to the one provided with my BT HUB years ago but it's a lot of messing about.
The few errors that accumulated on the dsl information screenshot occured when messing around with the ports on the router and undoing the cable tie. I don't understand the spectrum stats but I included the minimum / maximum graph even though I have never seen them stoop that low whenever I have checked that graph out with the min / max unticked. The signal to noise ratio graph also always stays between 3 and 4.
-
Your problem(s) is (are) very perplexing. ??? I do not understand why the circuit behaves as you report.
-
Honestly I'd be thinking the router is faulty somehow.
-
I believe your problem is similar to mine. I don't think this is to do with your Fritzbox (I get the same results on my Zyxel and Draytek, in addition to my Fritzbox).
In my case, there is a high resistant fault (something to do with jelly crimping) that openreach won't fix because of where the cables are and how accessible they are. I believe there's also noise on the line (it seems that when our neighbours are in, and they are not in often nowadays, and when they put something on, presumably the boiler or water tank heater, for every 2 errors on the line (ES on fritzbox), I usually get one SES, but this, I believe depends on how intensive the noise thing is, which makes me think it's a hot water tank). During this the min effective data rate also gets reduced to 3kbps).
So far, I've been trying to resolve our issues for over a year now since we started working from home and switched over to VDSL. Lots of testing, lots of money spent, too, lots of emails to Plusnet and lots of openreach visits (14 at least). Openreach weren't transparent with us: two mentioned a high resistance fault, whereas another admitted they didn't know where the interference was coming from, but because no-one complains from the neighbours who also have the problem as confirmed by them and BT wholesale (all retired and don't use the internet as much), they'll not investigate just one flat.
-
@Edinburgh_lad One extreme technique that I employed last year was to order an additional line and then cancel (‘cease’ ?) the bad one.
-
I don't believe this is a physical line issue as only the PPP connection appears to be dropping. More likely either a Zen config issue or an issue with a linecard.
-
I believe your problem is similar to mine. I don't think this is to do with your Fritzbox (I get the same results on my Zyxel and Draytek, in addition to my Fritzbox).
In my case, there is a high resistant fault (something to do with jelly crimping) that openreach won't fix because of where the cables are and how accessible they are. I believe there's also noise on the line (it seems that when our neighbours are in, and they are not in often nowadays, and when they put something on, presumably the boiler or water tank heater, for every 2 errors on the line (ES on fritzbox), I usually get one SES, but this, I believe depends on how intensive the noise thing is, which makes me think it's a hot water tank). During this the min effective data rate also gets reduced to 3kbps).
So far, I've been trying to resolve our issues for over a year now since we started working from home and switched over to VDSL. Lots of testing, lots of money spent, too, lots of emails to Plusnet and lots of openreach visits (14 at least). Openreach weren't transparent with us: two mentioned a high resistance fault, whereas another admitted they didn't know where the interference was coming from, but because no-one complains from the neighbours who also have the problem as confirmed by them and BT wholesale (all retired and don't use the internet as much), they'll not investigate just one flat.
Methinks you are jumping the gun, slightly.
If your circuit has a high-resistance fault (HR), then that absolutely requires mending first before you can even contemplate the second scenario you are alluding to, which is REIN.
The metallic path facility (MPF), has to pass a various suite of tests to ensure its integrity is capable of eliminating normal levels of noise interference'. If there is a HR prevalent, then the circuit is highly susceptible to these normal levels of noise, causing multiple errors/LOS/PPP drops.
Once the MPF is deemed as good, only then can the finger of suspicion be pointed towards REIN/PEIN/SHINE events should the issue continue.
Plus, OR will of course investigate - whether it's one flat or 200 flats. The technology has changed indescribably in the last 3-4yrs for pin-pointing patterns of noise, timings, circuits affected etc etc ..... but REIN faulting is still a gratis service provided by OR, it is not a given. If Mrs Jones powerline adapter in the flat above yours is causing high frequency noise events, OR nor your ISP can be held accountable for that.
Regardless of that though - if you suspect you still have a HR, why not try and force the fault by using your landline on 'quiet line test' or ringing someone and see if your error rates continue to climb. That is a sure-fire way of knowing.
[Moderator edited to remove one spurious [/b] tag.]
-
I'll hazard a guess that our member "Reformed" will probably be able to state actual bandwidth v distance figures for the various category cables.
Not really! Those are minimum standards they've passed but most of the time the shorter runs we have in our homes will handle way more.
I use 7 for short runs as it's a more durable cable. It is prone to more faults when being made though. It's not fun to attach the RJ45 plugs to.
That's what I do anyway. 7 for very short patch cables, DACs for sub-5m unless I have to use RJ45 in which case 6 or higher for 10G just to be sure, 5e for 2.5/5G, fibre for anything longer. I buy premade so that they may be returned and don't make enough cables to justify a drum as I don't use that much of those types. Freebies with equipment cover most of my needs.
Pluggables, so SFPs, don't seem to transmit at as high a power as direct ports in some cases so don't run them at 10G over more than 30 metres.
With 10 metre runs most Cat5e and above should be fine with 10G, with 6 certified to 55 metres and 6a and above 100.
-
Methinks you are jumping the gun, slightly.
If your circuit has a high-resistance fault (HR), then that absolutely requires mending first before you can even contemplate the second scenario you are alluding to, which is REIN.
The metallic path facility (MPF), has to pass a various suite of tests to ensure its integrity is capable of eliminating normal levels of noise interference'. If there is a HR prevalent, then the circuit is highly susceptible to these normal levels of noise, causing multiple errors/LOS/PPP drops.
Once the MPF is deemed as good, only then can the finger of suspicion be pointed towards REIN/PEIN/SHINE events should the issue continue.
Plus, OR will of course investigate - whether it's one flat or 200 flats. The technology has changed indescribably in the last 3-4yrs for pin-pointing patterns of noise, timings, circuits affected etc etc ..... but REIN faulting is still a gratis service provided by OR, it is not a given. If Mrs Jones powerline adapter in the flat above yours is causing high frequency noise events, OR nor your ISP can be held accountable for that.
Regardless of that though - if you suspect you still have a HR, why not try and force the fault by using your landline on 'quiet line test' or ringing someone and see if your error rates continue to climb. That is a sure-fire way of knowing.
[/b]
I don't want to hijack the OP's post, but in the words of one Openreach engineer that came to see us (in fact the very first one): 'it is what it is', which sums up everything. Seemingly there were no spare 'good' pairs in the cable and the cable is underground and they couldn't access it, so that's where we are.
However, today, Virgin Media have brought their equipment in to put their FTTP in the area, so I can't wait to wave goodbye to Openreach.
-
I don't want to hijack the OP's post, but in the words of one Openreach engineer that came to see us (in fact the very first one): 'it is what it is', which sums up everything. Seemingly there were no spare 'good' pairs in the cable and the cable is underground and they couldn't access it, so that's where we are.
However, today, Virgin Media have brought their equipment in to put their FTTP in the area, so I can't wait to wave goodbye to Openreach.
Yeah - I read a lot of that 'He said, she said' stuff.
If you've had a poor engineer, well the odds are that's going to happen with circa 30,000 of them employed by OR .... but you've had "14 engineering visits at least". That sounds more to me like somebody isn't in possession of the full facts, or has misinterpreted what's been said by the engineer, or your circuit is performing within the 'cone of acceptance' agreed between OR and the ISP's ....... either that or there's a conspiracy theory going on between 14 different OR engineers, and your ISP ?.
If for whatever very bizarre reason OR can't access our their own underground cables, there's a plethora of alternative solutions that can be used. Simply put, OR can not leave a live fault on a customers MPF - with the previously mentioned advances in remote testing and collating of data, there's not a cat in hell's chance OR's 14 different engineers have simply walked away from a full on fault condition without either fixing it, or applying remedial measures to fix it.
-
And me also not wishing to cut in on the OP’s thread, but what BS just said is relevant to me and my always-fixed faults, but never fixed long-term. See https://forum.kitz.co.uk/index.php/topic,26851.msg450753.html#msg450753 - If you’re willing, perhaps contribute on this topic but in that thread. That would be appreciated.
-
I'm going to leave this post short with screenshot attachments. A continuous flow of corrections / errors building yet again. From 0 to this after several hours with 5 days 12 hours of uptime this time around. The entire thing is just unstable and unreliable :/. I'm not going to bother rebooting the router to clear them, evidently had enough. FTTC is just rubbish. The issues that crop up on my line or at the cab or wherever the latest issues are never seems to be easily identifiable, sucks it really does.
That peculiar isssue with the downloads is still happening as well, The Fritz!Box 7530 router disconnecting the link with the ISP then re-authorising it, then all of a sudden it's stable? I have noticed that saturating the line with Usenet downloads appears to be far more stable than Steam in regards to PPP disconnects, but as this issue is recent, and we already tried removing the only new thing ie one new ethernet cable, that issue is just as confusing as any other irregularity I've experienced.
-
Didn't someone else have a Fritzbox 7530 recently that was unstable and got it replaced which fixed everything?
-
Didn't someone else have a Fritzbox 7530 recently that was unstable and got it replaced which fixed everything?
It's a red herring. I have the same problem as he does (almost exactly) and so it's unlikely that BobC's issues were the same as mine because of the router. Plus, I've also tested using other routers (Broadcom/Lantiq-based) and it makes no difference.
Here is my Fritzbox graph from Sunday 2 weeks ago and from this Sunday (I believe the discrepancy in the times errors occur is due to BST change, but this could be a red herring, too). Is it that all my neighbours are on the Internet around the same time, their browsing resulting in cross-talk and so errors? Is it some kind of interreference (someone's equipment) that's on on Sundays - the times of errors suggesting that and also that it's a system on a timer like a boiler or hot water tank? Or is it a high resistant fault that has never been fixed because the line is difficult to access and it's performing within parameters (3 disconnections a day according to Plusnet and OR is acceptable). After the three drops today, preceded by an accumulation of errors, I have no errors on my Fritzbox counters at all despite being connected for 5 hours now.
So, in a nutshell, I have the same problem as BobC, including the fact that Min. effective data rate on my Fritzbox goes down to 3, whereas his is 6 kb/s.
BobC: what exchange are you connected to? Also, have you noticed that your 2.4GHz WiFi is also affected when these errors occur? Mine seems to be affected to the point where the router slows down big time, ping and jitter increase etc.
Another question to those reading the thread: what's the impact of an amateur radio station on VDSL signal?
-
Is it that all my neighbours are on the Internet around the same time, their browsing resulting in cross-talk and so errors?
Crosstalk doesn't work like that. It's the sync from a neighbouring line that causes interference not the traffic they send.
As almost everyone leaves their modem/hub synced 24 hours a day then the crosstalk is always present.
It can be very noticeable when a crosstalking line gets activated for VDSL2 as the SNRM and the attainable drops. Next resync will be at a lower rate.
When 1 of these lines goes on holiday for a week and turns off their modem the SNRM increases as does the attainable rate, meaning you can sync higher temporarily.
Crosstalk is very much a lottery. The neighbour next door might have zero effect on your line as their pair may not be adjacent to yours in the bigger bundle. However someone from the next street down might be knocking 10Mb off your sync with crosstalk as your pairs run together for hundreds of meters.
-
I'm curious, how exactly does an idle line in sync cause the same crosstalk as a loaded line in sync? Logically there should be less noise, same way a WiFi Access Point creates less interference if its idle than if its active.
-
There are constant PTM packets being sent/received whether the line is being used or not.
It's the same reason that CRC/ES are the same for a line downloading at full rate as they are for a modem synced with no router connected.
The signal is always there. Power doesn't increase when traffic is being sent.
-
In ADSL, with ATM, you’re sending idle cells all the time, is that that right? In VDSL, with PTM, That isn’t the case, so I believe, but I’m unsure.
-
Yes the signal is always there, but surely its not just constantly sending empty packets at max line rate, that would be hugely wasteful in electricity.
-
In ADSL, with ATM, you’re sending idle cells all the time, is that that right? In VDSL, with PTM, That isn’t the case, so I believe, but I’m unsure.
I believe it's the same with PTM.
Yes the signal is always there, but surely its not just constantly sending empty packets at max line rate, that would be hugely wasteful in electricity.
It uses the same power whether data is being transferred or not. It's required to maintain sync.
It's a very small amount of power, often single digit mW.
-
I desperately need to reread the docs about PTM framing and ADSL2 / VDSL2 specs again because I’ve forgotten important details. But I suppose when you have no PTM PDUs to send, at the physical layer you just send some arbitrary constellation of some sort over and over again, anything that doesn’t look like a valid start-of-frame.
-
I desperately need to reread the docs about PTM framing and ADSL2 / VDSL2 specs again because I’ve forgotten important details.
You're not the only one. :)
Nowadays I rely upon forum members (say Reformed, for one example) to put right my incorrect memories.
-
Also, whilst wearing my moderators collar, I should mention that we have rather hi-jacked BobC's topic. :-[
If he should so wish, I could see about splitting off those posts which are not related to his (ongoing) problem.
-
It uses the same power whether data is being transferred or not. It's required to maintain sync.
It's a very small amount of power, often single digit mW.
Thinking about it more I guess this kinda makes sense, would need some complicated form of SRA that goes up and down on demand otherwise.
I still don't understand how the crosstalk would be the same though, how can it be equally as noisy when not transmitting data (above what's necessary to keep the link and PPP connection live) as it is when heavily loaded? I mean there's been plenty of cases where people have said their line drops when loaded but is stable when idle or lightly utilised, which would surely run contrary to what you are saying?
-
I still don't understand how the crosstalk would be the same though, how can it be equally as noisy when not transmitting data (above what's necessary to keep the link and PPP connection live) as it is when heavily loaded? I mean there's been plenty of cases where people have said their line drops when loaded but is stable when idle or lightly utilised, which would surely run contrary to what you are saying?
It's the noise a line is receiving that's the problem, not what it's sending out.
-
So, I've done as someone suggested (I can't remember - I think it was Black Sheep - but thank you) and I dialled a number from my landline to my mobile. Immediately, the error count (ES) jumped up from 16 to 35 during the time I heard the ringing tone. However, the errors are on 'Central Exchange' part only on Fritzbox, which, I presume, means 'send' direction, rather than 'receive'.
-
What happens in the other direction (dialling your landline from your mobile)?
-
No change in error counts.