exchange negotiates deliberately unstable 3dB target SNR from today- why ?
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Plusnet Community
- :
- Forum
- :
- Help with my Plusnet services
- :
- Broadband
- :
- Re: exchange negotiates deliberately unstable 3dB ...
Re: exchange negotiates deliberately unstable 3dB target SNR from today- why ?
15-05-2011 6:31 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
no - the info you posted does not indicate why you only get 6.5M out of a possible 11M or 12M - you should post everything that your data source lists ( to a new thread)
The info you need to look for is called RCO - relative channel occupancy - which can be a lot less than the sync speed, depending upon how much of your bandwidth is being taken by error protection bits imposed because your telephone line is sub-standard.
[edit: I'm wrong - RCO is not the percentage measure of interleaving overhead and you appear not to have interleave - sorry :-\]
Re: exchange negotiates deliberately unstable 3dB target SNR from today- why ?
15-05-2011 7:42 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
stable so far anyways not really happy about interleaving being put on though.
Re: exchange negotiates deliberately unstable 3dB target SNR from today- why ?
15-05-2011 11:14 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
I'd keep an eagle eye on it. Are you seeing Reed-Solomon uncorrectables at 3dB interleaved ?
Re: exchange negotiates deliberately unstable 3dB target SNR from today- why ?
15-05-2011 11:20 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Re: exchange negotiates deliberately unstable 3dB target SNR from today- why ?
16-05-2011 2:39 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Seems the instability from Thursday-Saturday (see graph) has caused your line to be banded. That's why you can't sync any higher than 2272Kbps at the moment. If you plug into the test socket I can see if that can be removed.
Jojo
Re: exchange negotiates deliberately unstable 3dB target SNR from today- why ?
16-05-2011 5:53 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
All of those disconnects you show were caused by me deliberately re-training the line after discovering it was crippled at 2M and, on Sat pm, carrying out the tests required by the fault reporter !!! The graph shows no failed connections, only session starts and stops.
The 'banding' must have occurred earlier ?
I will raise a slow speed fault report.
Re: exchange negotiates deliberately unstable 3dB target SNR from today- why ?
17-05-2011 11:27 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
By all means raise a fault, but like I said if you plug into the test socket I can get the banding lifted.
Jojo
Re: exchange negotiates deliberately unstable 3dB target SNR from today- why ?
17-05-2011 5:53 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
I'm sorry - I don't understand what's going on here. In particular, I don't see the connection between having 'banding' lifted and me plugging directly into the MJU.
When I filed a fault report, the troubleshooter asked me to plug my microfilter directly into the test socket. That made no difference to my line stats - indicating strongly that whether I am plugged into the test socket or not is not a factor. In fact, the only difference in my house wiring between being plugged into the test socket and having the MJU faceplate attached is just the MJU faceplate connector - I have no house wiring attached to the rear IDC connections of the faceplate. All my house analogue telephones are beyond the first microfilter.
Why doesn't the fault team lift the 'banding' as part of their investigative process ? And if you lift it, won't you confuse them ?
and I was advised to raise a fault report, as clearly this 'banding' is an unreasonable restriction placed as a result of a fault.
Re: exchange negotiates deliberately unstable 3dB target SNR from today- why ?
17-05-2011 6:07 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
OK - I am now permanently plugged into the test socket behind the MJU faceplate. Please take whatever action necessary to increase my broadband speed back to my previous ADSL2+ performance levels (17Mbps profile or better)
Thanks.
ps - why doesn't a fault report automatically get filed when BT place a line onto this inferior sub-ADSL1 'banded profile' ? At the very least, a warning e-mail to the customer that their line has performance problems would be reasonable ?
pps - could you please post the graph data for the 10 days prior to the period you posted ?
Re: exchange negotiates deliberately unstable 3dB target SNR from today- why ?
18-05-2011 10:10 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
I will look into getting that lifted. Once I have then please leave it in the test socket. If we do this we can get a better idea of whether it's something internal or external.
Jojo
Re: exchange negotiates deliberately unstable 3dB target SNR from today- why ?
19-05-2011 12:07 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
I'm now connecting at 15323 11-12dB SNR, but the existing problem of significant error rates on the line remains unfixed.
Here are my modem stats for this afternoon and evening
---
[tt]
BusyBox v1.00 (2006.09.20-01:51+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
# adslctl info --show
adslctl: ADSL driver and PHY status
Status: Showtime Channel: FAST, Upstream rate = 1224 Kbps, Downstream rate = 15323 Kbps
Link Power State: L0
Mode: ADSL2+
Channel: Fast
Trellis: ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 10.8 6.3
Attn(dB): 23.0 11.1
Pwr(dBm): 0.0 12.1
Max(Kbps): 18660 1228
Rate (Kbps): 15323 1224
G.dmt framing
K: 239(0) 57
R: 16 6
S: 1 4
😧 64 4
ADSL2 framing
MSGc: 59 10
B: 238 56
M: 1 4
T: 2 3
R: 16 6
S: 0.4980 5.9240
L: 4096 316
😧 64 4
Counters
SF: 1960492 1960490
SFErr: 6 0
RS: 254863976 33328330
RSCorr: 4983 0
RSUnCorr: 57 0
HEC: 6 0
OCD: 0 0
LCD: 0 0
Total Cells: 1146919359 807204
Data Cells: 793939 29207
Drop Cells: 0
Bit Errors: 0 0
ES: 6 0
SES: 0 0
UAS: 91 0
#[/tt]
---
I'm guessing that I'll be going round the same loop again as the broken DLM logic gradually edges me nearer to a sub-ADSL1 banded profile like before. As your faults people have also interpreted the graph that you posted as temporary 'line instability' - they think that it might just go away on its own. I hope I don't have to keep posting here, frankly. I'd like it fixed instead.
Re: exchange negotiates deliberately unstable 3dB target SNR from today- why ?
19-05-2011 1:42 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
There is no explicit "uptime" figure, but the SF stats (superframes) show 1960492, and at 59 per second, this represents just over 9 hours.
In that time, you've had 6 superframes with errors, all of which are counted as HEC errors. There were 6 ES (Errored seconds), which means all 6 errors came very spread out - suggesting that the interference was not a single impulse.
Conversely, your interleaving is working. There were 254863976 RS (Reed Solomon) chunks, of which 4983 were detected to have a fault, but the FEC (Forward Error Correction) process fixed them. There were 57 RS chunks that could not be corrected by FEC, and these 57 will have led to the 6 HEC errors.
Less than 1 error per hour is trivial - I get 8-10 an hour on a rock-solid line, although that is with interleaving turned off (so there is no FEC process happening).
In fact, the only figure that looks out of place is the 91 UAS (Unavailable Seconds). This means that your line has taken 91 seconds to synchronise (or re-synchronise). That is a lot, given the low number of faults shown in the rest of the stats.
Using FTTC since 2011. Currently on 80/20 Unlimited Fibre Extra.
Re: exchange negotiates deliberately unstable 3dB target SNR from today- why ?
19-05-2011 7:25 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Thanks for a superb post ! I've learned loads from it - one of the best ADSL-explanatory posts I've seen, in fact.
My worry about the non-zero number of uncorrectable RS errors is based on my ADSL1 experience. I had an 8128/448 line and the only time I ever saw uncorrectable RS errors in my stats was when there was an obvious voice fault on the line. How did you calculate 59 superframes per second, btw ?
At what error level will the DLM seek either to raise or lower the target downstream SNR, though ? Is my current error level going to mean the DLM stops its pernicious fiddling ? All this info is still missing - or at least, I haven't seen any posts that detail the make and model of DSLAM that BT uses and whether they have overlaid their own DLM logic on it or are using the algorithms that come with the kit.
Re: exchange negotiates deliberately unstable 3dB target SNR from today- why ?
24-05-2011 1:45 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
ADSL1 works nominally on 4000 frames per second, in sending the various streams of data (whether DSL header/framing, fast-path, or interleaved user data). Within those frames, the interleaved data is sent as small chunks encoded with RS - but I've never really worked out the rate at which those happen.
However, the ADSL frames are then grouped into a "superframe" structure - with 68 frames carrying data, and 1 frame carrying synchronisation data, so that the receiver can work out the way the frames have been structured. I think the frame rate is actually adjusted to squeeze in that extra sync frame, so to get 4000 frames/sec of user data, the line runs at (69/68*4000)=4058ish frames per second.
CRC data is calculated on a superframe, and then sent (in 8 bits) as part of the 1st frame of the next superframe. This means that CRC failures can only come every 68th (user) frame from the 4000 (user) frames/sec - or 58.8 CRC errors per second.
More information around pages 7 and 8 here: http://www.iol.unh.edu/services/testing/dsl/training/ADSL_Tutorial.pdf, but it is a very techie document.
I don't know about HEC errors directly, although they seem to be CRC checks on the ATM cell headers. However, my experience (on my Netgear DG834GT) is that the HEC error count seems to be a subset of CRC error count, and never appears alone; I've so far assumed that they therefore follow the same rules on timing... but cannot really be sure.
As to the error-level needed to cause changes in the SNR targets, I don't know. It has only happened to me once - and the time the SNR was changed occurred rather later than the errors actually happened: I had 4 significant bursts of CRC+HEC errors over a day (11PM, 3AM, 10AM and 3PM, if I recall), and the line resynced around 5PM when there were no problems. I don't know the actual number of errors in the spikes, as my statistical graphs now average those 2 days over the entire 24 hour period, rather than keeping the counts related to each 15-minute period. They show the average about 500 errors - suggesting that the spikes were around 10,000 errors in a 30 minute period.
I've attached 2 graphs that give an idea of the scale of "normal" and "abnormal"...
You can see some of the smaller "mini peaks" on the 2nd graph. The one earlier in May was about 1600 errors in a half-hour period, and the spike in April was 3 bursts (150 over 2 hours at 8AM, 600 over 2 hours at 10AM and 900 over 2 hours at 6PM). Neither of those caused a twitch in DLM - but the spikes in February did trigger it.
I think we have some ideas that a number of *resyncs* in a short period can trigger DLM, but I haven't seen anyone yet show how *errors* (without resyncs) can trigger DLM.
Using FTTC since 2011. Currently on 80/20 Unlimited Fibre Extra.
Re: exchange negotiates deliberately unstable 3dB target SNR from today- why ?
24-05-2011 5:02 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Plusnet Community
- :
- Forum
- :
- Help with my Plusnet services
- :
- Broadband
- :
- Re: exchange negotiates deliberately unstable 3dB ...