These are my latest HH3a stats after a DLM resynch - part of an ongoing battle with it over the SNR
IP is 6.06 and speed 5.92.
The errors an hour after the resynch were CRC 702269 HEC 6925930 Secs 28828
What I want to know/understand is why the errors were so high after the resynch and why am I currently still able to get the speed I can as in the past errors less than half the total shown have completely throttled the line.
FYI this is a follow on from this thread http://community.bt.com/t5/BB-Speed-Connection-Issues/Low-Noise-high-errors-again/td-p/734960
Solved! Go to Solution.
It's not an easy question to answer ... but this may give you an insight.
Sync is acheived by the msan sending a series of tones down the line to the modem, and according to the acknowledgements, the modulation standard is set. The loop loss is measured electronically and according to same, the amount of SNR (not SNRm) is used to set power factors so that the dslam can transmit the databits over the frequencies for the tones that were accepted. Some tones and thus frequencies will have been lost, as the line can't sustain them, because of either outside influences or mere line length. Once the SNR and power is set, the dslam will apply a buffer which is normally target margin (6db) (can be 3db on DSL2 running a special algo at the msan control).
Once all these parameters are set the line will attempt to transmit data putting analog information into digital virtual buckets to transmit down the wire.
If any of the databits are destroyed in total, or the majority of the packet is useless, a cyclic checksum will command a resend of that packet. If the packets are fairly good, and transmittable, they will go but will be checked and error corrected by a soft block code algorithm using RS codewords to fix the packet, these don;t get resent merely fixed.
If the line is having a bad day, the errors may rack up and quickly, so the modem has the capability to drop the connection if it sees multiple second counts whereby the entire payload was corrupted, but it won't do it until a threshold (count) is breached.
Lines change all the time, and at different times of day, as for example impulse noise increases at night owing to external influences, street lamp radiation, radio frequencies etc. and this is normally absorbed by the margin of the SNR, or put another way the noise margin. If databit transmission becomes difficult the MSAN control can increase the margin to enable the linedata to be "heard"... at the cost of linespeed.
To get back to your original point about error rates .... if your line sees high CRC checks (and resends) high HECS , header corrections ... it will absorb high levels of bandwidth and reduced throughput will ensue.
With FEC high figures simply shows interleave and block error correction is working, and it is demonstrating the rate of bits that are acknowledged as repaired. All lines will see some, and some more than others. The better the line and quality of the path, the less errors will be seen.
The DSL also has a further trick up its sleeve. If certain frequencies can't be used when negotiation takes place, it has the ability to swap databits from one virtual bucket to another bit-free part of the spectrum, that isn't being utilised for transmission, and in doing so maintains the throughput without wasting any bandwidth. That's bitswapping and is used frequently on longer, or errornous lines where "normal" databit transmission is difficult.
To put all this into perspective .... if your line starts to crackle .... high counts of errored seconds will be seen, and cyclic checking will go up, along with packet header correction. And as all this takes up overhead, throughput and data transfer depletes until the modem drops the connection.
On regaining a new re-negotiated connection, the dslam may according to line history and the "fault" that caused linedrop .... impose a higher level of interleave, via the DLM line algorithm. It can also reduce sync like it does at night, in order to negotiate a connection that is sustainable.
Crackle is probably the worst case scenario, as eventually the connection is bound to drop. But even high levels of impulse noise can destroy data packets, so if you have say poor extension wiring that absorbs REIN it will do the same, cut back the throughput.
Hope this helps.
wow RogerB another great information post
Thanks for the reply - the hub is connected direct to the test socket so I would guess that as all this has been occurring since BT put the 3db in place that the line changes aren't being absorbed and the line appears to be not the best.
I have noticed that the errors always jump when I don't use the internet 3am to 4pm.
Presumably I still get decent speeds because the error increase since the first hour has been proportionately lower and the line is able to cope.
I think it's a good idea if someone could put RogerB's comments in an easy place to view as they are very informative and easy to follow.
Again .... it's difficult to answer your presumptions, apart from to state this ....
The line algorithms that DLM uses to sustain a connection are very powerful and complex, and they can call on different aspects of control as mentioned previously .... noise margin level, interleave level, modulation modes, bitswapping the data and other corrective applications, but also to vary each aspect and mix or use more than one .... it's that flexibility that allows DSL to transmit and recieve the data down copper wires of all types, lengths and quality ... and thus is the fundemental foundation for running line derived broadband. And if you consider it all happens at light speed, it demonstrates why the technology can be troublesome sometimes, and not an exact science.
But more than anything it demonstrates the importance of line training, and letting the connection set the maximum stable rate unhindered .... the so called 10 day period for training.
It's important for 2 reasons ... it sets the MSR, and secondly it uses the data to renegotiate a new connection if needed, using the history of previous connection attempts and the timeframes it ran for before dropping.
It enables the MSAN control to run the algorithms in a particular way that analyses the connection and at the same time using logic control, differ the line solution. Once a line has met the MSR and settled and established, the MSAN pulse check algo will only visit the connection once every 24 hours, whilst the running algo is constant.
If a line flaps or is unhealthy and has high margin or is in a banded line profile, the pulse algorithm may "visit" the connection multiple times a day, and force a drop, a resync, or an interleave change.
The better a connection becomes, the more latitude DLM gives the line .... to just get on and bitload.
BT run their network this way primarily because it is really the only way to stop corrupted data getting back to the exchange and network MSANs ... to keep the network uncorrupted, as clearly the network caters for business, including financial institutions as well as other commercial entities .... along with residential users.
And so the line algorithms have to be powerful enough to keep the data moving in a controlled fashion, whilst at the same time satisfying the needs of the end user. Not always easy to achieve.
Thanks - it does seem a shame that it isn't possible to permanently fix the SNR at 6db for those who need it although hopefully DLM will get the message about my line. The level of SNR actually doesn't affect my speed - stayed constant when margin varied 8.6 to 4.6db.
It will be interesting as to who causes the next resynch, me because the speed is throttled by errors or hopefully DLM as part of the line 'evolution'
wow RogerB another great information post
We'd run out of lager Don ....
And I was feeling bored.
This is an update but I also need help. I would point out that I have logged a phone line fault as there seemed to be a slight hiss on the quiet line test when using a cordless phone (not a hum but it is slight and the line may have always been like it) - I am going to get hold of a corded phone tomorrow before I receive a second call back.
However bearing the above in mind back to my broadband. Things were fine until 00.28 on the 18th when there were 2 disconnects presumably by the DLM. Unfortunately what it did was to lower the SNR to c3db The errors 36 mins after this were CRC 1673346/0 HEC 31036098/2 Error secs 48506/1 and my throughput fell to 2.24 ( IP was still 6.06) which meant surfing was slow but doable.
During the day up to 15.59 looking at the event log there were multiple disconnects and at this time with a connection time of 20 mins the errors were CRC 2536399/0 HEC 53416737/2 secs 72405/1 and within 10 minutes I was unable to load web pages so I disconnected the adsl cable. Later on I rang BT which caused some more disconnects whilst they checked the line and I was told to swop filters. During the period since 15.59 BTW speedtester was showing speeds between 0.00 and 6.04 (even though profile was now 5.97)
I was able to use internet from 21.00 onwards with fluctuating speeds above 2.20 and after midnight it ran at 5.88 so things looked ok.
today when I logged on it took ages for the hub stats page to load which showed errors of CRC 1265082/32 HEC 122107104/7 secs 126259/1 (connection had not dropped) I could only open web pages after again taking out the adsl cable.
Have recently logged in and had to take adsl cable out again to create a connection - IP profile now 5.89 and speed 5.89. The SNR has increased from the 3db to only 4db.
My problem depending on the phone line situation is now that DLM insists on using the 3db regardless of the disconnects (at the moment) my broadband becomes unusable very quickly and there appears no way that I can produce a stable 3 day connection so should I contact the mods anyway and ask for SNR to be set at 9db or do I need to wait until I use a corded phone