Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: JoshShep on April 12, 2012, 06:36:40 PM
-
Hi everyone,
To cut the long story short, since moving to Fibre in December last year I have been having issues with my broadband.
After numerous Engineer visits, and lots of work been carried out to try and solve my issues nothing has worked.
I was estimated 35 Mbps, and I'm about 560M from the cabinet with an attainable rate of 45 Mbps.
After getting my profile reset, it only takes a couple of days for my sync rate to drop to 28 Mbps and it normally stops there.
There are always errors on the line and I get regular disconnections throughout the day. More often on a night from 7pm onwards.
Today I had another friendly Engineer visit and was told because everything possible has already been done, the last resort must be REIN interference.
He drove around the street whilst on the phone to a REIN Engineer with his radio tuned into the 612KHz frequency, and discovered 4 doors down there is interference. They both agreed that there is a problem and a REIN Engineer is booked to visit in the next few days.
I would just like to say thank you to BT Openreach for all the help so far, they've been great and tried there very best to fix the issues I have been experiencing.
Cheers,
Josh
-
Interesting Josh.
Can anyone describe what REIN sounds like, or even better, post a link to where we could hear an audio clip?
Also, on discovery of REIN, what powers (if any) do BT have in getting the person(s) responsible for it to fix it?
REIN has been more or less ruled out regarding my own connection issues, but having just driven the recently confirmed route with the car radio tuned to 612 KHz AM frequency, I do hear the background sound change to a fairly loud humming/buzzing sound in a couple of spots.
It will be really interesting to hear how this pans out for you Josh.
-
Hi Paul,
"If you get a distinct noise enveloping a larger area, then this may be picked up by your router causing an SNR problem (or even drop of sync). By using the radio you may be able to get an idea of where the noise is coming from. Switch the suspect appliance off & retest your DSL connection. By distinct noise you're looking for a clear buzz, whistle, clicking etc. White noise or a general shhhhh noise is less likely to be the cause of the problem, same as any radio broadcast"
And to answer your question on what powers BT have, I don't have a clue, I believe if it's coming from someone's home and is faulty equipment all they can do is ask the person to replace/fix it. I just hope if this is the case they also have broadband and welcome them with open arms because more that likely there also having issues. :)
I'll keep you updated mate.
-
As you know BE, I've already posted up info regarding REIN and the legalities surrounding it. To get a first hand idea of what it sounds like, tune your radio into 612Khz on the MW scale and drive under a high-voltage electrical distribution cable, the ones that are attached to the large pylons.
It is akin to your description below, but it's more of a buzzing noise than a hum. Bear in mind REIN is everywhere, just drive around like a saddo (me) with your radio on the frequency mentioned, and you'll hear it regularly and sporadically. It depends on the level of 'noise' as to whether it's service-affecting.
What Josh describes above is perfect for fault-inducing REIN. IE- The circuit will reset to it's 'max' but DLM will drop it down due to high-error counts caused by REIN. This is assuming that the D-side cable has been PQT tested and has an AC Balance of >-50dB. I personally think it should be above -60dB or even -65dB, but the REIN team will take the case on -50dB or above.
With minimal REIN interference on ADSL, we can fit an RF3 filter which when coupled with the SSFP will halt the REIN in its tracks. Now, I'm not sure if this same product will work on VDSL and its higher frequency band-plans ???
HTH a little, :)
-
Hi Paul,
"If you get a distinct noise enveloping a larger area, then this may be picked up by your router causing an SNR problem (or even drop of sync). By using the radio you may be able to get an idea of where the noise is coming from. Switch the suspect appliance off & retest your DSL connection. By distinct noise you're looking for a clear buzz, whistle, clicking etc. White noise or a general shhhhh noise is less likely to be the cause of the problem, same as any radio broadcast"
And to answer your question on what powers BT have, I don't have a clue, I believe if it's coming from someone's home and is faulty equipment all they can do is ask the person to replace/fix it. I just hope if this is the case they also have broadband and welcome them with open arms because more that likely there also having issues. :)
I'll keep you updated mate.
In a nutshell and also in laymans terms, The 'Radio & Telegraphy Act' only applies if someone is 'knowingly' broadcasting. If a neighbours set-top box has gone faulty, for example, then he isn't 'knowingly' transmitting. Without going too deep, a certain broadcaster will allow us to contact them with the S/N's of the faulty equipment and then despatch another to the 'offenders' house if we localise the REIN to that piece of equipment. Otherwise, we localise the source, inform the ISP, and it then becomes their baby.
As mooted many times before, REIN is a gratis service that Openreach offer, and timescales are pretty tight because of this. Don't despair too much though as my guess would be 80% can be sourced by a limited REIN engineer, anything of substance goes to our 'Precision Test Officers' who utilise PSD meters, osc'ies, directional finders and anything else that costs over £50 to purchase. :)
-
I find that my ICOM IC-R5 rather useful in that respect as it:
(1) can be tuned to 306 kHz
(2) be tuned to 612 kHz
(3) cost more that £50 to purchase (second-hand)
:P
-
Then you can entitle yourself a 'PTO', B*Cat. Good luck with Josh's REIN issue bud. :P ;) ;D
-
I find that my ICOM IC-R5 rather useful in that respect as it:
(1) can be tuned to 306 kHz
(2) be tuned to 612 kHz
(3) cost more that £50 to purchase (second-hand)
:P
I'll book you in for an appointment on Sat if you want mate? :lol:
-
Then you can entitle yourself a 'PTO', B*Cat. Good luck with Josh's REIN issue bud. :P ;) ;D
Thanks! As long as Bald_Eagle1 "picks me up" -- careful with those talons -- and "drops me off" -- onto the back of a nice woolly Black Sheep -- I'll be willing to assist with resolving Josh's troubles. :silly:
-
I'll book you in for an appointment on Sat if you want mate? :lol:
Certainly, providing others co-operate! See my post, above. (Suffolk to Yorkshire would be hard on the pads, otherwise.)
-
I'll book you in for an appointment on Sat if you want mate? :lol:
Certainly, providing others co-operate! See my post, above. (Suffolk to Yorkshire would be hard on the pads, otherwise.)
Cats in cages (and not occupying a seat) can travel free on National Rail.
Change at Ely and/or Peterborough for an East Coast Main Line service.
cheers, a
-
I'm curious folks, of all the frequencies used by DSL, why does 612kHz seem to be a kind of reference frequency for REIN?
I'm not questioning that wisdom, I just want to know if I'm missing something. :hmm:
-
It's not a 'specific' channel as such 7LM. It's just that there's nothing else around that particular frequency that could 'interfere'. There's a similar frequency that can be used on the LW scale as told to me by one of our PTO experts, but I can't for the life in me remember what it was ??!! :)
-
Its not 612kHz thats the reference point but nearer 300 khz that actually IS the "reference" point. Its just that a typical radio dosn't go that far down, you can use the next harmonic which is at 600 or 150khz.
Any major REIN at that frequency will make a marked affect on dsl service. To a lesser degree further up the frequency range will do as well. Unless its at a harmonic (by harmonic I mean nice round intergers like double or half trebble/third,quad'/quarter. The effect depreciates a degree each harmonic further away from the key frequency your concerned with.
Its the same principle with musical notes, octives, keys etc.
Havnt been on this site in ages and the 1st thing I click on is REIN, typical. If you want nasty broadband try the U.S.A. I feel as if I'm getting the service as if I'm on the end of an 11km long line I often worked on in norfolk.
-
Welcome back Ezzer !
I hear of other parts where they've done amazing things. Somewhere I have a picture of an old "dobbin" pulling overhead fibre over fields and forests and doing much less damage than an infernal combustion engine - and doing the job faster as well.
There are a few chinks of light over here too, but it ain't happening by tea time !
Kindest regards,
Walter
PS
http://b4rn.org.uk/north-lancashire-residents-make-broadband-history
(@ B S = RP for Ezzer) Perhaps this and your managerial broadcast are not unrelated ?
One is actually achieving something, the other sounds like - lies, damned lies & statistics. IMHO the behemoth will NEVER get to the places I walked for the first time in a howling wind. I thought I'd found evidence of elephants up on the fells above Caton near the windmills !! Later discovered it was only bison - but VERY impressive @ 5 Ins Diameter !
V sorry for the digression !
PPS - Have a look at my news report yesterday.
-
Thanks for the replies to my 612kHz question, I need time to digest.
But meanwhile... good to hear from Ezzer again :)
-
Its not 612kHz thats the reference point but nearer 300 khz that actually IS the "reference" point. Its just that a typical radio dosn't go that far down, you can use the next harmonic which is at 600 or 150khz.
Any major REIN at that frequency will make a marked affect on dsl service. To a lesser degree further up the frequency range will do as well. Unless its at a harmonic (by harmonic I mean nice round intergers like double or half trebble/third,quad'/quarter. The effect depreciates a degree each harmonic further away from the key frequency your concerned with.
Its the same principle with musical notes, octives, keys etc.
Havnt been on this site in ages and the 1st thing I click on is REIN, typical. If you want nasty broadband try the U.S.A. I feel as if I'm getting the service as if I'm on the end of an 11km long line I often worked on in norfolk.
Ha ha ..... yeah, right !! I bet you've been looking in on this site for months just waiting for a REIN query to drop in ??!! ;) :lol:
To mirror Walters sentiments, welcome back Ezzer, sir. Good to have you on board again. Walter's alluded as to my previous alias, time enough has gone by for it to be known that I was once the evil tyrant 'razpag'. ;D
How's the great US of A treating you mate ??
-
Hence Black Sheep ;)
Well, I've got Married. :love: We had our own little ceremony with my parents looking on via skype. Even when I'm getting wed I cant get away from the net. Although we will still have a wedding proper in August as this one was more of a registry type wedding. In fact you can just go into the car registration office, get the paper, pop out sign it, get some witness to sign, nip back in and thats it. So we wil have a ceremony under our terms up in the mountains. Parents there in real life this time though. Just hoping they dont get altitude sickness. The rest of the family here suffers from it but I seem to thrive
Enjoying lovely warm weather. Temperatures up in the 90's in old money most days. It rained a couple of nights ago so the grass has done its annual trick of going from a straw colour to green as if a switch was flicked in the night. Although we're due for more snow on the weekend. Ever watched South Park ? well I was by there 2 weeks ago but I'm by north park. And thats sort of what it's like
Well I've only just got my Authority to work. The immigration proccess is long and expensive. half a mo' I think this reply belongs in chat,,,,
-
Ha ha ...... yes Ezzer, hence BS. ;) ;D
Will follow you over on 'Chat'.
-
Thanks to Bald_Eagle1 I now have some stats to look at, only thing is I don't really understand them, take a look and see what you think please?
-
A few more.
-
Thanks to Bald_Eagle1 I now have some stats to look at, only thing is I don't really understand them, take a look and see what you think please?
Baldie is the man for a proper answer, but my 2p's worth.. you have a fair bit of noise between DMTs #250 - #650.
It's tempting to blame cross-talk from adjacent pairs carrying ADSL2+ in your distribution cable bundle. However, ADSL2+ crosstalk should stop at DTM#512 (2.2MHz), the highest subcarrier used by ADSL2+. Yet the noise continues to DMT #650. That suggests the noise is crosstalk from other VDSL2 pairs, perhaps aggravating existing ADSL2+ crosstalk.
That noise is causing a notch in the SNR in that downstream (DS1) band (DMT#32-DMT#859) and this is impacting bit loading. For some reason, even when the noise subsides around DMT#650, the remaining subcarriers in the band remain unused. Presumably a consequence of Lantiq's implementation of Dynamic Line Management? Hence the 30000Kbps cap on your throughput. The combination of that noise and the DLM means you are losing around 8Mbps potential bandwidth.
cheers, a
-
Crosstalk, sounds like it could be possible. Would that explain why I sometimes get upload speeds as low as 0.8Mbps? There the same results I got on ADSL2.
What would you recommend me to do?
-
One thing has just dawned on me.
The scripts were written specifically for the Huawei HG612, connected to a Huawei DSLAM (well before I had even heard of the ECI modem & the slightly different plans used from an ECI DSLAM).
All the relevant data for the graphs as collected from the HG612 is formatted into just 2 columns.
i.e. Tone No. in column 1 & data in column 2.
To separate DS & US data, the scripts use the tone band plans as discovered from a Huawei DSLAM:-
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3939)
However, an ECI DSLAM uses, & the HG612 discovers these tone band plans:-
Discovery Phase (Initial) Band Plan
US: (0,95) (880,1195) (1984,2771)
DS: (32,859) (1216,1959) (2792,4083)
The differences between the ECI & Huawei band plans may not be huge, but they MAY be causing some slight graphing discrepanicies/inaccuracies when a HG612 is connected to an ECI DLSAM.
I don't really have time to adjust the scripts at the moment, but I am aware that BlackEagle is working with them to possibly create .exe rather than .bat files.
FYI, BlackEagle was also originally provided with an ECI modem for his connection, so may well have already spotted & be dealing with the slightly differing band plans.
-
Crosstalk, sounds like it could be possible. Would that explain why I sometimes get upload speeds as low as 0.8Mbps? They're the same results I got on ADSL2.
It would make sense that noise from crosstalk is also affecting the upstream (US) bands, especially the higher frequency US1 band. Unfortunately, we cannot gauge the extent of that noise in the US1 band. The modem cannot calculate noise levels in upstream bands - they have to be measured at the DSLAM and we don't have access to that data.
What would you recommend me to do?
Not a lot you can do. Crosstalk is perhaps the greatest limitation of xDSL.
In terms of VDSL2 it's relatively early days.
Openreach/ECI/Lantiq will be remotely monitoring statistics at the VTU-R. Hence the usefulness of TR-069 remote management. Crosstalk measurements taken in the field will be collated and overlaid onto theoretical models. These will be used in the refinement of the DLM algorithms. And as the bigger picture unfolds, those updated algorithms will be distributed as remote firmware upgrades to the DSLAMs.
If that were my line, I would be wondering why a sizeable chunk of utilisable tones in DS1 band are not being used (DMT#650 to DMT#859)..
It may be that Openreach/ECI/Lantiq are trying their best to juggle finite resources - attempting to fairly distribute the aggregate 'Shannon Capacity' of all the pairs in a bundle, while mitigating inter-pair crosstalk. To this end, Openreach/ECI/Lantiq will be able to see an overview of the line data for all xDSL pairs served by a DSLAM, all the xDSL pairs in a distribution bundle, etc..
No answers really. Although in the great scheme of things, 30,000kbps is still pretty useable.
cheers, a
-
The scripts were written specifically for the Huawei HG612, connected to a Huawei DSLAM (well before I had even heard of the ECI modem & the slightly different plans used from an ECI DSLAM).
All the relevant data for the graphs as collected from the HG612 is formatted into just 2 columns.
i.e. Tone No. in column 1 & data in column 2.
To separate DS & US data, the scripts use the tone band plans as discovered from a Huawei DSLAM:-
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3939)
However, an ECI DSLAM uses, & the HG612 discovers these tone band plans:-
Discovery Phase (Initial) Band Plan
US: (0,95) (880,1195) (1984,2771)
DS: (32,859) (1216,1959) (2792,4083)
The differences between the ECI & Huawei band plans may not be huge, but they MAY be causing some slight graphing discrepanicies/inaccuracies when a HG612 is connected to an ECI DLSAM.
I don't really have time to adjust the scripts at the moment, but I am aware that BlackEagle is working with them to possibly create .exe rather than .bat files.
FYI, BlackEagle was also originally provided with an ECI modem for his connection, so may well have already spotted & be dealing with the slightly differing band plans.
CORRECTION:-
When I first wrote the scripts, I did indeed use specific Huawei band plan tone numbers.
I must have realised that these would be incorrect when connected to an ECI cabinet around the time we were first made aware of the ECI modem/cabinet combination.
It may even have been JoshShep that made us aware of the ECI combination via the TBB forum?
The scripts actually do now use the band plans as discovered at Discovery Phase, so the data collected via a HG612 modem, even when connected to an ECI cabinet should split up & plot the data correctly after all.
Aplologies for the previous misinformation folks.
I'm not getting any younger & my memory must be playing tricks on me :-[
-
Aplologies for the previous misinformation folks.
I'm not getting any younger & my memory must be playing tricks on me :-[
:doh: D'oh!
-
These errors anything to worry about? I noticed allot of them clock up sometime during the night or early morning.
-
.
-
The errors are just clocking up.
-
The errors are just clocking up.
I often see many more errors than that over a similar time period.
What is unusual is that you seem to be achieving more from the 2nd band plan than the first band plan.
Asbokid has already suggested possible reasons.
Ongoing graphs of your connection over an extended period via the START_LOGGING_24-7.BAT script may be able to identify definite patterns regarding times and/or types of issues such as SNRM drops that might be able to be linked to events like REIN from a nearby neighbour's house etc.
The unusual spike in your Hlog graph may not have much (if any) impact as it occurs at the higher frequency band plan that isn't available for your connection when it re-syncs, unless it is that that actually stops you achieving anything.
I doubt it though as a spike in the Hlog graph actually means lower attenuation at those tones/frequencies.
-
Just though I might as well give this a try and may have come onto something.
Plugged a filter directly into the test socket, with only the modem connected SNRM is currently 5.8dB
As soon as I plug the phone in it drops to 5.6dB and then when I pick the phone up it drops as low as 5dB
Could also the faulty VDSL filter.
Any ideas guys? Also 0 errors are showing.
Edit: It's a wireless iDECT phone.
-
Hi JoshShep,
I suggest it would be worth trying the phone line with a standard corded phone after switching off the power to all the DECT phones.
Kind regards,
Walter
-
Latest results, http://www.speedtest.net/result/1900935182.png
-
Latest results, http://www.speedtest.net/result/1900935182.png
WHAT #/?$%*&^£"!!!!!!?
-
@Josh,
Who is your ISP, please? And what do they say regarding your ridiculous throughput speed?
-
@Josh,
Who is your ISP, please? And what do they say regarding your ridiculous throughput speed?
It's TalkTalk mate, this is the update I got from them,
"Sooo, engineer did raise a REIN case which has been scheduled for engineer investigation tomorrow (pending any other more important jobs…).
It’s due a review on Wednesday so I’ll ring again Thursday to see what they think.
Obviously making the situation better will depend on OR finding and being allowed/able to fix the issue, but I’ll update on Wednesday when I’ve spoken to them".
Something is being done (I hope) I believe it has to be some sort of interference, It's just not acceptable. That or some major crosstalk. I should have an update before Friday.
-
Latest results, http://www.speedtest.net/result/1900935182.png
WHAT #/?$%*&^£"!!!!!!?
:( I know Paul, its not acceptable!
-
Something is being done (I hope) I believe it has to be some sort of interference, It's just not acceptable. That or some major crosstalk. I should have an update before Friday.
Best of luck. :fingers:
Please keep us updated.
-
Something is being done (I hope) I believe it has to be some sort of interference, It's just not acceptable. That or some major crosstalk. I should have an update before Friday.
Do you still have the Huawei HG612? What do its statistics indicate?
Crosstalk is usually identifiable from a graphical plot of the Quiet Line Noise (QLN) line data.
The overall quality of your pair is captured by the Hlog graph (attenuation).
cheers, a
-
Something is being done (I hope) I believe it has to be some sort of interference, It's just not acceptable. That or some major crosstalk. I should have an update before Friday.
Do you still have the Huawei HG612? What do its statistics indicate?
Crosstalk is usually identifiable from a graphical plot of the Quiet Line Noise (QLN) line data.
The overall quality of your pair is captured by the Hlog graph (attenuation).
cheers, a
Yeah I do a, Just got a few new ones.
-
.
-
If you take a look too, my SNRM has been sitting around 4.9, and it goes as low as 4 later on in the evening.
-
Sounds like there taking the pee, getting really frustrated to be honest, this is the reply I got.
"Just spoken to them and the engineer didn’t go out yesterday so the next update is going to be tomorrow Josh.
It’s a frustrating process because it’s best endeavour, OR have no requirement to find/fix REIN for us because it’s not them causing the problem!
I’ll chase again tomorrow and keep you updated".
I understand it isn't OP that are causing the issue but anyone can see when I have an attainable rate of around 37Mbps, and I'm receiving a capped rate of 30 due to errors on the line it isn't acceptable!
Is there anyone I could contact to try and get these issues sorted?
Would Ofcom be a possibility?
And any ideas why my SNRM is so low?
Thanks
-
Sounds like there taking the pee, getting really frustrated to be honest, this is the reply I got.
"Just spoken to them and the engineer didn’t go out yesterday so the next update is going to be tomorrow Josh.
It’s a frustrating process because it’s best endeavour, OR have no requirement to find/fix REIN for us because it’s not them causing the problem!
I’ll chase again tomorrow and keep you updated".
I understand it isn't OP that are causing the issue but anyone can see when I have an attainable rate of around 37Mbps, and I'm receiving a capped rate of 30 due to errors on the line it isn't acceptable!
Is there anyone I could contact to try and get these issues sorted?
Would Ofcom be a possibility?
And any ideas why my SNRM is so low?
Thanks
Do you know your loop length? The graphs indicate high attenuation. The crosstalk from adjacent ADSL2 pairs only compounds the background noise (the trough shaped like a dental cavity).
That said, tones #512 - #859 have reasonable S/N ratios, and could be utilised in theory. Yet we can see from the Bit Loading graphs that those tones are not used. That lack of tone utilisation is due to the DLM algorithm running on the DSLAM control board. At a guess it is tweaked to give you and your neighbours a fair bite of the cherry each.
Sorry, no answers.
cheers, a
-
Sounds like there taking the pee, getting really frustrated to be honest, this is the reply I got.
"Just spoken to them and the engineer didn’t go out yesterday so the next update is going to be tomorrow Josh.
It’s a frustrating process because it’s best endeavour, OR have no requirement to find/fix REIN for us because it’s not them causing the problem!
I’ll chase again tomorrow and keep you updated".
I understand it isn't OP that are causing the issue but anyone can see when I have an attainable rate of around 37Mbps, and I'm receiving a capped rate of 30 due to errors on the line it isn't acceptable!
Is there anyone I could contact to try and get these issues sorted?
Would Ofcom be a possibility?
And any ideas why my SNRM is so low?
Thanks
Josh, OR do not guarantee speeds. Well, they do, but it's 28Kbps. You could try Ofcom, but if it is indeed a REIN driven fault, you may as well forget it. What you have to understand is (if I read the situation correctly), that OR's wires test perfect. This means they have met a certain criteria laid out that all ISP's have agreed to.
Now, if 'Johnny Ham' your local amateur radio enthusiast, decides he is going to transmit and causes your line to error severley, which in turn has the DLM alter your parameters, it is not OR's fault. Same if it's a faulty set-top box, or a faulty street light etc etc.
From personal experience, I can tell you that OR do visit this type of fault scenario, but it may take umpteen visits to localise the offending item. Due to the ever-increasing higher frequencies being pumped down our D-side cables, REIN is more prevalent than it ever was. However, to go full circle here, if your line passes the testing criteria and it is suspected REIN, we will only attend when it is business-viable. If the 'workstacks' are high, we are obliged to attend to these first as the SP's are paying us to do so. Nobody is paying us to look after your REIN case.
So, patience is a virtue I'm afraid.
-
Sounds like there taking the pee, getting really frustrated to be honest, this is the reply I got.
"Just spoken to them and the engineer didn’t go out yesterday so the next update is going to be tomorrow Josh.
It’s a frustrating process because it’s best endeavour, OR have no requirement to find/fix REIN for us because it’s not them causing the problem!
I’ll chase again tomorrow and keep you updated".
I understand it isn't OP that are causing the issue but anyone can see when I have an attainable rate of around 37Mbps, and I'm receiving a capped rate of 30 due to errors on the line it isn't acceptable!
Is there anyone I could contact to try and get these issues sorted?
Would Ofcom be a possibility?
And any ideas why my SNRM is so low?
Thanks
Josh, OR do not guarantee speeds. Well, they do, but it's 28Kbps. You could try Ofcom, but if it is indeed a REIN driven fault, you may as well forget it. What you have to understand is (if I read the situation correctly), that OR's wires test perfect. This means they have met a certain criteria laid out that all ISP's have agreed to.
Now, if 'Johnny Ham' your local amateur radio enthusiast, decides he is going to transmit and causes your line to error severley, which in turn has the DLM alter your parameters, it is not OR's fault. Same if it's a faulty set-top box, or a faulty street light etc etc.
From personal experience, I can tell you that OR do visit this type of fault scenario, but it may take umpteen visits to localise the offending item. Due to the ever-increasing higher frequencies being pumped down our D-side cables, REIN is more prevalent than it ever was. However, to go full circle here, if your line passes the testing criteria and it is suspected REIN, we will only attend when it is business-viable. If the 'workstacks' are high, we are obliged to attend to these first as the SP's are paying us to do so. Nobody is paying us to look after your REIN case.
So, patience is a virtue I'm afraid.
Thanks for clearing that up BS, I understand it can take time, but when I was told an Engineer would be in touch in the next couple of days he/she never called. I was told the issue would be solved and they have pinpointed where it's coming from.
Now on to my SNR Margin, why is it so low? It drops as low as 4 between now and 12pm. Is that acceptable?
-
Sounds like there taking the pee, getting really frustrated to be honest, this is the reply I got.
"Just spoken to them and the engineer didn’t go out yesterday so the next update is going to be tomorrow Josh.
It’s a frustrating process because it’s best endeavour, OR have no requirement to find/fix REIN for us because it’s not them causing the problem!
I’ll chase again tomorrow and keep you updated".
I understand it isn't OP that are causing the issue but anyone can see when I have an attainable rate of around 37Mbps, and I'm receiving a capped rate of 30 due to errors on the line it isn't acceptable!
Is there anyone I could contact to try and get these issues sorted?
Would Ofcom be a possibility?
And any ideas why my SNRM is so low?
Thanks
Do you know your loop length? The graphs indicate high attenuation. The crosstalk from adjacent ADSL2 pairs only compounds the background noise (the trough shaped like a dental cavity).
That said, tones #512 - #859 have reasonable S/N ratios, and could be utilised in theory. Yet we can see from the Bit Loading graphs that those tones are not used. That lack of tone utilisation is due to the DLM algorithm running on the DSLAM control board. At a guess it is tweaked to give you and your neighbours a fair bite of the cherry each.
Sorry, no answers.
cheers, a
Hi a, I'm 560m from the cab,
Looking through some old posts on the TalkTalk forums these were the results I had on ADSL2+
Connection Speed 10063 kbps 1019 kbps
Line Attenuation 36.5 db 17.9 db
Noise Margin 6.3 db 9.2 db
-
Once a REIN case is built, The REIN helpdesk 'diary' when to ring the owning engineer for an update. It's generally once a week if it's an ongoing issue. The Helpdesk are obviously aware of our policies regarding attending these cases only when workstacks dictate. To say an engineer will be in touch is wrong in my opinion, as our workloads differ from day-to-day, sometimes within an hour if we have severe electrical storms, high winds etc.
So they can not guarantee an engineer will call.
On the back of that, you say the problem has been pin-pointed ?? If that is the case, then you will not (or shouldn't) get to know where it was found, or indeed what it was found to be, that was the cause. For arguements sake, it could be a neighbours set-top box causing the problem. The neighbour hasn't got Broadband themselves and don't care about it. We have no powers to seize or unplug the offending item. So, all we do is report back to the REIN Helpdesk our findings, they in turn inform your ISP, and they now own the problem.
You will just have to keep on 'sampling' your circuit to see if the problem does go away.
-
Clear now, I guess like you said time will tell.
I think the best thing to do in my situation would be to opt for FTTP when it's available next year on demand.
-
Clear now, I guess like you said time will tell.
I think the best thing to do in my situation would be to opt for FTTP when it's available next year on demand.
That's it, rub it in !!! ;) ;D
We aren't getting FTTC until at least 2014 around here, and you are getting FTTP ??!! Bah-humbug.
-
Clear now, I guess like you said time will tell.
I think the best thing to do in my situation would be to opt for FTTP when it's available next year on demand.
That's it, rub it in !!! ;) ;D
We aren't getting FTTC until at least 2014 around here, and you are getting FTTP ??!! Bah-humbug.
What 2014? I feel for you mate, Once FTTP rolls around for everyone that once it I'm sure we can wave goodbye to the line issues :)
-
The Connection re sync this morning, I have no idea why but look at the difference in the graphs, this could be before the equipment is turned on, I have no idea. My SNRM has also shot up, but in result I have a lower sync.
Thanks,
Josh
-
.
-
DLM really doesn't like your connection does it?
What do the ongoing graphs show?
There should be some sort of indication in them as to what is happening & when it happens.
That 27399 k sync speed looks very suspiciously like anther "stuck" DLM profile.
Also, I think there is some sort of incompatibility with the HG612 modem & the ECI DSLAM that you are connected to.
QLN should only show 3 lots of data (as per your earlier snapshot graphs).
My Huawei HG612, connected to a Huawei DSLAM, has never exhibited the strange QLN graphs issue.
BlackEagle has a similar setup to yours & he also saw strange graphs for a while, which appears to have rcently resolved itself.
He also has what appears to be a very noisy connection.
http://forum.kitz.co.uk/index.php/topic,10968.msg215093.html#msg215093
-
I don't know how to get the ongoing graphs running mate, I have tried to follow the instructions but can't get them to work.
Thanks,
Josh
-
Which OS are you using?
Do you normally LOGIN to Windows or not?
Have you changed the modem's IP Address from 192.168.1.1?
How are your PC, router & modem physically connected to each other?
I'll try to clarify how to set up the ongoing logging & graphing later tonight for you (off to work now).
They can be really useful in getting your ISP to take matters seriously.
Without them (and the snapshot graphs), you are more or less out on a limb.
If possible, please post a couple of screenshots of where the setting up process maight be going wrong for you.
-
Thanks for the help Paul,
Windows 7
Still 192.168.1.1
Laptop: Wireless, Modem to Router Wan port, then Router back to modem Lan port 2
Router ip is 192.168.254
-
Do you normally LOGIN to Windows or not?
(i.e. with a username & password).
Just a yes or no answer will suffice.
-
No I don't mate
-
Just a quick question, to isp's have any control over speed profiles? Like throughput speeds?
Or does the DLM control everything speed related?
-
Just a quick question, to isp's have any control over speed profiles? Like throughput speeds?
Or does the DLM control everything speed related?
They can over-ride DLM if required, but it's usually DLM managed.
-
Even on Fibre?
-
Yes. They're not going to install a system they have no control of. ;) ;D
-
I know what your saying, just when I have asked TalkTalk what profile I'm on they just say, they have no control over profiles, this is done by OR or the DLM.
Thanks
-
Oh sorry, my mistake. I wrongly assumed you meant does anybody have control of the speeds, or is it all DLM-managed.
-
Oh sorry, my mistake. I wrongly assumed you meant does anybody have control of the speeds, or is it all DLM-managed.
D'oh! ;) :)
-
Oh sorry, my mistake. I wrongly assumed you meant does anybody have control of the speeds, or is it all DLM-managed.
D'oh! ;) :)
Ha ha ...... just watching The Simpsons as we 'speak'. ;D
-
And as for showing BT the stats from the Modem, I think they will try and blame that to be the issue as I was supplied with the ECI not the HG612.
Even though they both have perform the same.
-
And as for showing BT the stats from the Modem, I think they will try and blame that to be the issue as I was supplied with the ECI not the HG612.
Even though they both have perform the same.
I'm not clued-up with the modems, I'm afraid. All I know is, if we install a Huawei modem when it should be an ECI, boy do we get a rocket up our a*se.
Asbo and others will probably know how 'they' know, but 'they' definitely do. Just like when the change-out process was put in place to get rid of the Modem 1A's (Used to set on fire). 'They' would know if you'd installed a 1A or not.
Like I say, I dont get involved in the modem side of things, but there are reasons as to which one you get.
-
Hi Josh,
Windows 7
Still 192.168.1.1
Laptop: Wireless, Modem to Router Wan port, then Router back to modem Lan port 2
Router ip is 192.168.254
Same as mine, except I login to Windows with a username & password.
I have sent you a PM.
Paul.
-
Hi BS,
Here's my take on the situation.
Whilst "they" should quite properly check the modem's performance after installation or engineering works have been accomplished, I very much doubt if any attention is paid perhaps after the training period is over ? After all, there is so little going on, perhaps we could have hundreds of "theys" drinking tea all day long monitoring every single FTTC service ?????????? !!!!!!!!!!!!!!!!
I strongly suspect sleeping dogs are left asleep !!
Kind regards,
Walter
-
I strongly suspect sleeping dogs are left asleep !!
^-^ Not if I can obtain access to them! [bellow]Meow![/bellow]
:crazy:
-
Also, I think there is some sort of incompatibility with the HG612 modem & the ECI DSLAM that you are connected to.
QLN should only show 3 lots of data (as per your earlier snapshot graphs).
My Huawei HG612, connected to a Huawei DSLAM, has never exhibited the strange QLN graphs issue.
BlackEagle has a similar setup to yours & he also saw strange graphs for a while, which appears to have rcently resolved itself.
He also has what appears to be a very noisy connection.
http://forum.kitz.co.uk/index.php/topic,10968.msg215093.html#msg215093
The availability of upstream QLN data may be a feature, rather than a flaw, of the ECI DSLAM..
From ITU-T Recommendation - G.992.3 (07/2002) SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS [1]
Specifically, p.94 of [1]:
8.12.3.2
Quiet Line Noise PSD* per subcarrier (QLN-ps)
The quiet line noise PSD QLN(f) for a particular subcarrier is the rms level of the noise present on the line, when no ADSL signals are present on the line. The quiet line PSD QLN(f) per subchannel shall be measured by the receive PMD** function during diagnostics mode and initialization. The measurement shall not (i.e., cannot) be updated during showtime.
The QLN(f) shall be sent to the far-end transmit PMD function during diagnostics mode (see 8.15.1) and shall be sent on request to the near-end Management Entity. The near-end Management Entity shall send the QLN(f) to the far-end Management Entity on request during showtime (see 9.4.1.10).
* PSD = Power Spectral Density
** PMD = Physical Media Dependent (sublayer)
So the Management Entity (modem controller) on either end of the loop, far-end or near-end, can request the other end's QLN PSD during showtime.
It would appear that the Huawei SmartAX DSLAM ignores such requests, whereas the ECI Vinax DSLAM fulfils those requests (sometimes?)
cheers, a
[1] http://www.analytic.ru/articles/lib26.pdf
-
The availability of upstream QLN data may be a feature, rather than a flaw, of the ECI DSLAM..
I wondered if that could be the case
It would appear that the Huawei SmartAX DSLAM ignores such requests, whereas the ECI Vinax DSLAM fulfils those requests (sometimes?)
It was the sometimes part that threw me.
I think BlackEagle mentioned that the US data suddenly appeared, even though the modem hadn't re-synced (retrained)
My understanding was that QLN data (& Hlog data too) was not updated until the next retrain.
-
Hi BS,
Here's my take on the situation.
Whilst "they" should quite properly check the modem's performance after installation or engineering works have been accomplished, I very much doubt if any attention is paid perhaps after the training period is over ? After all, there is so little going on, perhaps we could have hundreds of "theys" drinking tea all day long monitoring every single FTTC service ?????????? !!!!!!!!!!!!!!!!
I strongly suspect sleeping dogs are left asleep !!
Kind regards,
Walter
That's what I feel is the situation myself, Walter. My point was we have to proide the 'correct' router on install, in response to Josh feeling he was being short-changed by getting flavour 'A' instead of flavour 'B'. ;) ;D
-
Hi Josh,
Windows 7
Still 192.168.1.1
Laptop: Wireless, Modem to Router Wan port, then Router back to modem Lan port 2
Router ip is 192.168.254
Same as mine, except I login to Windows with a username & password.
I have sent you a PM.
Paul.
Thanks Paul, got it mate, going to check in out today. Wasn't home last night.
Thanks again,
Josh
-
Got the ongoing graphs working big thanks to Bald_Eagle1 for the help, had a little trouble but here they are;
REIN has not impacted my line (yet) But I'll be sure to post some stats when it's present.
Thanks again Paul!
Josh
-
It looks, to me, as if you have a good FTTC VDSL2 service. ;D
-
It looks, to me, as if you have a good FTTC VDSL2 service. ;D
REIN has just started :(
-
Just like to thank Paul for the help again, I quess I have something to prove/show the next engineer that visits what is happening and when it's happening.
What you guys think? Is this in fact REIN?
-
REIN has just started :(
It will be interesting to see quite a few days of continuous graphs.
That's the first time I have seen graphs looking like that.
Are you able to leave it logging 24/7?
If a pattern develops, at least you would know when to go walking the streets with a radio tuned to 612KHz looking for it.
If it starts & stops exactly at the same time every day, it might suggest something like central heating on a timer.
-
. . . show the next engineer that visits what is happening and when it's happening.
. . . Is this in fact REIN?
Looking at the easy to interpret graph, we see the gradual decrease in the DS SNRM as the afternoon fades and the evening begins, which should be familiar to anyone with an xDSL service. That is normality and to be expected.
As for the other graphs, they most certainly show some sudden appearance of RFI at about 1900 hours. As Bald_Eagle1 has suggested, it would be nice to see a sequence of graphs covering a number of successive days . . . contiguous logging for a minimum of 3 to 4 days. :-\
-
I'm going to leave it over night Paul, I'll post more stats tomorrow morning.
I have made sure nothing in this house turns on at the times the REIN starts.
Might be worth asking neighbors either side if there central heating comes on at those times though.
Cheers,
Josh
-
. . . show the next engineer that visits what is happening and when it's happening.
. . . Is this in fact REIN?
Looking at the easy to interpret graph, we see the gradual decrease in the DS SNRM as the afternoon fades and the evening begins, which should be familiar to anyone with an xDSL service. That is normality and to be expected.
As for the other graphs, they most certainly show some sudden appearance of RFI at about 1900 hours. As Bald_Eagle1 has suggested, it would be nice to see a sequence of graphs covering a number of successive days . . . contiguous logging for a minimum of 3 to 4 days. :-\
I'll be posting quite a few more now I got the graphs working!
Put me in a good mood actually, now I have evidence. Might sleep well tonight ;) lol
Cheers,
Josh
-
Josh,
If possible, it would be ideal if you could leave it logging 24 hours a day 7 days a week for at least 2 weeks.
Any recurring patterns could then be easily identified.
When you have gathered that amount of data you can plot it in days, hours, minutes.
Apart from needing to leave the modem & logging PC switched on (no hibernating or dropping into power saving modes), I have seen no negative effects on my system & it has been logging continuously since November.
The log file (modem_stats.log) can get a bit large, so every now & then I rename it & allow the script to continue & create a new modem_stats.log
-
I'll be posting quite a few more now I got the graphs working!
Put me in a good mood actually, now I have evidence. Might sleep well tonight ;) lol
Just be careful Josh.
I have heard that some people can end up becoming obsessed with stats & graphs & such like ;)
-
Josh,
If possible, it would be ideal if you could leave it logging 24 hours a day 7 days a week for at least 2 weeks.
Any recurring patterns could then be easily identified.
When you have gathered that amount of data you can plot it in days, hours, minutes.
Apart from needing to leave the modem & logging PC switched on (no hibernating or dropping into power saving modes), I have seen no negative effects on my system & it has been logging continuously since November.
The log file (modem_stats.log) can get a bit large, so every now & then I rename it & allow the script to continue & create a new modem_stats.log
I think that should be fine, I'll set the desktop up in the guest bedroom, and just leave in on 24/7 for the next 7 days.
Cheers,
Josh
-
I'll be posting quite a few more now I got the graphs working!
Put me in a good mood actually, now I have evidence. Might sleep well tonight ;) lol
Just be careful Josh.
I have heard that some people can end up becoming obsessed with stats & graphs & such like ;)
I have a feeling I'm going to be the same from now on ;) lol
-
5 hour or REIN, 7 hour graph.
-
12 hour graph, showing disconnection at 5:20 this morning.
Edit: DLM has also increased my SNRM for more stability I presume
Cheers,
Josh
-
Just be careful Josh.
I have heard that some people can end up becoming obsessed with stats & graphs & such like ;)
Nah, I can't believe that BE :lol:
-
12 hour graph, showing disconnection at 5:20 this morning.
Edit: DLM has also increased my SNRM for more stability I presume
As part of the evidence, you now have a smoking gun, Josh.
We need to see if your line is hit with more RFI during the approximate 1900 - 2355 hours window, tonight.
-
It's all set up on the desktop upstairs now, it's been running for a few hours.
I'll post some more later tonight or in the morning.
Cheers,
Josh
-
We need to see if your line is hit with more RFI during the approximate 1900 - 2355 hours window, tonight.
& perhaps just as importantly, evidence of the periods when it is definitely NOT being hit with RFI
-
We need to see if your line is hit with more RFI during the approximate 1900 - 2355 hours window, tonight.
& perhaps just as importantly, evidence of the periods when it is definitely NOT being hit with RFI
^-^ Indeedy! :P
-
Fantastic example of why we should have access to the stats by default. Hope it gets sorted sooner rather than later JoshShep.
-
Surprisingly, not much interference last night at all, what could this indicate?
Someone didn't turn there central heating on last night?
I'll post some more graphs soon.
Cheers,
Josh
-
Someone didn't turn there central heating on last night?
Or the nearby Pub is quiet (don't pump many pints & its big screen TV is off) or it is even closed on Sunday nights?
-
Someone didn't turn there central heating on last night?
Or the nearby Pub is quiet (don't pump many pints & its big screen TV is off) or it is even closed on Sunday nights?
Actually that is very possible Paul, there is a pub at the top of the street about 300M away. But I think it is open on Sundays. :-\
Edit: It is open on Sundays, and it's there busiest day.
-
Edit: It is open on Sundays, and it's there busiest day.
There you go then. Something eliminated.
Eliminate the other 1001 potential sources & you will have cracked it ;)
-
Edit: It is open on Sundays, and it's there busiest day.
There you go then. Something eliminated.
Eliminate the other 1001 potential sources & you will have cracked it ;)
:lol:
-
Just had a re sync I have no idea why, from what I can see there are no problems, for the last couple of nights now no REIN has effected my connection, I have no idea why, It's normally every night!
But why the dissconnection? :-\
Cheers,
Josh
Edit: I'm tempted to put the ECI back in and hopefully recover some sync speed
-
As it had been up for 8 hours or so at the time of the re-sync, it must have also re-synced this morning.
Is there anything in the graphs from around that time to suggest what may have caused it?
Do you have a continuous modem_stats log you could graph or even email to me for further study?
You previously mentioned you are now logging the stats on a desktop PC in a different room.
Is the modem still plugged into the same power socket as when you did see all the REIN in your graphs or have you relocated it?
-
Just as an experiment, I have put the ECI back in.
I can't get the stats up so all I can go off is what speed test results give me.
And ping results using Command Prompt.
Surprisingly my pings have shot down from 31ms to 22ms.
This must be how the ECI kit work with each other so there must be some incompatibility like stated earlier.
Pinging bbc.co.uk [212.58.241.131] with 32 bytes of data:
Reply from 212.58.241.131: bytes=32 time=22ms TTL=243
Reply from 212.58.241.131: bytes=32 time=22ms TTL=243
Reply from 212.58.241.131: bytes=32 time=22ms TTL=243
Reply from 212.58.241.131: bytes=32 time=22ms TTL=243
Cheers,
Josh
-
As it had been up for 8 hours or so at the time of the re-sync, it must have also re-synced this morning.
Is there anything in the graphs from around that time to suggest what may have caused it?
Do you have a continuous modem_stats log you could graph or even email to me for further study?
You previously mentioned you are now logging the stats on a desktop PC in a different room.
Is the modem still plugged into the same power socket as when you did see all the REIN in your graphs or have you relocated it?
I'll send you all I have mate, but for now I leaving the ECI in, I need to learn how to unlock the ECI me thinks!
The modem is always plugged in the same place, Right next to the front door, where the NTE5 is.
-
It looks like DLM is stuck at 24999 k sync speed for your connection as your Attainable Rate is much higher than that.
I'm not sure that swapping back to the ECI modem will "unstick" it.
In fact, yet another re-sync caused by swapping modems may just have made things worse.
Was the modem unplugged at the time of this morning's re-sync (somewhere around 10:00 to 10:30)?
Maybe the front door was slammed which disturbed the power for a split second due to a loose wire in the power socket?
Your graphed stats certainly look unusual & a little disjointed here & there.
Does the actual modem_stats.log file have a gap in its harvested stats around the same time.
Feel free to email the log file itself to me if you wish.
-
Its a silly question, but I'll ask anyway.
Does "someone" regularly unplug your modem to plug in the vacuum cleaner? :lol:
-
Its a silly question, but I'll ask anyway.
Does "someone" regularly unplug your modem to plug in the vacuum cleaner? :lol:
Not a silly question mate, but no It's always plugged in.
-
Got another update,
"I’ve just spoken with the Openreach REIN department; the case has been picked up by dispatch.
This means the fault will be assigned to an engineer today. The REIN engineer should then pickup the case this week, most likely Thursday or Friday.
We are due our next update on Friday afternoon. I did attempt to escalate this case; however REIN investigations are done on best endeavours so the escalation isn’t guaranteed.
I will contact you if anything changes, otherwise I will be in touch on Friday".
Looks good, I'll just keep pestering them and hopefully it gets resolved eventually.
Cheers,
Josh
-
Be patient with them, Josh. REIN faulting tends to be either a quick fix, or a drawn out affair. I hope its the former. ;D
-
As Paul recommended I have swapped out the ECI for the HG612 again, and one thing I have noticed is that not as many errors are showing as before, I believe this is due to a low sync rate.
That or REIN isn't effecting me any more? Would OR tell me if they've already found the source of REIN?
Cheers,
Josh
-
If you are still "capped" at 25Mb on a connection that is occasionally capable of 40 Mb, I would expect SNRM to be quite high.
At a low sync speed, general errors tend to be fewer & maybe as SNRM is higher, the connection is able to "shrug off" the odd burst of REIN.
If the severe errors only occur once a week, at the same time each week, that should hopefully help you & others to track it down.
The thing is though, all through that big block of errors as previously shown in your graphs from last Saturday evening, your connection remained in sync.
It seems to re-sync at its lower speeds when the graphs suggest the connection looks pretty stable.
Unless the re-syncs are caused by one hell of a massive burst of REIN that happens between the 1 minute data samples, there could be a physical connection fault such as a dodgy joint or power supply issue etc.
Do your house lights ever flicker, or the TV switch itself off, or mains powered clocks need resetting for no apparent reason?
Do any of the re-syncs coincide with switching a kettle on or anything like that?
A visiting engineer may well pronounce the line to be O.K. if the “issue” isn’t actually evident at the time of his visit.
Good luck with this. I hope you can get it sorted quite soon.
Continuous logs & graphs may not be able to prove the cause, but they may be able to prove what is NOT the cause, in a process of elimination.
Nobody said this would be easy....................
(my own connection's issues still haven't been fully resolved since first reporting them last July >:()
-
Thanks Paul, hope you get your connection sorted sooner than later too!
Funny you should say though, the lights do flicker quite regular, mostly when powering on the hoover. And we do go though a load of light bulbs. Also the electric trips quite regular!
What could this mean?
Cheers,
Josh
Edit: I haven't noticed any re sync's when using anything electrical though.
The electricity does not trip sorry, when the light bulbs go out the lights trip not the actual power to the sockets
-
That or REIN isn't effecting me any more? Would OR tell me if they've already found the source of REIN?
No, they probably wouldn't. OR are working for and on behalf of the ISP, and it's them that will receive the feedback from the REIN Helpdesk. They (REIN Helpdesk) of course, get the engineers report first.
You can always ask your ISP if anything has been resolved.
-
That or REIN isn't effecting me any more? Would OR tell me if they've already found the source of REIN?
No, they probably wouldn't. OR are working for and on behalf of the ISP, and it's them that will receive the feedback from the REIN Helpdesk. They (REIN Helpdesk) of course, get the engineers report first.
You can always ask your ISP if anything has been resolved.
I'm expecting an update tomorrow, I'll email support then. :)
-
Please keep us posted regarding the outcome (or not) in this thread Josh.
Have errors started mounting again now it's dark outside?
-
It's not looking too bad tonight.
Cheers,
Josh
-
My, your sync speed really has taken a bit of a hit recently hasn't it?
That low speed must definitely account for the low error counts.
-
My, your sync speed really has taken a bit of a hit recently hasn't it?
That low speed must definitely account for the low error counts.
That's what I'm thinking Paul, my pings have also increased to 40ms, interleaving must have increased.
-
. . . the lights do flicker quite regular, mostly when powering on the hoover. And we do go though a load of light bulbs. Also the electric trips quite regular!
Edit: I haven't noticed any re sync's when using anything electrical though.
The electricity does not trip sorry, when the light bulbs go out the lights trip not the actual power to the sockets
That reads as if you have marginal mains wiring. It is almost as if it is telling you that it needs to be checked by a qualified electrician. :-X
How old is your house? How old is the wiring? Is your electricity supply fed underground or overhead?
-
. . . the lights do flicker quite regular, mostly when powering on the hoover. And we do go though a load of light bulbs. Also the electric trips quite regular!
Edit: I haven't noticed any re sync's when using anything electrical though.
The electricity does not trip sorry, when the light bulbs go out the lights trip not the actual power to the sockets
That reads as if you have marginal mains wiring. It is almost as if it is telling you that it needs to be checked by a qualified electrician. :-X
How old is your house? How old is the wiring? Is your electricity supply fed underground or overhead?
Think this needs further clarification. 'Power to sockets' remains unaffected, nut the 'Lights trip'. If Josh has an up-to-date spec board, that is what should happen. It is a 'split board' whereby the mains sockets are fed via RCD's and the lighting via MCB's.
I see what you are saying though B*Cat and it really is down to the wording. You are guessing he has the old rewireable board methinks ??
As I say, further clarification is needed. :)
-
. . . the lights do flicker quite regular, mostly when powering on the hoover. And we do go though a load of light bulbs. Also the electric trips quite regular!
The electricity does not trip sorry, when the light bulbs go out the lights trip not the actual power to the sockets[/color]
That reads as if you have marginal mains wiring. It is almost as if it is telling you that it needs to be checked by a qualified electrician. :-X
How old is your house? How old is the wiring? Is your electricity supply fed underground or overhead?
Think this needs further clarification. 'Power to sockets' remains unaffected, nut the 'Lights trip'. If Josh has an up-to-date spec board, that is what should happen. It is a 'split board' whereby the mains sockets are fed via RCD's and the lighting via MCB's.
I thought Josh might have just described the underlying issue, until he added the edit that it is only the lights that trip.
There might still be something to check there though, as I don't think simply powering up a hoover should cause a noticeable flicker on the lighting.
My lighting circuit also trips as intended whenever a light bulb "pops".
-
I will have it checked out you never know! It's an old house but fairly new wiring, you never know it might well be the issue.
DLM has made changes again, this time for the better!
-
48 Hour Graph
-
DLM has made changes again, this time for the better!
It is better, but 27399 k sync speed still looks suspiciously like a capped/stuck profile against the 40Mb+ attainable rate.
I wonder if DLM needs re-setting on a wide open profile for your connection to retrain over 2 days (as per BT's own SIN 498 document), or if DLM ups the sync speeds at various capped levels over a few days to see what your connection can sustain.
You should be getting some feedback anyway today shouldn't you?
-
DLM has made changes again, this time for the better!
It is better, but 27399 k sync speed still looks suspiciously like a capped/stuck profile against the 40Mb+ attainable rate.
I wonder if DLM needs re-setting on a wide open profile for your connection to retrain over 2 days (as per BT's own SIN 498 document), or if DLM ups the sync speeds at various capped levels over a few days to see what your connection can sustain.
You should be getting some feedback anyway today shouldn't you?
That's right Paul, I'll report back later on.
Cheers,
Josh
-
As I say, further clarification is needed. :)
Absolutely. I can see no obvious reason why the lights (on one circuit) should flicker when a transient heavy load (start-up current of a vacuum cleaner motor) is applied on a separate circuit.
(Note for those not in the know. Before he became a communications technician, Black Sheep plied his trade as a qualified sparky. ;) )
-
As I say, further clarification is needed. :)
Absolutely. I can see no obvious reason why the lights (on one circuit) should flicker when a transient heavy load (start-up current of a vacuum cleaner motor) is applied on a separate circuit.
(Note for those not in the know. Before he became a communications technician, Black Sheep plied his trade as a qualified sparky. ;) )
After further testing the lights do not flicker but then do dim, is this normal when powering on the hoover? And slightly but not as much when clicking on the kettle.
Any thoughts?
Cheers,
Josh
-
I know very little about this stuff, but what sort of lights are they? Could they be somehow linked to the mains circuit, it sounds as if the more power is drawn on the mains the less the lights get?
-
After further testing the lights do not flicker but then do dim, is this normal when powering on the hoover? And slightly but not as much when clicking on the kettle.
Is you mains power supply fed to you by overhead wires? Are you at the remote end of a country lane, in the village of "Much Mucking In The Duck Pond"?
If both answers are "No", then I would not expect that powering on the vacuum cleaner or the kettle would cause the lights to dim, transiently.
I think that Black Sheep and / or Walter may be the best qualified to comment on your power situation. :-\
-
Got my update,
"I’ve just received an update from Openreach, unfortunately it is not the best news.
So far they have been unable to task out an engineer; so I’ve escalated the issue.
This will now follow a high level escalation process, so OR management will now be involved.
OR REIN will provide the next update on 2nd May, however due to the escalation I expect an update on Monday morning.
I understand this will be frustrating; but please rest assured we are doing everything within our control to progress the fault with Openreach".
Sounds like a step in the right direction!
Although errors have been much lower than they have previously been!
Cheers,
Josh
-
After further testing the lights do not flicker but then do dim, is this normal when powering on the hoover? And slightly but not as much when clicking on the kettle.
Is you mains power supply fed to you by overhead wires? Are you at the remote end of a country lane, in the village of "Much Mucking In The Duck Pond"?
If both answers are "No", then I would not expect that powering on the vacuum cleaner or the kettle would cause the lights to dim, transiently.
I think that Black Sheep and / or Walter may be the best qualified to comment on your power situation. :-\
As with all things, trying to 'bottom out' an issue on a forum is difficult. I wonder if we're going off at a tangent as well here ?? Anyhows, as most folk will know, the lighting circuits and power circuits (ie: ring main sockets) should be on their own protective device, be that a rewireable fues, a cartridge fuse, or an RCD/MCCB etc etc.
However, there could be a fused-spur feeding a lighting circuit of its own, that is fed off the ring-main wiring. This is quite legal to do. It is most commonly used in loft-conversions or conservatory builds, whereby it's generally easier to extend the ring main into the 'new build', but trying to pick up the lighting circuit proves more difficult. By running a seperate 'fused-spur' that is teed-off this extended ring-main, you can fuse the circuit down to 5amps and run a lighting circuit from it. In effect, the 'fused spur' is acting as the main distribution board, but only for that particular lighting circuit. So, it is possible that if the ring-main (with the fused spur attatched) is working at near full capacity, then switching on a bank of lights could see a small voltage dip.
Hope that makes sense, cos it's not easy to put over in words. :-\ :)
-
That makes perfect sense, we have a conservetry.
Question is could this effect my broadband connection?
Cheers,
Josh
-
That makes perfect sense, we have a conservetry.
Question is could this effect my broadband connection?
Cheers,
Josh
Yes, you need to demolish the conservatory immediately !! ;D
Please forgive my moment of mirth there, Josh. This is why I said above, that we could be going off at a tangent. One minute we're talking about the why's and wherefores of 17th edition electrical wiring, and the next ... REIN.
Don't get me wrong, the two could be linked but I think we're trying to dig too deep here. If you suspect you have REIN's induced interference within the premises, and you perceive it to be your lights (whether they are directly fused or on a spur), then try and obtain a small AM/MW radio and tune it into 612Khz and observe if a 'buzzing' noise appears in place of the nominal hissing/whooshing noise that will be heard when REIN isn't detected.
Sorry for short reply, but off to do some paid graft. ;) ;D ;D Stick with it Josh.
-
Thanks for the information BS, I have inspected the house a few times and can conclude the REIN is not from my end.
Cheers,
Josh
-
Interesting stuff, Interleaving has decreased dramatically, it's the lowest I have seen in a long time.
-
Tonight might be the one that reveals all ???.
If you see anywhere near the errors/noise as last Saturday night, you may just be able to track it down by wandering the streets with a radio tuned to 612KHz MW or AM.
If it's all quiet tonight, then it's back to the drawing board again for you.
-
Tonight might be the one that reveals all ???.
If you see anywhere near the errors/noise as last Saturday night, you may just be able to track it down by wandering the streets with a radio tuned to 612KHz MW or AM.
If it's all quiet tonight, then it's back to the drawing board again for you.
I'll keep a close eye from 7pm,
All I know is errors have not been nearly as bad this week!
That may be why DLM is making changes, gradually recovering my profile step by step.
The issue has been escalated now so hopefully OR take proper action.
Cheers,
Josh
-
Nothing abnormal so far, a few errors but I believe there acceptable.
How many errors per day are normal/acceptable?
And is it normal to get a few errors when the phone rings?
Cheers,
Josh
-
Hmmm, the DLM capping is quite evident from that, although I think if it were me, I'd be concerned about the upstream errors Josh, as although I know I have a noisy line, I don't particularly suffer upstream errors. I can't really comment on what is/isn't acceptable for errors per day, just that if it starts impacting your throughput speed or making DLM cap you, then its obviously an issue.
Screenie of my current stats attached. :)
-
Just a quick reminder:-
The error counts in the modem's GUI seem to be a bit mixed up (a bug in the modem).
This was first spotted many months ago.
Reported FEC errors are probably CRC errors & vice versa.
e.g. you will see FEC errors incorrectly reported in the modem's, GUI even when Interleaving is completely OFF.
The error counts as obtained from various xdslcmd commands & therefore also reported in the ongoing graphs are to be trusted more.
The ongoing graphs do plot errors from both xdslcmd commands and the GUI, stating where they had been obtained.
US error data is also harvested, but not currently plotted at this stage.
The scripts could be amended to plot US errors though (if required).
EDIT:
Just so I don't feel left out, I have attached a screenshot of my modem's current status
-
Hmmm, the DLM capping is quite evident from that, although I think if it were me, I'd be concerned about the upstream errors Josh, as although I know I have a noisy line, I don't particularly suffer upstream errors. I can't really comment on what is/isn't acceptable for errors per day, just that if it starts impacting your throughput speed or making DLM cap you, then its obviously an issue.
Screenie of my current stats attached. :)
Yeah that's right BE, DLM has capped my speeds, due to high error counts in the past, my connection has been much better this week!
so hopefully things will get better, my issues have been escalated to OR, so it's all being reviewed.
I can see your on 40/2 and that would probably explain why I have more errors than you for upstream, I'm on the 80/20 trail, and the higher sync for both downstream and upstream the more errors you will get I believe.
Cheers,
Josh
-
Just a quick reminder:-
The error counts in the modem's GUI seem to be a bit mixed up (a bug in the modem).
This was first spotted many months ago.
Reported FEC errors are probably CRC errors & vice versa.
e.g. you will see FEC errors incorrectly reported in the modem's, GUI even when Interleaving is completely OFF.
The error counts as obtained from various xdslcmd commands & therefore also reported in the ongoing graphs are to be trusted more.
The ongoing graphs do plot errors from both xdslcmd commands and the GUI, stating where they had been obtained.
US error data is also harvested, but not currently plotted at this stage.
The scripts could be amended to plot US errors though (if required).
Thanks for that Paul, I had no idea!
-
From taking a look and what I can remember, me and Blackeagle are both with TalkTalk for out isp, we both have a big difference between out sync rate and out attainable rate, could this be TalkTalk capping our speeds? or is this just a coincidence?
Cheers,
Josh
-
I believe that ISPs are only able to cap FTTC throughput speeds.
Any sync speed caps are applied by DLM based on "various" factors such as error rates, Interleaving depth, number of re-syncs & so on.
Possibly BT can also cap sync speeds remotely (it certainly is the case with 80Mb or 40Mb), but if so, I'm not sure what it would be based on.
Occasionally DLM sticks at low sync speeds, even when issues have been "fixed" & requires an engineer visit to get it re-set.
-
From taking a look and what I can remember, me and Blackeagle are both with TalkTalk for out isp, we both have a big difference between out sync rate and out attainable rate, could this be TalkTalk capping our speeds? or is this just a coincidence?
Cheers,
Josh
Well yes, we are both with TT Josh although I think the baldy bird is correct in that its the DLM line profile that is managing that large difference in rates. However, there is also another thing we have in common, and thats that we were both supplied with th ECI modem and are both using an unlocked HUAWEI on our lines.
The fact that the modem is not matched to the DSLAM equipment may well have a bearing on things. I would unlock mine, which would enable me to see if there is much difference but I would rather have an untouched original should OR decide to investigate my line.
-
From taking a look and what I can remember, me and Blackeagle are both with TalkTalk for out isp, we both have a big difference between out sync rate and out attainable rate, could this be TalkTalk capping our speeds? or is this just a coincidence?
Cheers,
Josh
Well yes, we are both with TT Josh although I think the baldy bird is correct in that its the DLM line profile that is managing that large difference in rates. However, there is also another thing we have in common, and thats that we were both supplied with th ECI modem and are both using an unlocked HUAWEI on our lines.
The fact that the modem is not matched to the DSLAM equipment may well have a bearing on things. I would unlock mine, which would enable me to see if there is much difference but I would rather have an untouched original should OR decide to investigate my line.
That may be the case, but I don't think it would have too much impact. It's like ADSL some router's are better than others, it just depends on the chipset and how well they perform with the DSLAM equipment. That's what I think anyway.
Cheers,
Josh
-
Good news, profile is recovering I'm back to 32Mbps again,
Hopefully this is a good sign and things keep improving!
Edit: Just been told that OR was doing some work in the cabinet a few days ago, I didn't know about it but there were 3 Engineers there, maybe there was a problem with the cab?
-
@ Josh,
How do last night's stats look?
Anywhere near as bad as last Saturday night?
Ha - you beat me by a few seconds :lol: :lol:
-
Good news, profile is recovering I'm back to 32Mbps again,
Hopefully this is a good sign and things keep improving!
Apart from that big block of RSCorr errors it all looks pretty good.
(Was anything being used/downloaded when those errors mounted?)
Also, did the connection re-sync of its own accord this morning?
-
Good news, profile is recovering I'm back to 32Mbps again,
Hopefully this is a good sign and things keep improving!
Apart from that big block of RSCorr errors it all looks pretty good.
(Was anything being used/downloaded when those errors mounted?)
Also, did the connection re-sync of its own accord this morning?
I did do a little downloading yesterday, and also streamed the football match, and yes I did re-sync on it's own Paul,
Cheers,
Josh
Edit: Was looking at the wrong errors, I was not up at that time, so I have no idea what caused them.
-
That may be the case, but I don't think it would have too much impact. It's like ADSL some router's are better than others, it just depends on the chipset and how well they perform with the DSLAM equipment. That's what I think anyway.
Cheers,
Josh
I think that there may be a little more to it than that. From what I understand, OR engineers are in big trouble if they fit the wrong modem for the DSLAM. Besides, on TT ADSL I have had matching kit (Huawei router and Huawei MSAN) and broadcom chipsets have always performed better, in particular Thomson routers with broadcom chipsets ;)
-
That may be the case, but I don't think it would have too much impact. It's like ADSL some router's are better than others, it just depends on the chipset and how well they perform with the DSLAM equipment. That's what I think anyway.
Cheers,
Josh
I think that there may be a little more to it than that. From what I understand, OR engineers are in big trouble if they fit the wrong modem for the DSLAM. Besides, on TT ADSL I have had matching kit (Huawei router and Huawei MSAN) and broadcom chipsets have always performed better, in particular Thomson routers with broadcom chipsets ;)
Same situation here, always been on TalkTalk, LLU exchange. Had the Netgear DNG200 (Broadcom) was much better than the supplied router, it just all depends, none of them are participially incompatible, some perform better than other that's all.
The HG612 is a broadcom and the ECI is a Lantiq, they both perform very similar on my line.
Cheers,
Josh
-
That may be the case, but I don't think it would have too much impact. It's like ADSL some router's are better than others, it just depends on the chipset and how well they perform with the DSLAM equipment. That's what I think anyway.
Cheers,
Josh
I think that there may be a little more to it than that. From what I understand, OR engineers are in big trouble if they fit the wrong modem for the DSLAM. Besides, on TT ADSL I have had matching kit (Huawei router and Huawei MSAN) and broadcom chipsets have always performed better, in particular Thomson routers with broadcom chipsets ;)
That was very true BE. It was classed as a 10-point failure, which means they take you round the back of the Exchange and beat you !!
I mentioned this fact only recently myself on here, and would you Adam & Eve it ?? we go and get a 'brief' stating we can use ECI's in place of a Huwawei, and vice-versa if we are short on van stock. ::) ::)
-
5 day graph,
SNRM was returned to default value of 6dB around 10pm last night.
Cheers,
Josh
-
... and can conclude the REIN is not from my end.
I had to read that twice. ;D
-
Quite a few errors have mounted up tonight.
Due another update on the ticket Wed.
Cheers,
Josh
-
Similar timeframe as your last post Josh for my line. Can I ask, how did you get TT to escalate this for you, was it via the forum or telephone CS ??
-
FWIW, I/we have today started to remotely monitor another Huawei HG612 modem connected to an ECI DSLAM.
US QLN AND Hlog data can indeed be seen & plotted:-
I will spend a bit of time checking & adapting the scripts for the HG612 modem on an ECI DSLAM & hopefully an easily unlockable ECI modem is not too far away now anyway.
Example Current Stats attached.
-
Similar timeframe as your last post Josh for my line. Can I ask, how did you get TT to escalate this for you, was it via the forum or telephone CS ??
It was abit of everything mate, I can highly recommend to use the TT Forums thought!
There all great on there and you should get an update within 24 hours.
Cheers,
Josh
-
FWIW, I/we have today started to remotely monitor another Huawei HG612 modem connected to an ECI DSLAM.
US QLN AND Hlog data can indeed be seen & plotted:-
I will spend a bit of time checking & adapting the scripts for the HG612 modem on an ECI DSLAM & hopefully an easily unlockable ECI modem is not too far away now anyway.
Example Current Stats attached.
Great news Paul,
Thanks for the hard work mate! :)
-
Just a tip wih locating possible REIN wih a radio.
You will hear all sorts of noises from different electrical appliances when you hold a radio close by.
Also move the radio side to side 90 degrees and verticaly by 90 degrees. The reason : imagine a cable running in a straight line. Then imagine the electrical noise emminating from that cable like rings similar to the ripples on the surface of water when you dip your finger into it. This is very much like the way field lines work fom a cable with electricity.
In a MW radio the antenna is about the size and shape of a small marker pen. Its most sensitive to an electrical signal if the field line you imagined is running lengthways through the middle of that pen shape.
By not moving the radio around as you look for REIN you may be walking right past a source and not hearing it as the antenna is in the wrong orientation to pick it up. I remember a situation where everyone else wa suspecting one set of power cables yet this trick informed me the source was some HT power cables further away. (Anyone familiar with using a C.A.T. Cable avoidance tool. for locating utilites outside would be familiar with this concept when you think that the same type of antenna is that bulge at the base of the C.A.T.)
One way to experiment with this effect. If you have Dropwires in your neighbourhood feeding homes with telephony walk around with a MW radio at 612khz. You'll hear distinct shhhhh noise from amny of them. Thats Broadband you can hear. Isolate a cable and try rotating the radio by 90 degrees this way and that and notice how it get more sensitive in a certain orientaion. Now move from directly under the cable to a few feet away and note how you need to change the angle of the radio to get the greater sensitivity. Think of those radiating circles of electrical noise again. ;)
Nothing wrong with listening to the enviroment when the dsl is ok as you have something to compaire with when there is the problem. A new noise or something louder perhaps. You may hear a distinct noise but dnt let that fool you into a wild goose chase as just because a distinct noise in around the area ther's still a good chance that that's not the problem.
Don't be fooled into thinking the source has to be overhead cabling. I started thinking that way but later found the deception in my mind as to, just 'cos you can see it can sway you from considering an underground source which turned out to be as likely as overhead.
When I used the word 'source' above I perhaps should have used the term emmiter. The worst problem with REIN is the actual source generating the errant signal may be tucked away some where but the signal is emminating from any cable its ultimately connected to. ie I'm hearing a loud signal which I know to be the problem. I can hear it comming from the underground electrical cabling to equal volume along several streets on a housing estate. Later the source was found to be a LCD monitor in an upstairs study in a house toward the edge of the area with the noise.
That exsample wa a good one of braking things down to locate it. I could tell it was coming through the 240v network, so it's feeding through the mains. At the errant house the owner was amiable to turning off his electrics at the consumer board (noise dissapears) turn it back on (noise is back) then switch each fuse one by one in turn. (its the downstairs mains ring) (hold on, its only half the downstairs ring ? hang on its the upstairs ring but only half again this time the opposite side of the house, lets look up there too. Turning off appliances one by one. A monitor... noise goes, everyone in sync. turn it on, noise back everyones out of sync) My suspision is that as the house was a show home so the garrage was an office some urchin has messed up the wiring in adding more lights and sockets for the sales office. As to what caused the monitor to cause some REIN. No idea but flat screen monitors is the one item I would say has caused at least 25% of all REIN I've found excluding december.
Hope this helps
-
Very interesting read,
thanks Ezzer!
Edit: These are the sort of throughput speeds I get when my line is effected, this was just taken: http://www.speedtest.net/result/1925631218.png
-
Edit: These are the sort of throughput speeds I get when my line is effected, this was just taken: http://www.speedtest.net/result/1925631218.png
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F1925631218.png&hash=0c3f75771fe3733721400c5d631227df0521c4f3)
Is there anything obvious showing in your graphs from around the same time?
If not, it looks like really, really, really severe contention.
-
FWIW, I/we have today started to remotely monitor another Huawei HG612 modem connected to an ECI DSLAM.
US QLN AND Hlog data can indeed be seen & plotted:-
I have been dabbling with my scripts & it appears that US SNR data is also provided when connected to an ECI DSLAM.
Another example Showing US SNR is attached.
@ JoshShep & BlackEagle,
If you would like to email a recent Plink log or two to me, I could check this out a bit further.
-
7 day graph here.
I can't figure out any patterns of these errors;
they just seem to be random.
Cheers,
Josh
-
Josh -- A simple request . . . When posting a montage of your line statistics for our examination, please post them in the portrait format rather than landscape.
You have posted line_stats_L-20120502-1243.png, above, whereas line_stats_P-20120502-1243.png would allow more convenient viewing. :)
-
Josh -- A simple request . . . When posting a montage of your line statistics for our examination, please post them in the portrait format rather than landscape.
You have posted line_stats_L-20120502-1243.png, above, whereas line_stats_P-20120502-1243.png would allow more convenient viewing. :)
Thanks for that, will do next time!
-
7 day graph here. I can't figure out any patterns of these errors;
they just seem to be random.
Cheers, Josh
The spikes of errors could be misleading. They primarily record the packet flow on your connection as a function of time. The spikes are indicative of your internet usage pattern as much as they illustrate noise interference at any point in time. There would be no packets in error if there was no packet flow, IYSWIM. More important is the proportion of packets (or cells or frames) in error, measured as a percentage of those transmitted and received. That metric would capture the relative noise on the line along the time domain. The task then is to identify any variance in the distribution of errors across time.
cheers, a
-
The spikes of errors could be misleading. They primarily record the packet flow on your connection as a function of time. The spikes are indicative of your internet usage pattern as much as they illustrate noise interference at any point in time. There would be no packets in error if there was no packet flow, IYSWIM. More important is the proportion of packets (or cells or frames) in error, measured as a percentage of those transmitted and received. That metric would capture the relative noise on the line along the time domain. The task then is to identify any variance in the distribution of errors across time.
So, out of this lot, what data would be more beneficial in trouble-shooting, instead of or as well as the data currently being plotted:-
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 5654 Kbps, Downstream rate = 32148 Kbps
Path: 0, Upstream rate = 5795 Kbps, Downstream rate = 29624 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 4.1 5.7
Attn(dB): 0.0 0.0
Pwr(dBm): 12.3 6.3
VDSL2 framing
Path 0
B: 63 175
M: 1 1
T: 64 39
R: 16 12
S: 0.0687 0.9635
L: 9312 1561
D: 469 1
I: 80 94
N: 80 188
Counters
Path 0
OHF: 68852985 1057147
OHFErr: 3887 587
RS: 334919681 1664228
RSCorr: 4855931 273
RSUnCorr: 140410 0
Path 0
HEC: 39871 0
OCD: 0 0
LCD: 0 0
Total Cells: 92094052 0
Data Cells: 24616994 0
Drop Cells: 0
Bit Errors: 0 0
ES: 605 921
SES: 46 0
UAS: 65 65
AS: 228032
Path 0
INP: 3.00 0.00
PER: 3.29 9.39
delay: 8.00 0.00
OR: 58.20 27.25
Bitswap: 66317 10130
Total time = 1 days 14 hours 24 min 55 sec
FEC: 7935219 484
CRC: 11750 978
ES: 605 921
SES: 46 0
UAS: 65 65
LOS: 4 0
LOF: 5 0
Latest 15 minutes time = 9 min 55 sec
FEC: 2970 2
CRC: 5 2
ES: 2 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 3950 1
CRC: 1 3
ES: 1 3
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 14 hours 24 min 55 sec
FEC: 1464425 69
CRC: 283 144
ES: 76 142
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 1756226 86
CRC: 1197 242
ES: 155 230
SES: 3 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Since Link time = 2 days 15 hours 20 min 31 sec
FEC: 4855931 273
CRC: 3887 587
ES: 358 561
SES: 12 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
The montage of the graphs using some of that data is attached
-
EDIT:
Oops, sorry, I was wrong.. the cell count (at least for my ATM connection) increases when the link is up but not being used (from the transmission of idle cells).. So the various error counters should be increasing too.. So your graphs do capture what is needed.
The Bit Error Rate (BER) would be the more widely accepted measure of the quality of a transmission channel. If it's not available directly then an estimation could probably be derived from other statistics. The three graphs (CRC from GUI, HEC from GUI and RSUnCorr from telnet) and two other graphs (FEC from GUI and OHFErr from telnet) are basically identical. Could they be combined to save screen space?
Something that makes it difficult to spot the distribution of errors in the time domain is the tick frequency used on the x-axis for the noise graphs. Every seven hours has an x-tick, whereas a tick on a factor of 24 (hours) would be more intuitive. i.e. an x-tick every 4, 6 or 8 hours. That way it would be easier to compare the error distributions across different days of the week.
cheers, a
The spikes of errors could be misleading. They primarily record the packet flow on your connection as a function of time. The spikes are indicative of your internet usage pattern as much as they illustrate noise interference at any point in time. There would be no packets in error if there was no packet flow, IYSWIM. More important is the proportion of packets (or cells or frames) in error, measured as a percentage of those transmitted and received. That metric would capture the relative noise on the line along the time domain. The task then is to identify any variance in the distribution of errors across time.
So, out of this lot, what data would be more beneficial in trouble-shooting, instead of or as well as the data currently being plotted:-
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 5654 Kbps, Downstream rate = 32148 Kbps
Path: 0, Upstream rate = 5795 Kbps, Downstream rate = 29624 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 4.1 5.7
Attn(dB): 0.0 0.0
Pwr(dBm): 12.3 6.3
VDSL2 framing
Path 0
B: 63 175
M: 1 1
T: 64 39
R: 16 12
S: 0.0687 0.9635
L: 9312 1561
D: 469 1
I: 80 94
N: 80 188
Counters
Path 0
OHF: 68852985 1057147
OHFErr: 3887 587
RS: 334919681 1664228
RSCorr: 4855931 273
RSUnCorr: 140410 0
Path 0
HEC: 39871 0
OCD: 0 0
LCD: 0 0
Total Cells: 92094052 0
Data Cells: 24616994 0
Drop Cells: 0
Bit Errors: 0 0
ES: 605 921
SES: 46 0
UAS: 65 65
AS: 228032
Path 0
INP: 3.00 0.00
PER: 3.29 9.39
delay: 8.00 0.00
OR: 58.20 27.25
Bitswap: 66317 10130
Total time = 1 days 14 hours 24 min 55 sec
FEC: 7935219 484
CRC: 11750 978
ES: 605 921
SES: 46 0
UAS: 65 65
LOS: 4 0
LOF: 5 0
Latest 15 minutes time = 9 min 55 sec
FEC: 2970 2
CRC: 5 2
ES: 2 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 3950 1
CRC: 1 3
ES: 1 3
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 14 hours 24 min 55 sec
FEC: 1464425 69
CRC: 283 144
ES: 76 142
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 1756226 86
CRC: 1197 242
ES: 155 230
SES: 3 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Since Link time = 2 days 15 hours 20 min 31 sec
FEC: 4855931 273
CRC: 3887 587
ES: 358 561
SES: 12 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
A ratio is needed, describing the number of [packets|cells|frames|bits] sent and received, and the number of them arriving at their destination in error.
Which data is trustworthy though? For your VDSL2 service, several of the crucial fields are unpopulated.
For an ADSL2+ connection, this is reported by xdslcmd..
Path 0
HEC: 64715 21
OCD: 0 0
LCD: 0 0
Total Cells: 2400611752 440438110
Data Cells: 13617798 3052399
Drop Cells: 0
Bit Errors: 5780721 1430
We can see that 2,400,611,752 (2.4e9) ATM cells were received. Each ATM cell has a 48 byte payload + 5 header bytes = 424 bit cell length. And there were 5,780,721 (5.8e6) bit errors.
5.8e6 / (2.4e9 * 424) = 5.7e-6 = Bit Error Rate (BER)
When talking about bit- or packet- error rates, the coefficient (in this case 5.7) is usually ignored since it's almost irrelevant when dealing with numbers of such magnitude. Generally only the exponent (10^-6) is quoted as the BER.
In common language, around six bits in every million bits received by my TalkTalk connection are in error (before any error correction is applied).
Monitoring on a minute-by-minute basis that BER ratio (5.7e-6 in the worked example above) may hold the key to tracking down time-dependent problems from impulse noise, IMVHO.
cheers, a
-
I have checcked a few PuTTy/Plink logs from the HG612 modem (not only my own) & in every case, Bit Errors has zero values.
I also had a look at xdslcmd bert --start 300 (5 minutes of monitoring):-
# xdslcmd bert --start 300
# xdslcmd bert --show
xdslcmd: BERT results:
BERT Status = RUNNING
BERT Total Time = 300 sec
BERT Elapsed Time = 40 sec
BERT Bits Tested = 0x000000003F5CA480 bits
BERT Err Bits = 0x0000000000000000 bits
:
:
:
:
:
# xdslcmd bert --show
xdslcmd: BERT results:
BERT Status = RUNNING
BERT Total Time = 300 sec
BERT Elapsed Time = 280 sec
BERT Bits Tested = 0x00000001BB885400 bits
BERT Err Bits = 0x0000000000000000 bits
# xdslcmd bert --show
xdslcmd: BERT results:
BERT Status = NOT RUNNING
BERT Total Time = 300 sec
BERT Elapsed Time = 300 sec
BERT Bits Tested = 0x00000001DB369980 bits
BERT Err Bits = 0x0000000000000000 bits
#
In my (not yet released) script updates, Error Seconds & Serious Error Seconds data is harvested, for now only DS & US Error Seconds being plotted.
However, for monitoring noise levels, I imagine changes in SNRM values are perhaps the most relevant?
In general, stable & quiet connections seem to comprise more or less straight line graphs (even recently monitored low speed connections over much longer distances appear very stable).
My own connection currently seems stable(ish) at 29.5Mb sync speed.
I have no explanation why it was unstable for a few days & returned to relative stability again as no repair work was carried out (unless my connection simply prefers wet & cold weather).
Interleaving, INP & delay have been turned back on at fairly low levels so various error types are now visible (e.g. RSCorr), while other error types have diminished.
I see that both Josh's & BlackEagle's connections suffer from many "error" spikes, sudden changes in SNRM levels, stuck sync speeds & quite high levels of Interleaving etc.
For both those connections (as when mine plays up), no real timed pattern has been detected.
It is possible that bursts of interference/errors could occur anywhere between the 1 minute sampling, with only the cumulative error counts being visible in the harvested data.
I believe Routerstats can log data right down to 5 second intervals.
I can ALMOST get Routerstats working with the HG612, but it incorrectly alternates between reporting SNRM & sync speed values in the same SNRM graph.
If anyone wants to have a go at setting Routerstats up, the login URL for the HG612's GUI data is http://192.168.1.1/html/status/xdslStatus.asp
The SNRM & Output Power values need dividing by 10 to display correct values to 1 decimal point.
I might some time have a go at converting my scripts to run continuously, harvesting data at much shorter intervals, as an alternative to only running them every minute via Windows Task Scheduler.
-
Hi BE, yeah I can ALMOST get RS logging correctly, apart from the bouncing issue !!
Telnet would seem the better option as the ini file can easily be modified to replace the adslctl command with xdslcmd. Unfortunately, the HG612 logs into the atp shell so unless we can either persuade John to include an "sh" command to get to the correct shell, or find an atp command that returns the same data its a no go.
Unless its possible to embed a carriage return into the command line passed via telnet to the router. ?
-
Hi BE,
Hi BE, yeah I can ALMOST get RS logging correctly, apart from the bouncing issue !!
Telnet would seem the better option as the ini file can easily be modified to replace the adslctl command with xdslcmd. Unfortunately, the HG612 logs into the atp shell so unless we can either persuade John to include an "sh" command to get to the correct shell, or find an atp command that returns the same data its a no go.
Unless its possible to embed a carriage return into the command line passed via telnet to the router. ?
"Echoing" commands from a batch file includes a carriage return, as does "Typing" a one line text file.
For whatever reason, "Typing" a text file seems more reliable than "echoing":-
rem *************** Login using PERMANENT login files ***************
(sleep 2^
& type %LOGIN_FOLDER%\login1.txt & sleep 1^
& type %LOGIN_FOLDER%\login2.txt & sleep 1^
& type %LOGIN_FOLDER%\login3.txt & sleep 1^
& echo xdslcmd info --stats & sleep 1^
& echo exit & sleep 1 & echo exit & sleep 2)^
^| Plink -telnet -P 23 192.168.1.1>> %WORKING_FOLDER%\data$$
login1.txt just contains the one word admin
login2.txt just contains the one word admin
login3.txt just contains the one word sh
Is that anything like what you mean by embedding a carriage return?
-
Sort of BE. The ini file section contains this
LoginTelnet=1
TelnetUsername=admin
TelnetPrompt=#
TelnetCmd=adslctl info --stats
It depends on how RS sends this data over telnet. If you were to change the last line to sh then that would drop to busybox, but wouldn't issue a further command (RS must put a carriage return on the end itself). If you could send the command sh chr(13) xdslcmd info --stats then that would work, it is how to get the chr(13) embedded and sent as RS appears to type the command to the telnet session, therefore the actual characters will be typed, not the <CR>.
-
Haha. got it plotting an RX SNR graph via telnet !!! :P :P
How to do it.........
1) setup telnet login on experimental page as login with Admin and password.
2) Tick "Wait for password request"
3) Untick "Enable telnet...."
4) Change adslctl info --stats in the drop down box to xdslcmd info --stats.
5) Apply and save.
6) Start routerstats logging.
7) Goto the telnet page and click on the terminal tab.
8) Change "user defined1" to sh.
Routerstats should now go to the busybox shell and start logging downstream SNR !!
-
I have checked a few PuTTy/Plink logs from the HG612 modem (not only my own) & in every case, Bit Errors has zero values.
I also had a look at xdslcmd bert --start 300 (5 minutes of monitoring):-
# xdslcmd bert --start 300
# xdslcmd bert --show
xdslcmd: BERT results:
BERT Status = RUNNING
BERT Total Time = 300 sec
BERT Elapsed Time = 40 sec
BERT Bits Tested = 0x000000003F5CA480 bits
BERT Err Bits = 0x0000000000000000 bits
:
# xdslcmd bert --show
xdslcmd: BERT results:
BERT Status = RUNNING
BERT Total Time = 300 sec
BERT Elapsed Time = 280 sec
BERT Bits Tested = 0x00000001BB885400 bits
BERT Err Bits = 0x0000000000000000 bits
# xdslcmd bert --show
xdslcmd: BERT results:
BERT Status = NOT RUNNING
BERT Total Time = 300 sec
BERT Elapsed Time = 300 sec
BERT Bits Tested = 0x00000001DB369980 bits
BERT Err Bits = 0x0000000000000000 bits
#
That's a shame.. The bit error counter field from the BERT tests is populated in xdslcmd output from ADSL connections, but not for VDSL2 connections. Yet another Broadcom quirk.
With some basic arithmetic we could derive something close to the raw bit error rate from the other error counters.
The trouble with the error counters returned by the Reed Solomon decoder is that they somewhat mask the extent of the errors on the line, especially bursts of errors, as you might expect from impulse noise.
Only when the error count for a codeword exceeds the correction capabilities of the decoder is the error state categorised differently (RSUnCorrectable instead of RSCorrectable). This doesn't tell us the exact number of errors in a RS codeword, a number which we would need to calculate the Bit Error Rate.
At a guess, the Bit Errors counter has been deliberately disabled in a kludge by Broadcom to maintain performance in VDSL2. Perhaps at VDSL2 speeds, maintaining a raw bit error count would place too great a load on the DSP core which could badly affect performance.
Discovering whether a codeword is correctable by the RS decoder, with an error count that is within the correction capabilities of the decoder (i.e with no more than (n-k)/2 symbol errors) wouldn't be as demanding on resources as actually counting every single bit in error.
As soon as ((n-k)/2) + 1 symbol errors are discovered in a codeword by the RS decoder, with Broadcom's kludge applied, the decoder simply abandons the decoding, and returns an unquantified 'uncorrectable error' message to the caller and the RSUnCorr counter is increased by one.
The thinking is that once the decoder has discovered (n-k)/2 errors in a codeword - the maximum number of errors it can correct - it is pointless wasting CPU resources counting any further errors beyond that point (since the decoder can't correct them any way). The kludge, if that is what it is, would result in the error counters being blunted in precision to the length of the RS codeword (255 bytes?)
In my (not yet released) script updates, Error Seconds & Serious Error Seconds data is harvested, for now only DS & US Error Seconds being plotted.
However, for monitoring noise levels, I imagine changes in SNRM values are perhaps the most relevant?
In general, stable & quiet connections seem to comprise more or less straight line graphs (even recently monitored low speed connections over much longer distances appear very stable).
My own connection currently seems stable(ish) at 29.5Mb sync speed.
I have no explanation why it was unstable for a few days & returned to relative stability again as no repair work was carried out (unless my connection simply prefers wet & cold weather).
Interleaving, INP & delay have been turned back on at fairly low levels so various error types are now visible (e.g. RSCorr), while other error types have diminished.
I see that both Josh's & BlackEagle's connections suffer from many "error" spikes, sudden changes in SNRM levels, stuck sync speeds & quite high levels of Interleaving etc.
For both those connections (as when mine plays up), no real timed pattern has been detected.
Maybe if the error counter data from each 24 hour period was over-plotted (and plotted with a vector-based format that allows for zooming), it could help to identify whether the noise was confined to the day (or night), and during certain hours thereof. We might expect to find that noise from RFI ingress wains during the wee hours (e.g. 1am-6am) since many domestic electrical appliances are powered off during that period.
It is possible that bursts of interference/errors could occur anywhere between the 1 minute sampling, with only the cumulative error counts being visible in the harvested data.
The error counters appear to be updated every second.
I believe Routerstats can log data right down to 5 second intervals.
I can ALMOST get Routerstats working with the HG612, but it incorrectly alternates between reporting SNRM & sync speed values in the same SNRM graph.
If anyone wants to have a go at setting Routerstats up, the login URL for the HG612's GUI data is http://192.168.1.1/html/status/xdslStatus.asp
The SNRM & Output Power values need dividing by 10 to display correct values to 1 decimal point.
I might some time have a go at converting my scripts to run continuously, harvesting data at much shorter intervals, as an alternative to only running them every minute via Windows Task Scheduler.
The PhD thesis of Nedko Nedev (Univ of Edinburgh, 2003) at [1] is on the Analysis of the Impact of Impulse Noise in Digital Subscriber Line Systems. Nedev speaks of VDSL in the future tense, but his findings are probably just as relevant today.
Nedev defines impulse noise as...
Impulse noise is a non-stationary stochastic electromagnetic interference which consists of random occurrences of energy spikes with random amplitude and spectral content. The causes of impulse noise on the telephone line are diverse and vary from telephone on/off-hook events, through noise from home, office, and industrial electrical appliances, and transport vehicles, to atmospheric noise from electrical discharges.
We could expect all of those 'events', except perhaps the last (natural atmospheric noise) to reduce during the night. Plotting the error rate (however it is defined) against the 24 hour clock should highlight any correlation of impulse noise and the hour of the day.
Nedev goes on to characterise impulse noise as...
The salient statistics of impulse noise include inter-arrival times, impulse durations, impulse amplitudes, and frequency spectrum
We can't measure several of those statistics using just the diagnostic data from the modem. We have no way of measuring the amplitudes of the noise impulses. And although the QLN data provides us with a frequency analysis of line noise, it is only a spectral snapshot of line noise from the initialisation phase. While very useful, it is limited to gauging time-invariant interference such as noise from crosstalk.
However, to a somewhat blunted degree of precision, the error counters from the modem could be used to estimate the inter-arrival times of impulse noise, and the impulse durations (to a precision of a second or two). Not sure how useful that could be. Interesting topic really ???
cheers, a
[1] http://www.era.lib.ed.ac.uk/bitstream/1842/1366/1/Nedev.pdf
-
Little update, the REIN Engineer came today.
He inspected the house with his RF 444B Tester, and found a problem with the power supply for the modem, I heard the noise and it wasn't normal.
He put his tester against the drop wire just before the NTE5 and we heard the radio, he said this was quite normal, but installed a RF3 filter to reduce the RF interference.
So he installed the Filter, changed the modem and power supply and gave it the all clear, he didn't click that I originally was supplied with the ECI modem but installed a new Rev.3 HG612 anyway, I had the Rev.1 which he said were known for overheating and loosing sync, he also ran some tests with his JDSU and everything came back clear,
Lastly he went to the cab and made sure everything was fine there, and off he went.
No change in sync, but I now need a profile reset, I have requested one so should be within 24 hours.
Hopefully the power supply is what was causing the problems and things improve, really nice guy I must add!
I didn't expect anyone coming today as my isp never informed me. hence why I still had the HG612 connected :lol:
Watch this space.
Cheers,
Josh
-
No change in sync, but I now need a profile reset, I have requested one so should be within 24 hours.
Hopefully the power supply is what was causing the problems and things improve, really nice guy I must add!
That all sounds pretty positive, Josh.
I'm not too sure about the DLM reset within 24 hours though, unless the 'rules' have been changed.
I believe the DLM reset should have been done while the engineer was still on site to request it & also check the result of the reset.
You might need another engineer's visit just to organise the DLM reset.
I presume the first task after the engineer left was to unlock the new HG612?
It will be interesting to see how the connection performs over the next week or so (once the reset has been done).
-
That's what I thought, in the past when I've had a reset it's been on site.
They have done a reset remotely before so it is possible,
just something they don't normally do/request.
and yeah, the modem was unlocked as soon as he left ;D
Cheers,
Josh
-
Quick question for Black Sheep, is it normal to hear the radio coming down your drop wire? Using the RF Tester of course.
Thank you,
Josh
-
Anyone?
-
Anyone?
^-^ No, that is an abnormal situation. :no:
Just out of interest, which radio station was it?
-
I am not 100% sure,
I believe it was FM radio, maybe radio 2.
Cheers,
Josh
-
I believe it was FM radio, maybe radio 2.
:hmm: Hmm . . . Let's consider that.
Radio 2, on Band II (i.e. VHF), can be found in the 88 - 91 MHz frequency range.
ADSL uses up to 256 tones, each 4.3125 kHz wide. Maximum frequency 1.104 MHz.
ADSL2 uses up to 256 tones, each 4.3125 kHz wide. Maximum frequency 1.104 MHz.
ADSL2+ uses up to 512 tones, each 4.3125 kHz wide. Maximum frequency 2.208 MHz.
VDSL2 (profile 17a) uses up to 4095 tones, each 4.3125 kHz wide. Maximum frequency 17.660 MHz.
So there is no possibility of frequency conflict. However it would be a good idea to minimise the presence of spurious signals being fed into the xDSL port of the modem. Hence the fitting of the BT80B-RF3 to the line.
-
I believe it was FM radio, maybe radio 2.
:hmm: Hmm . . . Let's consider that.
Radio 2, on Band II (i.e. VHF), can be found in the 88 - 91 MHz frequency range.
ADSL uses up to 256 tones, each 4.3125 kHz wide. Maximum frequency 1.104 MHz.
ADSL2 uses up to 256 tones, each 4.3125 kHz wide. Maximum frequency 1.104 MHz.
ADSL2+ uses up to 512 tones, each 4.3125 kHz wide. Maximum frequency 2.208 MHz.
VDSL2 (profile 17a) uses up to 4095 tones, each 4.3125 kHz wide. Maximum frequency 17.660 MHz.
So there is no possibility of frequency conflict. However it would be a good idea to minimise the presence of spurious signals being fed into the xDSL port of the modem. Hence the fitting of the BT80B-RF3 to the line.
Thanks for the @burakkucat,
All I remember is, he placed the aerial from the 444B RF Tester on the drop wire just before the NTE5, and we could both clearly hear a radio station.
He said it would be a good idea to fit an RF3 filter, and said it should be ok now.
He also mentioned that REIN doesn't normally effect VDSL,
He told me about a time a faulty sky box was giving off REIN and a whole street on ADSL was effected and everyone on VDSL was fine.
Cheers,
Josh
-
He also mentioned that REIN doesn't normally effect VDSL,
He told me about a time a faulty sky box was giving off REIN and a whole street on ADSL was effected and everyone on VDSL was fine.
Hmmm.
VDSL2 uses the same lower frequencies as ADSL1 through to ADSL2+ along with even higher frequencies.
Unless standard faceplate filtering for VDSL2 connections is far, far superior to standard filtering for ADSL connections, I would take such a broad statement with more than just a pinch of salt.
Now, if the VDSL2 cabinet was only a few metres from everyone in that street & they had really high SNR & SNRM levels, really low attenuation levels & really high attainable rates of say 130Mb or so, using brand new & really good condition copper cables, then maybe the engineer's statement could have been true.
I suspect if everyone in that street was the same distance from the cabinet as I am, REIN from that Sky box might have had a bit of an effect on the VDSL2 connections.
So, the engineer's statment may have been the truth, but perhaps not the whole truth ???
-
Hope this is helpful...after suffering from REIN for many years and using a Netgear to artificially keep my target snr around 4dB I have managed to keep a 3.5 meg profile with DLM on a 54dB attenuation line...I decided to risk "Faster Total Broadband" with BT and seen (on his JDSU) 19meg coming in at the test socket on Friday morning...
I haven't unlocked their thingy majig with asbokids firmware yet but am getting an 18meg profile and around about 16meg wirelessly downstairs... I live about a mile and a half (following the poles) from the green PCP....is this a story with a happy ending? :o
-
Hi strontium90,
I live about a mile and a half (following the poles) from the green PCP....is this a story with a happy ending? :o
Well, that's around 2400 metres, so as long as you can maintain those speeds, with a stable connection, it looks pretty happy to me :)
We have seen evidence of those sort of speeds over 1600m connections (very stable connections though).
I don't suppose the engineer mentioned the line length as reported by his JDSU did he?
Paul.
-
Forgot to add this,
The REIN Engineer that came also told me my line length is 900m from the cab according to his JDSU,
But that can't be true, it's no where near that length! ???
-
Hope this is helpful...after suffering from REIN for many years and using a Netgear to artificially keep my target snr around 4dB I have managed to keep a 3.5 meg profile with DLM on a 54dB attenuation line...I decided to risk "Faster Total Broadband" with BT and seen (on his JDSU) 19meg coming in at the test socket on Friday morning...
I haven't unlocked their thingy majig with asbokids firmware yet but am getting an 18meg profile and around about 16meg wirelessly downstairs... I live about a mile and a half (following the poles) from the green PCP....is this a story with a happy ending? :o
3.5 to 18 is a great difference, as long as your line is stable, id be happy :)
-
Update - 17/08: Had an Engineer here yesterday, he did some tests and concluded there are issues at the cab, they wanted to do a lift and shift but some test failed so they wasn't able to do so, he has escalated the issue and should be picked up within a few days, speeds are down to just 19Mbps at the moment so something isn't right.
The line AC balance is 60, so that is good. And he confirmed the distance is 700M to the cab.
He wasn't happy with something and said it will be sorted out and for me not to worry, it's been a long process, these issues have been there since early December last year.
Fingers crossed it gets resolved sooner than later.
Cheers,
Josh
-
Update - 17/08: Had an Engineer here yesterday, he did some tests and concluded there are issues at the cab, they wanted to do a lift and shift but some test failed so they wasn't able to do so, he has escalated the issue and should be picked up within a few days, speeds are down to just 19Mbps at the moment so something isn't right.
He wasn't happy with something and said it will be sorted out and for me not to worry, it's been a long process, these issues have been there since early December last year.
Fingers crossed it gets resolved sooner than later.
Fingers crossed indeed.
Did the engineer confirm whether he was talking about the old PCP or the new fibre cab?
My guess would be the old PCP.
I am starting to wonder though if there could be a potential issue with fibre cabs equipment overheating under certain conditions.
They do need cooling fans anyway, but what if the fans don't switch on soon enough e.g. at times when equipment is hot due to peak demand and/or during warm & dry weather?
-
Update - 17/08: Had an Engineer here yesterday, he did some tests and concluded there are issues at the cab, they wanted to do a lift and shift but some test failed so they wasn't able to do so, he has escalated the issue and should be picked up within a few days, speeds are down to just 19Mbps at the moment so something isn't right.
He wasn't happy with something and said it will be sorted out and for me not to worry, it's been a long process, these issues have been there since early December last year.
Fingers crossed it gets resolved sooner than later.
Fingers crossed indeed.
Did the engineer confirm whether he was talking about the old PCP or the new fibre cab?
My guess would be the old PCP.
I am starting to wonder though if there could be a potential issue with fibre cabs equipment overheating under certain conditions.
They do need cooling fans anyway, but what if the fans don't switch on soon enough e.g. at times when equipment is hot due to peak demand and/or during warm & dry weather?
He didn't say, he just wasn't happy with how things were performing,
He checked the pairs underground going to the cab and concluded that wasn't the problem.
He got to the cab and found there is an issue there, he wanted to do a lift and shift but he was unable to do this because OR currently have a system problem with performing a port swap for TT lines.
He said it should get picked up soon, I hope tomorrow.
And in regards to the heat coming from the cabs, I always here the fans cooling the systems but this is during the day, I guess like you say at busy times it could actually overheat and cause problems for everyone?
The weather is getting warmer and we both know our lines perform better when it's cold or wet. It could again just be a coincidence but who knows...
Cheers,
Josh
-
UPDATE 6/06/2012
Hi guys,
a couple of weeks back I had an Engineer visit, he wanted to go a lift and shift at the PCP, he wasn't able to do so.
But today that was done I believe, I wasn't at home so could't comment on what has been done, from what I was told by TalkTalk, a new part of copper for the cab has been installed today, and a lift and shift has been done also.
A line reset wasn't done, I have no idea why, but for the next few days I'll watch the errors, now the HG612 has been connected again.
Here are some stats, notice my attainable rate has gone up, and I'm now back on the 40M profile.
Cheers,
Josh
-
UPDATE 6/06/2012
A line reset wasn't done, I have no idea why, but for the next few days I'll watch the errors, now the HG612 has been connected again.
It SHOULD have been done. Some repair work was carried out, your attainable rate is higher than 40Mb, you have SNRM to spare, yet your sync speed is only 22400k (22398k actually).
That MUST be a capped DLM profile that needs resetting immediately, never mind in a few days.
Were you expecting to be capped at 2Mb Upstream? Your connection appears to be capable of more.
How does your pbParams data compare with previous data, especially attenuation & SNR?
-
Hi Paul, I know it should have, I wasn't able to request it, and trust me I would have.
Here is a before and after.
Please tell me, are there any improvements?
Cheers,
Josh
Edit: and yes I was expecting the 2 meg cap on upstream, 40/2 profile.
-
Well, you were syncing at 6Mb US back in May, at a lower DS sync speed.
The fact that you have reverted to a capped 2Mb US may have assisted in upping your DS attainable rate (to some extent).
SNR & SNRM appear to have improved, possibly due to the L & S and/or replaced copper (presumably the cabinet jumper cables?)
Could you not request/insist upon a DLM reset/recalc now via your ISP anyway?
I believe there may have been a recent slight relaxation on the requirement for an engineer to actually be present.
-
Could you not request/insist upon a DLM reset/recalc now via your ISP anyway?
Yes you can. OCE on talktalk members can pass it back to networks as low sync speed & then networks will request BTOR to reset DLM. Thats how it worked for me anyway ;)
-
Could you not request/insist upon a DLM reset/recalc now via your ISP anyway?
Yes you can. OCE on talktalk members can pass it back to networks as low sync speed & then networks will request BTOR to reset DLM. Thats how it worked for me anyway ;)
Thanks for that mate! :)
-
@JoshShep,
Any news of progress, DLM resets, or deterioration since your last message?
-
@JoshShep,
Any news of progress, DLM resets, or deterioration since your last message?
It's not good news Bald_Eagle, basically I have been told my line is running at the maximum speed it will handle...
Even though I had a stable speed on 32Mbps for over 3 months a while back.
Currently syncing at just 22398 kbits/s
I don't know what to do now, my attainable rate is still around 40Mbps at 9:45 at night, and errors are at a minimal.
I'm a little disappointed to say the least. :(
-
@JoshShep,
Any news of progress, DLM resets, or deterioration since your last message?
It's not good news Bald_Eagle, basically I have been told my line is running at the maximum speed it will handle...
Even though I had a stable speed on 32Mbps for over 3 months a while back.
Currently syncing at just 22398 kbits/s
Oh dear. That's terrible news :(
I was told that when DLM had capped my connection at 24Mb sync speed.
I don't know what to do now, my attainable rate is still around 40Mbps at 9:45 at night, and errors are at a minimal.
I'm a little disappointed to say the least. :(
What are your ongoing & current stats graphs looking like these days?
If they are pretty much error-free, that is surely sufficient grounds to get DLM reset.
If they are full of massive errors and/or noise interference, then it must be back to the REIN investigation etc.
Your GUI screenshot shows better stats than mine, over a longer period, yet my sync speed is currently 28492 k, against attainable rate averaging around 34000.
FWIW, I have attached my ongoing stats over the latest 30 days.
The differences since the repair can be clearly seen, although sync speed does seem a shade low & US Line Attenuation increased when my band plan tones were adjusted (2 days prior to the engineer's visit).
I have mentioned this to Alex R from Plusnet, (he now works in the "Complaints" section instead of "Faults" section, but he is still personally monitoring my connection's progress).
At least I won't need to repeat all my issues when I make my formal complaint about it taking 11 months to restore my connection's stability (if not its initial speeds).
You can't give up the fight just yet, surely?
-
Also FWIW, I have attached my current stats for comparison purposes.............
-
I have not been running the graphs sadly, only because when I show them to OR Engineers or my ISP, they just tell me, they can see all these stats already because they have similar tools running and monitoring my connection, basically they take no interest in them.
Just to ask how long does it take for DLM to make changes to you profile? And is an Engineer visit always required when you have been capped?
I'll start running the stats again though, so I can compare the stats now the work has been done in the PCP.
PS. How can I update my stats so they look like yours, and give me more information?
Cheers
-
I have not been running the graphs sadly, only because when I show them to OR Engineers or my ISP, they just tell me, they can see all these stats already because they have similar tools running and monitoring my connection, basically they take no interest in them.
So, everyone can see the same stats, yet supposedly nothing is wrong?
Assuming there are no outstanding physical line problems, is the REIN investigation still a possibility, or has that been cancelled now?
Just to ask how long does it take for DLM to make changes to you profile? And is an Engineer visit always required when you have been capped?
Following repair works, some users (not many at all) have seen DLM take positive action within a few days, speeds increasing bit by bit in "capped" increments until the highest stable speed has been found.
Others have seen DLM stuck at low sync speeds with high attainable rates for weeks/months & some have simply requested & actually received a DLM reset - via their ISP, but BT OR have to do it.
I believe BT OR are now a little more relaxed in not INSISTING an engineer must be present, although in your case it may be helpful for witness/evidence purposes of what your line CAN achieve (as a belt & braces approach as obviously your own graphs/stats are just ignored).
Worst case scenario for you would be that the line is physically in "good" condition & any "problems" are caused by external means, outside BT's direct control.
Wasn't the REIN issue more or less tracked down at one point?
I'll start running the stats again though, so I can compare the stats now the work has been done in the PCP.
Your current error counts are probably only low due to the really low sync speed cap i.e. the connection isn't being pushed to its max.
However, prolonged monitoring may still help to determine the sources of interference/noise/abrupt disconnections etc.
It's a shame you didn't continue monitoring your stats as you may now be back to square one again.
PS. How can I update my stats so they look like yours, and give me more information?
That will all be in the next release. I am still testing/attempting to resolve an occasional issue of a few minutes of missing stats that only seems to occur during overnight virus scanning when the scanning program seems to hog all the PC's resources, spanning over a few minutes at a time.
I could email test versions for you to try if you were willing to provide detailed feedback as & when necessary.
(An couple of error / information log files are also created alongside the ongoing modem_stats.log)
-
Josh, afaik, TT cannot see those stats, certainly not in the detail which you can graph them. Having reviewed your thread on the TTFM forum, the answer you received from OCE_Nathan whilst only a quote from networks, is to say the least, a little disappointing.
Do you have any graphs of the period when your connection was significantly faster ? Hopefully you do.
I would be inclined to ask why BTOR have said this is the fastest speed that the line can run at. Is it length, Aluminium etc etc ??
Sadly, TT are constrained a little by what they can do and see as an Infinity reseller, however as a customer of theirs it is up to them to liase with BTOR on your behalf. See my thread on TTFM here (http://www.talktalkmembers.com/forums/showthread.php?t=79418) where networks successfully intervened on my behalf in spite of OR re-clamping my line.
-
Good news guys, had an unexpected engineer here this morning, he came at 9AM and he's just left.
He said there is a "loop" somewhere but tracking it is the problem, climbed up the pole, and tested the pairs from up there, no problems...
Came back into the house, snipped a little wire off and hay presto fault is now cleared.
I don't know what he did exactly, don't think he did, all we could think of is maybe there was a little snip in the copper wire just before the NTE5 and that's what was bringing the speeds down so much.
Anyway, he went to the cab, made sure the speed from the cab is the same I'm getting from the premises, yeah all good.
Phoned home, got a reset and here are the results.
I know it all sounds a little too good to be true, and too easy for all the work that's been carried out, and I know it's still early days and of course DLM will make adjustments to the profile in the next 48 hour or so, but for now I'm keeping my hopes high as I've never seen these speeds before on my line.
And just to be safe, I'm keeping the ECI modem in for the next few days, just to see how things go, and while the changes are made. hopefully the line settles above the 35Mbps I was predicted.
:drink: guys! :)
Josh
-
That's looking pretty good Josh.
Did the engineer mention what had prompted today's unexpected visit?
Your speedtest.net test suggests you are very close to the full whack for a 40Mb connection.
As a TalkTalk user, are you able to see your IP Profile/BRAS Rate anywhere?
The BT speed tester would report an IP Profile of 38.72Mbps for a capped sync speed of 39999k (96.79% of sync speed to 2 d.p.) .
-
Sounds like the engineer removed the bell wire
-
:no: No, I don't think that would have been it.
Remember the engineer was working on the Openreach side of the NTE5/A. The "bell wire" only "appears" at the EU side of the NTE5/A, from the junction of the capacitor and resistor connected in series across the pair.
It reads as if there were defective connections where the incoming service cable attached to the NTE5/A -- possibly the IDC type -- and removing them both, trimming the ends and remaking the connections cleared the fault.
-
That's looking pretty good Josh.
Did the engineer mention what had prompted today's unexpected visit?
Your speedtest.net test suggests you are very close to the full whack for a 40Mb connection.
As a TalkTalk user, are you able to see your IP Profile/BRAS Rate anywhere?
The BT speed tester would report an IP Profile of 38.72Mbps for a capped sync speed of 39999k (96.79% of sync speed to 2 d.p.) .
It is Paul, all I can think of is when the new drop wire was installed, and the cable is stripped to get the pairs for the connection, maybe he snipped a little too much into the pairs? And actually cut a part of the cable?
Because he did stipp quite a lot of new cable trough to make a clean connection,
Either that or when he climbed the pole to check things out he actually fixed something without knowing?
Plus it could also be from a few weeks ago when the lift and shift was done, it could have actually fixed and all I needed was in fact the DLM reset because of the capped profile.
The Engineer said it was showing a loop error, and when he phoned for the reset he was asked how he fixed it, he just laughed and said I don't know I must have magic hands all I did was strip a little new cable through.
Anyway it may have in fact done the trick. :)
I am tempted to put the HG612 back in and see the results;
But I'm going to wait a few days to see how things go.
And finally no sadly there is no way of showing your ip profile on TalkTalk, I just get an error from the BT speedtester site.
Cheers,
Josh
-
:no: No, I don't think that would have been it.
Remember the engineer was working on the Openreach side of the NTE5/A. The "bell wire" only "appears" at the EU side of the NTE5/A, from the junction of the capacitor and resistor connected in series across the pair.
It reads as if there were defective connections where the incoming service cable attached to the NTE5/A -- possibly the IDC type -- and removing them both, trimming the ends and remaking the connections cleared the fault.
Think you could be right mate! :)
-
Think you could be right mate! :)
:thumbs: Cats and dogs (even those wearing headphones) can be friends! :friends: