Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: mikehiow on July 30, 2013, 09:37:10 AM
-
I lost sync yesterday, at which point the phone died too. Currently awaiting an engineer.
What got me curious though was that the fttc modem is still attempting to sync jumping between initialising and establishing link. If I unplug the modem it just sits there on no signal.
I'm just curious how that's possible? What does the modem look for in the first instance before trying sync? Is it just some resistance on the line or what?
Sent from my HTC One using Tapatalk 4 Beta
-
What does the modem look for in the first instance
Power=On? :lol:
-
DSL will work to a fashion down 1-leg of the 2-wire circuit, but the PSTN (Phone) requires both legs to be intact. It sounds to me like there's an extremely high HR on either the wires or the equipment, which is allowing the router to attempt a handshake, but not providing full synch. :)
-
I agree with BS, your router is attempting the handshake, but at some point it failing one of the stages to set up the full DSL link
http://www.kitz.co.uk/adsl/adsl_technology.htm#sync
Ive watched your thread with interest because some of the things you were experiencing sounded so similar to my own problems, but BE & BS are more capable than me when it comes to FTTC technology and you are in the best of hands with them.
Like you Ive also experienced FECs with interleaving switched off... noise bursts with no attributable source, Ive seen changes in attenuation and although I havent experienced downstream loss of speed, I reckon I would have lost some if I didnt have a large amount of 'spare' SNRm to start with.
Its also ironic for the first time yesterday, I too started seeing issues with the physical phone line and also for the first time seeing a signs that my issue could be attributable to a HR fault.
With your phone line being down you should get some sort of priority, Im still waiting to hear when my next visit will be. Good luck, I hope that the engineer finds where your problem is and you are soon back up and running.
-
What is HR? Im not convinced this is related to my broadband fault - since moving the modem back to the master socket the attenuation dropped quite a lot and my speeds have returned to normal.
Of course that's not to say my speeds weren't a mixture of two issues.
There was an OR engineer outside my house this morning pulling a new line for someone - I wonder if some work was done in the cab for that yesterday and perhaps mine was knocked.
Sent from my HTC One using Tapatalk 4 Beta
-
HR = High resistance. With current flowing down a wire you want low resistance. If the wire is corroded, or trapped in a lid (thus lessening the wires cross-section -- making it thinner), then there is a higher than usual resistance impeding current flow.
The problem with your BB is related to the problem with your phone, as they both utilise the same pair of wires. We (Kitz and I) were merely pointing out how your router is attempting to synch, whilst your phone is completely dead. All this is based on what you are telling us in your own words. :)
-
I think we've crossed wires. Kitz was referring to my other thread where I was banded to 60mbps with some odd characteristics (like the FEC count with interleaving off). That's what I was responding to when suggesting my broadband issue isn't related to this incident (the phone and VDSL being down)
Thanks for clarifying what HR stands for - should have been obvious really.
Sent from my HTC One using Tapatalk 4 Beta
-
Hi did you have any big thunderstorms when this happened ?
-
Mentioning thunderstorms, we had quite a prolonged spell of them yesterday.
Their effect can be seen in the attached 2 day montage.
Strange thing is though, how DS SNRM started to fluctuate at around 23:00 last night (quite a while after the thunderstorms had passed by) & has continued to do so since.
I forced a modem resync this morning & shortly afterward a modem reboot.
I also completely power cycled the modem on returning from work this evening.
As a consequence, my connection has now lost use of the D2 band again & DS sync speed is down to 17571 Kbps & DS SNRM still continues to fluctuate >:( >:( >:(
-
Actually, my original post wasn't just a joke, it was observation. The modem does not even need anything to be connected to the DSL port for it to attempt connection. As I write this I have another DSL modem (HG622) sitting alongside me, powered up, but not connected to anything at all. The DSL light is flashing as it 'attempts' to sync.
If you think about it, this is by design. The modem has no way of knowing (for sure) when or whether a (temporary) line fault might resolve itself. Is it better for it to keep trying, in the hope that sooner or later it will be sucessful, or just sit there waiting for somebody else to do something? These things are supposed to run 24/7 unattended, so I would suggest that the former strategy is at least understandable.
-
Watching the HG612's GUI on a live connection, it seems to refresh the data roughly on a 10 second cycle, so that's perhaps how regularly it attempts to sync whenever anything is connected to it, even if a DSL connection is unobtainable at the time.
-
Sync reappeared by its self this morning. 35/13 with attainable sat just a little bit higher. Interleaving sat at 900/300.
I don't think an engineer has visited yet as the phone is still out. I just hope it doesn't take ages for the speed/interleaving to return once the fault has been fixed.
Sent from my HTC One using Tapatalk 4 Beta
-
Actually, my original post wasn't just a joke, it was observation. The modem does not even need anything to be connected to the DSL port for it to attempt connection. As I write this I have another DSL modem (HG622) sitting alongside me, powered up, but not connected to anything at all. The DSL light is flashing as it 'attempts' to sync.
If you think about it, this is by design. The modem has no way of knowing (for sure) when or whether a (temporary) line fault might resolve itself. Is it better for it to keep trying, in the hope that sooner or later it will be sucessful, or just sit there waiting for somebody else to do something? These things are supposed to run 24/7 unattended, so I would suggest that the former strategy is at least understandable.
I have to say, this is not the case with my day-to-day findings ?? Even when I've fixed the line, the minute the synch light begins to start flashing, the EU's will generally comment that, "This is the first time it's done that for 'x' amount of days". I have my JDSU sat next to me in 'Synch & Data' mode, it remains 'Idle' until it sees a DSLAM when it will attempt to 'Handshake' and hopefully gain full synch.
Mike has posted today at 0736, that his router has connected but at extremely low speeds. This supports the evidence that there is a HR on both legs, or at least 1-leg fully 'dis' on his MPF.
-
Sync reappeared by its self this morning. 35/13 with attainable sat just a little bit higher. Interleaving sat at 900/300.
Are DS & US SNRM still showing plenty of scope for improvement?
SNRM on my connection has always been around the 6dB mark, confirming my connection maxes out whatever it is being sent.
However, it has lost around 10 Mbps DS since December, also seeing reduced power, particularly in the D2 band.
I don't know if lower sync speeds drive power levels i.e. a connection only uses whatever power is needed or if power levels drive sync speeds i.e. does lower power = lower sync speed (e.g. lowered power levels to combat crosstalk onto other connections)?
These lower sync speeds and power levels do also seem to coincide with the reduced speed estimates that many users are now reporting.
-
How a modem/router tries to reconnect varies from model to model, and it also depends on the router's configuration. A lot of routers have an option "Reconnect automatically". Over the years I've tested numerous different models; some of them sit there for ever trying to reconnect, even when they are disconnected from the telephone line, and others quickly give up when there's no signal. Some have to be manually prodded into action after a line disconnect. I don't think there's any "standard behaviour" for this.
-
Actually, my original post wasn't just a joke, it was observation. The modem does not even need anything to be connected to the DSL port for it to attempt connection. As I write this I have another DSL modem (HG622) sitting alongside me, powered up, but not connected to anything at all. The DSL light is flashing as it 'attempts' to sync.
If you think about it, this is by design. The modem has no way of knowing (for sure) when or whether a (temporary) line fault might resolve itself. Is it better for it to keep trying, in the hope that sooner or later it will be sucessful, or just sit there waiting for somebody else to do something? These things are supposed to run 24/7 unattended, so I would suggest that the former strategy is at least understandable.
I have to say, this is not the case with my day-to-day findings ?? Even when I've fixed the line, the minute the synch light begins to start flashing, the EU's will generally comment that, "This is the first time it's done that for 'x' amount of days". I have my JDSU sat next to me in 'Synch & Data' mode, it remains 'Idle' until it sees a DSLAM when it will attempt to 'Handshake' and hopefully gain full synch.
Mike has posted today at 0736, that his router has connected but at extremely low speeds. This supports the evidence that there is a HR on both legs, or at least 1-leg fully 'dis' on his MPF.
As I said in the OP - the modem was sat on No Signal continuously until I plugged the RJ11 cable in, at which point it would attempt but fail sync. The modem definitely 'knows' when the line is connected.
Are DS & US SNRM still showing plenty of scope for improvement?
SNRM on my connection has always been around the 6dB mark, confirming my connection maxes out whatever it is being sent.
However, it has lost around 10 Mbps DS since December, also seeing reduced power, particularly in the D2 band.
I don't know if lower sync speeds drive power levels i.e. a connection only uses whatever power is needed or if power levels drive sync speeds i.e. does lower power = lower sync speed (e.g. lowered power levels to combat crosstalk onto other connections)?
These lower sync speeds and power levels do also seem to coincide with the reduced speed estimates that many users are now reporting.
SNRM is at 6dB, which would coincide with the new max attainable figures. It's pretty impressive that it's managing to function at nearly 40/10 with the phone out of order.
-
Just a quick one, perhaps for BS.
If the fault is raised as a voice fault, will the engineer that attends be able to request a DLM profile reset?
-
How a modem/router tries to reconnect varies from model to model, and it also depends on the router's configuration. A lot of routers have an option "Reconnect automatically". Over the years I've tested numerous different models; some of them sit there for ever trying to reconnect, even when they are disconnected from the telephone line, and others quickly give up when there's no signal. Some have to be manually prodded into action after a line disconnect. I don't think there's any "standard behaviour" for this.
I think that Eric is fully correct on this. Our individual experiences differ.
-
I have my JDSU sat next to me in 'Synch & Data' mode, it remains 'Idle' until it sees a DSLAM when it will attempt to 'Handshake' and hopefully gain full synch.
As Eric has pointed out to me, each modem implementation may be different. :-[ Your JSDU is just another implementation, for those purposes. However, how does it 'see' a DSLAM? By physical line conditions, or attempting the very early part of the sync?
Mike has posted today at 0736, that his router has connected but at extremely low speeds. This supports the evidence that there is a HR on both legs, or at least 1-leg fully 'dis' on his MPF.
I am sure that you are absolutely correct, and I wasn't suggesting otherwise. I was trying to answer his original question What does the modem look for in the first instance before trying sync?
on the basis of my direct - and reproduced - experience of Huawei VDSL modems (612&622); which is that they don't need anything at all to try to sync. I shouldn't have assumed that he had a Huawei modem though. Nevertheless, try it with a Huawei modem and tell me if it does something different, as that would a significant difference in our experiences of them. :friends:
-
I agree with BS, your router is attempting the handshake, but at some point it failing one of the stages to set up the full DSL link
http://www.kitz.co.uk/adsl/adsl_technology.htm#sync
Ive watched your thread with interest because some of the things you were experiencing sounded so similar to my own problems, but BE & BS are more capable than me when it comes to FTTC technology and you are in the best of hands with them.
Like you Ive also experienced FECs with interleaving switched off... noise bursts with no attributable source, Ive seen changes in attenuation and although I havent experienced downstream loss of speed, I reckon I would have lost some if I didnt have a large amount of 'spare' SNRm to start with.
Its also ironic for the first time yesterday, I too started seeing issues with the physical phone line and also for the first time seeing a signs that my issue could be attributable to a HR fault.
With your phone line being down you should get some sort of priority, Im still waiting to hear when my next visit will be. Good luck, I hope that the engineer finds where your problem is and you are soon back up and running.
kitz yeah FEC can be enabled without interleaving, althogh for a openreach service its unusual as they dont set it without interleaving.
But when I was on ukonline (who gave full freedom to set on modem side) I could turn on FEC on my modem whilst on fast path.
-
In the interests of science, I have repeated the experiment with an ECI B-Focus V-2Fub/r Rev.B (I knew it must be useful for something :D), and indeed that modem, with nothing connected, does not appear to attempt to try to sync. All lights except the power light remain dark at all times.
Further, I have not observed either of the HG612/622 modems long enough (e.g. for > 1hr) to know whether their behaviour changes after a number of attempts/or a time interval.
-
Mine was a HG612. It was continually looping and trying to sync (observing the web interface rather than the light on the modem) connected to the dead phone line.
Disconnected, it sat on no signal permanently.
The modem had been powered up for several hours.
-
Disconnected, it sat on no signal permanently.
In the GUI Mike, yes? But the DSL lights were showing what? (Just in case my modems are both somehow 'different' ???)
[Edit] On the assumption, for the moment, that the DSL light was still flashing, then we can probably conclude that the HG612 (at least) flashes the lights as it tries to find a signal with which to sync, and
1) if the line is connected but as BS said DSL will work to a fashion down 1-leg of the 2-wire circuit ... allowing the router to attempt a handshake, but not providing full synch.
it shows it trying to sync in the GUI, but
2) if the line is disconnected it continues to try (DSL light still flashes) but shows no signal in the GUI.
i.e. detection of any kind of signal (even on one leg) will allow it to move further into its attempt to sync properly, but no signal does not prevent it from repeatedly looking to see if it can get a signal with which to try to sync?
-
Probably.
Either way, engineer has been and gone - he says there was a DIS on one leg in the PCP. He also tells me that my line is Aluminum - I suppose I'm quite lucky to get 80/20.
Interleaving is heavier, sync has increased a bit to 50/16. I can't be arsed to keep checking and hoping it recovers, so I've asked Plusnet for a profile reset.
-
Probably.
Either way, engineer has been and gone - he says there was a DIS on one leg in the PCP. He also tells me that my line is Aluminum - I suppose I'm quite lucky to get 80/20.
Interleaving is heavier, sync has increased a bit to 50/16. I can't be arsed to keep checking and hoping it recovers, so I've asked Plusnet for a profile reset.
Result. As per my previous note ............ 'DSL will work to a fashion down 1-leg of the 2-wire circuit, but the PSTN (Phone) requires both legs to be intact. It sounds to me like there's an extremely high HR on either the wires or the equipment, which is allowing the router to attempt a handshake, but not providing full synch. :)'
-
It was indeed a good shout.
Hopefully once I've had my profile reset, I can just leave this FTTC connection to 'just work'.
-
Resync over night - wasn't logging :/
Dropped from 55/16 to 32/11!
I hope that is just DLM acting on some information before and around the time it was fixed!
-
:(
-
Well it's recovering very slowly - and without the help of Plusnet, who after a week have only just decided to respond to my support ticket and are now claiming it's a copper joint fault.
There has been a resync at ~6am every day, without fail.
Day 1 saw interleaving raise to 2000/275 and sync drop to 33/13
Day 2 no change
Day 3 saw US raise to 16mbps whilst US interleaving went up to 360. DS interleaving dropped to 600.
Day 4 saw DS interleaving drop to 600, US interleaving removed completely.
Day 5 has seen US back to 20mbps and DS interleaving off.
As it stands, I'm left with interleaving off again and a sync of 33/20.
Full monty stats over the period here (http://vxr.in/share/line_stats__FULL_MONTY_P-20130805-0759.png), for anyone that is interested.
-
I've taken a quick look at your graphs and it does seem as if there is a definite infrastructure problem present -- possibly a HR or semi-conducting joint.
Have you asked PlusNet to run a Copper Integrated Demand Test (http://www.openreach.co.uk/orpg/home/products/llu/cidt/cidt.do) (CIDT)?
-
Have you asked PlusNet to run a Copper Integrated Demand Test (http://www.openreach.co.uk/orpg/home/products/llu/cidt/cidt.do) (CIDT)?
I'd be interesting to see how that is answered. I havent added it yet to my ticket, as I didnt want an addition to send it back to the bottom of the pile.
-
I've taken a quick look at your graphs and it does seem as if there is a definite infrastructure problem present -- possibly a HR or semi-conducting joint.
Have you asked PlusNet to run a Copper Integrated Demand Test (http://www.openreach.co.uk/orpg/home/products/llu/cidt/cidt.do) (CIDT)?
The graphs posted in my last post? What on them would indicate that?
If you're looking at graphs before that, I did have an issue where one leg was DIS at the PCP which was repaired around a week ago - I imagine that issue was slowly getting worse until it cut out all together.
As for the CIDT, they may well have done that as they are claiming a copper issue as a result of tests stating possible HR.
-
As for the CIDT, they may well have done that as they are claiming a copper issue as a result of tests stating possible HR.
Ok thanks, there was nothing on any of my tickets to specifically indicate a CIDT had been run.
-
I've taken a quick look at your graphs and it does seem as if there is a definite infrastructure problem present -- possibly a HR or semi-conducting joint.
Have you asked PlusNet to run a Copper Integrated Demand Test (http://www.openreach.co.uk/orpg/home/products/llu/cidt/cidt.do) (CIDT)?
The graphs posted in my last post?
Yes.
What on them would indicate that?
I've based my assessment on the changes recorded in both the line and signal attenuation values. For the best interpretation of your graphs, they need to be inspected by an Eagle eye . . . All being well, I expect Bald_Eagle1 to be passing this way soon. ;)
-
Can you be more specific? I mean, the line had only really improved since the DIS killed my DLM profile.
I'm not well versed on this stuff, however.
Sent from my HTC One using Tapatalk 4
-
Although an improvement on the bog-standard Eclipse/RAT/Fast Test systems, the CIDT will still miss a small 'HR'. Don't get me wrong, if the HR is sufficient enough, it will show a fault on the test result that the other low-end tests would miss. I wouldn't put all your eggs in this particular basket though. ;) :)
-
As it stands, I'm left with interleaving off again and a sync of 33/20.
Full monty stats over the period here (http://vxr.in/share/line_stats__FULL_MONTY_P-20130805-0759.png), for anyone that is interested.
From the latest graphs you posted, it appears that US Interleaving may well be OFF, but that DS Interleaving is still ON (at a depth of 500+).
Definite problems were seen with Attenuation & SNRM variances.
These may now have settled down, but it does appear that the connection may have resynced again this morning.
If it did resync, it may be useful to see how it has performed since.
Indications are that your connection is capable of supporting higher DS sync speed (high SNRM values) & that error rates have been relatively low.
Hopefully, DLM will now see a reasonably steady connection & increase speeds (in small steps) over the next couple of weeks or so.
It does occasionally happen that connections can be capped/banded at low speed levels, seemingly indefinitely.
I have seen mention of DLM taking over 50 days or so to eventually restore decent speeds following repair works.
Hopefully, you won't have to wait that long.
You could always request a DLM reset via Plusnet, but it would no doubt require another engineer's visit (if BTOR actually do agree to it).
It may be wise to continue monitoring to demonstarate a stable connection i.e. daily or user initiated resyncs cease.
The daily resyncs may just be DLM attempting to deliver higher speeds (but unable to do so until it or manual intervention removes the capping/banding).
-
It certainly is off - although there's probably only a couple of samples on that graph. I can assure you DS Interleaving is currently set to 1.
The resyncs each day are DLM and happen around 6am usually, although there was one this afternoon where I accidentally knocked the power out reorganising my network.
It's worth noting that the 29th to the 1st is where the connection had the fault mentioned in the OP of this thread. It looks to me that any significant variances since then are simply where SNRM/Power etc. has changed with the resync at a different sync.
I've graphed from the time of this morning's until now here (http://vxr.in/share/line_stats__FULL_MONTY_P-20130805-2127.png)
As for requesting a DLM reset - I have, Plusnet have taken a long time to get back to me and now believe their is a copper fault, but I'm not convinced.
-
It certainly is off - although there's probably only a couple of samples on that graph. I can assure you DS Interleaving is currently set to 1.
Ah. I can see it now.
The resyncs each day are DLM and happen around 6am usually, although there was one this afternoon where I accidentally knocked the power out reorganising my network.
Hopefully a single resync where power was OFF won't have a negative effect on what appears to be somewhat improved stability.
It's worth noting that the 29th to the 1st is where the connection had the fault mentioned in the OP of this thread. It looks to me that any significant variances since then are simply where SNRM/Power etc. has changed with the resync at a different sync.
I've graphed from the time of this morning's until now here (http://vxr.in/share/line_stats__FULL_MONTY_P-20130805-2127.png)
As for requesting a DLM reset - I have, Plusnet have taken a long time to get back to me and now believe their is a copper fault, but I'm not convinced.
Are Plusnet planning to arrange an engineer's visit to investigate the copper 'fault'?
If so & if things remain stable with high SNRM & attainable rates, but still at capped/banded speeds, that might be your best opportunity to request the engineer to arrange a DLM reset.
-
Apparently it's "with" BTOR and I'm told a DLM reset will be part of the procedure in rectifying the fault.
I'm not convinced - hopefully the engineer phones me up again this time.
-
Engineer visit this morning - got me out of bed!
DLM Profile reset - now back at 80/20.
I asked him about this suspected copper fault, he reckoned the resistance was 1 ohm out and I shouldn't worry about it, but it was enough to flag up on the tests.
-
Now I'm stumped.
I woke up this morning to find DLM had shaved off some DS and added a fair bit of interleaving :/
The graph doesn't show anything obvious since the profile reset I don't think, so I'm a little confused.
Full monty: http://vxr.in/share/line_stats__FULL_MONTY_P-20130807-0657.png
Current stats at resync: http://vxr.in/share/line_stats-L-20130807-0434.png
-
Now I'm stumped.
I woke up this morning to find DLM had shaved off some DS and added a fair bit of interleaving :/
I suspect that you're still on the 80/20 profile though. Perhaps after DLM had moved you back up the profile bands, it decided that it didn't like something about the (previously observed) error rates that merited introducing a fairly hefty dose of interleaving DS. Once it had done this, the actual sync rate is what the modem can achieve within the profile band given the DSLAM's input parameters. They're not in the latest stats you've provided but I suspect that INP and delay are also set.
This has happened to me too.
My parameters are now depth=1237, R/N=16/80 or 20% (INP=3, delay=8) and so the resultant DS actual sync rate is 78687Kb/s.
Compare your depth=1193, R/N=16/67 or 24% (INP and delay currently unknown to me), and your resultant actual DS sync rate is 76986Kb/s.
With interleaving at that depth you can expect high rates of FEC (corrected) errors reported. AFAICS this is solely a result of the large ongoing interleaving depth, as ES and CRC rates are low. Without interleaving, these would probably result in a (slightly) higher CRC rate instead. Which is 'better', well that's something that only the DLM algorithm thinks it knows best (and you're on an ECI DSLAM, I believe, whereas mine's Huawei).
My observation (of the Huawei DSLAM) is that shifting this looks like it's going to take some time, if ever.
-
I wondered if it was looking at older rates, but shouldn't a profile reset remove all of that?
-
I wondered if it was looking at older rates, but shouldn't a profile reset remove all of that?
Until CSPs like OR are willing to publish their DLM algorithms (which I doubt they will because of 'commercial confidentality'), we will never know for sure, but I believe that it has been suggested before that the entire line history is recorded (by OR anyway) in its WHOOSH system (BS will correct me I'm sure), and this could and may well be used by DLM. :(
Your profile has been reset to 80/20, your history hasn't. Only time might do that, I fear.
-
I'm not sure about the entire history, Colin, as I don't have access to the higher levels. But, we can view up to 28 days historic data via WHOOSH, at engineering level. This is usually suffice to gauge the circuits performance. :)
-
I'm not sure about the entire history, Colin, as I don't have access to the higher levels. But, we can view up to 28 days historic data via WHOOSH, at engineering level. This is usually suffice to gauge the circuits performance. :)
In reality, neither did I, but I did think you also kept the original record from activation time too? Certainly 28days is sufficient to continue to impact DLM for, well, at least 28days after something has happened! ;D
-
Is that stored per port or per line?
If it's per line, that may explain why I was re-banded in the next DLM adjustment window following my lift and shift.
-
Well, there was no change yesterday morning, but this morning it seems to have recovered completely.
http://stats.vxr.in/ongoingstats/Ongoing_Stats_20130809-0704-12Hrs/line_stats__FULL_MONTY_P-20130809-0704.png
-
I'm not sure about the entire history, Colin, as I don't have access to the higher levels. But, we can view up to 28 days historic data via WHOOSH, at engineering level. This is usually suffice to gauge the circuits performance. :)
thats not much of a history :(
a month is nothing really.
so basically if you visited me you might be mistaken in thinking my line has only ever managed 69mbit, when 9 months ago it could do 110mbit.
-
However, BS has also confirmed on a different thread that they also store the record from your original activation too.
The 28days allows them (potentially) to gauge the lines recent perfomance. Your activation record presumably shows that you got 80Mb/s then. The rest will be 'put down' to crosstalk, I have no doubt.
-
Certain figures are taken during the initial 10 days on BTw DLM, which are permanently stored.
Sync speed over this period is monitored and used to work out the MSR and FTR (http://www.kitz.co.uk/adsl/maxdsl2.htm) which will stay the same for the whole time you are on a particular product ie adsl1, adsl2+ and also presumably FTTC.
This initialisation period is often confused as part of the everyday DLM process, but its NOT... as the DLM is a continual ongoing process. Its more of a one time only event, although it can be reset by request after Engineer work, it seldom is.
Any of the BTw speedtests where you login on the BT realm were also stored for up to 7 days, although not sure how often these are done now that the BTw performance tester has changed. These results could also be accessed by the ISP.
-
PS if anyones interested... theres an old image of one of my WOOSH tests here (http://www.kitz.co.uk/adsl/images/WOOSH.gif).
Despite having a good line which easily syn'd at 8128, look how easy it is to get permanently landed with an incorrect MSR profile leaving me with an FTR of just 1590 :(
That 2272 figure was the old standard 2Mb sync speed, but I was stuck with that record for my duration on Maxdsl. I also used to continually get the 2Mb stuck default bRAS profile.
-
For the record, the GEA WHOOSH system does capture 'Baseline' values (ie: when the circuit is switched on).
Certain figures are taken during the initial 10 days on BTw DLM ... and also presumably FTTC.
IIRC from the GEA SIN, there is no 10-day initialisation period for FTTC. DLM will commence on the second day after activation assuming that there has been a sync held for any reasonable time on Day 1.
-
Certain figures are taken during the initial 10 days on BTw DLM, which are permanently stored.
Sync speed over this period is monitored and used to work out the MSR and FTR (http://www.kitz.co.uk/adsl/maxdsl2.htm) which will stay the same for the whole time you are on a particular product ie adsl1, adsl2+ and also presumably FTTC.
This initialisation period is often confused as part of the everyday DLM process, but its NOT... as the DLM is a continual ongoing process. Its more of a one time only event, although it can be reset by request after Engineer work, it seldom is.
Any of the BTw speedtests where you login on the BT realm were also stored for up to 7 days, although not sure how often these are done now that the BTw performance tester has changed. These results could also be accessed by the ISP.
except kitz I am pretty sure the 10 days monitoring to make a MSR and FTR is abandoned on FTTC, now there is no min acceptable speed on any given line. This is why a few of us are not happy with fault resolution for FTTC problems. Instead there is rules such as a 25% loss of speed within a 14 day period.