Broadband Related > ADSL Issues
Uneven Latency - Imbalanced Rates
Weaver:
Line 3 current stats today below. Something has gone wrong and the line 3 upstream SNRM is actually right down to 3.2 dB from a 6dB target. I thought it was supposed to be 9dB target according to the AA clueless server. This problem has arisen, I think, because I commanded the modem to restart the link using a CLI command and it was done at a time when the up-down square-wave SNRM was in the high=good state/part of the day after which it later dropped to the bad/low state, down from 6dB. This was why I had been running it at a 9dB upstream target, so that it would have 9dB from which to drop to around 5dB during the bad part of the day.
Am I reading the following correctly? Looks like I am getting away with it, with the low upstream SNRM. Normally I would expect problems, based on experience from history.
But I cannot see any reason why line 3 upstream would be slow. I would expect to find evidence that it actually cannot keep up u/s in reality and is slower u/s than its upstream sync rate would suggest.
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 241 Kbps, Downstream rate = 3260 Kbps
Bearer: 0, Upstream rate = 419 Kbps, Downstream rate = 2916 Kbps
Link Power State: L0
Mode: ADSL2 Annex A
TPS-TC: ATM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 3.3 3.2
Attn(dB): 65.0 41.1
Pwr(dBm): 18.2 12.4
ADSL2 framing
Bearer 0
MSGc: 52 12
B: 33 5
M: 4 16
T: 3 8
R: 10 16
S: 1.4673 7.1680
L: 796 125
D: 2 4
Counters
Bearer 0
SF: 17702971 994832
SFErr: 109 12
RS: 770079254 4119412
RSCorr: 6822 188468
RSUnCorr: 281 0
ReXmt: 10706 0
ReXmtCorr: 10158 0
ReXmtUnCorr: 306 0
Bearer 0
HEC: 454 15
OCD: 3 0
LCD: 3 0
Total Cells: 1956678951 281504381
Data Cells: 32954672 8233824
Drop Cells: 0
Bit Errors: 12591 1290
ES: 36 11
SES: 13 0
UAS: 130 119
AS: 284479
Bearer 0
INP: 26.00 2.00
INPRein: 0.00 0.00
delay: 8 7
PER: 15.95 16.12
OR: 29.07 8.92
AgR: 2932.65 426.90
Bitswap: 60695/60765 6595/6595
Total time = 3 days 11 hours 23 min 44 sec
FEC: 7380 188468
CRC: 579 12
ES: 36 11
SES: 13 0
UAS: 130 119
LOS: 1 0
LOF: 9 0
LOM: 0 0
Latest 15 minutes time = 8 min 44 sec
FEC: 1 469
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 7 775
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 11 hours 23 min 44 sec
FEC: 399 14691
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 1690 48967
CRC: 1 5
ES: 1 5
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 3 days 7 hours 1 min 17 sec
FEC: 6822 188468
CRC: 109 12
ES: 25 11
SES: 2 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
Weaver:
Complete stats for all lines attached, in case this helps. I can’t think straight - in which direction should I line 3’s rate, up or down?
Weaver:
I did a brief experiment with line three set at 80% modem load factor instead of 90%. The results seem encouraging, in that an upload speed test with speedtester2.aa.net.uk gave 1.39 Mbps upstream at 80% instead of 1.26Mbps before at 90%. Those numbers are very accurate as I did a huge number of tests. The figure quoted is max, not arithmetic mean.
All very weird. You slow it down and it speeds it up.
I haven’t done a long enough test yet to see what’s what really clearly on the CQM graphs but I will do so later.
Weaver:
By the way, what’s the noise spike on all modems at bins ~125 - 127 ?
Weaver:
A result. After a lot of speed testing, I had a weirder breakthrough still. As far as I can tell, going all the way down to 70% is the answer for maximum throughput. The speedtester2.aa.net.uk reports 1.50 Mbps upstream combined when set at the following -
Firebrick’s upstream links : modem loading factors ::
Line #1: 95%
Line #2: 95%
Line #3: 70%
Line #4: 95%
So that’s the route back to full speed. But I have no idea what is going on here.
After having reduced the L3 modem loading factor (perhaps at 80% though, not down to 70% yet), I did manage to successfully level out the latency figures so that they were much more nearly balanced. For example comparing line 2 and the problem line 3 during a sustained flat out upload I read figures of
*L3:
Min 42.9
Avg 112.7
Max 161.6
——————
*L2:
Min 34.5
Avg 57.6
Max 95.3
Before this, the L3 latency figures were just really a bit uncomfortably high. I would rather not have things set up such that all other tasks - such as routine web browsing or DNS lookups - are a complete pain if during any upload. And certainly not if there isn’t even any good reason why I absolutely need to for upstream performance.
So current state of play now:
=== * Current upstream speed rates * ===
The Firebrick's internet access links have the following _upstream speeds_ (expressed as IP PDU rates) right now:
#1: 441111 bps
#2: 419265 bps
#3: 259404 bps
#4: 419265 bps
Total combined rate: 1.539045 Mbps
- These are the data rates used by the Firebrick on each link, expressed as IP PDU rates. These figures are always below the 'upstream sync rate' of each modem because overheads due to protocol layers below L3 have been accounted for. The reduced rate given here is the theoretical maximum calculated for each modem in the most optimistic possible scenario, based on sending a large packet, of a certain chosen size, upstream. In addition, a second reduction, the so-called 'modem loading factor' has been applied too. This reduction is based on experience and it has been tuned to get best upstream performance whilst avoiding overloading the modems.
Fractional speed contributions:
#1: 28.661% [██████████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]
#2: 27.242% [██████████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]
#3: 16.855% [████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]
#4: 27.242% [██████████████ ‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒]
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version