Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mikehiow]

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.

[mikehiow]

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?

[ColinS]

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.

[ColinS]

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.

[Chrysalis]

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.

[ColinS]

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 ), 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.

[mikehiow]

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.

[ColinS]

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?

[mikehiow]

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.

[Black Sheep]

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.  '

[mikehiow]

It was indeed a good shout.

Hopefully once I've had my profile reset, I can just leave this FTTC connection to 'just work'.

[mikehiow]

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!

[kitz]

[mikehiow]

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, for anyone that is interested.

[burakkucat]

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 (CIDT)?