Kitz Forum
Broadband Related => ADSL Issues => Topic started by: kitz on July 04, 2013, 10:11:53 AM
-
Damn. I think I have a problem with my line - this is just as Im about to order FTTC.
Normally my line is rock steady and NEVER ever budges... and will sit at 3dB SNRM for weeks without even a slight bump.
My upstream attenuation has increased from 7dB to 10dB, downstream slight rise of .5 dB to 14dB
Ive tried switching everything off aside from the PC which I need to use for DSLstats.
Last night I couldnt even hold the connection and SNR was going wild - (I was watching it via the router GUI)
I lost 'annex-M' at one point and I did eventually sync at a (for me) lowly 16Mbps
It mostly seems to happen overnight, but dslstats is also showing various times of the day when Im not in. The connection dropped several times over last night.
I dont have time to look into anything as Ive got a lot going on atm, and need to be out of the house soon... but I'll attach a couple of graphs to show what I mean.
-
I think that those violent fluctuations are more likely to be due to a physical line fault than RF interference. Could this be related to the FTTC upgrade (engineers working on the line or in the exchange)?
-
I found out on Mon that I need to be off Be by Aug 1st.
Anything anyone else on Be needs to think about, or just personal to you? (I'm "considering" PlusNet ...)
-
I've recently left O2 to move back to Plusnet on Fibre Essentials. Went fairly smoothly, all in all, apart from the initial engineer visit by Kelly Communications. Plusnet suggested that I might get a 30M connection, but it's been at around 37M since 23 May - which I'm quite happy with.
Good luck in resolving the current issue, and in choosing your new ISP.
toulouse
-
The only time that a line's attenuation will change is under fault conditions . . .
(Surely b*cat does not need to say any more? ??? )
-
Thanks for the replies... typical that it happens now of all times :/
>>> Anything anyone else on Be needs to think about, or just personal to you?
Not just me, but I believe anyone affected will have got an email this/last week, if you havent heard anything your probably ok for now. According to my source there was a meeting last Friday and Aug 1st is the date that when accounts will come under control of sky and they envisage starting transferring accounts over. :/
TBH I dont envisage everything happening on the 1st of Aug and although I was told my exchange was going over on that date Im personally not too sure and think its just a push for me to make a commitment to sky.
I was delaying in the hope that we'd have more time :(
>>> choosing your new ISP
I was waiting to see Zens offer (http://forum.kitz.co.uk/index.php/topic,12500.0.html), but atm its looking like PN.
Ive just rang for my MAC code, but they only provide them during working hours according to the recorded message I just got.
>>> The only time that a line's attenuation will change is under fault conditions . . .
I know... or faulty filters etc.. I really dont have time to mess atm. :'(
Ive just checked my attenuation and its now at 5,2 / 13,5. This isnt something Im used to seeing fluctuate so I dont record it on dslstats.. I better had do for future.
The last disconnect was at 10:30 this am and touch wood since then it looks like its been stable. Will have to see how it behaves this evening. I could probably reboot atm and get a bit more sync... but not worth it IMHO
>>>> Could this be related to the FTTC upgrade
I did wonder if something at the exchange, but scrolling back on dslstats its been happening for a few days now. Mornings, afternoons, evenings and night-time. This is so very unusual as I never normally see any fluctuation at all.
I haven't yet started the migration process.. so cant be anything to do with that.. need my MAC first.
Thanks for dslstats, because if it wasnt for that, I wouldnt have graphs to see whats going on whilst out/sleeping etc etc.
----
edit just realised I dont see an option to record attenuation.. although not surprised as its not something you'd normally expect to see changing. Just double checked I took a screenie last night on the ipad and it definitely was at 10,4 for the upstream. SNRM was at 102,2/0,7
-
PS whilst talking about FTTC, I pretty sure Im going to need HWS.
My NTE is in the hall at the bottom of the stairs, but theres no electrical socket nearby.
If I test via the NTE for any reason then I need to get an (electric) extension cable and trail it across the door leading into the lounge., and into the hall. Its lethal though if anyone walks in to the front room.
A data extension cable is a bit out of the question too, as that would need to go around 4 doorframes!
Ideally a new NTE into the computer room would be best solution. 'Computer Room' is on 1st floor, but it is directly above the hall... so perhaps external wiring outside of the house and a new NTE in here would involve the least cable.
-
Ideally a new NTE into the computer room would be best solution. 'Computer Room' is on 1st floor, but it is directly above the hall... so perhaps external wiring outside of the house and a new NTE in here would involve the least cable.
Agreed. That would be the most logical solution. :)
You really need the services of a Black Sheep . . . ;D
-
Agreed. That would be the most logical solution. :)
You really need the services of a Black Sheep . . . ;D
I do... I've already collared a certain ovine .. He advises me that engineers carry crimpers so if I ask nicely I may be able to get the lju that is in the pc room reverse wired so that I have an extension to where the existing NTE5 now is, so I can still use my phone in the hall.
The telephone extension runs under a few floorboards skirting boards and under the carpet going up the stairs. With my hand being knacked and according to the docs little chance of ever getting better, it's not going to be something I can do too easy these days.. So if the same cable can be reverse crimped it would be ideal. :) I will have bacon in ready just in case. ;)
-
MAC key ordered :'(
They tried to get me to take out Sky FTTC and offered me a discount which is still dearer than PN.. plus they admitted that unlike PN they dont offer a static IP.
-------
Same problem last night with the line it started at 1.50am - I'd long gone to bed at that time.. and its still happening atm.
-
Here we go again....
Line Attenuation (Up/Down) [dB]: 10,5 / 14,0
:(
Not sure if it could be connected, but I looked at my stats before I phoned Be for my Mac and atten was
7,2 / 13.5
Didnt particularly hear anything on the line... goes to do a QLT using an old type phone.
[edited to add]
Nope cant hear anything just the usual very quiet hiss
-
Not just me, but I believe anyone affected will have got an email this/last week, if you havent heard anything your probably ok for now.
No email, but FTTC will be available in my area fairly soon (several cabs are up), so maybe that's (already FTTC-enabled) where they're focussing efforts to limit people jumping ship to fibre from BT, PlusNet etc.
I'll probably plan to move ISP sooner rather than later if that's going on and switch to FTTC later if/when its available.
-
or faulty filters etc.. I really dont have time to mess atm. :'(
etc. includes your router and wiring of course. ;)
(comment about no power near NTE noted :( )
-
>>> but FTTC will be available in my area fairly soon
FTTC has been here since Oct last year, and although available to BTw ISPs, Sky seem to take a while before they get around to offering it as available to their customers. This seems to happen on all exchanges and they can be up to 6 months behind BT. Sky has only been doing Sky fibre here since about Apr... no idea why they seem to lag behind so much.
---
I suspect I am one of the very few using Annex M at this exchange.
In fact I dont know anyone who is now using Be* afaik its mostly O2 users on that MSAN. I think unfortunately anyone with a need for speed will have already jumped ship to FTTC.
This town has a history of heavies.. goes back since the beginning of adsl and we were the first exchange ever to suffer from contention. When Sky LLU came here, most of them jumped ship because of the cheap Unlimited.
Ive put a few people on sky here, but they are light users and dont notice the effects of contention for browsing.. but I sure as heck do notice it. From what Ive seen of the Sky connections here, they often do see congestion.. which is another reason why i dont want to go Sky.
-
Just my 2 cents worth.....
while I was with O2, with which I had been very happy indeed, at the same time as all the work was going on to install the local fibre cabinets, my O2 service did take a bit of a hit on several occasions. This would have been around December last year.
During an unscheduled engineer visit as part of the troubleshooting, the BT Openreach engineer was telling me about the upcoming Fibre service which was due to go live in March this year, and what speed I might see. Interestingly enough (or not as may be), he was pretty damned accurate. If I remember correctly, he said that I was about 750 metres from the cabinet and that I should see a connection speed of around 37-38Mbps. I'm actually at 37Mbps and have been since the service went live on 23 May.
I mention this only as a possible cause of the present issue in and around Kitzland, that could be involved in the present problem, based upon my similar issues last year.
toulouse
-
or faulty filters etc.. I really dont have time to mess atm. :'(
etc. includes your router and wiring of course. ;)
(comment about no power near NTE noted :( )
I know... I need to do the master socket thing I guess, but this is a real PITA because of no power nearby... it involves shifting some heavy furniture and trailing a power extension lead across the doorway to the lounge. Also when I used to test via the NTE I had a laptop. Can hardly shift the PC downstairs too. :(
Just this am sent a message to one of the PN guys about HWS (http://www.openreach.co.uk/orpg/home/updates/briefings/super-fastfibreaccessbriefings/super-fastfibreaccessbriefingsarticles/nga02412.do)
-
I need to do the master socket thing I guess, but this is a real PITA because of no power nearby...
Can't you extend the router DC power, just needs thin 2-core flex which can run around skirting boards etc. and some choc-bloc connectors. ;)
And obviously a long LAN cable if you need a wired connection, which you probably don't to monitor the router stats.
I use TP-Link WR-702N "nano" routers to pick up the wireless LAN and provide an RJ45 LAN connection transparently for various devices, especially when testing.
-
Just my 2 cents worth.....
while I was with O2, with which I had been very happy indeed, at the same time as all the work was going on to install the local fibre cabinets, my O2 service did take a bit of a hit on several occasions. This would have been around December last year.
toulouse
Cheers for the comments.. when the cab was going in I did see some disruption which I mentioned at the time. That seemed to settle down after a couple of days.
I really do need to do the NTE thing, I'll see if I can borrow a lappy, it will be much easier. I can bear with a trailing power cable for a few days to the router. As long as I warn any visitors to be careful :D
Not sure why this would rear its head literally days after Id decided I was going to move. Unsure what to do because if its a line fault need it fixing before I move.. and its now going to be hard to raise a fault after Ive requested a MAC.
If its internal wiring or something to do with the Be* MSAN, then that will be solved during migration and a HWS. :-\
-
Kitz,
Have you considered simply maintaining the distributed filter arrangement you have with your existing ADSL2+M solution? Leave everything where it is; let them install in the hall, and after 24hrs, remove the SSFP, and put your dongles back in and run the VDSL modem and router upstairs? :-\
-
Thanks Colin. At first I thought good idea.. But on 2nd thoughts perhaps not the best solution.
1. I doubt the engineer could fit it in the hall from the existing nte because of the lack of power nearby anyhow.
2. The existing setup has about 20-30m extension which goes up the stairs hidden under carpet - length is long because it follows the up and level of each stair.. It's then hidden under some skirting floor boards which I can't now easily acess becaue I thought years ago when putting in fitted furnature it would be a good idea to hide it all away. This cable is/was cat5, BUT, it's had the spare wires stripped out leaving only one pair. Years ago it was a good idea because the other pairs weren't needed and it also made the cable thinner and more flexible. Admittedly it wasn't me that did all the hard work of cable stripping.
-----
I've really been racking my brains about how best to do this... Tbh one of the other reasons for delay is its the cabling that has been a major concern for me.
I have my MAC and just tried placing an order with PN, and I notice there is an additional option which must be the HWS which gives a free 30m data extension kit.
However I seem to be having problems ordering online and it keeps chucking me back out to the help section. I could order as a new customer fine... but I still have my old PN login and email so I'm in effect I'm trying to add an order to my existing account via the upgrade path. I'll try phoning on Monday and see if I can speak with someone who knows me as I would like to retain the same account if I can.
if I get chance ill try draw a rough plan to see if anyone can think of best possible cabling solution.
-
Just had a look see what the line has been doing today, and touch wood its been relatively stable as far as the SNRM is concerned. :fingers:
Attenuation has changed again - very slightly for the better ???
Line Attenuation (Up/Down) [dB]: 10,4 / 13,5
I now 'have' a lappy which I will install DSLstats on, but Im not moving heavy furniture around at this time of night too hook the router up from the master socket.
>>> if I get chance ill try draw a rough plan to see if anyone can think of best possible cabling solution.
Ive just done a quick search and on the PN forums, Ive found a few of posts which sound a similar set-up to mine. ie existing NTE in a hall with no power, and the room directly above being used for router location.
Solution in all 3 cases was to relocate the Master socket to the bedroom/study and then 'backwire' the extension, so what was the old NTE becomes a normal extension. I do aim to do a wee bit of cabling rejig though too first.. to try and make things a bit simpler/tidier for a new set up.
These are Barratt houses so thinking about it, there surely must be a heck of a lot homes in the same style with the same problem of no power near the NTE, and people using the 3rd bedroom as a study & router location.
-
According to dslstats, line has been stable again last night and SNRm has hardly moved. Im talking variances of 0.1 / 0.2 and whilst not quite my usual rock steady flat lining, I can cope with that.
Hmmm neighbour is away this w/e :-\
However perhaps just co-incidence as the changes in atten have occurred since shes been away, and also some of the really bad noise spikes from a couple of days ago sometimes occurred when she was at work.
Still have the high increased attenuation and its perhaps knocked about 100 kbps from my upstream sync and Im seeing more CRC/HECs than normal, but aside from that, the line is acceptable atm.
-
Thanks Colin. At first I thought good idea.. But on 2nd thoughts perhaps not the best solution.
Sure, whatever you think is best. However...
1. I doubt the engineer could fit it in the hall from the existing nte because of the lack of power nearby anyhow.
So, what would you do now if (as you suspect) you had a DSL fault that needed the modem/router to be plugged directly into the NTE test socket? Pehaps, temporarily, use a trailing extension power lead? If so, that's all you'd need to do here to. No? :-\
2. The existing setup has about 20-30m extension which goes up the stairs hidden under carpet - length is long because it follows the up and level of each stair.. It's then hidden under some skirting floor boards which I can't now easily acess becaue I thought years ago when putting in fitted furnature it would be a good idea to hide it all away. This cable is/was cat5, BUT, it's had the spare wires stripped out leaving only one pair. Years ago it was a good idea because the other pairs weren't needed and it also made the cable thinner and more flexible. Admittedly it wasn't me that did all the hard work of cable stripping.
I understand perfectly. It is these practical issues that makes all such connections difficult in existing installations. Got a new build in a green field somewhere, fine, you can call in all your friends and 'do a BB4N'. But live in a 100 yr. old multi-storey building in a conservation area, and it becomes a lot more difficult. Each installation has its own optimal solution. There is no 'one-size' solution that fits all, no matter how enthusiastic some people may be. IMO, of course. ;)
-
Sorry I think I may have misunderstood what you meant?
Do you mean running exactly as is now without any VDSL faceplate. So therefore remove/reverse what the engineer does after he's gone back to...
NTE5a --> 20+m of telephone extension ->> LJU --> adsl filter ---> FTTC modem --> FTTC router.
Would this be ok? Perhaps my mistake because I thought you had to use data extension from the VDSL faceplate at the master socket. Sorry if Im a n00b with this, no-one else I know has FTTC, its not even available from the other Blackpool exchanges yet, so Im about to start my own learning process and hence why I dont have much input in the FTTC section atm
So, what would you do now if (as you suspect) you had a DSL fault that needed the modem/router to be plugged directly into the NTE test socket? Pehaps, temporarily, use a trailing extension power lead? If so, that's all you'd need to do here to. No?
Yes and hence the delay in testing from the NTE as I also need a loan of a lappy to hook up to the router to read stats.
I have concrete floors and the doors are tight fitting which dont allow sufficient room to open over electric extension cable. It therefore obstructs the opening of the door between the hall and lounge.
If I test via the NTE for any reason then I need to get an (electric) extension cable and trail it across the door leading into the lounge., and into the hall. Its lethal though if anyone walks in to the front room.
My query was that I think any engineer would see straight away how very much of an obstruction the cable is by not allowing proper access to the lounge from the hall and know that it cant in anyway be a permanent solution?
-
Righty-o .............. we've just received a new communique stating that we can go back to terminating the data-extention cable directly onto the krone terminations of the VDSL frontplate. This is preferred over connecting via the RJ45 method.
So, Kitz, the easiest method of installing FTTC at your premises would be to .......... leave the original NTE5 where it is in the hallway (as it could feed other extention sockets, SKY set-top box, alarm auto-dialler, anything really). Then, ask the engineer (if he can't suss it himself) to terminate the CAT5 pair onto the krone strips of the VDSL frontplate. Now, upstairs, he only has to change the existing telephone extention socket over to a data-extention socket and hey presto ......... job done.
The modem and router can now be sited upstairs and no new wiring need be run.
-
Thank you for the info :)
-
Sorry I think I may have misunderstood what you meant?
Do you mean running exactly as is now without any VDSL faceplate. So therefore remove/reverse what the engineer does after he's gone back to...
NTE5a --> 20+m of telephone extension ->> LJU --> adsl filter ---> FTTC modem --> FTTC router.
Would this be ok?
Yes, that was what I meant and yes, IMO, it would (this is how mine is run, and it is totally compliant with SIN498) - but see my reply to BS below. :)
-
Righty-o .............. we've just received a new communique stating that we can go back to terminating the data-extention cable directly onto the krone terminations of the VDSL frontplate. This is preferred over connecting via the RJ45 method.
Well, I'm glad they finally realised how stupid their previous instruction was then. :no: It's a shame that what you have/are allowed to do is subject to such contrariness, but hey ho! ;)
So, Kitz, the easiest method of installing FTTC at your premises would be to .......... leave the original NTE5 where it is in the hallway (as it could feed other extention sockets, SKY set-top box, alarm auto-dialler, anything really). Then, ask the engineer (if he can't suss it himself) to terminate the CAT5 pair onto the krone strips of the VDSL frontplate. Now, upstairs, he only has to change the existing telephone extention socket over to a data-extention socket and hey presto ......... job done.
The modem and router can now be sited upstairs and no new wiring need be run.
Yes, it would be, especially as Kitz is unlikely to want to change the location of her equipment room, and it also avoids the need for the (temporary) trailing power socket and DSL filter when testing at the NTE5a test socket. :thumbs:
However, the new instruction leaves an interesting debate on the location of the 'soft' (VDSL) NTE location. IMO, it will remain where it always is, which is now be upstairs in the VDSL modem (where this is separate). So, no need to traipse back downstairs to test except where there is evidence to believe that the CAT 5 data extension cable (which it has now become) is itself faulty, then? ::) But somehow I suspect that trailing power socket will still be useful for those 'play-it-by-the-script' sceptics (which excludes you, obviously!) :lol:
[Edit] The more I think about it, I suspect that OR will quietly abandon the 'soft' NTE boundary, as, with the new Cab-only installations, the time will come shortly when OR will no longer be providing the VDSL modem, and so won't need to 'support' them like they currently do. ::) Is there any known instance of OR using TR069 to actively manage any of these modems, e.g. by updating firmware, or (god forbid) switching them off while they work on tone-tracing pairs in a cabinet. ;D
-
Hi Colin, I've no idea if TR069 is used to 'manage' remote modems. TBH, it doesn't fall within my job remit which, as a multi-skilled engineer, is way enough as it is !! :)
-
Hi Colin, I've no idea if TR069 is used to 'manage' remote modems. TBH, it doesn't fall within my job remit which, as a multi-skilled engineer, is way enough as it is !! :)
:friends:
-
Thank you, I feel much better for it. ;) ;D
-
Well last weekend when I borrowed the laptop, emptied & moved a bookcase/table thingy out of the way and tried to do some testing, the line behaved itself and I couldnt find any difference between using the NTE and the extension.
One thing I did find out (and remember) by carrying out this exercise is that the piece of furniture will not fit if I add an i-plate, as its right up to the doorframe as it is. So if a vdsl faceplate is added in the current location, then the gap really is so tight that I wont be able to open the door to the hall. Not BTs problem, but Im now hoping that he will move the NTE permanently because I really have nowhere else for that piece of furniture to go :(
The line aside from some bouts of SNR and a couple of line drops seems to have been okish for the past week. The fluctuations and drops are usually during the night. Its far from my usual rock steady connection but since mostly the SNR fluctuations seem to be about 3dB I doubt anyone would take this as life threatening.
Today the attenuation has changed yet again. Now at:- Line Attenuation (Up/Down) [dB]: 9,1 / 14,0
----
As we all know, attenuation shouldnt change and upstream issues are normally either a line fault or internal wiring. Ive been unable to detect any difference between master socket and extension.
QLT on phone seems ok, although admittedly not been able to do one at same time as the problems occur.
Using the phone doesnt seem to cause any issues with my line stats
There is no pattern to the issues.. they mostly occur in the wee small hours or in the mornings.
-----
Previous Att (Annex_M) 7 / 12.5
Previous Att (adsl2+) 4 / 12
This is a record of my attenuation over the past few weeks
7,0 / 13,5
10,4 / 14,0
5,2 / 13,5
10,5 / 14,0
10,4 / 13,5 07/07/2013
10,4 / 14,0 11/07/2013
9,1 / 14,0 13/07/2013 10:59:12
Unfortunately Ive just upgraded dslstats so lost the ability to see all the old stats :(, but I have been able to recover the SNRM showing what happened today, and tried to reconstruct what I can from what info is available. This is kind of typical of what I see.
10:55 first my upstream SNRm takes a loss of about 3dB, downstream loses 1.5 dB, things get flakey for a few mins.
10:59 Attenuation changes
10:59 Upstream SNRM drops to 0dB (was previously 5dB)
10:59 Line drops
11:00 Line comes back up
11:24 Period of instability. Upstream fluctuates between 4dB and 0dB Corresponding fluctuations in downstream SNRM between 3dB and 1dB. Line continues to hold.
11:45 Line begins to stabilise 4dB up 3dB down.
-
hmmmm... Ive just this min recalled toulouses post (http://forum.kitz.co.uk/index.php/topic,12660.msg239426.html#msg239426)
Ive been advised (how true or not this is Im not sure - because I really cant imaging it happening on 1st Aug exactly and think its a push to get me on Sky & lose annex-m) that my exchange is due to come under sky control.
All my problems seem to be around my upstream which is hit hardest, and if you recall one night I said I lost Annex_M (July 4th).
Could it be possible that Sky/Be are doing something thats buggering about with their MSAN affecting my upstream/Annex-m connection.... or am I just being too suspicious? Something weird is definitely happening though. ???
-
This isnt right :(
Seen lots of loss of connections this am.. this is the atten log
13 Jul 2013 17:08:56 14.0 9.1
14 Jul 2013 06:00:17 14.0 8.7
14 Jul 2013 07:31:32 14.0 10.4
14 Jul 2013 07:33:06 14.0 7.9
14 Jul 2013 07:38:53 14.0 8.7
14 Jul 2013 07:40:27 14.0 7.9
14 Jul 2013 07:50:25 14.0 10.5
14 Jul 2013 07:51:59 14.0 4.5
14 Jul 2013 07:56:11 14.0 8.8
14 Jul 2013 08:03:32 14.0 10.4
14 Jul 2013 08:10:21 14.0 5.6
14 Jul 2013 08:48:37 13.5 8.6
14 Jul 2013 09:54:42 13.5 5.5
14 Jul 2013 10:00:28 14.0 7.0
14 Jul 2013 10:13:03 14.0 6.5
14 Jul 2013 10:27:45 13.5 8.1
14 Jul 2013 11:21:45 14.0 7.7
The upstream green spikes are actually negative SNRm values
-----
Edit
Off to get a wireless adapter for this PC, so at least I dont have to keep borrowing a lappy to test from the NTE.
Not the best method I know but at least I should be able to let dslstats run for a while.
-
Not good. That does looks like a sick line. :(
Have you checked with a good quality microfilter plugged directly into the test socket?
-
>> Have you checked with a good quality microfilter plugged directly into the test socket
Yep - did that last w/e when I borrowed the laptop, but the line was behaving itself then (both from master socket and extension).
Well last weekend when I borrowed the laptop, emptied & moved a bookcase/table thingy out of the way and tried to do some testing, the line behaved itself and I couldnt find any difference between using the NTE and the extension.
Line was mostly ok last week, aside from a couple of incidents in the wee small hours, but its kicked off again this weekend in the mornings.
atm its flatlining again and showing no signs of anything being wrong... theres no pattern to the times when it misbehaves. QLT is fine.
Anyhow got a wireless adapter now to put in the PC and i'll try rig something up so I can permanently record from the NTE - even if it does involve a trailing mains cable right across the door between hall and lounge. Time to go emptying the bookcase again and moving furniture :(
-
Since they're the bane of my life at the moment...
It's not the PSU starting to fail is it?
Ian
-
Cheers - It dawned on me about 1/2 hr ago too, thats the only thing I havent tried - about to go up into the loft to get an old router out. ::)
Presently its running rock steady and flatlining at 5db down and 6dB up still from the extension where its been at since about mid-day.
-
I think the router and modem tinkerer's toolbox [1] should contain a 12 volt battery with a variety of power connectors on the end, to be used to rule out ailing PSUs and mains-borne noise!
A little sealed lead acid battery perhaps, or a homemade nicad/NiMH pack, or what I've done a couple of times - a battery pack from an old 12volt drill.
[1] Not to be confused with the router and modem tinkerer's's's social club, which is's.. here, isn't it? ;D
Ian
-
The position of the apostrophe is important --
"The router and modem tinkerer's toolbox."
"The router and modem tinkerers' social club."
:P
-
Fixed! :-X
-
Fixed! :-X
:thumbs:
-
>>> modem tinkerer's's's social club, which is's.. here, isn't it? ;D
:lol: :lol: :lol:
-
Private Eye magazine started up a Pedant's corner on their letters page a few years back, to publish letters and comments from readers who were pointing out dull factual errors.
This led to much letter writing to Pedant's Corner as to the correct position of the apostrophe in Pedant's Corner.
As a result, each issue would have the apostrophe in a different position to the last.
Until someone suggested the idea of renaming it "Pedantry corner".
(Though there were then complaints when it filled the entire lower half of a page)
Ian
ps sorry for hijacking your thread Kitz - did the PSU make any difference?
-
No worries, breaks up the monotony (or not) of my line.
No not made any difference so far, but then again the line was behaving itself again before I hauled everything around to get to the master socket.
And I've only tripped over the damn cable 3 times so far... even though I know its there.. Grrrrr
House is a bit of an obsticle course with shifted furniture, books and other various items piled up on the floor to make it lighter to move... Trailing power cable at the bottom of the stairs and across the door from hall porch door into the lounge.. Fun times ;D
-
Scanning this thread quickly one small point of detail that I'd question is 'attenuation should never change'.
I realise the problem seems to have been fixed by a new router but in terms of stitching up the loose ends, I can't help put my pedant's hat on and mention... any conductor's resistance is a function of temperature and it may be no coincidence that you saw slightly raised line attenuation over the past week or so. The effect is measured on the absolute (kelvin) scale, in which 2 degree centigrade represents only less than 1 percent; nevertheless the fluctuations over the past week or two have been more like 15 degrees, so I suspect it may well become measurable.
Although the effects of climatic conditions on line resistance are small, they do exist. I seem to recall hearing that power distribution companies sometimes have to make allowance for it in HT wires. My own router has been showing 57dB this past few days, compared with it's usual 55/56, but my connection is in the best of health in every other respect. I may be wrong, but I've been attributing the slight change to the hot weather.
RE the faulty router (if we have confirmed it is faulty), I'd bet a pound it a penny you'd find a bulging capacitor or two inside. These components are also affected by temperature and, if on their last legs, the demise can be accelerated by higher temperatures.
Take care not to trip. Reminds me I have my own tripping challenge today, to work out why the mains RCD mysteriously tripped out last night . :(
-
>>> I realise the problem seems to have been fixed by a new router but in terms of stitching up the loose ends,
No its not the router. :(
Perhaps I confused by saying yesterday afternoon that the line was running rock steady, but that was whilst the TG582n was still on.
Last week it ran rock steady for a few days still using the TG582n and the only reason I was putting a different router on was for the sake of elimination and rule out that it wasnt the TG582n/PSU.
Im now using a ST585, which I put on last night, and although its holding on to the line a bit better you can see there are still issues there.
Some time just before 4am Upstream attenuation changed from 7dB to 9dB.
I'll attach the graph from Routerstats showing the dip in SNRM at just before 4am, and also periods this morning between 7am to 8.30am where you can see upstream SNRM is dropping down to zero. (You'll need to scroll image to the right)
These slight & brief bursts I also saw using the TG582n, and I think my previous posts may have said that aside from some overnight blips then it mostly ran rock steady for a few days... until it kicked off again this weekend.
>>> you saw slightly raised line attenuation over the past week or so
Upstream attenuation has been fluctuating between 4.5dB and 10.5dB.
Ive not seen anything like that before.. not on such a relatively short line, that has never before shown any changes.
>>> Take care not to trip.
lol.. I may be about to make matters worse. :-X
Yesterday I installed a wireless card in this PC to enable me to plot with routerstats with routerstats/dslstats whilst connected to the master socket. However, the wireless signal from the ST585 isnt too good and my throughput speed is carp. Thinking of temp trailing a long length of cat 5 cable out of here and over the banister, just so I can plot with RS (dslstats wont work on the ST585 ) whilst everything is in the NTE test socket.
-
No its not the router. :(
Sorry, my mistake. I'd not been following the thread, read it in a hurry, and clearly misunderstood :-[
All the same (clutching at straws to justify my contribution), I'd be open-minded to the possibility that whatever has changed(broken), the warmer weather may have been a factor in breaking it.... not that it helps a great deal, of course.
Thinking of temp trailing a long length of cat 5 cable out of here and over the banister, just so I can plot with RS (dslstats wont work on the ST585 ) whilst everything is in the NTE test socket.
Indeed, that seems to add a whole new dimension of tripping hazard. Do take care! :o
-
No worries, yes warmer weather may have something to do with slight changes in attenuation, and I welcome any suggestions or pointing out something I may have missed. :)
However not allowing for the fact that dB is a logrithmic figure... more than doubling of the attenuation is a heck of a lot.
Also as a very rough guide, upstream attenuation should be in the region of about 1/2 of the downstream.
I realise this post has got quite long now so I'll summarise
--------------
Symptoms
Previously rock steady short line with unwavering SNRM - it would sit quite happily at 3dB for months on end.
About 2 weeks ago started seeing changes in upstream attenuation and burst fluctuations in SNRM which causes the line to drop.
No obvious pattern to the times, although they mostly occur overnight, morning or weekends.
I dont think Ive once seen it happen in the evenings which is when you'd most likely see changes in SNRm
Logging SNRM shows its burst type noise - length can vary between a few seconds... to a periods lasting a couple of hours.
Noise bursts will often, but not always, follow or accompany a change in upstream atten.
This post (http://forum.kitz.co.uk/index.php/topic,12660.msg239759.html#msg239759) shows a log of how much the upstream attenuation can vary over a fairly short time span fluctuating between 4.5dB and 10.5dB
Tests performed:-
Change of adsl filter
Change of router
Test from master socket (direct into test socket)
QLT is ok
Using the phone doesnt trigger an event.
Test not performed
AM radio
1) - I dont have a portable am radio
2) - Times are too sporadic to know when the problem is going to occur.
Other possible areas which could cause this type of fault
Line fault
Faulty line card at the MSAN
At first I thought it may be REIN/EMI when I started seeing the drops in SNRM... but unsure re the changes in attenuation
At this point Id normally suggest raising a fault with the ISP, but problem first occurred a couple of days after Id decided to move to FTTC
Migration and transfer to FTTC due to be completed this Friday. I hardly think Be* are going to investigate after I asked for my MAC, but Im very aware that if its a line issue, then its not at all a good start for FTTC where its harder to monitor whats going on :(
-
Just noticed whilst I was typing out all the above, Ive had another noise burst lasting about 10mins.
Admittedly the ST585v6 seems to be holding on to the line better when SNRm drops to 0dB.
Whilst the TG582n will drop the line when it gets to negative figures, I hardly think its a fault as such & I can rule out a hardware issue.
I'll keep the ST585 in the master socket for today, but tbh I dont see much point in keeping trialling wires all over waiting for an accident to happen... and it will be nice to get a decent wireless signal again from the TG582n for the ipad etc... and a proper wired LAN for the PC.
-
>>> Admittedly the ST585v6 seems to be holding on to the line better when SNRm drops to 0dB
hmmm Im also beginning to suspect that routerstats is possibly throwing me a few false 0dB readings as the graphs shows quite a few zero dbs this afternoon but none of the surrounding spikeyness which I normally see around the time when my line starts going flaky. Theres been about half a dozen or so dips this afternoon recorded in RS which Im beginning to suspect is false reports.
Unlike dslstats - afaik RS doesnt advise you when its not been able to get figures from your router.
-
and I know Im responding to myself but just this minute found out this little gem of information.
---------------
Someone else on the same Be MSAN as me is also seeing remarkably similar symptoms!
This is the response I just got after asking how his line was doing. -
I hadnt even mentioned to him that I was seeing weird issues with my upstream attenuation
I am glad you asked actually. I don't know whats happened to the line here ... /snip/...
I don't have a clue how the upstream attenuation has changed by that much. Im thinking it's a line fault
Yep his Be connection is also seeing upstream atten changes and looking at his stats hes lost over half of his upstream speed and he is also beginning to wonder if he had a line fault :(
Not 100% sure - but there is a strong chance we are both on the same line card, since we were both activated on about the same day as soon as the Be MSAN went live.
-
Ah, now that is interesting. Do you know if he has submitted a fault report?
-
I have not submitted a fault report yet but I will do tomorrow.
@Kitz I have installed DSLstats and will report back later with some stats. Ill leave it running all this week.
Edit: If you need any stats pulling or any screenshots posting just let me know.
Edit 2: Just reboot my router to try and get a decent sync and here are the results:
Downstream Upstream
Attenuation (dB): 28.0 17.1
Connection speed (kbps): 16905 1360
SNR margin (dB): 3.3 3.8
Power (dBm): 19.2 12.0
If you could post the results I sent you earlier kitz so we can compare, as I did not click save sent message so i can't see it.
-
Cheers jabns :)
I think what would be most telling is if you experience burst noise on the SNRm at the same time as me.
btw dslstats was written by our very own Eric (http://forum.kitz.co.uk/index.php?action=profile;u=20).
Check out its options and theres a logging facility for attenuation which he put in after I asked him nicely. This may come in very useful to log your up atten too.
Since we dont live in the same estate then I suspect its now looking like it could be something on the Be MSAN.
-
Edit 2: Just reboot my router to try and get a decent sync and here are the results:
Downstream Upstream
Attenuation (dB): 28.0 17.1
Connection speed (kbps): 16905 1360
SNR margin (dB): 3.3 3.8
Power (dBm): 19.2 12.0
If you could post the results I sent you earlier kitz so we can compare, as I did not click save sent message so i can't see it.
ADSL Link Downstream Upstream
Connection Speed 14407 kbps 598 kbps
Line Attenuation 28.5 db 9.6 db
Noise Margin 7.3 db 3.1 db
-
Attenuation changed again today, upstream atten now at 5.5 dB. Still got the ST585 pm as Ive been out all day and not long been back home.
Line dropped at about 12.40ish, lost some of my downstream speed, but as you can see its the upstream that takes the hammering.
line stats:-
Uptime: 0 days, 8:00:00
Modulation: G.992.5 Annex M US 56
Bandwidth (Up/Down) [kbps/kbps]: 2,407 / 19,979
Data Transferred (Sent/Received) [MB/MB]: 8.12 / 29.34
Output Power (Up/Down) [dBm]: 13.0 / 17.5
Line Attenuation (Up/Down) [dB]: 5.5 / 12.5
SN Margin (Up/Down) [dB]: 5.0 / 3.5
Vendor ID (Local/Remote): TMMB / µ
Loss of Framing (Local/Remote): 4 / 0
Loss of Signal (Local/Remote): 1 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): 0
Error Seconds (Local/Remote): 144 / 0
FEC Errors (Up/Down): 0 / 0
CRC Errors (Up/Down): 70,700 / 328
HEC Errors (Up/Down): 313,890 / 237
attached graphs from 12:40
-
I will post the last 48 hours of graphs in the morning. Im currently not a home but don't worry its been logging ;)
-
ok... Ive not been home much either...
For the record these are my stats over the past few days. There are a few other tiny periods, but aside from these Ive been flatlining.
These are the main periods of instability:-
attenuation changes:-
15 Jul 2013 03:16:11 12.5 9.0
16 Jul 2013 12:40:06 12.5 5.5
17 Jul 2013 05:11:54 12.5 7.0
Periods of upstream SNRm fluctuations
18/07/2013 05:47 to 06:30 - Loss of about 4dB SNRm
17/07/2013 11:46 to 12:40 - Fluctuations of 2dB SNRm
17/07/2013 09:55 to 10:45 - Slight fluctuations of SNRm
17/07/2013 04:00 to 05:15 - Period of huge instability, downtime and lost of syncs
Stats just before I unplug the ST585 - Ive lost some sync speed both up and down, but as mentioned Ive not been around nor had chance to monitor things too closely.
Link Information
Uptime: 1 day, 7:56:49
Modulation: G.992.5 Annex M US 56
Bandwidth (Up/Down) [kbps/kbps]: 2,385 / 19,392
Data Transferred (Sent/Received) [MB/MB]: 50.44 / 142.34
Output Power (Up/Down) [dBm]: 13.0 / 16.5
Line Attenuation (Up/Down) [dB]: 7.0 / 12.5
SN Margin (Up/Down) [dB]: 5.0 / 3.5
Vendor ID (Local/Remote): TMMB / µ
Loss of Framing (Local/Remote): 8 / 0
Loss of Signal (Local/Remote): 3 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): 0
Error Seconds (Local/Remote): 380 / 0
FEC Errors (Up/Down): 0 / 0
CRC Errors (Up/Down): 72,717 / 121
HEC Errors (Up/Down): 339,498 / 82
-
The TG582n has been back on since yesterday afternoon.
Decentish sync speeds although the upstream line attenuation is back up at 10.3 dB
All seems relatively quiet last nite. Downstream SNRm has complete flat-lined at 3dB. Upstream is stable at around 3 - 3.5 dB
Possibly the last set of stats from me:-
DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 2.507 / 20.871
Data Transferred (Sent/Received) [MB/MB]: 69,87 / 205,79
Output Power (Up/Down) [dBm]: 13,0 / 18,3
Line Attenuation (Up/Down) [dB]: 10,3 / 13,5
SN Margin (Up/Down) [dB]: 3,2 / 3,0
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / BDCM
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 0 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 27 / 0
FEC Errors (Up/Down): 0 / 0
CRC Errors (Up/Down): 290 / 28
HEC Errors (Up/Down): 71 / 68
-
Oh dear.... perhaps not the Be DSLAM afterall. :'( :'(
Here we go again with the weekend wee small hours thing.
Graph 1 shows how rock steady the line normally is
Graph 2 shows the decline in upstream starting at about 05:30am
Graph 3 shows now and how the line is slowly recovering back to normal (11:45)
I dont have any record of attenuation, but it clearly shows losses of up to 10dB of SNR on the upstream.
Because my SNRm now is just shy of 16dB, this doesnt seem to have caused any ill effects at present, but its no wonder that when on adsl2+ my line couldnt handle such losses. :(
So it seems this intermittent problem has followed me to fttc :(
-
So it seems this intermittent problem has followed me to fttc :(
Very puzzling. ???
So, at present, all we can definitely conclude is that the 'disruptor' is coupled into the D-side and that it is affecting the lower-frequency, upstream tones . . . :(
-
yep :/
-
I may have missed a graph or some data somewhere, but how do we know it is only affecting the lower frequency US tones now that Kitz has moved to a FTTC connection?
-
I may have missed a graph or some data somewhere, but how do we know it is only affecting the lower frequency US tones now that Kitz has moved to a FTTC connection?
By virtue of the fact that it is the US SNRM only that is being depressed by up to 10 dB when the 'disruptor' becomes active? :-\
-
I agree that if US ADSL2+ Annex M tones 6 to 56 were affected, it is highly likely the same tones will also be affected on Kitz's VDSL2 connection.
However, if there was evidence that all the VDSL2 US tones are being affected, leaving DS tones each side unscathed, it could point toward something other than just an 'interference' issue at just certain tones/frequencies.
We have seen evidence from other VDSL2 connections where only the US U2 tone band was affected to a much higher degree than the U0 & U1 bands, suggesting 'interference' at specific frequencies only (see attached example graphs).
The point I'm making is that any data reported/graphed from the HG612's 'collective' values for the connection don't always depict the whole picture & that it is often useful to examine what actually happens within each tone band.
-
Thank you for spelling it out. :)
I trust you are prepared and ready to explain to Kitz how to obtain the relevant graphical information? :-\
(Oldham to Blackpool is but a few flaps of the wings, in a westerly direction . . . ::) )
-
Thank you for spelling it out. :)
I trust you are prepared and ready to explain to Kitz how to obtain the relevant graphical information? :-\
(Oldham to Blackpool is but a few flaps of the wings, in a westerly direction . . . ::) )
I think this may be the information I was trying to gather the other night from various sources.
I (think) I now have HG612_Modem_Stats running, but its not been up long enough to provide much info so far.
Below (1) is what I have from running GraphPD manually.
I assume that this should plot every 6hrs automatically with out me having to do anything further. (2) Settings
-
I think this may be the information I was trying to gather the other night from various sources.
I (think) I now have HG612_Modem_Stats running, but its not been up long enough to provide much info so far.
Below (1) is what I have from running GraphPD manually.
I assume that this should plot every 6hrs automatically with out me having to do anything further. (2) Settings
Not quite.
Ongoing stats are automatically plotted once per day.
Your settings are for that to be scheduled at 06:00 each day.
Snapshot logging/graphing (current data such as bitloading etc.) can be scheduled to start at a given time & repeat throughout the day (see my settings in the attached).
I have snapshot data logged/graphed each day at 06:00 (a quiet time) & repeated each 8 hours i.e. at 14:00 (when SNRM is likely to be at its peak) & at 22:00 (usually quite a 'noisy' time).
-
Not quite.
Ongoing stats are automatically plotted once per day.
Your settings are for that to be scheduled at 06:00 each day.
Thank you :)
I think I already have that set. Everything Ive done, Ive done from within the GUI, do I need to do anything else?
The only thing Ive run manually is the set date/time batch file. I havent set any scheduled tasks aside from the 1st one that the program sets up for you.
-
Okay this problem has now been here for the past 3 days, each time starting at around 5am.. the periods of instability seem to be lasting longer too. But overall its so erratic that I cant say for sure of a pattern yet.
21/07/2013 05.30 to 11.45 am up to 10dB fluctations
22/07/2013 05.10 to 11.10 am up to 7dB fluctuations
23/07/2013 decline started at 3am - still ongoing at present. Losses of up to 13.5db & upstream SNRm was down to 2.5dB a short while ago.
Graphs below show
(1) the gradual decline that started at 3am
(2) Present
If I didnt have a 16dB SNR margin my line would be dropping constantly this morning :(
-
Adding my stats from HG612_modem_stats.
These show that this morning all 3 upstream bands were affected to various degrees.
Downstream is showing slight losses of 2dB
-
Kitz,
Any chance you could post BE's Full_Monty plot from 1 day's Onging stats (If you have a complete one yet demonstrating this issue)?
I would be helpful to be able to see what else is going on at the same time, e.g. error rates of one kind or another and bitswapping.
-
Does this help?
-
Thanks Kitz.
Well that just about does it for me ::) - so to state the obvious, only the US bands are affected (significantly) with a reduction in SNR margin, just like you said. Don't have the bitswap rates/tones affected in this version of the FM plot, but Eric's program will have them. It would be interesting to see that nothing much is happening in the US bands there. If not, then you're getting a sudden change in SNR with (so far) no obvious signs of the effects of impulse noise on the line. Which might leave broadband EMI if it wasn't that all 3 DS bands are affected but none of the intervening DS bands. ???
So, to my suspicious mind the line card in the cabinet is now sus. What are BS's thoughts? :hmm:
-
Does this help?
I see that logging commenced at around 18:37 yesterday.
Perhaps you could run graphpd.exe manually or via the Settings editor GUI some time after 18:40 tonight so that we can see a full 24 hour period?
It appears the US SNRM was still ongoing at the time you generated the Full Monty montage.
It does have SOME similarities to Mikehiow's US issue (Full Monty attached).
As his connection resynced during the issue this morning, his US Line & Signal attenuation were also updated, showing quite a hit.
-
>>> It appears the US SNRM was still ongoing at the time you generated the Full Monty montage
Yes they were - it didnt stop until 5.30pm. This is the longest period of instability since its started :(
>>> Perhaps you could run graphpd.exe manually or via the Settings editor GUI some time after 18:40 tonight so that we can see a full 24 hour period?
Now attached.
-
Hmmm.
There is some general 'background' fluctuation in US SNRM in the lowest frequency U0 band (ADSL frequencies).
However, the U1 & U2 bands went crazy (VDSL2 frequencies).
We can also see some SNRM fluctuation, to a lesser degree, in the DS bands.
Apart from a burst of US errors just before 11:00 (at the time US SNRM was at its lowest), your connection looks to be pretty much error-free.
I'm a little surprised though that the U0 band is actually in use with such high US attainable rates.
Mind you, we have recently seen quite a bit of 'oddness' about a number of VDSL2 connections (my own included) - lower speeds, reduced estimated speeds & disturbance, particularly in the US bands.
I suppose your current cabling arrangement has to be prime suspect, but if the issue continues after the cabling is attended to, I'm afraid that I for one have no suggestions as to what the cause may be or indeed a possible cure.
I do wonder if BT have been 'tweaking' DSLAM settings/power back-off etc. & that in itself could be the cause of similar issues (although you had started seeing these issues before switching to VDSL2).
A visiting engineer did suggest that lower speed estimates & maybe reduced performance may just be related to the roll out of BT Vision (to ensure the best possible performance for BT Vision).
This was his own theory though as no official communication had been issued to engineers.
I also wonder if the reasonably prolonged spell of hot weather has anything to do with it?
We have to presume that cabinet fans are up to the job, but who knows?
I wish you the best of luck in at least getting the internal cabling sorted (now that it appears it's no longer under your control) & I'm sure you'll keep us regularly updated with progress (or not, as the case may be).
P.S. The date & time setting batch file probably contains the wrong default modem IP address.
This is how it should look for a default setting:-
"(sleep 1 & type login1.txt & sleep 1 & type login2.txt & sleep 1 & type login3.txt & sleep 1 & echo date -s %DTSTAMP% & sleep 1 & echo exit & sleep 1 & echo exit & sleep 2) ^| Plink -telnet -P 23 192.168.1.1"
The soon to be released update uses an exe instead of a batch file to set the modem's date/time & it takes the modem's IP address from the ini file, also now automatically resetting the modem's clock following a detected resync/modem reboot.
On ADSL connections, the HG612 syncronises with a time server, but doesn't for VDSL2 connections (at least when used in the default bridge mode).
Setting the modem's date/time is only useful if the HG612's internal logging is enabled & it's not all that necessary (other than another check on resyncs etc.) as all the timings in the programs' log files is taken from the PC's system time anyway.
-
Thank you BE for your input, advice and information - appreciated.
Last night the SNRM was dropping down to 0dB.
It started again at 1.30am till 2am. Then again at 10am and just recovering again now.
The internal wiring done by the contractor is just going to confuse things, I had it running from the old master socket previously and that didnt make any difference to my line dropping.
I sent an email to Bob yesterday and hes asked me to commence the troubleshooting process, but gawd knows where I stand on this. Two weeks ago I had a rock steady 3dB SNRm line. The issue only started after I'd started the process to move to PN and I was hoping it was the Be MSAN. I have a horrible feeling that Plusnet and BT may just say tough :(
-
I have a horrible feeling that Plusnet and BT may just say tough :(
We shall have to ensure that Bald_Eagle1 assists you in keeping PlusNet 'on the case'. After all, he is the expert! ;)
-
Just an update and so I can post the last 2 days full monty stats for viewing.
Bob responded to my mail and a suspected EMI/REIN fault has been logged with PN.
Someone from PN tried to call me yesterday. I wasnt in but they left a message saying they will call back this morning.
-
Bob responded to my mail and a suspected EMI/REIN fault has been logged with PN.
Someone from PN tried to call me yesterday. I wasnt in but they left a message saying they will call back this morning.
That's good news as it confirms the matter is being taken seriously.
It is sometimes handy to combine a few days/weeks/months of stats into one montage.
e.g. to create a montage of the last 2 days, run graphpd.exe & enter 2 d (lower case) & montage will be created in a separate & suitably named/dated folder.
-
The message basically said they were looking at raising a suspected REIN fault with BT, but need some more info from me first.
Thank you BE for the instructions on how to combine several days stats into one, I hadnt realised it would do that.
-
Fingers crossed.
But I still think it's a strange form of REIN that affects the US bands while skipping the intervening DS ones. ???
-
Engineer's appt booked for tomorrow am.
I dont think its gone through as REIN yet due to the fact that my internal wiring is now a bit of a pigs ear which definitely does need to be sorted, although they have recorded on the fault to BT that their is a possible external line fault on the D-side too, and that upstream atten & SNR are jumping around.
Lets hope its a BToR guy with proper equipment this time :fingers:
>>> I still think it's a strange form of REIN that affects the US bands while skipping the intervening DS ones.
Thats something that struck me last night at one point too. The fact that FTTC has the split bands, yet its still mostly just my upstream.
-
Engineer's appt booked for tomorrow am.
... my slot was 8am to 1pm... and no-one turned up... grrrrr :(
-
Don't you just hate it when that happens
I certainly do
toulouse
-
and no-one turned up... grrrrr :(
As I'm sure you will have noticed by now there's a lot of that being reported on the PN forums and no-one seems to be doing anything about it.
Even worse PN don't seem able to know until hours afterwards so don't/won't warn the customer.
Hopefully you'll stick your 10 cents in on the feedback section there. :angel:
-
Even worse PN don't seem able to know until hours afterwards so don't/won't warn the customer.
Well, I think in fairness to PN, if they don't know about it then they could hardly tell the customer could they? Perhaps you were advocating more proactive monitoring, but short of continually looking for BTOR 'feedback' and/or continually phoning the customer (which might not even be possible depending upon the nature of the fault) I'm not quite sure what you would expect them to do.
The problem, I suspect, is in the BTOR tasking, particularly when it's handed out to other sub-contractors, which means there's another link in the reporting chain. Absolutely infuriating I know, but the pressure has to be focused where it will make a difference, and that, in this case, is BTOR.
Perhaps there ought to be a quid pro quo for no-shows on either side. Customer or BTOR pays depending upon who's at fault (after common sense has been applied). :-X
----
edited by admin to fix quote tags
-
Perhaps there ought to be a quid pro quo for no-shows on either side. Customer or BTOR pays depending upon who's at fault (after common sense has been applied). :-X
Definitely. It's a totally unfair system.
e.g. Engineer turns up and says no-one was in - you get a bill. Converse very much does not apply.
PS ColinS Can you go back and edit your post, its quotes are unbalanced somehow. :'(
As for PN, the problem is that the failures of the current system are pretty obvious and the only way customers can put pressure on BTOR (if they are at fault) is via ISP's like PN - but they don't seem to care either, or if they do keep it to themselves.
There are loads of glaring issues with the processes but PN (and others) seem happy to live with them as its the end customer who bears the pain. >:D
-
I have another appt for tomorrow am.
I not sure where the problem lays with regards to failed engineer visits so cant comment on that, but having had a quick look around this doesnt seem to be just a PN problem and other SPs also seem to have their share too.
>> Perhaps there ought to be a quid pro quo for no-shows on either side.
I know on one of my tickets there was mention that if I wasnt in when the engineer visited I could be liable for a £50 fee. I've seen mention that some other ISPs have quoted more! I also noticed that El Reg did an article about the number of failed BT engineer appointments
I have found this link (http://bt.custhelp.com/app/answers/detail/a_id/9394/~/customer-service-guarantee) about claiming compensation from BT for missed appointment which is supposedly the princely sum of £10. Many many moons ago (about 10 yrs ago) I did successfully make a claim for 2 in a row failed engineer visits. BT credited my blue phone bill with iirc £50
-
As for PN, the problem is that the failures of the current system are pretty obvious and the only way customers can put pressure on BTOR (if they are at fault) is via ISP's like PN - but they don't seem to care either, or if they do keep it to themselves.
There are loads of glaring issues with the processes but PN (and others) seem happy to live with them as its the end customer who bears the pain. >:D
Our posts crossed. A convo I just had with one of the PN BOT guys, would appear they they are aware of the failings of the BT/ISP appt system, and if I understood correctly they are being billed for these 'failed' visits. I was told an actual figure of how much its costing PN per month for this and also engineer repeat engineer visits because the fault isnt corrected first time. Sounds like PN may be doing an audit because the sum involved a huge. Certainly the guy I spoke to isnt happy about the current situation because it reflects badly on the SP and its them that have to deal with annoyed EU's and then go through the booking process again.
I think Colin may have hit the nail on the head with his mention about how many people/organisations become involved and its the ISP that has to co-ordinate the times.
-
I have found this link (http://bt.custhelp.com/app/answers/detail/a_id/9394/~/customer-service-guarantee) about claiming compensation from BT
That's interesting, though the way its worded is very phone line oriented.
Maybe that sort of thing is a difference between BT Retail and other phone/broadband providers?
For example I've seen comments that when the phone service is down (and I realise I'm digressing from the original topic) BT Retail will provide FOC diversion to a mobile, PlusNet do not.
-
Our posts crossed.
I was probably editing my original post to add some afterthoughts. :-[
One reason I tend to "lay into" PlusNet (apart from having once been a customer, still having access and several referrals AND probably returning soon) is that they are a BT Group subsidiary so, at a certain level, WILL have the ear of senior BT management in a more significant way than some other ISP's. And of course they sell themselves on "award-winning service".
Not to mention than when they incur major costs from the failings of another part of the same group someone really should be listening! :-X
Good luck with the "rescheduled" appointment. 8)
-
Had the usual 5am problems today and my line struggled to remain in sync despite a 16dB SNRm
It finally came back up at 79,999 down 9,234 up.
Line struggled until about 9.20. BToR guy arrived at about 10.10
Nice Mr BToR man just left, unfort the line was fine whilst he was here, but at least he understood SNR and attenuation and was interested in my graphs.
He took one look at the wiring and said this definitely needs sorting and Im afraid Im going to have to report what the contractor has done as VDSL should not have been provisioned like this. He took a look at my layout and agreed that by far the easy option would be a 3m external run and proper NTE shift. Unfortunately he couldnt do it as he had no ladders and has arthritis otherwise he said he would have done it today. Someone from BT should contact me on Monday to arrange the NTE shift.
He put his JDSU on the line, but because it was working right at the time it didnt show up anything, but having looked at my graphs he has put in for a D-side shift/ new UG pair. He has also recommended in his report that if the d-side shift doesnt fix it that a specialist REIN engineer be called in.
BToR guy leaves at about 10:40... Typical - my upstream starts misbehaving at 10:45.
-
At least things are moving, Kitz. I would probably cease from monitoring your stats for a while, at least until the fix has been put in place. Did the engineer perform a PQT test ?? I'm intrigued as to why he said it needs a D-side change ?? I'm not saying it doesn't require one, but has he communicated to you that he has found a definite fault via his tests ???
Either way, get yersen in t'back garden whilst you can (before the torrential downpour arrives), pour yourself a glass of wine and put 'Upstream thoughts' to the back of your head for the time being. ;D
Edit: By 'tests' I mean copper pair tests, whereby I'm assuming your comments are towards the 'Synch and data flow' tests ??
-
>>> he communicated to you that he has found a definite fault via his tests
Unfortunately not, Typically the line was fine between 9:20 and 10:45, he even joked watch it misbehave again when Im gone.. and it damn well did (and is doing now). He could see the low 9,234 sync though and he seemed to understand the SNR graph showing what had been going on earlier this morning. He said whats going on at 5am... and said that perhaps needs a REIN specialist. I cant recall now if he has actually booked one, or if he said he was going to recommend if the d-side shift didnt fix it. He said my internal wiring is going to complicate things, but could see an issue outside of this.
He did run through the tests available to him on his JDSU which is when he said he was going to recommend "a new UG pair"
I told him that the problems had started whilst on Be's MSAN. He was a guy in his early 50's/late 40's ? and seemed to know how the system worked.
Anyhow yes, I am now going to take up your suggestion and Im off out to do some gardening whilst the sun is still shining :)
-
I'm pleased to read that progress is being made on both fronts. :)
As soon as the proper wiring to the relocated NTE5/A has been installed that will remove one layer of confusion.
-
Had the usual 5am problems today and my line struggled to remain in sync despite a 16dB SNRm
It finally came back up at 79,999 down 9,234 up.
Line struggled until about 9.20.
That indicates that it did actually resync, at least once.
Did you mean it had resynced a few times or that it finally resynced just the once?
An Ongoing montage for the last 24 hours would confirm when/how many times (as would RESYNC.LOG in the Current_Stats folder - unless some of the resyncs were still at 80/20 Mbps).
Also, excellent advice from BS - forget the monitoring for now & get outside & catch some rays - while it lasts :)
-
Update:-
After a heavy night, a very tired kitz answered the phone at 8.30am to an unexpected call from a BToR engineer asking if he could come round this morning. (https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.emotionless.co.uk%2Femotes%2Ff%2Fdrink10a.gif&hash=174dc9a7b55f9b5ff4a8fd5defe390fc0f8ade4d)
I wont bore you with full stats because hopefully now they wont be needed.
Anyhow, I now have no internal wiring at all. New NTE is located in required position straight up the external wall... and hes gotten rid of the 25m internal wiring by running a separate 3m external cable back down to the old NTE so that I have an extension in the hall. The wiring is all neat and tidy and hes got rid of that horrible box so I can now use my desk drawers again. It looks oh so much better and Im well pleased. :clap2:
Next he goes to check the outside box , and calls me to 'come have a look at this' - Photo attached.
As soon as he touched the white wire, the copper disintegrated from the joint! He was surprised that my voice line hadnt been noisy. This has now all been removed and replaced.
Hes just gone now, these are my before & after atten figures showing a slight improvement for both up and down.
27 Jul 2013 10:23:22 0.8 17.8 28.9 N/A 11.1 24.4 38.5
28 Jul 2013 11:29:23 0.8 16.7 26.9 N/A 10.4 23.4 36.3
My upstream SNRm has also increased by 3dB to a record high of 18.5dB.
Hes done several tests with the JDSU (BS may be able to explain this further) some of them werent quite right and there still shows a possible problem with the REIN figure. Another figure which should be near 60 is showing at 5.
Hes going to be writing a report that all seems to be mostly working fine atm, but will ring me later in the week to check & see how its performing. I'm really hoping that it was that copper wire though that was causing all my issues. :fingers:
-
BT engineer on a Sunday. :-X
Is that "pulling rank"? :angel:
-
Nope I can assure you it wasnt. I was surprised as anyone to get that phone call which woke me this morning. I was told it would be Monday before I heard anything from BT.
I perhaps would have been a bit gentler on the vin0 if I'd have known. 8)
-
Hopefully that has fixed it. The picture of your outside box looks like something out of a horror movie. :)
-
Nope I can assure you it wasnt.
Sorry, I didn't mean by you. ;) Maybe someone in PN or more likely BT who keeps their eye on "things" online? 8)
Obviously if they can do it for you, they can do it for anyone. :lol:
-
shrugs.. I really don't know. I dont think its come from PN as I havent had a reply to my ticket after yesterdays visit yet... but Im not too surprised about that since its weekend and afaik BOT team dont work then.
The BT guy from yesterday perhaps did all he said he would.. he seemed most apologetic that he couldnt fix things then and there for me.
-
Anyhow, I now have no internal wiring at all. New NTE is located in required position straight up the external wall... and hes gotten rid of the 25m internal wiring by running a separate 3m external cable back down to the old NTE so that I have an extension in the hall. The wiring is all neat and tidy and hes got rid of that horrible box so I can now use my desk drawers again. It looks oh so much better and Im well pleased. :clap2:
Success! Clearly that engineer was one of Black Sheep's 'flock'. :D
Next he goes to check the outside box , and calls me to 'come have a look at this' - Photo attached.
As soon as he touched the white wire, the copper disintegrated from the joint! He was surprised that my voice line hadnt been noisy. This has now all been removed and replaced.
Yuk! :tongue:
Has a DLM reset been requested for your line?
-
It sounds like you're half way there towards a top-notch connection. There does appear to still be massive issues with the MPF though.
I can only give my views on what you are telling us, but the figure of '-5' (instead of '-60') tells me your circuit is extremely susceptible to WB Noise (Crosstalk and RFI). '5' is extremely low, and I've personally never seen a MPF as poor. This measurement is taken as Decibels (dB) and as a rough guide, if you draw a flat horizontal line on a piece of paper, then at the centre draw a '0' figure. Now, anything to the left of the '0' is entering into the audible range (positive dB) of the human ear, with a jet plane taking off being approx. +100-120dB. With DSL, we want the MPF to be as near to 'Perfect silence' (-60dB) as is possible, so back to the line on the paper and the further to the right of the '0' you go, the better it is. A typical circuit (length dependant) will be around the -40dB-55dB area.
So, I don't particularly see that REIN is the issue here, with a value so low any 'noise' will affect the circuit. If the circuit still misbehaves after the fault has been repaired, then it could be REIN ??
The corrosion seen in the BT66 (Grey outside box), is typical of the screw-terminal connections. That is why years ago, BT made it a 'defect' and if (and only if) the engineer has cause to enter the closure, then the wires should be gel-crimped together and the terminal blocks removed.
I think the best thing to do now, is to continue monitoring your connection, as I've just had an afterthought regarding the 'WB Noise' reading mentioned earlier in my post. I'm assuming he took this reading from your house 'looking back' towards the Cabinet, and as such taking the measurement against applied voltage ?? If so, I'm not sure how this would affect the reading, as I only ever perform this test on a 'dead' pair of wires. Ergo, it may be a corrupt reading ?? If I remember, I will do a 'WB test' tomorrow against a 'Live' pair of wires, to satisfy my curiosity. :)
-
Anyhow, I now have no internal wiring at all. New NTE is located in required position straight up the external wall... and hes gotten rid of the 25m internal wiring by running a separate 3m external cable back down to the old NTE so that I have an extension in the hall. The wiring is all neat and tidy and hes got rid of that horrible box so I can now use my desk drawers again. It looks oh so much better and Im well pleased. :clap2:
Success! Clearly that engineer was one of Black Sheep's 'flock'. :D
Next he goes to check the outside box , and calls me to 'come have a look at this' - Photo attached.
As soon as he touched the white wire, the copper disintegrated from the joint! He was surprised that my voice line hadnt been noisy. This has now all been removed and replaced.
Yuk! :tongue:
Has a DLM reset been requested for your line?
LOL ...... thanks B*Cat, there are lots of decent engineers out there, the problem is down to 'Lady Luck' as to whether you get one !!! ;) ;D
-
Well, a definite yay! :thumbs: for the wiring and junction box work, and also for an engineer who seems to know what he's doing.
Ian
-
Anyhow, I now have no internal wiring at all. New NTE is located in required position straight up the external wall... and hes gotten rid of the 25m internal wiring by running a separate 3m external cable back down to the old NTE so that I have an extension in the hall. The wiring is all neat and tidy and hes got rid of that horrible box so I can now use my desk drawers again. It looks oh so much better and Im well pleased. :clap2:
Success! Clearly that engineer was one of Black Sheep's 'flock'. :D
Next he goes to check the outside box , and calls me to 'come have a look at this' - Photo attached.
As soon as he touched the white wire, the copper disintegrated from the joint! He was surprised that my voice line hadnt been noisy. This has now all been removed and replaced.
Yuk! :tongue:
Has a DLM reset been requested for your line?
A reset is not required, B*Cat. I've just checked, and Kitz is still on her 'Open profile' of 128K-24M. :)
-
>>> then the wires should be gel-crimped together and the terminal blocks removed.
Yes that is what he's done, I still have the terminal block here. Hes snipped away the B/W & Or/W pair on the RH side. On the other side hes snipped the blue wire, but where the white wire was its just a mush of blue oxidised copper. He only poked that white wire gently with a screw driver and it disintegrated.
>>> but the figure of '-5' (instead of '-60') tells me your circuit is extremely susceptible to WB Noise (Crosstalk and RFI).
My apologies, yes it was a negative figure. He certainly wasn't happy about this particular reading. Yes they were taken here from my new NTE though.
He did briefly show me the results & iirc there were 3 measurements on that particular screen of the results. One of the readings said REIN towards the top left and displayed a figure which he wasn't too happy about either, but he mentioned that wasnt always an accurate indication? He definitely said he would be mentioning these figures in his report.
TBH I really was hoping that he'd found the problem, and I was conscious of the amount of time he'd spent here sorting out the 'Quinn Cabling' before he even started on the fault finding. The line was behaving whilst he was here, having just come out of a period of SNR silliness.
>>> is to continue monitoring your connection
I've been out this afternoon.... and returned to see this on DSLstats :'(
-
Hmm ...... a 30 minute burst of instability ??!!. :no:
The 3 results are the 'Summary screen'. There is a 'Page up' button on the JDSU that would have displayed each individual test and associated results. I can't for the life in me remember the 3'rd parameter on the 'Summary Screen' (as I tend to go straight to the in-depth results), but from memory the top one is 'WB Noise (REIN)' and the second one is 'Test Summary'. With a JDSU, we get 3 indicative flags ......... green tick = good, red cross = bad, exclamation mark = borderline pass.
I appreciate your comments about 'time spent on-site already', although that shouldn't play a part, disciplinary measures ensure it does. ::). However, he also may not have been UG (Underground) skilled, and as your estate is UG fed, there's nothing he could have done about the potential faulty D-side.
Different managers work in different ways, some will request the non-UG skilled engineer already on-site, build an 'Assist' for a UG guy to help fix the fault. Some will ask the non-UG guy to pass the job back 'incomplete' and have it put in the 'UG faults queue'. I don't know how your engineer has progressed the job, I suppose time will tell ??
-
Well I guess I shall have to see if it still does the 5am thing... not much I can do atm aside from keeping DSLstats running. He said he would call back to check.
>>> he also may not have been UG (Underground) skilled, and as your estate is UG fed, there's nothing he could have done about the potential faulty D-side.
The guy who came yesterday (http://forum.kitz.co.uk/index.php/topic,12660.msg240617.html#msg240617) mentioned about the D-side/UG perhaps needing replacing.
Although Im a bit concerned that the SNRm is fluctuating by 11dB and there is something still there wrong with the line... s atm I am not too unhappy about what happened today. Hes made good all my internal wiring and made really a nice neat job of everything. He's found & replaced the oxidised terminal block.
In all fairness its an intermittent fault and Im therefore willing to understand that this may be a process of elimination. With the state of my internal wiring and that oxidised joint, I can understand how anyone would perhaps think that these are going to be the obvious culprits.
I like to think Im fair... up to a point.. eg I certainly was NOT happy about the Quinn wiring.
Im not too chuffed about Fridays no-show appt, but I think this could be the reason why BT may have arranged the w/e visits.
I will however get peed off if I feel someone is taking the pee.
Soooooo if this continues, then I expect the UG pair being next on the list. I'm not quite ready to roar yet.. but be warned for if I do ;)
-----
lol I just realised I got caught by the forums automated swear filter :lol:
-
A reset is not required, B*Cat. I've just checked, and Kitz is still on her 'Open profile' of 128K-24M. :)
Hmm . . . 128k-24M ?? I would have expected 128k-40M if the profile was 'wide open'. :-\
-
Mis-type ............ 128K-80M.
-
Mis-type ............ 128K-80M.
Ah, much better! ;)
-
What you need is something to automatically clear the underground oxidization, by sending loud unpleasant frequencies down the line?
Perhaps if you call Dial-A-Disk and request this, it'll make the line 100% again.
http://www.youtube.com/watch?v=8CSSFdaVr5U (http://www.youtube.com/watch?v=8CSSFdaVr5U) ;D
Ian
-
hahaha.. Ive never heard that before
E.M.I E.M.I E.M.I
Hello E.M.I
- how apt :lol:
Perhaps I should post that one the main site.... or perhaps not!
...maybe Im just a tad too chilled this evening :)
-
........... and for today's episode ::)
Rather interesting development, I can account for each and every one of these spikes below.
Ive been at home this afternoon having to catch up on some domestic things and chores that have been neglected over the past few weeks.. and Ive been making and receiving several phone calls.
Without fail each time I use the phone (receive or dial out) then my downstream SNRm will drop.
When someone calls me and my phone rings.. the upstream SNRm will plummet.
I've also just replicated it using BT ring back facility.
I think this is new, but cant be sure because Ive not really made/received a series of phone calls like this in the past few weeks.. and been at my desk which is how I happened to notice the spikes appearing in DSLstats real-time.
Doesnt account for the previous periods of EMI like activity and certainly not the 5am stuff though.
---
Not sure when the BToR guy is going to contact me back like he promised...
nor have I heard anything from PN yet from yesterdays events updated ticket.
-
The evidence you are accumulating is beginning to point to a latent HR or semi-conducting joint. :-\
-
The evidence you are accumulating is beginning to point to a latent HR or semi-conducting joint. :-\
Agreed. It suggests what Kitz is seeing is the effects of a 'wetting' current caused by the use of the phone.
-
Agreed the first thing I thought when seeing the effects of using the phone was a HR fault. PN have today sent it back to BT.
Out of interest has anyone ever seen anything like this before? This is yesterdays graph up my Upstream SNRm which looks rather unusual how the U1 and U2 bands cross over and almost mirror - something Ive not seen before. I have a theory what this could be, but it would be interesting to hear others thoughts.
-
I'll suggest that as the three bands cover different frequency ranges, you are seeing frequency related effects as a result of the non-linear behaviour of a possible semi-conducting joint. :-\
-
Its weird isnt it? I've never seen anything like that crossover effect before, but still being a N00b at vdsl, I wondered if anyone else had seen this sort of behaviour in the past.
-
I have seen stats & graphs from quite a few different VDSL2 connections over the last 18months or so & that's the first time I've seen that effect.
So, it took around 6 hours before each band's SNRM stabilised, but at a completely different level to when the 'issue' started, yet the lowest frequency U0 band only saw steady & quite minor fluctuation throughout.
I'm tempted to go with b*cat's theory of a possible semi-conducting joint.
Has DS SNRM also been affected to anywhere the same extent?
I saw a similar effect due to a dodgy joint between pole the mounted DP & UG cable, but it only seemed to really affect DS SNRM.
I wasn't plotting data from each band back then but the attachments show the overall effect on DS & US SNRM & as my connection had/has no spare SNRM also the effect upon Attainable rates & sync speeds.
How does the overall DS/US SNRM graph look for the same period on your connection?
-
>>> Has DS SNRM also been affected to anywhere the same extent?
No.. it dips and stays there during the duration of the phone call, but recovers immediately after to its previous level. Using the phone causes a castle effect on the downstream SNRm. It does take a slight hit of a few dB, but as usual its the upstream that suffers by far the most.
>> How does the overall DS/US SNRM graph look for the same period on your connection?
The 'overall' SNRM looks fine and seems to recover.. its only when you look at the separate bands that you realise that U2 is making up for what is lost in U1 band.
My first thought was I wonder if power is being pushed up in U2, but I cant see any evidence of this.
Obviously the attainable rate drops dramatically by almost half when the phone is in use.
-
Ive just pulled out the bit loading graph which was taken at 2pm yesterday which would have been at about the time the phone was in use... it doesnt look too healthy in the lower tones.
For comparison - one taken 24 hrs later.
-----
edited to add
Ive just done a QLT and ring back... its still doing the same thing. Incoming call makes the upstream SNRm plummet. It would knock most lines out straight away as upstream SNRm loses 12dB
-
Looking back to when this issue started, on your ADSL connection, is it feasible the SNRM drops back then coincided with using the phone?
I had 2 main issues with my connection:-
1) DS SNRM would drop from the usual 6dB, occasionally to negative values & would most times resync when using the phone.
Dialing in, but not answering the phone, DS SNRM would increase, then for just a few hours, using the phone had no effect.
Simply removing the VDSL2 SSFP & using a dangly filter directly from the test socket cured that until an engineer replaced the SSFP.
2) At other times, the connection would frequently resync randomly (when NOT using the phone), but increasingly during hot & dry weather.
That was cured when the dodgy DP to UG cable joint was remade.
What does seem odd on your connection though, is that now the ADSL frequency bands seem hardly affected, the middle & higher DS & US bands (way outside ADSL frequencies) seem to be the ones affected - yet Bitloading in the lower DS & US frequency bands reduces drastically.
If you hadn't seen this issue while still on ADSL, my first thoughts would have been the modem itself struggling with the higher frequencies.
On VDSL2 connections, Line Attenuation per band remains static until the next resync & Signal Attenuation is dynamic & CAN fluctuate a little between resyncs.
Your attenuation appears rock solid, with no fluctuation at all.
Due to its intermittent nature, I suppose it could be EMI or a cable/joint issue.
My guess is leaning toward a cable/joint issue, but wouldn't that also affect Signal attenuation? Hmmm :-\
I wonder if a TDR test might just identify something somewhere in the D-side, that the more basic tests (PQT/Eclipse etc.) aren't detecting.
-
>>> is it feasible the SNRM drops back then coincided with using the phone
Absolutely not. Quite often it would start at 5am and last for a period of time.
Now I know Im a bit of a night owl, but even 5am is pushing my limits :lol:
TBH I dont think Ive seen the phone issue until after the engineers visit this weekend because I have tried QLTests in the past without any effect. A dip of 12dB on my adsl2+ connection would have wiped me straight out immediately so Im pretty sure this wasnt happening before FTTC.
>>>> Dialing in, but not answering the phone, DS SNRM would increase
Just tried that.. DS SNRm decreased by 1.5dB US SNRM decreased by 10dB
Both returned back to normal when the ringing stopped.
The longer the phone rings the worse the SNRm seems to get.. need to turn my ansaphone off to check this fully.
>>> At other times, the connection would frequently resync randomly (when NOT using the phone), but increasingly during hot & dry weather.
These were the symptoms I would commonly see, but it would happen mostly at weekends or in the wee small hours.
Aside from the one 1/2 hr period on Sunday, I havent seen this since the engineer replaced the oxidised terminals in the BT66, but it was intermittent before and could go a couple of days of before playing up again.
>>>> On VDSL2 connections, Line Attenuation per band remains static until the next resync & Signal Attenuation is dynamic & CAN fluctuate a little between resyncs.
Previously on adsl2+ my upstream line attenuation would randomly change.. sometimes frequently and by quite a lot.
Hmmm... just realised my DSLstats attenuation logs do now only show changes after a modem reboot. DSLstats is recording Line attenuation. Perhaps need to get eric to record Signal attenuation in order to monitor whats going on with the atten properly.
>>>> I wonder if a TDR test might just identify something somewhere in the D-side, that the more basic tests (PQT/Eclipse etc.) aren't detecting.
From the engineers notes supplied by Plusnet
circuit now working and testing ok on pq, eclipse and vdsl closeout, see stored results. at the end of the pq test on my jdsu there was a wb noise reading of -47 and a impulse noise reading of 104 which may indicate the possibility of rein being present
Hopefully the engineer would/should know what a TDR test is? (I dont) They all dont know what SNRm is and the effect of that on a line :/
---
Edited to correct formatting
-
>>> is it feasible the SNRM drops back then coincided with using the phone
Absolutely not. Quite often it would start at 5am and last for a period of time. Now I know Im a bit of a night owl, but even 5am is pushing my limits
TBH I dont think Ive seen the phone issue until after the engineers visit this weekend because I have tried QLTests in the past without any effect. A dip of 12dB on my adsl2+ connection would have wiped me straight out immediately so Im pretty sure this wasnt happening before FTTC.
>>>> Dialing in, but not answering the phone, DS SNRM would increase
Just tried that.. DS SNRm decreased by 1.5dB US SNRM decreased by 10dB
Both returned back to normal when the ringing stopped.
The longer the phone rings the worse the SNRm seems to get.. need to turn my ansaphone off to check this fully.
Hopefully, that will be common & very easy to diagnose issue for most engineers.
>>> At other times, the connection would frequently resync randomly (when NOT using the phone), but increasingly during hot & dry weather.
This were the symptoms I would commonly see, but it would happen mostly at weekends or 5am. Aside from the one 1/2 hr period on Sunday, I havent seen this since the engineer replaced the oxidised terminals in the BT66, but it was intermittent before and could go a couple of days of before playing up again.
>>>> On VDSL2 connections, Line Attenuation per band remains static until the next resync & Signal Attenuation is dynamic & CAN fluctuate a little between resyncs.
Previously on adsl2+ my upstream line attenuation would randomly change.. sometimes frequently and by quite a lot.
Hmmm... just realised my DSLstats attenuation logs do now only show changes after a modem reboot. DSLstats is recording Line attenuation. Perhaps need to get eric to record Signal attenuation in order to monitor whats going on with the atten properly.
He may already be doing that.
As mentioned, both your Line and Signal attenuation graphs are perfectly straight lines with no fluctuations at all in the graphs you posted.
I only ever see very slight fluctuations in Signal Attenuation on my longer distance connection.
>>>> I wonder if a TDR test might just identify something somewhere in the D-side, that the more basic tests (PQT/Eclipse etc.) aren't detecting.
From the engineers notes supplied by Plusnet
circuit now working and testing ok on pq, eclipse and vdsl closeout, see stored results. at the end of the pq test on my jdsu there was a wb noise reading of -47 and a impulse noise reading of 104 which may indicate the possibility of rein being present
Hopefully the engineer would/should know what a TDR test is? (I dont) They all dont know what SNRm is and the effect of that on a line :/
BS will be able to confirm whether or not all engineers are aware of TDR tests & exactly what they can identify, but basically any changes in a connection's physical properties can be seen graphically & the distance from the point of testing measured electrically & apparently quite accurately.
For some reason unknown to me, most engineers seem very reluctant to either carry out a TDR test or arrange one, the responses I have received when asked have been on the lines of "that wouldn't show anything that our ordinary tests don't already show".
I did purchase a 'Mole' TDR tester from a famous auction site & tried it on my connection as other engineer tests had all passed with flying colours.
It did show 'something' at a distance from my master socket that was very, very close to the location of the DP (where the main fault was eventually found & repaired).
-
TDR -- Time Domain Reflectometry.
http://www.exfo.com/glossary/time-domain-reflectometry-tdr
http://www.jdsu.com/ProductLiterature/hst3000tdr-an-acc-tm-ae.pdf
Attached below is an image of the ex-Beattie Tester 301C (a TDR device) that resides in The Cattery and some sample TDR traces from a JDSU document.
-
Hmmm... just realised my DSLstats attenuation logs do now only show changes after a modem reboot. DSLstats is recording Line attenuation. Perhaps need to get eric to record Signal attenuation in order to monitor whats going on with the atten properly.
You're right, DSLstats logs line attenuation at present. But it's very easy to switch to signal attenuation if that's what you want. I'm just waiting for the month to roll over so I can check that the traffic data is retained properly, then I'll be releasing the next version. I'll swap over to logging signal attenuation straight away.
-
Thank you for the responses guys.. and also for the additional info from BE and b*cat about TDR.
I havent really responded as I fear that I may be getting a bit boring and since the engineers appt isnt until Friday there isnt much I can do in the meantime.
However, I have lost sync after a couple of nose dives in SNRm out of the blue. SNRm takes a hit each and every time I use the telephone, but the upstream SNRm still has a mind of its own regardless of using the phone or not.
For my own records at least, Id like to record the following:-
Ive just taken a call and the line quality was dreadful with lots of crackles and hisses. Repeated by doing a QLTest which had a very audible crackle.
This is the SNRm graph this afternoon. You can see that the upstream is wavering between 18 - 12 dB without anything going on. You can see the drastic and sudden drop when the phone rang at about 15:10. The dip at 15:15 was me doing the QLTest. Also note how after hanging up my SNRm improved.... this seems to have all the signs of a HR fault :-\
Opening up the line, now seems to have made things much better afterwards and Im now recording the highest upstream SNRm ever at 18.6dB
----
PS just for completeness I include some HG612 modem stat graphs over the past 4 days showing more weird crossovers. The last time it lost sync was 01.30 yesterday morning. I was NOT using the phone at the time.
-
Engineers been.
Wouldnt do a TDR test.
Showed him the SNRm graphs which repeatedly will dip when the phone is in use, but I dont think he understood the importance of SNR when it comes to DSL, so it probably went over his head. Also had a bit of a 'debate' about CRCs which showed up on his unit when the line is open. "They dont matter because they carry data which they can recover form.. and Im not getting FECs which indicate more of a problem" :-X
Unfort I dont think this went down too well as he is an ex marine engineer in comms and this was his job for 20yrs. :'(
He said theres nothing he can do as my line passes all his tests aside from showing an indication that there may be REIN.
Guess I'll now have to see what his notes say to PN. But as far as hes concerned theres nothing wrong... so its suck it up time.
-
Oh dear. :(
Let's wait for Black Sheep's comments and advice.
(I would be complaining to PlusNet in the strongest possible terms and would insist that an Openreach SFI engineering visit is booked as a matter of urgency. :-X )
-
Tough call here for me, but this is how I see it.
I personally have a love/hate relationship with the ex-MOD guys and gals. Yes, they may have been at the top of their tree in their own arena, and a few that have shadowed me have got qualifications coming out of their ar5e, but they haven't got the slightest clue when it comes to civvy street faulting techniques. My caveat, as always, is the extremely poor training and buddying time these folk have to experience, doesn't make for a great 'Customer Experience'. As in all walks of life, you also get the, 'You can't tell me anything' individuals, but that's life in general.
With that off my chest, these noobies (like seasoned engineers) are also under the dreaded fear of being tin-tacked if they don't meet certain standards week in - week out. They are also told (just like us), to carry out a set procedure of tests, and if they pass, then basically walk away ...... job done.
I'm not going into the rights and wrongs of this again, been there ...... done that !! :)
Speaking from experience, suggesting that REIN is the underlying fault is quite often a cop-out for some engineers. I'd say a high 70-80% of REIN cases I'm asked to attend, prove to be otherwise. Again, do not take my words to be gospel in respect to your fault, I'm talking in general terms, not specific, as I've never attended your fault, Kitz.
Lets say the circuit IS fault free on the pair of wires (MPF), which TBH it doesn't sound like from your description ??, and it IS in fact RFI/REIN causing the heartache ............. then Mr Marine Engineer should have rung our 'Diagnostic Centre of Excellence (DCoE) and chosen the REIN team option, and requested a REIN task be built.
If this hasn't happened, then nothing more will be done to rectify your perceived fault, until another fault case is built.
At the very least, a new D-side pair change should be carried out, as there could be a miniscule 'HR' on your existing D-side, that the PQT/Eclipse test systems can not detect ??
As an aside, I was recently tasked to visit an EU's premises as part of the e-Viper procedure. 8 Engineers previously, all PQT's good, hardly any errors in it's dormant state, or when the landline was rung, but DLM consistently dropped the profile day on day (Mentioned in another thread on here). By rigging up the HAWK to the MPF and constantly ringing the line, the tiniest of 'blips' (HR) was detected on the D-side cable [1]. A new pair was provided and I've not seen one single DLM event since then. Being on an 'e-Viper' means I'm absenced out of the system, and time constraints are not really an issue, without getting silly of course.
So, there we have it, an eclectic mix of getting the right engineer, with the right knowledge and the right tools, with the right amount of time given to fix it. If I were you, I'd put an extra quid on the 'Lotto'.
[1] This technique will not work on the JDSU, as it 'sees' ringing voltage as 'High Voltage Detected' and you can't see the screen for the warning !! ::)
-
A succinct desription of life, as it must now sadly be, in OR. That's what makes your shares worth more. However, as I know, that's not how you feel the EU's ought to be treated. :friends:
-
As your ISP is PlusNet they should be able to see that there is a defect in the circuit, as Bald_Eagle1 has extensively conditioned them to understand the various graphs that can be plotted from the data that has been harvested from a compliant Huawei HG612 modem. ;)
Everything that you have experienced and recounted can be attributed to a HR or semi-conducting joint the D-side pair. It just needs the attention of an Openreach engineer who is competent at locating such a fault. (Personally I would connect my Tester 301C to the pair at the NTE5/A and look towards the PCP / FTTC / exchange and 'into' the -50V from the battery. Then make a call to your line and watch the trace as the 'ringing' voltage is applied. (Essentially the same technique as Black Sheep described, above.))
So get back to PlusNet, ask to see the engineer's notes and reject the logged outcome. You need an SFI engineering visit!
-
Thank you everyone for your replies - , yesterday I thought there was nothing much more I could do, so decided to leave it last night and do something else :drink:
Looking at DSL stats, my line started being noisy at about 10.30 last night wavering at times between 18.5dB and 4dB. I wont bother attaching a screen cap, as its just the usual stuff youve seen before.
It seemed to recover at about 8.30ish, when it settled at 17.5dB... ......until the phone rang at just after mid-day.
- I answered the phone, but the line was so noisy we couldn't hear each other.
- The caller rang back, still noisy.
- 3rd attempt, much better.
- I did a QLTest, and although slight hissing it was ok
- at 12:25 I took another call and the usual thing.. upstream takes an immediate hit and downstream remains lower for duration of call.
Also note that the 2nd call knocked my adsl connection out completely and the line resync'd
------------
>>> Bald_Eagle1 has extensively conditioned them to understand the various graphs that can be plotted from the data that has been harvested from a compliant Huawei HG612 modem.
Plusnet have been fine, in fact they suggested that I had the graphs ready to show the engineer.. but said engineer didnt even want to know (dont think he understood SNRm and its importance with adsl)
>>> ask to see the engineer's notes and reject the logged outcome.
Plusnet sent them to me, without even asking, commenting that they arent very detailed. They may mean something to BS*
Eng Notes: RARA, dial tone, VDSL modem sync and router authenitication ok. VDSL sync test from SSFP ok Up 20mbps, down 80mbps. Pair quality test carried out all test ok, REIN reading of 97 also indicated on PQT, AC balance is 79. All tests shown and described to EU. End user has tested line and advises that SNR is affected at intermittent periods throughout the day and particularly 0500hrs and line can be noisy. No voice issues found on site. No fault has been found when line is tested. Eclipse test ok, LTOK and GEA test Up 20 mbps and down 80mbps.
I guess now, that I'll have to wait another week for another appointment.
----
* Knows that BS has other things on this w/e so no hurry.
-
As you have now experienced audible noise on telephony calls that is actually good news! :)
Are you able to record any of your telephone calls? If so, be prepared to do so when you have a noisy one . . . Collect the evidence.
-
The noisy voice line isnt totally new, this is something I had already mentioned to Plusnet and also to the engineer who came yesterday, who didnt seem interested because it wasnt noisy at that particular time.
Ive just taken a call and the line quality was dreadful with lots of crackles and hisses. Repeated by doing a QLTest which had a very audible crackle.
Today is the first day however that it was so bad someone had to ring back.
Also one day last week when PN rang me to confirm a date/time for the engineers appt there were a couple of the times in the conversation when he couldnt hear me, yet I could hear him ok.
I dont have any way of recording voice calls that I know of :(
-
Just had a sudden thought. Are PlusNet capable of running a Copper Integrated Demand Test (http://www.openreach.co.uk/orpg/home/products/llu/cidt/cidt.do)? :-\
If not, then why not? :-X
-
You know b*cat its really bugging me now when I heard of the 'CIDT test' and why I had to look it up and ended up at that very page you linked to. It could of perhaps been somthing I stumbled across whilst searching to see what tests the JDSU did.
I do have these test results pasted in an early ticket.
GEA Service Test
Test Outcome Pass
Test Outcome Code GTC_FTTC_SERVICE_0000
Description GEA service test completed and no fault found .
Main Fault Location OK
Sync Status In Sync
Downstream Speed 80.0
Upstream Speed 20.0
Appointment Required N
Fault Report Advised N
Profile Name 0.128M-80M Downstream, Interleaving Off - 0.128M-20M Upstream, Interleaving Off
-
Just had a sudden thought. Are PlusNet capable of running a Copper Integrated Demand Test (http://www.openreach.co.uk/orpg/home/products/llu/cidt/cidt.do)? :-\
If not, then why not? :-X
Mmm. Been here myself before too ... on BE/ADSL2+. Be couldn't do it because (IMO) their systems development people need (or certainly seem to ask for) several years notice to do anything (OK, perhaps a small exaggeration! :lol:)
However regarding CPs don't need to update their systems to R1700 to use CIDT but may need to make local configuration changes to their internal XML and any automation relating to the B2B response/line test diagnositics along with updates to their processes and training.
I seem to remember that all CPs needed to migrate to R1700 (or beyond now, probably) by a certain time, and it was about a year ago I looked into that.
-
Quick reply.
As B*Cat states, it's great when there's audible noise, as it is obviously proof-positive of a fault somewhere. If this is the case, then the engineering visit doesn't have to be a 'Broadband' one, a simple 'Network' engineering visit would suffice.
The problem with this is the percentage chance of being TRC'd (Time Related Charges). As the PQT passes, also the Eclipse and the VDSL GEA test, there's a damned good chance that when you ring your CP to report the noise fault, the subsequent remote 'low end' test will also pass, with 'No fault found'.
This then falls under the CDTA process (Conscious Decision To Appoint). This is a pretty harsh process, which sees an awful lot of TRC being applied. The engineer will pick up a CDTA task, visit the premises and undergo the necessary tests. If they all pass and no audible noise is heard then job done and see you later. The only way the EU will not get TRC'd, is if the recent line tests have shown there to be a fault. If they have always shown a 'LTOK' (Line Tests OK), then the EU (or the ISP who will probably pass it on) will get a charge levied against them.
The reason behind not charging on historic tests showing a fault, is that remedial work on a completely different task may have cured the problem ?? IE: A joint remake, or a length of Aerial Cable being renewed ... etc etc.
Not much help, rather guidance for those reading. :)
-
>>> the percentage chance of being TRC'd
and there-in lies the problem. The fault is intermittent and I never know when its going to show up. Yes I can replicate the drop in SNRm very easy I only have to pick up the phone to do that. My ISP should also be able to see the times when it has lost sync after the phone rings, but because my SNRm is 18dB, the line often hangs in there.
Audible noise is sometimes there , and sometimes its fine.
TBH the last engineers visit didnt give me much hope, particularly after the CRC/FEC discussion and request for a TDR failed. From what I can gather he mostly did fttc installs, I cant recall now the name, home something?
To most of us here, theres something obviously wrong, its just trying to find out exactly what.
I dont want to be landed with a bill just because all is fine on the day the engineer arrives :/
-
That's the thing with intermittency. However, I believe that if you have been TRC's and a fault is found later, then the charges are reimbursed ? I'm not sure of time-scales between applied charges and potential reimbursements, but I'm sure your ISP will be able to inform you ?.
The key to this is as I mentioned before, the engineer should apply a TDR trace using his HAWK/mole, and ring the landline number whilst looking at the viewing screen for a change in trace. Alas, the new engineers wont have this kind of kit, and therefore wouldn't be able to do this. I would be tempted to try and raise a 'Chairmans letter' (e-Viper), as the probability is a long standing engineer will be despatched by the local OM (Operational Manager) ??
-
Cheers BS, I responded to my ticket the other day - I havent had a reply yet (guess its got caught up in the usual no BOT team at weekend thing), so am waiting to see what they come back with.
-
Just to add to this (yep I know - Im using this thread as a log!)
Had a wee bit of a bumpy 24hrs with the upstream SNRm all over the place. If I didnt have an 18dB margin, this line would be dropping out constantly.
Also made a discovery that using the phone as well as being able to knock out the connection when the phone rings can also wet the line and bring my SNRm back up when things get too rocky.
Bit loading doesnt look too good atm though in my lower frequencies :(
PN are trying to escalate this. BT were supposed to ring yesterday.. but didnt.
-
Another graph showing that I can improve my SNRm by opening the line and that dsl conditions are normally better for a while after Ive used the phone (not during though)
12:30 SNRm had started to decline again,
12:40 I simply took the phone off the hook for a min then replaced the receiver.. at which point the SNRm jumped back up to 18dB
---
Edited to add another graph
Whoops dont ring when SNRm is being stupid :-X
-
evening all,
Sounds like you are having a worst time then me. Though there are similarities to the problems I'm having and not just with the faulty adsl line, beatie not showing up, not doing what was agreed, deciding after a five minute line test that all the stats we have collected don't me anything. O and that crc errors aren't important
Whats your plan of action next ??
-
PN have been on to BT today about this & it has been escalated to their Management
I've got the engineer booked for you for 10/08 between 8am and 1pm.
I've made our supplier's management fully aware of the nature of the problem, and am hoping this visit will be productive.
I'm therefore hoping that Saturday brings an engineer who can locate the fault
-
It shouldn't be down to luck but, well.. good luck! :fingers:
Ian
-
Hi all,
Sorry for not posting the graphs. I had to shoot back off to Liverpool and much to my annoyance someone had plugged there own wireless router that was using the same IP as the shared internets router into their ethernet jack at my block off apartments where I was staying. I could not even set the ARP entry manually because I did not know the MAC of the right BT Hub. So I have had no internet for 2 weeks and not been able to VPN into the box doing the graphing >:(.
I have got the graphs for the last 2 weeks if it will be of any help though Kitz. If so I will post them for you.
Once again sorry for the delays,
James
-
Cheers James, not sure if they will help... I think this is more likely to be a HR fault on my own line as it is ongoing even though Im now off the BE* MSAN. I'm also pretty sure that after today, this is going to be written off as a no fault found :(
-
Copy of the reply Ive just sent to PlusNet
Engineer has just been. Hes tried various tests but the line appears to be perfectly fine. This is something that I cant disagree with because the line is behaving itself at the moment.
The engineers tests show that my SNRm is fluctuating and do do so when the phone rings, this can be replicated by the engineer who confirms this on his equipment.
The result however is that the line (today) passes all normal BT tests and whilst there is a problem on the upstream, as far as BT are concerned, downstream is more of an issue.
During his tests he could see that upstream SNRm was fluctuating between 18dB and 6dbB, but this didnt cause the line to drop, nor did it produced any errors.
TBH Im not surprised at either of these observations because with an SRNm of 18dB, a loss of up to 13dB isnt going to cause the line to drop... nor would I expect errors to start generating at 6dB.. as you know most lines wont start generating a huge amount of errors until <6dB SNRm or <3dB SRRm (adsl2+) - hence why the Target SNRm is set why it is.
He also tested from the cab, and could see that from there that the same SRNm fluctuations were still occuring, although slightly less.
The engineer reckons that my upstream SNRm is set at 18dB by the DLM to try and stabilise my line - this is the only thing that I disagree with - Its actually a SURPLUS margin because under good conditions the line is capable of syncing at way more than 20Mbps.
The engineer was very polite and helpful, I have no complaints about the work he tried to do to try and trace the fault, which obviously is going to be difficult with an intermittent fault.. and because the line was behaving today. As per normal, an incoming call will always help stabilise the line, and since he called to say he was on his way, then SNRm returned to 18dB after the call was terminated.
I fear there is nothing else he could have done today, regrettably I wont be too surprised if in a couple of days it all starts up again as it has done in the past. BT dont seem to be too concerned because it is only the upstream affected. :(
-------------------
PS
An observation is that WOOSH does not appear to have logged all of my Loss of Syncs. I know 100% that the line has lost sync on occasions yet for some reason these arent being recorded. Why this is Ive no idea... the only thing I can assume is that very quick resysncs arent caught. The engineer could see from my uptime here that sync events have occurred, but there isnt anything showing on WOOSH. The only reason I could think for this is that (like most router monitoring software) it only polls at set intervals and doesnt always catch quick events.
and something not added in my reply.... but between you guys and me... I think this case is one of the reasons why BT dont like the EU being able to see their stats.... All I'd know is that my line would intermittently drop out for no reason. I wouldnt even know that it was only my upstream. I may eventually put 2+2 together and notice that it occurred during phone calls, but this would likely be at a much later stage when the line would be in a much poorer condition.
-
and something not added in my reply.... but between you guys and me... I think this case is one of the reasons why BT dont like the EU being able to see their stats.... All I'd know is that my line would intermittently drop out for no reason. I wouldnt even know that it was only my upstream. I may eventually put 2+2 together and notice that it occurred during phone calls, but this would likely be at a much later stage when the line would be in a much poorer condition.
TBH, quite a number of believe that is the MAIN reason that BT had the modems locked down.
I can understand that BT wouldn't want 'meddlers' to mess up otherwise healthy connections by fiddling with settings etc., but I'm sure they could have allowed read only access - a bit like the mileometer, speedometer or temperature guage in a car.
Most 'normal' users will no doubt be blissfully unaware of what actually goes on with their connections & just accept that it is what it is.
-
>>> but I'm sure they could have allowed read only access - a bit like the mileometer,
Totally agree with you.
----
Ironically if I had still been on adsl2+, they would have had to do something about it by now because my connection would be up and down like [insert common saying].
Be's DLM (nor any other adsl2+ DLM) would not be able to keep hold of a line like this because the line needs a large Noise Margin to remain connected due to the huge variation in NM that Im routinely seeing.
Its rather unfortunate that the fault only occurred at the time Id requested my MAC to go FTTC. My SNRm graphs from early in this thread when still on adsl2+ show logs where Id be losing sync many many times in periods of just 1/2 hr. Moving to FTTC has given me spare margin.. and why the line often holds whilst still being sick underneath.
-
Question. Am I wasting time proceeding with this? Plusnet seem willing to give it another go without me even asking and have automatically sent it back.
Its just the the engineer this w/e implied that Ive nothing better to do with my time than worry about my connection and how it works... which is kind of ironic since I feel like Im running round like a blue ass fly trying to fit everything in atm.
The upshoot is that it does lose a huge amount of upstream when the phone rings (up to 18dB) and it will always lose 2dB of downstream SNRm when on a call. This was replicated by the engineer but it appears to be classed as a small loss and of no significance because its upstream.
I fully appreciate that HR faults are hard to trace, so Im not blaming engineers... but the fact that its an intermittent fault - seemingly worse whent the weather is hot. Its also not helped that my Loss of syncs arent being picked up on WOOSH, making me look stupid.
The tests that the engineer did last Sat showed nothing much other than being able to replicate the loss of SNRm. Also why would him simply testing from the cab cause an immediate and permanent loss of 2dB of SNR?
Do I just suck it up and accept that I have a fault and that my line is going to often lose SNRm and drop out... and wait god knows how long before it fails completely. Im already starting to use my mobile more often because of the landlines intermittent but unpredictable noise.
Im dreading the thought of another fruitless engineer visit and me looking like a twat/idiot/'someone with nothing better to do'.
-
Im dreading the thought of another fruitless engineer visit and me looking like a twat/idiot/'someone with nothing better to do'.
I know those feelings far too well :(
As one of my very long threads confirms, I experienced almost 11 months of intermittent, but genuine line faults/disconnections/low sync speeds etc.
The symptoms were very similar to yours except it was DS that always took the clobbering & US remained reasonable.
I would very often see DS SNRM drop gradually (during hot/warm & dry weather) or suddenly when using the phone).
The other difference was that as my connection has no spare SNRM due to line length, SNRM would often drop into negative values & cause an almost immediate resync when using the phone & also at other random times, usually at much lower speed.
As the usual engineer line tests etc. invariably resulted in LTOK, it was incredibly difficult to prove there actually was a fault, despite possessing detailed raw & graphical data over a very long period of time.
I even resorted to purchasing a battered Mole TDR tester from ebay which actually confirmed my suspicions of a dodgy joint at the pole mounted DP across the road from my house.
When that fault was EVENTUALLY fixed, I enjoyed around 7 months of perfectly acceptable line stability & sync speeds (30 Mbps DS on around 1000m of D-side line length).
I currently feel in somewhat a similar position again, having seen DS sync speed lowered, in distinct stages, by almost 10 Mbps since December, DS power in the D2 band lowered correspondingly & having a number of LTOK engineer visits.
Fair play to Plusnet, they are still pursuing explanations & a resolution from BTOR.
The latest BTOR comment is that they can do no more to investigate the issue as my connection is stable (true) & performing quite close to estimated speeds (also true - but they seem to conveniently ignore the fact that my speed estimates have been quite recently lowered to not much above 20 Mbps from the achievable 30 Mbps they had been for around 10 months or so).
Good luck with this, don't give in just yet - patience is a virtue :angel:
-
I fully appreciate that HR faults are hard to trace, so Im not blaming engineers...
Actually, I think that is quite a charitable attitude.
Having spent my career in telecomms/datacomms (mainly software and not telephony), I can honestly say that few things motivated me more than a seemingly inexplicable and hard to find fault. The sheer satisfaction of getting to the bottom of a problem that initially seemed unsurmountable is hard to beat. Or at least, it was always one of my biggest motivations, what a shame so many so called 'engineers' don't seem to see things that way. :(
-
Thanks BE.. I know youve been through the mill twice with BT faults, so you understand how I feel atm. I dunno how you stood it for months on end. :flower:
>> Fair play to Plusnet, they are still pursuing explanations & a resolution from BTOR.
Yep.... my experience too.. theyve chucked back a few times now saying its not good enough. My ticket tonight came back saying when are you available for another appt and I inwardly groaned at the thought of going through all the explanations again :(
>>> I even resorted to purchasing a battered Mole TDR tester
That reminds me, I dont know if he did a TDR test.. apparently the Test Head at the exchange was down and he couldnt complete all of the usual tests.
BlackSheep - he did a test on the JDSU which showed the upstream SNRm fluctuating between 18-6 dB when the phone rang... dunno what test that was? By flipping to another screen it showed FEC/CRCs
>>> my speed estimates have been quite recently lowered to not much above 20 Mbps from the achievable 30 Mbps they had been for around 10 months or so).
and this is what is making me feel bad.. when the line is stable and I dont use the phone then I get a good 80/20. When its stable it flatlines.... yep straight boring no deviation at all, not even 0.5 dB
When its playing up I still get 80Mbps down.... its just the upstream which dips from 35Mbps achievable and will sync down to 10Mbps.
-
I can't remember who is responsible for the following paraphrased quotation, but it should be written as a reminder on a card for every fault-finder as a source of encouragement and inspiration :)
Absence of evidence is not evidence of abscence (of a fault)
:no:
-
Question. Am I wasting time proceeding with this? Plusnet seem willing to give it another go without me even asking and have automatically sent it back.
I don't think you're wasting your time - it's a fault. It can be replicated.
But I understand how frustrating and awkward it can make you feel.
Sometimes there are those situations where you just feel "this isn't right" but you can't explain why to those who say it's all ok, but in your case, you've got graphs ;D
Regarding BT et al not allowing EU to see stats : I'm mostly in agreement with you on this, although I've been on the other end of things and it can be frustrating.
%%%%Mists of time%%%%
Multi-user VAX/VMS system. Every month or two there would be a user phoning or visiting in person to complain/accuse (sometimes loudly) that I clearly favoured user x over themselves, because they'd discovered $MONITOR/SYSTEM and it PROVED that user x was getting twice the CPU cycles that they were getting on the shared system and WHY WASN'T IT FAIRLY SHARED.
Telling the user that they should write more efficient code or that their process was waiting on I/O from a physical device more than user x's process was would either enrage them further or send them away quietly fuming to Write A Memo.
We tried education, it had (some) success, but ultimately, leaving the users in the dark (by restricting access to $MONITOR/SYSTEM) was the policy that quietened things down.
Ian
-
Question. Am I wasting time proceeding with this?
Not at all, like any enthusiast (and pretty much all of us here if i may be so bold as to speak for them in this instance) you just want the best your line can deliver. Embrace the OCD! ;D
-
While researching something else entirely different (cf Monty Python), I was reminded of this observation, which I thought we all might recognise from our various experiences with changes in BB speed estimates, fault-finding and the like, irrespective of CSP/ISP
After the Challenger Shuttle disaster the term "Normalisation of Deviance" was coined with respect to failure of the "O" Rings which caused the catastrophic failure. The deviation from acceptable had become so routine that those involved subconsciously thought this was "normal".
:hmm:
-
Thanks for the comments and support, guess I was just a bit weary yesterday. PN have booked another appt for me, its just the thought of going through it all again. Line has been generally been ok the past few days - except for when the phone rings and is in use. It does appear to get worse when the weather is hot & dry.
----
Using the phone will wipe out all my bitloading up to tone 96 (414 kHz) and will at least halve the bit loading in all frequencies in up to tone 1026.
All of my bitswap activity is in those lower tones, which is highly unusual, as normally you'd expect bitswap to occur at the higher frequencies
-
You must not 'throw in the towel', for PlusNet are on your side. ;) :flower:
Just one thing to consider. If PlusNet are also your telephony provider (I forget your precise details), are they referring the fault back to Openreach as an intermittent voice fault? (Crackly line, etc.) If not, why not?
You should also stress to PlusNet -- so that they make it clear to Openreach -- that the fault becomes so bad at times that you have to resort to using your mobile telephone. In other words the telephony service is not fit for purpose and must be repaired. >:(
I would not be surprised that if a network engineer was booked to attend and given instructions to re-crimp each joint in the pair between the PCP and your home the fault would then be fixed. :-\
-
>> If PlusNet are also your telephony provider
Just had my 'Goodbye' letter from BT this week. I think PN wait a few weeks after the dsl has gone over to FTTC before taking over the phone line.
>> that the fault becomes so bad at times that you have to resort to using your mobile telephone.
I told the OR guy last here that at times its been so bad that either I or the caller have had to ring back again. Resorting to the mobile is lazyness on my part to save me the possibility of making 2 calls... and my daughter calls me on my mobile for same reason. Plusnet now also ring me on my mobile because they too have experienced a bad call on the landline and couldnt hear me.
>> to re-crimp each joint in the pair between the PCP and your home
This is something I have wondered about since the engineer definitely disturbed something just by testing from the cab. I dont know enough about BT testing to know though why simply him testing at the cab would have a permanent affect on my linestats.
-
This is something I have wondered about since the engineer definitely disturbed something just by testing from the cab. I dont know enough about BT testing to know though why simply him testing at the cab would have a permanent affect on my linestats.
:hmm: Hmm . . . Assuming the PCP, through which your pair is connected, is quite normal then there would have been a pair of crimps joining the D-side and E-side wires of your pair together. When a NGA GEA FTTC VDSL2 service is provisioned on the pair, those two crimps are removed, the D- & E-sides are separated from each other and are then crimped to the respective tie-cables that link the PCP to the FTTC. So two crimps are replaced with four crimps. ::) I presume that any invasive testing would probably result in the removal of the two crimps that connect your D-side pair to the D-side tie-cable pair (link to the FTTC). If the subsequent re-made joint(s) were somewhat defective . . . :-\
Perhaps Black Sheep could indicate what would be the most likely method used, when testing from the PCP, please?
-
Eurika!
I think today's engineer has found the problem. Engineer this morning understood and could see the large fluctuations in my upstream whilst the phone was in use... and said he was off to change the d-side. A few mins later he called me to 'come look at this' as he noticed that the d-side to the BT66 was fine. He showed me the tests on his JDSU and sure enough the line was rock steady even with the phone in use and phone ringing.
So he comes back inside, and plugs his JDSU again from the test socket... line starts fluctuating and upstream dipping, along with the max sync dropping. So its not the fttc i-plate. Removes the NTE completely and tests from the bare wire. Line is fine.
Repeats the test, puts the NTE back on, trys the test socket.. line plays up.
Gets a brand new socket, installs it... and line is perfectly fine.
Ive no idea where the NTE came from, but according to todays engineer its not a new one, as he can tell by the badging. It's possibly the same one thats been moved from the old NTE location. I think the engineer was a bit surprised as he said its not an obvious failure point and not something they normally look for. I repeat this is not the face plate, nor the i-plate that failed, but the back part of the NTE
For the first time in several weeks my SNRm doesn't budge when the phone is in use nor when the phone rings. I really really hope that this is what it was. :fingers:
-
Fingers crossed. 8)
Don't you just love it when someone actually applies logic and discovers the actual cause of a fault, especially when it's rather out of the ordinary. :graduate:
-
Here's hoping! :fingers:
-
Go on, admit it Kitz - you got Black_Sheep to come round personally. ;D
No, all due credit and admiration for the engineer who took the time and trouble to identify and :fingers: fix your fault.
:clap2: :thumbs: :clap:
You've got to send in some sort of commendation to his boss in BT. It's so different, sadly, from most of the visit reports we hear, that it is genuinely astonishing - in the very best sense of the word.
:dance:
-
Today's engineer said that its usually the downstream that indicates that there is a problem with the line. He even admitted that when he saw my upstream fluctuating all over the place he wasnt sure if it was a normal feature.. just because its something that they would never normally look at.
However, by using his JSDU to monitor what the upstream SNRm was doing that was what allowed him to pin point where the fault was actually coming from.
It was only after being told my observations about the upstream, that he decided that he was going to use this info to attempt to trace the fault and work backwards from the BT66. TBH Im glad he did.. because if this is what the problem has been all along then changing the d-side would have done nada.
-----
It only dawned on me once he'd gone that the [bad] NTE is either the one most likely installed when the house was built and the one that the Quinn guy moved, or it came from the Quinns guys collection of old kit. It definitely cant have been replaced when the 1st BToR engineer re-wired because its not new enough. If it is the original, then it will have been backing right on to where all the oxidisation was in the photo showed earlier in my thread.
-
>>> Go on, admit it Kitz - you got Black_Sheep to come round personally
haha... nope, but I do believe he was I believe an SFI guy, who is given a bit more time to look into things... and as such he took on-board what I was saying about the upstream SNRm. Usual BToR engineers would not look at SNRm.
Credit too has to be given to the authors of monitoring programs such as DSLstats and HG612_modem_stats, because those tools have been invaluable to point out what was going on with my line. Without them, I would just have a line that would drop for no reason and not know why. So a personal thank you to Eric for not only writing DSLstats, but also taking on board the suggestions Ive chucked at him whilst this fault has occurred.. I also must not forget Bald Eagles scripts because they and everyone else involved in graphing & hacking the HG612 have helped tremendously too.
Anyway as I write this, I glance sideways to the other monitor as see two totally flat lines graphing SNRm for the past 2 hours. Lets hope thats it now. :)
-
If it is the original, then it will have been backing right on to where all the oxidisation was in the photo showed earlier in my thread.
Sounds quite likely. Hope he took it away, takes it apart & shows it round the linesman's room then. But again, all credit to him for listening to the customer, and being determined to follow through on that, despite what they might 'normally' do. :thumbs:
-
>>> Hope he took it away,
He did indeed.
hahaha that would be fun if they tested it on a more normal line. IF that is what been causing a normally rock steady line with 18dB of margin to drop out.. christ knows what it would do to an average line. :-X
---
BTW Ive never recovered the 2dB of SNR since last weeks testing from the cab...
However in the grand scheme of things, I will accept that as 'one of those things'... Im not going to go bitching about it as long as I have my line stability back which is the main thing as is being able to use the phone and broadband at the same time :)
-
Well that is some good news! :dance:
My thoughts on the old NTE5/A. If it was one of the very earliest design with the gas discharge over-voltage / surge-clamping device fitted to it (just like the one in The Cattery), then it could be that the problem was a result of that simple device going faulty.
In a different thread, I posted (http://forum.kitz.co.uk/index.php/topic,12515.msg237129.html#msg237129) that they glow a nice violet colour when ignited by an application of 500V DC.
-
Thank you b*cat ... It had a white casing not green, so I dont think it was quite as old as that one. TBH I didnt look too closely at the terminals because the engineer opened it up and looked at the circuit board suggesting that it was likely something on the board.
If this was the original NTE (which I now suspect it likely was)... and remembering the state of the BT66 which it directly backed on to, then it wouldnt surprise me if the circuit board had been exposed to the same damp conditions which had totally corroded the terminals inside the BT66.
-
Kitz, is your line still totally stable?
As there are quite a few similarities between your fault and mine I wonder if the cause of my fault may be the same?
If I get time over the weekend I might try bypassing the NTE??
NE hose I'm glad your line issue seems sorted :)
-
If this was the original NTE (which I now suspect it likely was)... and remembering the state of the BT66 which it directly backed on to, then it wouldnt surprise me if the circuit board had been exposed to the same damp conditions which had totally corroded the terminals inside the BT66.
Ah, then that is highly likely. And in that case, I would be tempted to get a tube of silicone sealant and fill the hole, via the BT66, to stop any future moisture penetration affecting the extension socket that is now located on t'other side of wall.
-
>>> get a tube of silicone sealant and fill the hole
Good suggestion - thank you.
>>> Kitz, is your line still totally stable?
I know this may sound silly... but it 'feels right' this time. The voice line is crystal clear now. My SNRm doesnt budge when I use the phone, nor when the phone rings.
I have lost some upstream SNRm (it previously could reach >18 dB) which has knocked about 1.5Mbps off my upstream attainable rate which happened when the engineer tested at the cab last week, so perhaps he disturbed something there, but since that isn't affecting day to day running Im not going to bitch about it.
Im getting hardly any errors - no FECs and only a couple of CRCs & HECs.
My Bit loading now looks right.. HLog looks good, QLN is a nice shape.
I'll attach a screen grab of my SNRm for the past 24hrs.. how boring is this (fault was fixed at about 10.30)
I'll also run a HG612_modem_stats for the past 24hrs, because I want Bald Eagle to see what my Upstream SNRm now looks like... all of those weird crossovers have now totally gone.
-
>>> If I get time over the weekend I might try bypassing the NTE??
This may not be so easy. Of course I have to publicly state that by totally removing the NTE you are encroaching on BT's equipment on which we the general public are not allowed to touch as its the other side of the demarcation point.
However I dont mind stating what BToR did. Using the test socket in the NTE showed that the line still had a problem, but when he removed the NTE he grabbed hold of the bare black (dropwire) cable which came into my house. Using alligator clips he attached his JDSU to the dropwire and then watched what happened when he rang my number.
-
Thanks Kitz,
I don't really want to cross to the "dark side" of the demarc but I may have too ???
-
Okay... Im winding down my ticket now with Plusnet so I'll add a couple of comments here too for the sake of closure.
Ive been continuing to monitor with DSLstats & HG612 modem stats for the past 4 days and I can say things have been rather boring.
Voice line is crystal clear and no more SNRm fluctuations when the phone is in use/rings. No more disconnects.
SNRM completely flat lines... its not even budged by 1dB since the fault was found.
All that weird cross-over on the SNRm has gone and all 3 bands are equal.
Plusnet asked me to send some stats up. Because I can only add one attachment per ticket I did a before & after montage, which I'll add here. I think you'll notice quite a difference.
Id like to say thank you to everyone who added input into this thread, theres too many of you so forgive me for not naming each one individually but there are certain people whose posts have been extremely helpful. I cant believe that I was ready to throw the towel in and it only took one engineer to actually listen to what I was saying for the fault to be traced... I'm so glad that Plusnet automatically rejected and booked another appt for me.
---
Bald Eagle just look at my upstream SNRm now.. see how all 3 bands are at the same level. Unfort I was too much of an FTTC n00b to not realise that on my line... the SNRm bands should all be level. Its almost like the fault on the circuit board was causing noise in the lower frequency bands and the higher tones were making up for it. I wasnt able to monitor my power output for that band because it was too much of a negative figure and never graphed. However, looking at a now and then on pbParams, since the fault has been fixed, my tx power has gone down another -5dBm
-
:thumbs: :dance: :flower:
-
Plusnet asked me to send some stats up. Because I can only add one attachment per ticket I did a before & after montage, which I'll add here. I think you'll notice quite a difference.
Indeed that does look just a little better.
The shame is though, that more 'normal' users would simply have no idea how poorly their connections were performing against what they should be capable of.
Even with such undeniable evidence, my own experiences tell me that not all engineers would be at all interested in graphs provided by a 'geeky' user, especially if his/her 'standard' tests all came up with LTOK, as we unfortunaltely know they often will.
At least you are with an ISP that does understand & does take responsibility for pursuing matters on users' behalfs, albeit rather slowly at times.
-
I think the hardest part was being aware that I had that 18dB margin, and therefore the line only dropped when the phone was in use and things got really bad.
If you will recall though, this fault orginally developed when I was on adsl2+ with a margin of just 3dB. It had held rock steady for years, but all of a sudden I was losing sync several times per hour. On less of a margin on adsl2+ it would have been much easier to replicate the fault.
If you look back at some of my early graphs you can see that the line was dropping out many times per hour regardless or not if the phone was in use.
Unfortunately the fault reared its head just after I'd decided to move and asked for my MAC, so there wasnt any point me raising it with BE* I was half hoping it would vanish during a change of MSAN. If I'd been on a longer line with less of a margin it also would have had way more of an impact. This is why I was nearing throwing the towel in and wonder if I should just accept that most of the time it worked ok... until I used the phone.
Having had a perfect 24/2.6 for years to suddenly start seeing frequent disconnects I knew something was up.
>>> my own experiences tell me that not all engineers would be at all interested in graphs provided by a 'geeky' user
I totally agree they are not:( It was only the guy this w/e that took note... in fact he even said he was going to have a go with his own HG612.
>>> At least you are with an ISP that does understand & does take responsibility for pursuing matters on users' behalfs, albeit rather slowly at times
I guess I cant fault the service as such, but like you say the ticket answer time is often slow hence always a week between something happening... could be a hell of a lot worse though I guess.
-
>>> my own experiences tell me that not all engineers would be at all interested in graphs provided by a 'geeky' user
I totally agree they are not:( It was only the guy this w/e that took note... in fact he even said he was going to have a go with his own HG612.
Wey hey!!!
I hope you pointed him in the direction of where he could get hold of a stats harvesting/graphing program or two ;) :lol:
It might not be too long before we see engineers firing up DSLStats & HG612 Modem Stats on their laptops in preference to their JDSU's when troubleshooting poor connections.
-
I did indeed BE :) I think this guy was a bit on the ball 'cause he noticed himself the 2 LAN cables and asked why.
-
Eurika!
I think today's engineer has found the problem. Engineer this morning understood and could see the large fluctuations in my upstream whilst the phone was in use... and said he was off to change the d-side. A few mins later he called me to 'come look at this' as he noticed that the d-side to the BT66 was fine. He showed me the tests on his JDSU and sure enough the line was rock steady even with the phone in use and phone ringing.
So he comes back inside, and plugs his JDSU again from the test socket... line starts fluctuating and upstream dipping, along with the max sync dropping. So its not the fttc i-plate. Removes the NTE completely and tests from the bare wire. Line is fine.
Repeats the test, puts the NTE back on, trys the test socket.. line plays up.
Gets a brand new socket, installs it... and line is perfectly fine.
Ive no idea where the NTE came from, but according to todays engineer its not a new one, as he can tell by the badging. It's possibly the same one thats been moved from the old NTE location. I think the engineer was a bit surprised as he said its not an obvious failure point and not something they normally look for. I repeat this is not the face plate, nor the i-plate that failed, but the back part of the NTE
For the first time in several weeks my SNRm doesn't budge when the phone is in use nor when the phone rings. I really really hope that this is what it was. :fingers:
you know what I will say as I am a jealous mardy sod :)
you had a great adsl line, a fault appeared, fault early on with your vdsl.
but instead of the responses I typiclaly get "deal with it", you got a good engineer.
maybe my mistake was acting dumb (when my engineer came I hid away my unlocked hg as I was scared it would be taken away for unlocking the thing. My engineer and his boss made a comment that my 60mbit sync was extremely good, 80meg sync impossible and that the error count I had at the time was excellent (much worse than your error count). So yes my moan is about the inconsistencies of treatment different people get on faults.
My own personal line is still about 35mbit down on the attainable from install day. Clearly massively underperforming and my error rate is getting higher and higher which has me worried I will be interleaved soon. No point me getting an engineer I will be told its all normal.
Also my snrm drops about 4-5 db during calls. Engineer ignored that also.
My theory is engineers and their area managers will know the state of any given area, if an area has a batch of bad lines (meaning everyone asking for pair swap) they get told no cant be done, else they be pair swapping all day long all year. But if an area the lines are good and a fault stands out then they look into it and try to fix. Its the only rationale I can put on the different levels of treatment people get in different areas.
Glad you got yours fixed tho.
When I read your adsl post at start I did chuckle I admit as I put up with that kind of issue for years on adsl.
-
kitz I forgot to ask do you have an overhead or underground line outside your property?
-
UG cabling. Theres a photo somewhere in the thread showing the BT66 and how corroded the terminals were.
>> I hid away my unlocked hg as I was scared it would be taken away for unlocking the thing.
Plusnet know full well that some users unlock and they are very well aware of Bald Eagles Graphing scripts. In fact if they know you have an unlocked modem they will often ask you to upload BE's full monty graphs.
In my particular case it was PN that encouraged me to show the graphs to the engineer so he could see too.
The problem is that not all engineers will understand them.. and I did have one engineer who was entirely dismissive telling me that all the CRCs he saw racking up on his JDSU werent important and my line was fine cause I had no FECs (on an un-interleaved line d'oh). I did politely say that perhaps he may have that the wrong way round, but he insisted he was right and CRCs corrected themselves and he wasnt going to argue. On two of my appts the Test Head was down at the exchange anyhow and full tests couldnt be completed.
If you notice I was also having voice issues with some very noisy voice calls and had resorted to using to using my mobile more as I was getting tired of having to ring people back when they couldnt hear me on the landline. In fact Plusnet rang me and the guy I spoke to was witness to call where he couldnt hear me at all about 3 times due to noise bursts, so they were aware first hand that there was an intermittant voice fault too.
You will also note if you read through the thread, that I too was just about the throw the towel in. However as it turned out I didnt have to because PN straight off rejected BT's FNF and had already escalated it & arranged another appt (with an SFI engineer this time) without me saying anything.
This is one area PN's BOT team do seem to be pretty good at, and if they can see your graphs have something glaringly obvious, then they do appear to fight your corner as much as they can.
>>> When I read your adsl post at start I did chuckle I admit as I put up with that kind of issue for years on adsl.
An adsl line that had sync'd at full 24Mb and 2.6 up on annexM... and sat stable with an unwavering SNRm of 3bd for 6 years without issue totally flatlining.
Then practically overnight started losing sync about 20 times per hour. Downstream dropped to 16Mbps and at times it lost the ability to sync at Annex_M because of the upstream issues.
The only reason I didnt pass it over to BE is cause Id already requested my MAC... If I hadnt already started the FTTC process then I would have been screaming at BE to get it sorted. That is some fairly serious degradation in my books. :(
-
thanks, I have long suspected UG cabling has a huge impact on error rates (as well as snrm variation) so your answer is added to my database.
My line is UG but only up to the pole, my dropwire is from a pole exposed to radio signals etc.
Also I agree PN do seem good at dealing with these type of faults.
Also I do agree on your adsl experience I wouldnt be happy in the same boat, my chuckle was more in reference in that we were both used to different standards on our adsl lines as yours was of much higher standard.
-
DAMN AND BLAST
Its been hot and sunny here today.
Just noticed my Sync Speed
Down 79,999 Up 14441
:'( :'( :'( :'( :'(
Also my kim rang this afty and we got cut off 3 times & calls were noisy... she thought it was perhaps her mobile signal.. but now Im beginning to wonder :(
Calls were @ 3.15 - 3.45 pm (ish)
---
Edited to add..
Looks like I have 0dB SNRm in my 1st upstream band, 2nd upstream taken a hit too.
-
:o :( :thumbdown: :wall: :comp:
b*cat tries to emulate Maru (http://sisinmaru.blog17.fc2.com/) by hiding in a brown paper bag (for safety). :paperbag:
-
so its all gone crazy again?
that dsl stats app looks pretty at least.
-
The technical term to use in times like these is "arse".
:(
Still.. given that two faults have been discovered (and fixed) that were caused by corrosion... is there another location that could be similarly affected?
Ian
-
Still.. given that two faults have been discovered (and fixed) that were caused by corrosion... is there another location that could be similarly affected?
b*cat extracts himself from the paper bag and nods his head in agreement.
It seems as if a competent engineer will be required to open each joint enclosure between the DP & the PCP and re-crimp each joint in Kitz' D-side pair. Failing that, perform a pair-swap. :-\
-
Still.. given that two faults have been discovered (and fixed) that were caused by corrosion... is there another location that could be similarly affected?
b*cat extracts himself from the paper bag and nods his head in agreement.
It seems as if a competent engineer will be required to open each joint enclosure between the DP & the PCP and re-crimp each joint in Kitz' D-side pair. Failing that, perform a pair-swap. :-\
kitz is lucky that voice is affected and stability is impacted (loss of sync).
IF it was just loss of sync speed, then BT policy would likely be "tough luck".
Basically with BT if someone goes wrong is best to be a major fault then they more likely to fix.
-
Sorry to hear you are having problems again.
a competent engineer will be required to open each joint enclosure between the DP & the PCP
This what I was promised TWICE by BT to try and correct my issue but it never happened :rain:. Thankfully for me things have settled down.
-
This is no longer funny... and now kitz is about to go grrrrrrrrrrr
From my last post.. I could only get syncs at about 15Mb that week. Over the past week numerous times my voice has been faulty and people cant hear me because of the noise and static bursts. Several times people have had to ring me back.. or Ive had to use my mobile.
For example I needed to ring my webhosts the other night and couldnt get to speak to them because when I got through my phoneline was a PoS and we couldnt hear a damn thing.
So I have an engineers appt booked for this afternoon... and so far no show.. 10 minutes until I rant.
----
and interestingly I had a phone call from 08003289393 a very short while ago. The phone rang twice then the caller hung up when I answered. Ive looked that number up and it supposedly belongs to BT. I really hope they arent going to claim I wasnt in.. because Ive been in the front gardening all afternoon with the phone right by my side. :angry:
-
and interestingly I had a phone call from 08003289393 a very short while ago. The phone rang twice then the caller hung up when I answered. Ive looked that number up and it supposedly belongs to BT. I really hope they arent going to claim I wasnt in.. because Ive been in the front gardening all afternoon with the phone right by my side. :angry:
Have you tried calling that number? (I have done so and I don't think you will be happy to know what the recorded announcement says . . . )
b*cat hides in a brown paper bag, for safety. :paperbag:
-
I really hope they arent going to claim I wasnt in
That appears to be exactly what they're claiming. :wall:
-
OMG! No i hadnt rung it back.. but have done now.
I dont believe this... now Im going to ROAR!!!!!!!!!!!
BBL
-
Just say it must have been an earth-contact trip. ;) :-X
-
Well it would appear that there is some low-life who will try a trick to put a failed appt down to the EU's fault... and cause them to get billed for a failed appt.
I am livid. I have proof that I was in if needed, an actual timeline infact.. so they aint going to wriggle out of this one.
Unfortunately theres nothing much PN can do about this tonight now.. but I am expecting a call back tomorrow after theyve had time to take this further.
So atm.. I feel very justified to be more than a little annoyed... not just only at the no show appt.. but the deceitful way someone has tried to pass the buck to the EU.
-
Perhaps you should now 'take it on high' to the 'big cheese' (Ian Livingston), thus ensuring that the failing of Olive's ('Liv' Garfield's) sub-company is recorded at Beattie Group level? :-\
-
It wouldn't be an engineer, Kitz. We don't call from 0800 numbers.
And being all secretive like I am, I can tell you without going into any detail whatsoever, it definitely WASN'T an engineer to blame. You'll just have to take my word on that. ;) :)
-
Cheers BS... I shall try get some answers tomorrow then from PN... and see what this is all about.
-
yeah engineers ring from mobiles, I have had 3 contact me this past 12 months, all mobile numbers.
-
I see you have got an engineer with you. Fingers crossed. ;) ;D
-
I see you have got an engineer with you.
You work for the NSA and I claim my £10 ;) :lol:
-
Ha ha ...... kind of, but only when the Moon is in Sagitarius, and death walks these forums !!! Apart from that, here's your tenner, pal. ;) :)
-
Grrr just typed a long post then accidentally lost it by pressing backspace in the wrong window :(
-
so you retyping? ;)
-
I see you have got an engineer with you. Fingers crossed. ;) ;D
I did indeed, but adsl has been off for most of the day.
1) Yesterdays issue was a failure on BTs part to contact me when they should have... from what I can piece together via PN and todays engineer:-
Engineer allocated my fault was stuck on another job and knew he wouldnt be able to make my appt so he contacted where-ever so my job could be re-allocated back into the pool for someone else to pick up. Unfortunately no-one else was available to pick up my fault. At this point someone from BT is supposed to contact me to rebook the appt. Someone from BT tried to call but only let it ring twice and marked as 'EU unavailable'.
PN are to give feedback to BT about the system and that someone should have tried harder than 2 rings to contact me.
However it was allocated to todays pool where the same engineer that was scheduled from yesterday picked it up this morning.
---
2) Short version
Bit shocked to answer the door the morning to see a BToR.. anyhow he attempted to do some tests.. messed around with his JDSU several times.. muttered something about it failing on practically everything.. and says he's off to do some tests at the cab. Comes back and says hes going to replace everything. Goes away and comes back later this afternoon. New pair, new d-side and re-crimped every joint between my home and the cab.
----
Although he's given me the best available spare pair, in some respects its perhaps not quite as good for DSL as my old one... but tbh I am so sick and tired of this now that stability and a voice line that works has become my priority. Id rather have a line that is decent _all_ of the time rather than one that is all over the place.
Before:
Max attainable:103172 37187
Sync 79999 20000
SNRM 12dB 18dB
After:
Max attainable: 98148 31752
Sync 79999 20000
SNRM 11dB 12.5dB
The engineer noticed these differences.. and actually offered to try another pair - but it was getting late.. and hes given me his number so I can contact him if need be and ask for him to be re-allocated since he knows what hes done and what he hasnt.
However... I noticed this
Previous power was 14.3dBm / 6.8dBm New is 14.3dBm/4.7dBm
My line of thinking atm is that Power has gone down.. therefore that will affect the SNRm etc.
Based on adsl2+ theory.... Power is under control of the DSLAM/Router... and if it needs more juice then it should ask for it.
So for some reason the DSLAM has decided I dont need as much upstream power on the new pair which will account for the lower upstream figures... and as such I dont need to worry, because if in future I need it.. then it should give it. Thoughts?
-
oooh I think I forgot to add some where that during a 2 second burst period .. I experienced over 85,000 HECs and 35,000 CRCs
Is that a record?
-
kitz my thoughts are you do seem to be getting lucky with engineers, 2 out of 3 now doing work, it seems opposite to my own experiences and most other reports I read on the net where engineers refuse to do much, I wish I had an engineer who redid all joints, changed d-side etc. Any tips on getting engineer to be cooperarive? Although I did hav an engineer change my dropwire on last visit his boss made him undo the work.
Your upstream power going down I expect is the dslam managing crosstalk, its documented by various vdsl vendors that a way for isps to manage crosstalk is to reduce upstream power, and its logical to assume this is done on short vdsl lines as they have excess signal. This is quite possibly controlled by DLM.
Here is my output power, notice my downstream power is lower than yours.
Output power (dBmV) 13.4 6.7
Yesterday I lost sync, my upstream snrm went down to 0 (or close to it) for a short time, when the connection came back up I had a much higher upstream snrm tho, my up attainable has gone from 27meg to 34meg, and upstream crc errors are much lower than they used to be, so I think BT did some work somewhere on my loop. However this makes my up/down sync even more imbalanced, as a line with 34 attainable on the upstream should easily manage 80mbit and my down attainable dropped to 72 now.
I dont think you have broke any records with that error rate, but your normal error rate where you said you get 1 or 2 a day is possibly a record, thats extremely low for fast path.
Almsot forgot to say, the most important thing is if your line is stable now, if it is then the new lower attainable sync is still fine, just because thats gone down it doesnt mean it wont be more stable.
-
kitz my thoughts are you do seem to be getting lucky with engineers, 2 out of 3 now doing work,
You missed some.. Ive had about 6 or 7 visits now.. Ive totally lost track. Ive had my share of US visits.
Your upstream power going down I expect is the dslam managing crosstalk,
Yep powercut back, did actually have a discussion with the engineer about that.
Its not part of the DLM though aiui its more to do with negotiation between the router and DSLAM and PSD masking, the idea being that your signal strength doesnt go above 'x'. Power can be altered on the fly and can often be seen on adsl2+ being ramped up if the line starts to struggle. Its a proper (ITU?) standard that feature across all dsl DSLAMS/MSANs.
Set masks are defined based on line length with various profiles for standard and max power. With adsl2+ these PSD masks should be exactly the same regardless of SP MSAN/DSLAM. Its FTTC Im unsure about and know that there's possibly some additional parameters thrown in such as total line length & d-side length.
Any tips on getting engineer to be cooperarive?
Well I always offer coffee/tea/biccies... today didnt have any bacon in or would have offered a bacon butty. :-[
I try to be polite and despite the fact that there are some area's I know about I make sure I dont come across as condescending, even in the case when I knew one of the engineers was point blank wrong about something. If I say something I usually try to balance it with something like .. youre the expert with the wires and I wont pretend to know that side of things better than you. I dont bluff either and if Im not sure about something Im happy to say so, this usually triggers a better conversation because they usually then like to tell you about their PoV.
Bear in mind though that sometimes they cant do what is needed. This may be because the assigned engineers doesn't have the skills or it could be that the fault isnt considered serious enough to warrant it.
I guess in my case with voice now being badly affected they had to make more of an effort to track down the fault today.
dont think you have broke any records with that error rate,
Damn... oh well its a personal best for me then. :D
Never seen more than a couple of CRC per day on my line..mostly 0 for weeks. Before the line fault I may rack up an odd few during a close thunderstorm but thats it.
I cant recall ever having seen that many CRCs/HECs rack up so quickly in all the linestats that I can recall ever having seen. Some lines may accumulate them over time... but I thought it was rather a lot for a 2 second burst & so did the engineer who said it went waaaaaay over their fault threshold :/
-
I cant recall ever having seen that many CRCs/HECs rack up so quickly in all the linestats that I can recall ever having seen.
Need I say anything? :o ;D
-
Graphs aren't 'My thang', but isn't that showing FEC, as opposed to Kitz comment about CRC/HEC ?? ???
-
if its the old graph script then FEC=CRC due to the web gui bug.
Personally I have seen 200k CRC a second before.
-
Graphs aren't 'My thang', but isn't that showing FEC, as opposed to Kitz comment about CRC/HEC ?? ???
Yes it is, and yes, they were all recovered. The technology works. The numbers are astonishing though, although this only happens very rarely and decreasingly so lately. :o;D I'm not worried about it.
-
if its the old graph script then FEC=CRC due to the web gui bug.
No, it's not, so it isn't.
-
Jeeze 3.5 m - Thats one hell of a lot of FEC's.... !!! :'( What the heck was going on there Colin?
I only mentioned it because the engineer said it far exceeded the fault threshold for my line. After the burst they continued at about 100-200 per second whilst the line was open... then stopped when the phone was put back on the hook.
I was told what he'd consider the fault threshold for my line, and I was surprised that it was quite low. I'm deliberately not going to quote it though because it is based on line length and I dont want anyone googling this at a later date and thinking they have a fault without knowing all the other factors. Some of it may be down to the individual engineers interpretation based on whatever else they observe during their tests. It stands to reason that a short line with 18dB of SNRm is not expected to generate as many errors as a long line with say only 3dB of SNRm.
These CRC/HEC noise bursts also likely correlate with the problems on my voice line where callers would complain about hearing a very high pitched burst of static that shrieked down the phone line and hurt their ears.
Oddly I never heard that at my end despite several callers mentioning it. The line would be very noisy hissy crackly and just couldnt hear what the other person was saying and then either the voice and/or dsl would drop out.
Also bear in mind that my voice line had become increasingly unusable over the last 2 weeks.. and last weekend I wasnt even able to use it to speak with anyone. I could dial out... but we wouldnt be able to hear anything at all. This is also the same period when my upstream wouldnt sync at more than 15Mb.
I also found out yesterday that such a high level of HECs (for my line) is considered symptomatic of a physical line fault (as opposed to say REIN) as long as all other obvious causes have been eliminated... and of course its not simply that the line is running on too low a target SNRm
-
yeah, since you are used to almost no errors when you seeing 200 a second thats a big alarm, infact on any line 200 a second is a problem, you will see noticeable packetloss with that error rate. A better indicator I feel is looking at SES stats. Generally if you only seeing ES's then the erorr rate is probably not high enough to be a problem, if you seeing SES's then usually performance is also affected.
I expect the error rate threshold is determined by line length and quality, this I already believed to be the case anyway, like I mentioned in another post, the way customers get treated seems dependent on the area, if an area with good short lines then a line with errors and low sync will stand out like a sore theumb and get treated as a fault, but if an area half the lines are syncing low and high error rates are the norm then it will be treated as normal service. I am of course interested in your threshold :p curious if my current error rate is above that threshold. My error rate on vdsl was about 300 crc a day (when I had 90 attainable with spare snrm), about 600 a day after dropped to 73 with 6.5db snrm, and since then its been anything between about 600 a day and 1200 a day. Since 2 days ago tho when my line resynced itself the error rate has gone down again to about 600 a day and the upstream error rate plummeted that was previously about 200-300 a day and now about 60 a day. Thats 60 a day on a 14db margin as my upstream attainable is now over 30mbit. This error rate doesnt give me any visible packetloss.
Also regarding voice quality, whenever I have had a BT line, its been bad, now if I use it there is a background hiss and audio is quiet both ends. This I have always just considered normal as my BT lines have always been like this, when I had a VM line the quality was very different, my mobile phone is much clearer and louder than my BT landline. But again I think is down to what is acceptable in any given area.
The big question is, is your fault cleared up now?
-
A better indicator I feel is looking at SES stats.
Agree that ErrSec & SES give a better indication than total count, because when looking at line stats you dont often know if its burst or continous.
When recording with DSLstats/HG612Modem_stats I would see ESecs and SES during the 'burst periods' when the phone was in use.
Now I may be wrong (BS could perhaps confirm) but I dont recall seeing ErrSec & SES displayed on the JDSU. Its a small screen and from what I can recall by looking over his shoulder it only showed CRC/HEC/FEC on the page that the engineer was watching when doing his tests. It may have been on another page or further down the screen?
error rate threshold is determined by line length and quality, this I already believed to be the case anyway
It makes total sense for it to be this way.
My error rate on vdsl was about 300 crc a day (when I had 90 attainable with spare snrm)
In this respect the engineer is limited in that they can only monitor for a 5-15 min period. Tough luck if its intermittent :( The past 2 engineers have been good and know their stuff and have also both been interested in stat monitoring progs. Luck of the draw with engineers and how much they now.
Ezzer gives a general guide here (http://forum.kitz.co.uk/index.php/topic,1465.msg49938.html#msg49938)
whenever I have had a BT line, its been bad, now if I use it there is a background hiss and audio is quiet both ends.
Mine used to be good, then it started getting a cyclic hiss.. obviously this then progressed to noise being worse than the voice level.
Now its a very slight background hiss on QLT, but call quality is clear. I have only tested with cordless though since the fault. Id need to plug my old corded phone back in to give a better indication.
The big question is, is your fault cleared up now?
Its been up for nearly 2 days and SNRm hasnt budged. Can use phone without any problems and nothing happening to the SNRm. Looks like Ive had a few FECs on the upstream and a some CRC/HEC on the downstream but Im not too bothered as all seems well as far as Im concerned.
Im ignoring my upstream RS graph which is periodically blipping with 4.5e+006 spikes.
Also need to do a full modem power recycle as I could do with monitoring from fresh and clear out any totals, because theres a hell of a lot of ES & SES which were likely picked up the day before the fault was cleared.
---
Edited to correct stupid typ0
-
Well a JDSU wouldnt need ES and SES as when its used its been looked at live.
Whilst a modem tallies the errors over a long period of time, its unlikely someone is sitting watching it 24/7 so the eS and SES give an idea exactly as you said if the errors are spread out or not. so 300 CRC errors with 60 ES and 0 SES would suggest an average of 5 errors per occurance and none of them been serious.
-
Wrong again. Here's a 'Screen snapshot' of my very own JDSU.
-
Now I may be wrong (BS could perhaps confirm) but I dont recall seeing ErrSec & SES displayed on the JDSU. Its a small screen and from what I can recall by looking over his shoulder it only showed CRC/HEC/FEC on the page that the engineer was watching when doing his tests. It may have been on another page or further down the screen?
Thank you BS for the screenie & putting us right :)
-
:)
-
Wrong again. Here's a 'Screen snapshot' of my very own JDSU.
Purrfect. That saves me having to scrabble around in my 'what not' whilst looking for the appropriate image! ;D
-
Closing this off now, as my ticket from PN has just auto-closed too.
3 weeks its been like this.
Stats arent as good on this line as they used to be on the other pair, when it wasnt being stupid.
But at least Im stable and able to use the phone again. :)
-
That is essentially a purrfect SNRM graph. :)
-
yeah its very good, it does seem kitz is in a pretty good area for dsl. But I can understand why she is annoyed losing what was previously better stats as we all want perfection. But at least its now stable and with still a decent snrm.