Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 [2] 3 4 5

Author Topic: Fastest ever downstream performance  (Read 17190 times)

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Fastest ever downstream performance
« Reply #15 on: January 20, 2017, 09:46:53 AM »

The ip profile doesn't change after I have supposedly changed the downstream target SNRM, and that is after having allowed a long time - far more than the suggested 4 hours - for the target change to take effect. Note that the actual SNRM

Line 3, supposedly with 3dB target

BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2556kb/s FTR=2278kb/s MSR=2848kb/s ServOpt=1 I/L=I
A SERVICE OPTION CHANGE ORDER IS IN PROGRESS ON THIS LINE
Up Sync=440kb/s LoopLoss=42dB SNR=6.6dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2898kb/s LoopLoss=64.9dB SNR=1.6dB ErrSec=12 HECErr=N/A Cells=0

Line 3, supposedly with 6dB target

BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2553kb/s FTR=2278kb/s MSR=2848kb/s ServOpt=1 I/L=I
A SERVICE OPTION CHANGE ORDER IS IN PROGRESS ON THIS LINE
Up Sync=426kb/s LoopLoss=41.9dB SNR=6.4dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2894kb/s LoopLoss=64.9dB SNR=1.2dB ErrSec=1 HECErr=N/A Cells=0
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Fastest ever downstream performance
« Reply #16 on: January 20, 2017, 10:27:42 AM »

Oh, and going back to something aesmith said earlier, what I meant about uncorrected errors was that the amount of error correction overhead in bits is a configurable parameter in ADSL - see G.992.3 §7.5 table of control parameters, and I don't know if modems might vary that as well depending on what the DSLAM says to them.
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Fastest ever downstream performance
« Reply #17 on: January 21, 2017, 09:29:11 AM »

I'd forgotten you're on 21CN, does that support different levels or depths of interleaving?  If so then that could affect the available rate.

FYI I just did a quick test to see the worst case effect from uncorrected errors by running a speed test from my desktop PC.   Speed test returned 2.74meg which is 96% of the current A&A line rate of 2842156.  That's with pretty much constant uncorrected error rate of 70 per minute, if my maths is right that's about 0.3% of full size IP frames being lost.   Would be interesting to see a Wireshark of a speed test on an error free line, I suspect there'll be quite a few retransmits due to drops on the wider Internet side.   

My 96% is a worst case because that's measured at a single PC without taking account of other traffic on the network here. To do a proper test I've found it effective to run multiple simultaneous downloads using something like ftp, then look at the total rate being received on the router.
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Fastest ever downstream performance
« Reply #18 on: January 21, 2017, 04:19:53 PM »

Conveniently my line's been running error free for a bit, and running a couple of speed tests shows pretty much exactly the same speed.  I think this confirms by belief that BT slowing a line down in response to high error rates is not for the good of the end user.   Also suggests that the noticeable but low error rates on Weaver's line probably isn't hurting anything.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Fastest ever downstream performance
« Reply #19 on: January 22, 2017, 05:01:20 AM »

I strongly suspect that the following is what things should look like.

I later made a similar attempt on Line 1, that is, I tried to apply a change from downstream target SNRM = 3dB to 6dB, and I got the following - see below. As you see, the process kicked off a training period with the expected retrains, the sync rate reduced and the SNRM increased following a BT-forced resync, although the SNRM actually looks like it's been increased from basically zilch to 3dB, rather than from 3dB to 6dB. Really ought to wait for the required few days now though to see if it does go all the way up to something like 6dB.

I maybe need to power-cycle lines 3 and 4?

But it seems anyway that lines 3 and 4 are not being successfully controlled by BT due to who knows what reason, either something in AA or in BT's systems. It's not just in respect of SNRM, it's in respect of the lack of ability to either derive or set the FTR to the appropriate values when MSR is limited to max of 2272.

-- log for Line 1 (@a.1) --

BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2512kb/s FTR=1817kb/s MSR=2272kb/s ServOpt=1 I/L=I
A SERVICE OPTION CHANGE ORDER IS IN PROGRESS ON THIS LINE
Up Sync=537kb/s LoopLoss=41.8dB SNR=6.1dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2678kb/s LoopLoss=64.9dB SNR=2.9dB ErrSec=0 HECErr=N/A Cells=0   cwcc@a
20 Jan 11:42:03   Tweet: Line UP 2017-01-20 11:41:19 cwcc@a.1 01471822470 IV49 9BN OnLine   AAISP
20 Jan 11:41:21   Tx rate (adjusted) 2503998 to 2354058   -Auto-
20 Jan 11:40:03   Tweet: Line DOWN 2017-01-20 11:39:55 cwcc@a.1 01471822470 IV49 9BN LostCarrier   AAISP
20 Jan 11:39:08   20 Jan 11:39:53   Test SNR reset: RateBandDS=160-24384 InterleaveLevelDS=On TargetMarginDS=6dB RateBandUS=32-Uncapped InterleaveLevelUS=On TargetMarginUS=6dB:SNR Recalculation initiated which will enable the line to reach optimum speed, stabilization retrains can be expected over the next couple of days.   cwcc@a
20 Jan 11:39:03   Update Update RateBandDS=160-24384.3dB->160-24384.6dB   cwcc@a
17 Jan 09:01:17   Tweet: Line UP 2017-01-17 09:00:18 cwcc@a.1 01471822470 IV49 9BN OnLine   AAISP
17 Jan 09:00:42   Tweet: Line DOWN 2017-01-17 09:00:17 cwcc@a.1 01471822470 IV49 9BN LostService   AAISP
17 Jan 07:41:10   BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2512kb/s FTR=1817kb/s MSR=2272kb/s ServOpt=1 I/L=I
A SERVICE OPTION CHANGE ORDER IS IN PROGRESS ON THIS LINE
Up Sync=541kb/s LoopLoss=41.6dB SNR=5.8dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2848kb/s LoopLoss=64.9dB SNR=1.1dB ErrSec=0 HECErr=N/A Cells=0
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Fastest ever downstream performance
« Reply #20 on: January 22, 2017, 11:31:45 AM »

I wonder if that SNR figure is in some way being misreported.  If you forget the absolute values, things otherwise look as expected with the change resulting in a reduced synch speed and correspondingly reduced BRAS and A&A rates.

Regarding the FTR/MSR figures if it works the way mine did then I'd expect them to change shortly to 288/288 and then to the correct figures at the end of the training period.  These won't affect throughput of course.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: Fastest ever downstream performance
« Reply #21 on: January 22, 2017, 11:57:54 AM »

I expect the behaviour of the SNRM is related to the performance of the modems, which perhaps achieve high speeds at the expense of stability.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Fastest ever downstream performance
« Reply #22 on: January 22, 2017, 02:48:53 PM »

ejs is certainly correct - these DLink DSL-320B-Z1 are super-aggressive and there is a small price to be paid for this, not normally a problem though.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Fastest ever downstream performance
« Reply #23 on: January 26, 2017, 05:44:44 AM »

No matter what I do, the SNR seems to be too low. A bit low even compared to 3dB, never mind the fact that the target is now supposed to be 6dB. This is true for all three lines, although I'm pretty sure that the ten day training period hasn't completed yet. There have been log entries and resynchs that strongly suggest that the lines are indeed in the training period though.
Logged

aesmith

  • Kitizen
  • ****
  • Posts: 1216
Re: Fastest ever downstream performance
« Reply #24 on: January 26, 2017, 09:06:01 AM »

I wouldn't worry about low reported noise margin unless either the error rate goes up or the line keeps dropping.  From what I understand your "problem" line has been more stable on the 6dB target?
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Fastest ever downstream performance
« Reply #25 on: January 26, 2017, 10:30:40 AM »

@aesmith: Line 1 is supposedly in the training period heading for 6dB, and indeed it has shown entries in the clueless logs that indicate that it is supposed to be doing it, yet the SNRM is still really low around 1dB. It shows little tiny flicks of packet loss a dozen times per day, very short periods each time, behaviour which the other lines are currently not exhibiting. So I'm not really worried about it, just monitoring it and wondering why nothing seems to really affect the actual SNRM achieved. The downstream sync rate went down very slightly, for something like 2550 to just under 2500 - I forget the exact numbers - after I supposedly adjusted the target. Maybe I do just have to forget about it until the ten day period is up, at least.

Even then, I don't know that I am going to actually do anything further about it, such as (trying) increasing the target to 9dB to see if that has any effect. I wouldn't want to lose any speed anyway as it is reliable enough currently, provided we don't get any more episodes such as the two-hour-long downtime with constant resynching that happened with line three a couple of weeks back.

These modems are just very aggressive and are perhaps just a bit waywardly so. I know there are modems that can apply a kind of offset target SNRM offset parameter, for want of anything like the correct term. Bet Bt really hate that. Maybe their defaults are just a little like that, but there does seem to be more to it, in that they do seem also to be unresponsive to pressure from BT+AA to (directly or indirectly) get them to change their behaviour.
« Last Edit: January 26, 2017, 10:34:13 AM by Weaver »
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: Fastest ever downstream performance
« Reply #26 on: January 26, 2017, 04:07:02 PM »

Without access to any bitloading data, we don't know if the DSL-320B-Z1 supports monitored tones (the ability to increase the bits assigned to a tone that had previously been bitswapped down to zero bits). If the modem can't do that, then it's pretty much inevitable that the SNRM will tend to decrease and not recover.
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: Fastest ever downstream performance
« Reply #27 on: January 26, 2017, 04:35:40 PM »

yeah pretty much every modem I ever used on adsl never remapped bits to a tone once it reached zero.

So that meant after the first night time period when my high tones were battered down to zero bitloading, my lower tones had higher bitloading and of course I loss overall snrm for the remaining lifetime of the dsl session.

It really is an eye opener how much more stronger the signal is on short lines vs long lines.

If you look at a vdsl2 graph, the adsl frequencies only take up a small portion at the very left.  On a 50db attenuated line (my old adsl line) then the strength of those tones was less than what I have on the far right of my vdsl line.  Even with massive power cutback my vdsl line has higher bitloading then I could achieve with adsl on the same tones.
« Last Edit: January 26, 2017, 04:38:43 PM by Chrysalis »
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Fastest ever downstream performance
« Reply #28 on: January 27, 2017, 11:09:37 AM »

I didn't know that about zero bit-loaded tones. Very good to know, makes a lot of sense regarding cheap implementations. And indeed SNRM does tend to head downwards montonically, so this would explain a lot.

q1: Perhaps this has some implications for the best time of day at which to reboot modems?

q2: Perhaps modems need to be rebooted regularly in any case? (if you can manage it)

Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: Fastest ever downstream performance
« Reply #29 on: January 27, 2017, 11:36:00 AM »

When and whether to reboot modems is down to what you deem most important on the line.

If stability is king then you want to reboot at night so you are syncing up during the time the line is at its weakest.
If raw performance is king then you do the opposite.
If you want the best of both worlds and dont mind downtime, then you could reboot when the sun comes up and again when it goes down every day.

The mystery of your snrm will probably be answered if you was plotting the historical behaviour of your lines.
Logged
Pages: 1 [2] 3 4 5
 

anything