Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Chrysalis on July 09, 2017, 11:18:41 AM
-
Line is completely dead today :(
no sync light on modem, no voice tone.
The fact there is no voice tone should at least make it easy to report, shouldnt have to go through sky hub routine on fault.
-
:(
Hope that you get it sorted soon.
-
thanks kitz, it is an external fault detected on tests so no engineer visit required, 1-5 day fix time.
Some sites arent working over EE, they only on ipv6 no ipv4, all ipv4 traffic they use a tunneling system and I think its not working properly. All fun and games today.
Also my VOLTE is broken so when I make a call I am dropping down to a slower connection as well.
-
thanks kitz, it is an external fault detected on tests so no engineer visit required, 1-5 day fix time.
Is there any indication as to the location of the fault?
The reason why I ask is that if an out-of-control vehicle has flattened the "fibre" cabinet, both the Broadband and telephony services would be non-existent. If that was the case, the big unknown is what manufacturers' equipment would be used for the replacement.
-
no idea I cannot see my own cabinet from here, but I will pray you are right.
-
I have left my modem powered down, but will check if its fixed using the handset.
I have fixed also most of my EE issues now and can reach most endpoints, I managed to force ipv4 natively to bypass their ipv4 inside ipv6 tunneling system.
I will try to look later at my cabinet.
-
It looks like you are still down (MDWS).
The odd thing is that I cant see anything on any of the usual status checkers.
-
I havent looked at the cabinet, its too far for me to walk at the moment, and I am not getting a taxi just to see if its broken :)
I have checked my DP and outside of house, no damage there, so I guess the cabinet is the second most likely spot as rest is underground.
If it is still dead wed afternoon I am due to be going that way in a taxi for a hospital appointment so I can visually check then.
-
Two weeks ago our DSL & Internet LEDS on the 8800NL went blank at 12:00 no connection for 2 hours though telephone worked and called ISP they did the tests and code fault came up as being on OR side this fault effected everyone on are cabinet.
Having a local exchange serving the POTS and another serving the Broadband seems to have an advantage when it comes to situations like this.
-
burakkucat your initial theory might be right.
I checked on the BTw checker, and only adsl is listed.
FTTC doesnt appear at all, not even a waiting list.
-
something might be happening, my phone now has a cord line error, which wasnt present the previous 2 days.
-
I still think its odd that nothing appeared on any of the service status that I could see.
I usually use the Zen one as they are quite detailed with the information.
For example this one which shows NGA FTTC PCP1 - link (https://status.zen.co.uk/broadband/fault-outage-details.aspx?reference=37811)
There's also another one NGA FTTC NMBHKG PCP 26 RAYLEIGH - CARD DOWN CAUSING LOSS OF COMMS
Do you know if its just Sky connections that are down?
-
There is a sky alert for the east midlands, but that is now supposedly fixed and didnt list Leicester, I know there is an openreach issue as my modem isnt syncing. Also sky told me was an openreach external fault detected.
For all I know this external fault could just be my line, no specifics were given.
-
If this means anything.
If I ring my landline, it rings on the phone calling out but not at home.
-
I checked on the BTw checker, and only adsl is listed.
FTTC doesnt appear at all, not even a waiting list.
How very odd. ???
If the service is still out tomorrow, it might be worthwhile asking your taxi driver to drive slowly past the pair (telephony and fibre) of cabinets so you can look and take photographs, if necessary.
-
If this means anything.
If I ring my landline, it rings on the phone calling out but not at home.
Does Leicester suffer from Openreach sub-contractors (either Kelly Communications or M.J. Quinn)? Someone has quite clearly reconnected your pair but to the wrong up-stream telephony circuit.
Are you able to make a call to 17070 so as to hear the "This circuit is defined as . . ." announcement?
-
nope line is dead
before line was dead, but now line is dead 'and' the phone has a "line cord not detected error" (that error usually appears if disconnect phone from socket).
Looks like an attempted repair has happened but been messed up based on the changes and your thoughts, but I have to wait till friday now as sky told me I need to give it up to 5 days.
--edit--
I just tried modem and can confirm that still dead also.
-
Radio Derby saying a major cable fault (Cable Fire) affecting a large area two days ago.
-
yeah is a message about that on the sky user forum but I think thats a sky backhaul issue which wouldnt affect my modem sync.
I am on hold with them, as getting impatient.
--update--
Raised to second stage repair, fault with MU, road works needed, aim to have resolved by midnight 12th july. Sky will be given another update on 13th.
I am about 2 gig into my 10 gig of purchased data from EE right now :) Been watching youtube videos at 240/360p
-
nope line is dead
before line was dead, but now line is dead 'and' the phone has a "line cord not detected error" (that error usually appears if disconnect phone from socket).
Doesnt that usually mean between the DP and customers equipment.
I know you said you have UG. Do you have a BT66? If so are they the old metal IDC blocks which can be prone to corrosion?
-
I dont know whats going on hence me asking for advice :)
I would love to know what a MU fault is as well :)
Its good I have a planned fix date now, before I was advised it could be anything within 5 working days.
Basically the cord error on my BT handset, usually appears if its not connected to the nte5, so basically its just saying there is no detected phone line.
There is kitz what I think is a junction box near the roof, my line is fed from it, however I have never been able to get it checked by an engineer, they tend to take a look at it and decide to not bother. It seems tho openreach already know where the fault is based on what sky told me, it looks like its under a road somewhere if they need to do roadworks.
-
Basically the cord error on my BT handset, usually appears if its not connected to the nte5, so basically its just saying there is no detected phone line.
It would just be looking for the nominal 50V DC across the pair.
As for an "MU fault", perhaps Black Sheep would be able to enlighten us, please?
-
Main Underground
The MUCJ network consists of the cables junction (CJ) network, which connects local exchanges to
each other and to their parent trunk exchange for long-distance calls and the main underground
(MU) trunk network, which connects trunk exchanges to each other.
BT's Copper Cable (https://www.ofcom.org.uk/__data/assets/pdf_file/0030/83766/sky_and_talktalk_group_regulated_costs_for_bts_copper_cable.pdf)
-
Main Underground
Yes, that would be it. Thank you. :)
In terms of main trunk network and the junction network I wonder how much of them are still metallic? I would guess that almost all of both networks would now be optical-fibre based. :-\
-
So how would the MU affect a FTTC connection which is only D side?
Is this MU a secondary fault which they have detected or it can somehow affect the D side as well.
-
MU, road works needed,
So how would the MU affect a FTTC connection which is only D side?
I suppose MU could also apply to the fibre part of the network back to the headend exchange... but then that wouldn't account for why your phone isnt working either would it. :no:
I was thinking last night if it was the Main Underground, then you would expect a lot of people in your area to be affected. I still find it very strange that nothing is showing on the status checkers. The Zen one is usually very good giving info right down to the specific PCP no. Are your neighbours also having problems?
There's one checker that I haven't tried and that is the Openreach one here (https://www.homeandwork.openreach.co.uk/help-and-support/local-network-status-checker.aspx) as it requires your post code.
-
I have sent you a PM, and all the neighbours I speak to are on VM.
-
cabinet looks normal, the mystery is still ongoing :)
Didnt go by it on the way, and I had to make the taxi go by it on way back so I could have a look :)
--edit--
I got dial tone.
-
I got dial tone.
A quick 17070 to listen to the "This circuit is defined as . . ." message would be appropriate. If it does not return your number then that's something else to report to Sky.
-
sorry hospital rang so had to divert my attention
17070 gives correct number
I can ring my phone
modem still has no sync
-
sorry hospital rang so had to divert my attention
That has to be the priority.
17070 gives correct number
I can ring my phone
modem still has no sync
Using the telephone, does it behave as normal; does it sound normal? (I'm trying to assess the state of the D-side pair.)
If "yes" is the answer to both questions, then the lack of access to the Internet will be down to a DSLAM fault or further upstream towards the head-end exchange. Ideally we would really like to know if any of your near neighbours are also affected with the outage.
-
yeah it sounds normal, my theory is I am on a new pair, and its simply not been connected to the FTTC cabinet.
I will ring sky early tomorrow morning giving it time for the midnight today expiry to pass.
-
Hmm . . . That is a possibility. But it causes one to question the competence of the person tasked to fix the fault. :-X
-
I can smell a rat here :doh:
-
Your ISP should have been able to detect a fault and if needed issue one of those OR engineer visits ASAP it's now 5 days without a DSL signal as neither of these has been done it makes me wonder whats going here.
-
I also think something strange is going on. What it is I dont know but a 5 day outage and nothing on any of the status checkers. If it was either the copper or Fibre MU.. or even the cab, I would expect something to show up on the Zen status.
I then started wondering if MU could be something to do with the Sky backhaul but then again you'd expect them to put something up on their own SS. If they had to dig up the road, then would there be anything on roadworks.org as surely it would cause some traffic problems.
If it was a new pair - or rather pair swap- then I wouldn't expect you to then have to wait for them to put the DSL back on it. Its all rather puzzling. Could someone have nabbed the line?
-
A couple of pages back I asked the (somewhat tongue-in-cheek) question --
Does Leicester suffer from Openreach sub-contractors (either Kelly Communications or M.J. Quinn)? Someone has quite clearly reconnected your pair but to the wrong up-stream telephony circuit.
I am wondering if, during the time this outage event has been ongoing, the port on the DSLAM line-card has been allocated for somebody else's use and no one is prepared to admit to the blunder. :-\
-
thanks for the help so far, i have wondered of course if there is a cover story but it went down during dusk on sunday not the sort of hours one would expect an engineer to be working.
have sky accidentally ceased and now are reactivating if yes then their tech support are good actors, are openreach covering up? no idea.
i have just presented what i believe to be the facts. as soon as possible this morning i am ringing sky again.
-
Well I got through to someone who was in a pretty bad mood, wouldnt say anything other than I am on day 4 of the 5 days and openreach are still working on it.
-
Just noticed modem is synced when went into lounge to get food.
And holy I have a good pair, fair to say the banding is now holding line back.
74mbit sync with 10db snrm. Modem is still only connected over lan tho I will connect back to pfsense in a bit, as need to go doctors.
Attainable Rate (Kbps) 92036 36746
-
sky is still down, but I have connected the unit to pfsense and left my phone as the gateway so it should be uploading to MDWS over my EE connection.
I did this before leaving just in case more crosstalk appears so have a set of baseline QLN etc.
-
back online now, so seems fixed.
The way the voice came back first followed by cabinet and then later sky, seems to match what would happen on a new line provision?
-
back online now, so seems fixed.
That's good to know. :) Hopefully no more problems. :fingers:
Since I have been prompted, by N*Star's & Kitz' posts, to give your problem some further thought I have come to a conclusion that something out of the ordinary has occurred and the information, of which you have been provided, is both opaque & non-committal. I guess we will never know the true train of events. :-\
-
If my attainable plummets over next day or so that may suggest they reconnecting other users, so will be interesting to see if it holds.
-
I have just taken a quick look, via MDWS, at your circuit's statistics.
Currently there is not a lot to see. However there is a rather peculiar pulsing in the DS of your SNRM plot. It's not so obvious for the US. :-\
-
yep the snrm is fluctuating.
Sky just rang me up advising me there is damage to the cabinet and it will be fixed within 3 days, he seemed shocked when I told him I am using the connection, so based on what he told me, my connection may well go down again.
I dont know why data like the QLN isnt showing on MDWS, it is recorded ok in dslstats.
I will fire up baldeagle's dsl script and record a snapshot ,. then I will post the montage here.
-
I have enabled auto snapshotting once a day again on BE's script, but will keep using dslstats for the ongoing stats.
-
I dont know why data like the QLN isnt showing on MDWS, it is recorded ok in dslstats.
I believe the Hlog & QLN plots are only created once per hour . . . if I am correctly remembering what tbailey2 has mentioned.
The QLN is, er, "interesting" for the DS bands. I can only describe them as "very furry".
-
My ES/hour per hour isnt looking too good considering the high snrm. I hope this pulsing stops when they finish their work.
-
I believe the Hlog & QLN plots are only created once per hour...
That's correct. The same applies to SNR per tone and bitloading. This was a measure to reduce the load on the server.
-
At a guess the SNRM pulsing your seeing is one of your crosstalker modems is loosing DSL connection every 10 minutes, at least we are getting somewhere with this odd issue it never rains but it pours on Chrysalis.
-
The pulsating can occur if your line comes back up after a power outage. Also seen it happen after an outage and when a crosstalker comes back online.
It can sometimes be resolved by doing a full power cycle of your modem and leaving the line disconnected for a short while.
I don't know why it does this, but the 'after a power outage pulsating thing' its something I've observed way back to the days of maxdsl.
-
yeah they connecting people, I have seen 2 noticeable snrm dips, one of them large, attainable is now below 80mbit.
I got a feeling this is a reroll of the crosstalk lottery and will be annoying if I end up below my previous speed, and especially if this pulsating sticks around.
I think newt may be right on the pulse cause, they now smaller since the large dip, so I assume the affect of that crosstalker with the unstable modem is now drowned out by other crosstalk noise.
-
Ok so it went down again, I got too curious so struggled myself down to within viewing distance of the cabinet, no one there, so it must have gone down of its own accord or someone is working elsewhere en route. I have left the modem powered on, connected to pfsense and will leave the phone routing the net, incase anyone wants to watch the fireworks. My phone will need unplugging at some point tho as its draining faster than the usb port on pfsense is charging it, even with screen off.
-
been using sky on and off but now having a few resyncs close to each other so may turn the modem off as I assume this can trigger DLM.
-
been using sky on and off but now having a few resyncs close to each other so may turn the modem off as I assume this can trigger DLM.
Yes, that would be a wise move.
-
ok so I have been looking at my old QLN data.
dslstats hasnt been keeping historical QLN data, so data I have got is from march and older on my hg612 modem stats, and from today and yesterday, I do now moving forward have daily snapshot graphs been recorded by hg612 stats.
So the fuzzy QLN graph on yesterdays montage is actually almost identical levels of QLN to what I had in march, the only difference is the line been fuzzy not steady, and of course the much higher sync attainable for the same levels of QLN.
My QLN (later) today is the worst I have ever had, however I currently have an attainable of over 80mbit/sec. So it would appear the level of crosstalk present on my line right now is not lower than before the fault but I now have a higher attainable speed. This is assuming QLN is a reliable indicator of levels of crosstalk. The 3rd graph I added from this morning shows the attainable in the 90s with very comparable levels of crosstalk to march of which my attainable was 69. It is as if they have cleaned the line somehow.
Sadly I got no QLN data for this sync This is to let you know that a resync/restart occurred on your line at 09:56 Fri 14-07-2017 local time (+/- 1 minute).
Reason: 1 Remote Defect Indicator/DLM
Current Downstream Sync Rate is now 73971kbps @ 12.4db SNRM. Attainable is 98142kbps
Current Upstream Sync Rate is now 20000kbps @ 18.3db SNRM. Attainable is 39032kbps
as measured at the time of this email.
-
blurghhh. Its definitely got a lot noisier. There is also more sign of crosstalk than previous.
That said my own QLN is showing the same horrible noise that doesnt look too dissimilar and also started fairly recently :/
-
thanks for the insight kitz :)
-
ok so I have been looking at my old QLN data.
dslstats hasnt been keeping historical QLN data, so data I have got is from march and older on my hg612 modem stats, and from today and yesterday, I do now moving forward have daily snapshot graphs been recorded by hg612 stats.
You have a lot more data now on MDWS between now and back to March and well back into last year as well
-
another montage for today, this is on a 97 attainable 2 hours uptime, lower QLN.
-
Well sky just rang to say the fault is fixed by openreach, they literally rang just as I was watching the stats and messing with pfsense gateway failback settings as had another drop.
I asked them to confirm the fix time which they said was 4pm today, my dsl uptime is 17 minutes right now so line rsynced at 3.52pm today.
When the sync has dropped its not a instant recovery like normal, it tends to stay down for a few minutes before resyncing.
We agreed they ring back the same time tomorrow so I can tell them if the outages stop after this point.
What I find odd is how quick sky rang me after the fault been cleared, but maybe they have staff sitting there dedicated to watching openreach fault tickets.
So if the fault is now cleared (by openreach) I would assume no more loss of sync will happen now, and maybe the last few days they have just been monitoring and rebooting the dslam or something.
-
Your circuit is my current default view via MDWS and I can see that things have certainly settled down. :)
But will refrain from any comment regarding the Hlog and QLN plots until 24 hours have elapsed. (Currently your Hlog plot has a severe "tail-end droop", something I occasionally see with Kitz' circuit, and the QLN plot is still "well furry" -- or "fuzzy".)
-
Number of ES since the afternoon resync has pretty much double, averaging 20ES hour.
There was also a SES burst right before the resync. I know I need to wait as the outages might go away now they have closed the fault. The new line condition may be better attainable speeds but error wise looks a lot less stable than before the fault. I suppose not too surprising tho given the extreme amount of QLN now.
Yeah now I have busy bitswapping on every DS tone, before it was only in the adsl power cut back tones and the upper part of DS3. So there is a lot more variable noise going on with the line now.
So 110 ES in 4 hours, be circa 600 in a day with a 7.8db snrm.
-
My concern is the modem disconnections are these being forced by yourself or your line just disconnects out of the blue ?
-
I have not done any disconnections or modem power cycles, they all out of the blue.
They also all last for at least a few minutes. So the sync light stays completely off for a short time before flashing again.
Bear in mind I have also had dslstats problems, so there is bigger gaps on the mdws plots than the outage lengths.
-
My concern is the modem disconnections are these being forced by yourself or your line just disconnects out of the blue ?
If you look, you'll see that except for the last resync, the others are mostly RDIs...
-
I am not doubting you it's the MDWS connection that made me wonder, Look random disconnects are the worse kind of fault the next would be no DSL signal anything else like lower sync rate or loss of fast path to interleaving is a small drop in the ocean, Have always said line stability is paramount over line speed.
-
I agree newt, obviously if it carries on like this I will not let sky close the fault. But I have to give it time to see if the drops stop when openreach have stopped their work, their fault close time was 8 mins after the modem last synced.
If the dropouts stop but the high ES continues then I may well cap the line to a lower speed to get the ES to a rate I am happier with. I actually have no intention of asking for the 74mbit banding to be removed, its probably not a good idea to push this line to a 6db margin with how things are going.
Ok so it seems dslstats stopped about 7am and it was about 11.30am when I restarted it, any other gaps are outages.
My pfsense is auto falling connectivity back to EE mobile data as well which will shorten the gaps of data been sent to MDWS but I think if the dsl sync is down nothing gets sent anyway? not sure on that,
For now I have hg612 stats sending to mdws until I get to the bottom of the dslstats problems. So there shouldnt be a monitoring problem tonight.
http://i.imgur.com/bHYGYuq.jpg
can see the jump after 4pm
-
As for the errored seconds lets travel back in time by 30 days DR Who style this time as a female you were hitting 135 per day and now 248 + it's not extreme you gained a sync of 6Mbps and gained 10Mbps attainable so it very obvious you well see more errored seconds it will still remain in amber
-
the daily total is misleading as it includes the 4 hours missing and the lowered ES from before 4pm.
If the ES slows down again in the morning then fine.
This is my thinking, first I think I am now on the middle DLM profile, it looks like sky may have moved me back at some point, so 1440 new daily ES limit.
It looks like this line might routinely now hit the 600-700 range for ES on a daily basis giving less than a 1000 ES headroom for error bursts and the like, whilst previously I had over a 2000 ES headroom. On the flipside tho the line I think should have more resilience to "external" interference such as storms if it keeps the higher snrm. Previously my line could keep under half this ES rate with a 4.5db snrm, but of course it had lower levels of QLN to deal with.
Roll on g.inp, lets hope there is no problems with the summer testing.
-
If I fill in your MDWS blanks I would say 540 how does that sound to you
-
If I fill in your MDWS blanks I would say 540 how does that sound to you
realistic if the ES slows down again later, too low if it maintains the average hourly rate since the 4pm resync.
-
What the worst that can happen A you go above 1440 es per day then Interleaved and back to Fastpath in a weeks time
The worst case would be B you go above 10 disconnects per day and become banded this looks very unlikely from your stats
-
to me interleaving is unacceptable :) especially if my line loops between interleaving and fast path continuously.
Banding I am not so bothered about. Stability and latency are more important to me. I have even been considering dropping to 40/10 and the only thing that stopped me when I renewed with sky was that they dont offer a static ip on 40/10.
If my ES goes above 600 regularly I think I will apply a 70000kbit cap to the sync to reduce it, I got a feeling the sync will be stable now tho, as I am pretty sure I usually would have had an outage during the evening by now.
-
You may get some T/Storms on Wednesday something to keep an eye on
-
close to 1 ES/min now, 20 since midnight. O_o its increasing each passing hour.
interesting it seems at least on my line with this modem there is a cap on the bitswaps/min, the cap seems to have been long term on my line but before this fault it was only reached for short periods of the day.
during this past week the bitswapping rises sharply during the evening and then hits this cap of about 22-23/min but drops again the next morning. Can see the line is flatlined on MDWS like it hit a ceiling, but it is occasionally able to spike over it. On the previous days it might be easy to assume the line is flat because of an outage but no outage so far this evening so these are actual readings.
This probably explains the steadily rising ES of which I expect to reduce tommorow morning, but has no bearing on the doubling of ES since the resync as at 4-5pm the bitswaps were still low..
-
ok I wont be closing the fault.
The flat line of bitswaps at 22/min just carried on, and it looks like the problem eventually causes the line to lose sync, the line lost sync around 8am and then when it came back up bitswaps were low again. Interesting as well is the last update was 8.07am to mdws and then 9.26am for the next so the outage looks like it lasted for over an hour.
Not visible on mdws is HEC errors, these have been huge, before the fault my HEC was always similar to the CRC count now its many times more.
Not sure what I will be saying to sky yet, whether I just keep it dumbed down that the line went down for over an hour, or try to explain all the odd behaviour.
-
Not visible on mdws is HEC errors, these have been huge, before the fault my HEC was always similar to the CRC count now its many times more.
I've added Header Error Control/min as B0 HEC after B0 FEC in the list as the data is available.
-
cool, great tony :)
-
Even had to visit the Kitz library and read up on what HEC errors are.
HEC Errors - Header Error Check/Correction
Count of HEC Errors. HEC is a type of CRC error check which has been performed on the header of an ATM cell, but 1 bit errors can be corrected. This count is usually where HECs have been uncorrected and have been discarded.
If these errors are too high within a short period of time it will slow throughput... and could even lead to connection instability - See Out Of Cell Delineation.
-
Yep I read it last night as well, kitz wiki the only useful source for it on the internet :)
So I just spoke to sky again.
Update as follows.
Openreach raised a new fault for my cabinet this morning at 10am.
Sky just now ran another line test which is still failing.
Escalated again to openreach.
Fun and games.
I see also now that error rates are up again following the 4pm resync, they were very low between 9.26am and 4pm under 5 ES/hour vs 30+ ES/hour before 8.07am.
-
outage again this morning but for a shorter time 8.56am to 9.37am, I am speculating this has probably been happening since the sync came back last week during the mornings, but I wasnt aware due to the monitoring issues.
Also again is the stuck bitswaps, high error rate all night, then boom by magic after the resync all looks decent again probably now until about 4pm.
-
I wont lie, getting pretty annoyed now, just want it fixed. It was looking hopeful, got to almost 5pm but the afternoon outage occurred. Also it may now only be my line as I am no longer seeing variable levels of crosstalk indicating other lines on the cabinet may be fine.
Looking at kitz thread her problems continue as well, but probably worse for her as its harder to draw attention to error bursts than full on outages.
They saying is a battery needs changing and openreach providing a new status update tomorrow.
-
Ok Errmm so all the power outages in Leicester has damaged a Battery cell somewhere, I suppose if like a car battery when the voltage has gone below the minimum it won't hold the charge for that long even after being fully charged so needs a new one.
-
Well not good news.
Sky just rang me again, they have raised a complaint with openreach as openreach advised battery would be fixed today and it hasnt, and in addition the new fix date is almost a month away the 16 august. With a chance it may be be fixed before then.
-
should be fixed now, issue was that the cabinet was running on batteries, it had to go down twice a day for battery swaps but now power is reconnected.
-
Do you have any idea how full your cabinet is? That sounds fairly impressive that they've only needed swapped twice a day, and service has been consistent inbetween.
That will be the 8am/4pm resyncs/outages you've been experiencing then.
-
As far as I know its highly utilised.
-
I've seen various times mentioned for batteries - 4hrs / 6hrs/ 8hrs all having come from fairly reputable sources.
There was someone on these forums a couple of years ago whose DSLAM was being powered by batteries for several days and he said Openreach were coming to swap them out every 8hrs.
Is yours sorted now Chrys? I just had a quick look on MDWS and cant see any downtime for the past couple of days.
-
yeah its sorted
-
New minor event to report :)
This morning it looks like some work has been carried out I guess on another port/line, this caused temporarily my SNRM to shoot up, this happened twice, after the second time my SNRM is now lower.
The bitswapping which has been stuck for several days at a fixed rate has now since this change moved down to normal levels again, which is the primary reason I posted this update.
This is one of the reasons I didnt push for my banding to be removed, I think my line wont stay capable of the full 80mbit for that long, so if I had it removed I it would only serve to annoy me when the inevitable reduction of attainable occurs.
-
Seems to have affected your upstream most:/ Prior to this morning you were hovering 7.6-7.7 Seems to have settled back at 7.7 again now.
Your max attainable since the other week is the best its been in ages.
-
Looks like the speed checker database is really broken now for my address.
Clean High 21.5
Clean Low 15
Upstream
Clean High 1.2
Clean Low 0.8
Handback threshold 13.1
Is served by cabinet 78 on the checker, I would appreciate if someone can check that cabinet location for me :) So I at least know its using the right cabinet.
---
Thanks to kitz's excellent guide here http://www.kitz.co.uk/adsl/cabinet-lookup.htm#fttc_cab_info I have confirmed it seems to be using the same cabinet.
---
Another update, all the neighbours I checked served by the same pole have normal estimates, I thought I remembered black sheep saying the estimate is based from the pole, but for some reason my own address has a very low estimate.
-
Another update, all the neighbours I checked served by the same pole have normal estimates, I thought I remembered black sheep saying the estimate is based from the pole, but for some reason my own address has a very low estimate.
The "guesstimator" data is based from the DP in question.
-
So do you have a theory why when on the same DP I have different results?
I pm'd you address info so you can check yourself, and neighbours.
-
My feeling is that one (or more) of the databases have become scrambled.
Something else does not seem right, to me . . .
You have mentioned cabinet number 78 but if I enter Leicester as the location, in the Magenta Systems CodeLook database, and select all 109 cabinets, then scroll down to P78 it shows --
Cabinet P78 FTTC doing Field Survey, live due by April 2018 Phase SEP Leicestershire 18b Huawei
That certainly doesn't match the live ECI equipped cabinet, to which your circuit is connected. Very puzzling. ???
-
yeah that is weird, thanks for looking into it.
-
You have mentioned cabinet number 78 but if I enter Leicester as the location, in the Magenta Systems CodeLook database, and select all 109 cabinets, then scroll down to P78 it shows --
That certainly doesn't match the live ECI equipped cabinet, to which your circuit is connected. Very puzzling. ???
That's the Montfort exchange. My guess is Chrysalis is on the Leicester Central exchange. Need to select Leicester North on Codelook.
Cabinet P78 FTTC Available from 15th November 2012 Phase 09a 2012-2013 552 ECI LE3
-
yes i am on leics central
-
That's the Montfort exchange. My guess is Chrysalis is on the Leicester Central exchange. Need to select Leicester North on Codelook.
Cabinet P78 FTTC Available from 15th November 2012 Phase 09a 2012-2013 552 ECI LE3
Thanks j0hn. I realised that and mentioned the above (correct) information to Chrysalis, in a PM, just before going to find my bed.
-
Is fixed now.
-
Due to lack of MDWS I got an update.
Lost sync just now, line stayed dead for a couple of minutes rather than an immediate resync. Also had no voice for the 2 minutes.
It came back, I did assume all was the same in terms of attainable, as I knew previously my SNRM had dropped to below 6db, and a resync would have me around 78mbit.
Now I am at 78mbit, but the SNRM is only 5.3, so attainable is now 2mbit down from immediately before the resync at about 76mbit, given the 2 min full on outage I am paranoid a tie pair swap has been carried out, although I am not sure if that would cause a voice outage. US attainable is also down but given the varying natures of UPBO from one sync to the next I look at that with less interest.
Latest 1 day time = 13 hours 50 min 48 sec
FEC: 0 669
CRC: 9787 60
ES: 249 56
SES: 17 0
UAS: 117 106
LOS: 1 0
LOF: 8 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 664
CRC: 1064 60
ES: 428 57
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Big spike of CRC and clear SES but ES looks safe for DLM purposes.
--edit--
Active SNRM and attainable is continuing to fall (other lines been reconnected?)
-
Just a thought . . .
I wonder if a G.9700/9701 (a.k.a.G.Fast) pod has been added to the PCP and in the process of connecting it up, the tie-cables to/from the DSLAM containing cabinet were disturbed? :-\
-
Not sure- perhaps worth Chrys going for a small stroll to check out that theory. I saw this post earlier but didn't have any answers :(
The decrease in SNRM after sync will obviously be another modem syncing after Chrys's but he will already be aware of that, so I had nothing useful to add :(
-
Due to my mobility issues no stroll down to the cabinet was viable, and I was not getting a taxi for it. :)
Prior to the outage, I was synced at 79987 but with 5.4db snrm and attainable of about 78.
After the 2 min outage which included voice I was synced at just over 78000 but also with a 5.4db snrm (so someone synced soon after me), and attainable of about 76000.
Then some hours later another loss of sync occurred and I am now at my current sync of just under 74000. This one was just a quick resync not a sustained outage that I noticed. My SNRM has dropped since this event as well although only a small amount thankfully.
Both of these syncs have about 2DB of SNRM lost on the upstream and a resulting loss of about 5 mbit US attainable.
Overnight it seemed stable, no loss of sync or sudden changes of SNRM. ES rates seem very similar.
Its annoying but I will put things into perspective.
Had over 6 months at full sync following years of struggling to even hit 70mbit sync speeds.
The clean low rate for my area (20th percentile) is only just over 60mbit now, indicating how low some people around me are syncing.
The handback threshold is only just over 50mbit (10th percentile) indicating how low at least one person near me is syncing, so my current sync speed is still well in the upper range for my area. I just hope it stabilises again now tho.
-
Just a thought . . .
I wonder if a G.9700/9701 (a.k.a.G.Fast) pod has been added to the PCP and in the process of connecting it up, the tie-cables to/from the DSLAM containing cabinet were disturbed? :-\
Interesting theory, as you know engineers are not supposed to touch live pairs without a proper reason, doing things like swapping tie pairs on active customers is a big no no. Black Sheep will obviously be aware of this. If they in the way of a pod installation then that would be such a reason. I may be able to check this upcoming weekend as I have a feeling will be in the car in that direction then.
-
I have had a further thought.
A G.9700/9701 (G.Fast) pod needs a power supply. It is my understanding that the nominal -50V DC supply is taken from the associated fibre cabinet. To do so, an appropriately sized cable would have to be installed between the two cabinets and I would assume that the same duct as the tie-cables would be used. Thus there is a potential for disturbance to the tie-cables during such activity. Finally, I would expect that the power link cable would not be connected at the fibre cabinet end with the power supply circuitry live . . . hence a short power down of the DSLAM and a G.993.2 service outage.
-
It could have been a 'Card reset'. Carried out as an absolute last resort, but a necessity at times.
In doing so, it clears up a 'Has synch but no PPP session' fault, 99% of the time.
-
ok thanks black sheep.
-
I did check on sunday, is no pod next to cabinet, also is no pod next to cabinet across the road from me.