Kitz Forum
Broadband Related => ADSL Issues => Topic started by: Weaver on July 25, 2019, 06:59:51 PM
-
I’m still getting the same annoying line 3 upstream variation with 24-hour period. See pic, upstream is in green, the square wave:
(https://i.ibb.co/m04XcQM/8442208-D-5-A6-A-4279-9-D1-A-A7600-EBC134-D.jpg)
The target upstream is (supposedly) set at 9dB target SNRM. Now the intention was that the upstream was supposed to drop later following retrain or boot and drop from 9dB to 5dB, not from 6dB to 2dB. Yet for some reason the modem started at 6dB after it was booted or a retrain otherwise triggered, and then later the SNRM dropped right down from that 6dB to ~2dB. So in fact now surprisingly during part of the day the green upstream is actually below the red downstream which is around 3dB where it should be.
This has happened before a good few times. The odd thing is that as far as I can tell I now seem to be getting away with running at 2dB upstream whereas before when this happened, I am pretty certain, I was getting a serious error rate on the upstream that was very detrimental to performance. Iirc I reduced the upstream sync speed and the measured throughput got a lot better.
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 250 Kbps, Downstream rate = 3040 Kbps
Bearer: 0, Upstream rate = 412 Kbps, Downstream rate = 2788 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): 2.9 2.7
Attn(dB): 65.5 41.4
Pwr(dBm): 18.1 12.4
ADSL2 framing
Bearer 0
MSGc: 51 12
B: 32 5
M: 4 16
T: 3 8
R: 10 16
S: 1.4889 7.2846
L: 763 123
D: 2 4
Counters
Bearer 0
SF: 14915350 255571
SFErr: 895 9
RS: 637631222 2399862
RSCorr: 36862 265027
RSUnCorr: 7046 0
ReXmt: 59688 0
ReXmtCorr: 54418 0
ReXmtUnCorr: 7309 0
Bearer 0
HEC: 5529 8
OCD: 196 0
LCD: 196 0
Total Cells: 1572009115 232784059
Data Cells: 43202508 7628938
Drop Cells: 0
Bit Errors: 156506 1014
ES: 401 9
SES: 0 0
UAS: 57 57
AS: 239070
Bearer 0
INP: 26.00 2.00
INPRein: 0.00 0.00
delay: 8 7
PER: 15.91 16.39
OR: 28.65 8.78
AgR: 2804.62 420.07
Bitswap: 41695/41697 3455/3455
Total time = 2 days 18 hours 25 min 27 sec
FEC: 36862 265027
CRC: 895 9
ES: 401 9
SES: 0 0
UAS: 57 57
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 10 min 27 sec
FEC: 31 1057
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: 63 1281
CRC: 2 0
ES: 2 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 18 hours 25 min 27 sec
FEC: 2190 57435
CRC: 5 2
ES: 5 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 26280 126705
CRC: 867 5
ES: 385 5
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 2 days 18 hours 24 min 29 sec
FEC: 36862 265027
CRC: 895 9
ES: 401 9
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
The upstream errors don’t look too bad at all? What do you think.
Mind you I’m thinking that the downstream is iffy - it’s ok now but had a really bad period in the past which it could not cope with. Does that sound right?
-
After an absence for a while, as I mentioned in another thread, the line 3 upstream square wave thing is back again.
Here are the line 3 stats, with target upstream SNRM set to 9dB. This snapshot is taken in the SNRM-high part of the daily cycle. By this I mean that later on, within less than 24 hours, the upstream SNRM should drop sharply in this case, by about 4dB, then so many hours later it should jump back up.
— Line 3 —
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 321 Kbps, Downstream rate = 3088 Kbps
Bearer: 0, Upstream rate = 389 Kbps, Downstream rate = 2807 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.1 9.1
Attn(dB): 65.0 41.1
Pwr(dBm): 17.9 12.4
ADSL2 framing
Bearer 0
MSGc: 52 11
B: 32 5
M: 4 16
T: 3 8
R: 10 16
S: 1.4792 7.7241
L: 768 116
D: 2 4
Counters
Bearer 0
SF: 37522 36999
SFErr: 0 0
RS: 1632222 313907
RSCorr: 9 0
RSUnCorr: 0 0
ReXmt: 2 0
ReXmtCorr: 1 0
ReXmtUnCorr: 0 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 4024079 555792
Data Cells: 58564 10216
Drop Cells: 0
Bit Errors: 0 0
ES: 26358 99
SES: 4891 0
UAS: 10777 8052
AS: 608
Bearer 0
INP: 26.00 2.00
INPRein: 0.00 0.00
delay: 8 8
PER: 16.08 16.41
OR: 28.84 8.28
AgR: 2823.00 396.16
Bitswap: 192/192 8/8
Total time = 36 days 2 hours 46 min 7 sec
FEC: 263198 166305
CRC: 127201 61
ES: 26358 99
SES: 4891 0
UAS: 10777 8052
LOS: 612 0
LOF: 589 0
LOM: 1330 0
Latest 15 minutes time = 1 min 7 sec
FEC: 0 0
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: 71 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 55 55
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 2 hours 46 min 7 sec
FEC: 1865 2
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 55 55
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 7686 74201
CRC: 961 3
ES: 41 3
SES: 29 0
UAS: 173 162
LOS: 1 0
LOF: 9 0
LOM: 0 0
Since Link time = 10 min 7 sec
FEC: 9 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
Need to compare this with the values in the u/s-SNRM-low part of the cycle, as a recheck.
-
Unfortunately this is the high part of the cycle again, so disregard but it might be interesting for comparison. Snapshot taken just after forcing a retrain, so the attn value shown should be current.
Will need to try to remember later on and get a snapshot at the right time
— Line 3 2019-09-20T00:50:00 ; again high part of cycle? —
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 325 Kbps, Downstream rate = 3120 Kbps
Bearer: 0, Upstream rate = 389 Kbps, Downstream rate = 2774 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.2 9.0
Attn(dB): 65.0 41.1
Pwr(dBm): 17.8 12.4
ADSL2 framing
Bearer 0
MSGc: 53 11
B: 31 5
M: 4 16
T: 3 8
R: 12 16
S: 1.4508 7.7241
L: 772 116
D: 2 4
Counters
Bearer 0
SF: 0 549
SFErr: 0 0
RS: 0 4658
RSCorr: 0 0
RSUnCorr: 0 0
ReXmt: 0 0
ReXmtCorr: 0 0
ReXmtUnCorr: 0 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 5651
Data Cells: 0 12
Drop Cells: 0
Bit Errors: 0 0
ES: 26377 100
SES: 4900 0
UAS: 10978 8253
AS: 9
Bearer 0
INP: 26.00 2.00
INPRein: 0.00 0.00
delay: 8 8
PER: 16.04 16.41
OR: 29.40 8.28
AgR: 2790.35 396.16
Bitswap: 4/4 0/0
Total time = 37 days 3 hours 2 min 51 sec
FEC: 277951 168296
CRC: 127655 62
ES: 26377 100
SES: 4900 0
UAS: 10978 8253
LOS: 613 0
LOF: 597 0
LOM: 1330 0
Latest 15 minutes time = 2 min 51 sec
FEC: 23 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 59 59
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 249 0
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 = 3 hours 2 min 51 sec
FEC: 3492 0
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 59 59
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 13126 1993
CRC: 453 1
ES: 18 1
SES: 9 0
UAS: 197 197
LOS: 1 0
LOF: 8 0
LOM: 0 0
Since Link time = 9 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
-
This might or might not represent the low part of the cycle; there was a retrain early in the morning and I forced a retrain just before capturing this snapshot in order to make sure the reported attenuation figures would be up to date.
Line 3: 2019-09-21:
(https://i.ibb.co/kXx5Nng/42-F45-F33-6873-476-A-9618-26-C7-DDADA33-A.jpg)
Snapshot of stats after retrain:
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 276 Kbps, Downstream rate = 3052 Kbps
Bearer: 0, Upstream rate = 352 Kbps, Downstream rate = 2748 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 6.0
Attn(dB): 65.0 41.2
Pwr(dBm): 17.7 12.4
ADSL2 framing
Bearer 0
MSGc: 52 11
B: 31 4
M: 4 16
T: 3 9
R: 10 16
S: 1.4642 7.1111
L: 754 108
D: 2 4
Counters
Bearer 0
SF: 20764 19593
SFErr: 0 0
RS: 903248 187192
RSCorr: 41 2
RSUnCorr: 0 0
ReXmt: 2 0
ReXmtCorr: 2 0
ReXmtUnCorr: 0 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2158686 273397
Data Cells: 3687 8136
Drop Cells: 0
Bit Errors: 0 0
ES: 26388 101
SES: 4910 0
UAS: 11103 8368
AS: 334
Bearer 0
INP: 26.00 2.00
INPRein: 0.00 0.00
delay: 8 7
PER: 15.92 17.00
OR: 29.14 8.00
AgR: 2764.79 358.59
Bitswap: 147/147 8/8
Total time = 38 days 23 hours 12 min 59 sec
FEC: 311878 171800
CRC: 128120 64
ES: 26388 101
SES: 4910 0
UAS: 11103 8368
LOS: 614 0
LOF: 606 0
LOM: 1330 0
Latest 15 minutes time = 12 min 59 sec
FEC: 258 12
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 65 65
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 718 9
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 23 hours 12 min 59 sec
FEC: 21461 1168
CRC: 465 0
ES: 11 0
SES: 10 0
UAS: 125 115
LOS: 1 0
LOF: 9 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 15958 2336
CRC: 1 2
ES: 1 1
SES: 0 0
UAS: 59 59
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 5 min 33 sec
FEC: 41 2
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
-
The US attenuation does not seem to have changed . . . 41.2 dB looks familiar.
-
The time of day would suggest that is yet another high-part-of-cycle snapshot. I will try again later after I have clearly seen it drop.
So I took another look
And
hello, no cycle in the last 24 hours up to the present now! Things have become irregular!
In the following picture, the glitch in the centre was the forced retrain last night when I took the previous stats snapshot. The present time as usual is on the right. Sunday morning, the present, is the last sample.
(https://i.ibb.co/QvrHXRN/D6-BEF64-E-2-EFC-4-F13-86-C7-2-DA38-D7898-D5.png)
-
In another thread I said the line 3 upstream diurnal cycle thing was fixed by the post lightning strike repairs. I jinxed it by speaking too soon. It’s back, and in a slightly worse form if anything; the latest jump upwards is about 5dB.
(https://i.ibb.co/85vCZ9W/3-CAED7-DB-EF63-46-A2-B29-F-78809-EA74-FE3.png)
The exceptionally high values seen in the graph are no bad thing at all though. It just seems that the above picture shows an exceptionally good, very quiet period. The upstream sync speeds associated with these SNRM values are much much better, at around 500kbps for 6dB, compared with the sync rates that I was having to put up with before - of around 400k, or ~350k or even worse.
-
Latest line 3 capture, very high upstream SNRM (in green) step, 6dB high, all the way down to a ridiculously low SNRM of 0.5 dB, which is worrying; however despite the low value the error count in the stats seems to be fine, so it seems that I am managing to get away with it, and it must just be a quiet line or one with a type of noise that the interleave and FEC can handle well.
(https://i.ibb.co/Nm7kTV3/AAB8-FBBE-68-D9-4-B5-E-A894-2-AE339649-DFE.png)
I don’t know why this isn’t obeying the configured target upstream SNRM which is supposed to be 9dB. I perhaps need to get a forced retrain that is initiated externally and not from a command entered at the modem CLI, which is what I had done here earlier. I don’t know where it is getting the high step value of 6dB from, unless it’s just some fixed default. I don’t know how the clueless target SNRM is supposed to get enforced either.
-
So it seems that the weirdness has became even weirder. I am unable to rationalise what is taking place. (Even with some rather fantastic flights of fancy.)
-
:hmm: ???
I take it there is nothing corresponding on the other lines at the same time.. either upwards or downwards?
-
the very sudden movement up and down is the type of pattern seen when a piece of equipment is turned on and off. So a device somewhere is causing that probably.
-
@kitz
The other lines :
line 1 - no pattern at all
Line 2 - irregular pattern, smaller height
Line 4 - no pattern.
Today, line 3 retrained on its own for some reason and was in the low SNRM state; it then went up to 9dB following its target set by me. But 9dB was the new ‘low’ so after so many hours it went up to 14dB and is ridiculously slow at 240kbps, about half of what it should be. That’s the problem with a variation this large, the sync speeds are usually way wrong.
-
Picture for crazy line 3, now super slow u/s. The link dropped for whatever reason while in the ‘low’ state, as I mentioned before and that’s why it is now so ridiculously slow. And the 9dB target was my own idea.
Line 3:
(https://i.ibb.co/whBQYgb/4-D444-F46-38-F7-4-E79-9112-5-E47-C3-C7125-F.png)
I don’t suppose there’s any chance of identifying the source, is there? But how could it be only this one line?
-
Link 3 continues as useable, look how enormous the drop is, and the low value is rather worryingly low. The 9dB target is not helping me:
(https://i.ibb.co/WncVm88/9-C119186-1-DD6-4484-971-F-91476127-F80-A.png)
Line 1 is back to normal :
(https://i.ibb.co/MDfjV62/6-FB111-AF-574-B-4094-9-AB6-E2-B3-AC1-E577-E.png)
-
I think you might need to consult with the A&A wizards, to check if they can see anything untoward happening when monitored from their end of the circuit. I wouldn't expect anything to be seen but it would be worthwhile checking.
-
Agreed. I think so. I talked to them about a year ago, but we didn’t get very far.
I don’t suppose there is any such thing as a fixed upstream sync rate, is there? Set at the BTOR end by AA? I’ve never heard of such,
There are two practical problems arising from this:
1. possible low sync rate upstream, because a retrain happened in the low SNRM period. This is a nuisance, but it is necessary and we could say ‘it is what it is’ unless the noise problem can somehow be fixed.
2. In the case where there is a retrain in the high SNRM period, we are going to end up with a dangerously low SNRM later on.
Since the first issue is not critical, the real problem then is the second issue. The question is how much trouble is it going to cause in the latter case? Can we get away with running at the low SNRM. Need to look at the stats. What exactly should I use as a decision criterion?
One other thing - I wonder if I could improve things by changing the configuration of the modem? Is there a way to prevent reconnecting at a silly sync rate ?
-
I have been thinking about the external "noise" problem on line 3.
By virtue of your ISP you have full control of the target SNRM for all lines. For three out of four lines you have found, by experiment, that a target SNRM of 3 dB leaves you with sufficient signal "headroom" (over any noise) and a corresponding increase in synchronisation speed (over that which would be obtained with the default target of 6 dB). In the case of line number three, suppose you were to configure it exactly as lines one, two and four. At some point, there is a possibility that the corresponding modem will re-train to accommodate a negative SNRM. Would that line eventually "find its own level"? Possibly. :-\
My proposal is that you set all four lines with a target SNRM of 3 dB and for the next seven days monitor but do not react to any changes. Does your overall connection remain usable? Is Mrs Weaver able to do all she requires for her business? Are you still able to download the large files during the A&A off-peak period?
-
I would say that 3dB on the downstream is fine for two reasons -firstly because the variation is small enough, and possibly secondly the PhyR has such a powerful beneficial effect that I can get away with a lot, covered up by L2 retransmissions. But I would expect to need a much greater upstream target SNRM to achieve the same error rate because of the unfortunate lack of L2 retx capability in upstream. (I think it is absent on upstream anyway)
It might just happen to be though that I can get away with low upstream SNRM anyway because of the character of the noise. One other thing. Shorter packets mean lower probability of error per packet, if so measured, rather than if measured per byte and there is a the preponderance of TCP ACKs going upstream which are always short unless piggybacks.
You’re absolutely correct about the ‘learn to stop worrying thing’. The only reason that I’m interested in error rate is because it might be a source of poor performance and the time taken to do a backup - 40mins or upload a photo - 1 min sometimes - is annoying.
I could do with some guidance as to how to assess the error stats and label them adequate or not, in terms of corrupt packets per unit time.
One other point, I think it’s important to have upstream link be reliable because if an ACK going upstream gets lost or corrupted then that means an avoidable TCP payload retransmission which could well be a full 1532 bytes, which I am paying for.
If I do find out that there is any serious corruption problem with line 3 though then I will think about axing it.
-
Testing on our circuit when it was running error free, compared to when it was experiencing around 75 CRC per minute, showed no difference in download speeds. I'm sure I took Wireshark traces at the time, but can't think where I saved them. Looking at the two there were zillions of duplicate acks etc, showing that lots of packets were getting lost and retransmitted. My informal conclusion was that an error rate of something like 1 in 250 wasn't significant compared to what goes on in the wider Internet.
-
@aesmith so that would be a good order of magnitude metric to look for, CRCs per min > 250 during a flat out download and then an upload ? I would need to rescale that according to my link speed vs yours though as you will be getting x times more packets per second through compared to me.
If there were a problem with corruption of upstream packets then that would of course massively increase the probability of an error per packet because then the upstream packets would be those that are long, either ~16 times longer or 10.6 times longer depending on TCP IPv4/IPv6 with or without TCP timestamps. So that many times greater probability of uncorrected corruption of a packet, per packet.
Anyway, I would want to look at both directions.
(1) The figure of 16 for IPv6 = ( 1500 + 32 ) / (2*48) assuming an IPv6 TCP ACK is 60 + 32 bytes long which fits into 2 ATM cells and my total protocol stack overhead overhead is 32 bytes for everything from PPP to AAL5 CPCS, or if we add TCP timestamps at an extra 12 bytes that total of 60 + 12 + 32 would push us into 3 ATM cells for a TCP ACK so that would be 10.6 times longer packets.
(2) I’m telling myself, to a first-order approximation, if the probabilities are really small then n times longer means n times greater probability, or accurately pn = 1 - (1 - p)n. Is that right?
-
I’m suddenly having my doubts. I was talking about L3 PDUs before and doing an upload/download to generate some activity, but I’m completely wrong about that, am I not? In DSL with ATM, do idle cells count for CRC-counting testing purposes ? Do I actually need to do a flat-out transfer or not ? No L3 PDUs are getting sent but that doesn’t mean we cannot rack up a CRC count?
The CRCs counter - is showing CRCs in what per stated time interval? Is it per frame of L bits passed down to the lower layer as in the FEC frame structure table - so per call to a PMD.Bits.confirm primitive ? So I need to look up the L framing parameter and then multiply that by the number of bits in a packet to convert CRC stats to the probability of a packet of length n being corrupted.
-
I must say haven't looked at where the CRC is applied, whether at PPP or ATM or what. My reference example was based on a presumption that each CRC error would directly or indirectly kill off one IP packet. On that basis with an IP profile of 3,500,000 then downloading at full speed with full size packets would be about 290 packets per second. An error rate of 72 per minute means the loss of one in 241 or around 0.4%.
By the way, thinking about the reverse channel, packets lost as opposed to delayed would have much less effect. Let's call them "ACKs" on the basis that if the higher level data flow is unidirectional, they don't increment SEQ. Their only purpose is to pack the ACK counter back to the sender. If one is lost then nothing needs to be retransmitted, at worst the sender might see their window emptying sooner than it ideally should, but the situation would be fully resolved once the next ACK is received. So like voice and video, these packet should be treated as "better never than late".
-
@aesmith I was thinking exactly like you. But referring to the framing layer in G.992.3 table 7-1 this is at a level that is too low for there to be a knowledge of for example PPP or IP. And if you get CRC errors when there are no L3 PDUs being exchanged then that proves it.
In the context of table 7-1, you could get several FEC errors per L3 PDU of course, as each has only L bits (see table 7-6) in it. So counting the number of such errors would need to be converted to number of bad L3 PDUs by rescaling according to n_bytes_in_L3_PDU and the L framing parameter.
-
Agreed, you could be losing fewer IP packets than the number of CRCs. How to work that out is a bit beyond me. Intuitively my feeling is that it's unlikely unless there's some special pattern to the CRCs, like coming together in rapid bursts. If they're randomly spaced, 72 in every 60 seconds, then what is the chance of any one packet taking around 3.5ms experiencing more than one?
-
Indeed, the chance is low. But the probabilities still need to be rescaled, my best guess is, from one event per L bits rescaled up to events per round_up( (1500 +32 ) / 48 ) * (48 + 5) * 8 bits ie per L3 PDU to be a useful scaled value which tells us how many L3 PDUs get corrupted.
For my line 1, For example
L downstream = 805 bits,
L upstream = 170 bits,
so the probability scale factor would be ( round_up( (1500 +32 ) / 48 ) * (48+5) * 8 / L ) ; which is to be multiplied by the probability of corruption of one FEC frame to get the per-L3 PDU corruption probability, assuming the probability is low so first order is good enough, which it is, and then some. This is all assuming that I have understood the modem stats correctly and read the G.992.3 spec section 7 correctly, that is.
-
Someone check my reading -I’m pretty sure the preceding posts are wrong - I misremembered the definition of L - isn’t that parameter the number of bits per symbol ? So not what I want at all. I think in the preceding discussion where I wrote L, I should have written NFEC = M * K + R bytes, where K = B+1 ; from table 7-7
Downstream Upstream
Bearer 0
MSGc: 53 12
B: 33 62
M: 4 1
T: 3 1
R: 10 14
S: 1.4509 3.6235
L: 805 170
D: 2 8
So therefore we have
downstream : NFEC = 4*(33+1)+10 = 146 bytes, and
upstream : NFEC = 1*(62+1)+14 = 77 bytes.
So is it correct then to say that the CRC stat counter is the number of events per every unit of 146 bytes d/s or 77 bytes u/s ?
Edit: or would it be more appropriate to leave out R and just consider M * K alone? As then we are comparing like with like? That is, bits from the upper layer data stream only. So instead, we would have 136 bytes downstream and 63 bytes upstream instead.
-
I'm not convinced you need that level of detail to analyse the impact of a given data rate. My understanding is that CRC errors are uncorrected errors, meaning that data is lost. I can't see that it makes any difference at what layer these are detected and recorded, until you reach a higher level correction. I see this simply using my figures as 60 seconds during which 17,400 packets were transmitted, and during which there were 72 uncorrected errors. Would it be over simplistic to say that the chance of one packet receiving two errors as being one in 241x241, ie one in 58,000?
-
You’re absolutely 100% right. I’m working from one end, low to high and you’re working down from the other direction. My L give the link speed which you are using. I only looked into this as I wanted to know the answer to the question ‘errors in what/per unit’, that’s all. The probabilities are so low that first order is good enough and there’s effectively no chance of losing an error count because two errors occurred in the same FEC frame or even in the same L3 PDU. And if there is an error burst, then so what.
I only looked into this because I realised that I had forgotten what the units of the figures being quoted in the stats are.
-
Now, for some reason, the upstream rate is far better: 1.44 Mbps from speedtest2.aa.net.uk (the journey is from the miserable ~1.2Mbps up to what I used to attain = ~1.5Mbps; best 1.56Mbps.) I don’t know why this is is say 0.150-0.20 Mbps better. Also all of the downstream results are quite a lot better that what they were. They were around 2.7-2.8Mbps before.
Live sync rates:
#1: Up Sync=560kb/s LoopLoss=40.4dB SNR=5.9dB ErrSec=0 HECErr=0 Cells=0
Down Sync=3034kb/s LoopLoss=65dB SNR=3.0dB ErrSec=0 HECErr=N/A Cells=0
#2: Up Sync=532kb/s LoopLoss=40.9dB SNR=6.4dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2836kb/s LoopLoss=64.5dB SNR=3.8dB ErrSec=0 HECErr=N/A Cells=0
#3: Up Sync=452kb/s LoopLoss=40.4dB SNR=1.7dB ErrSec=1 HECErr=0 Cells=0
Down Sync=3005kb/s LoopLoss=64dB SNR=3.5dB ErrSec=0 HECErr=N/A Cells=0
#4: Up Sync=502kb/s LoopLoss=40.9dB SNR=6.3dB ErrSec=0 HECErr=0 Cells=0
Down Sync=3004kb/s LoopLoss=64.5dB SNR=3.4dB ErrSec=0 HECErr=N/A Cells=0
I always take the highest results and discard the rest, because we are trying to measure the capabilities of the link itself, not a particular software implementation or protocol or a particular capability in a certain scenario.
-
Latest 24-hour pic for line #3 SNRM; upper, green is upstream, red is downstream:
(https://i.postimg.cc/BQbJmgyP/B71-D58-D4-5028-46-A7-94-EB-9-F6-BB3-E9-BC8-B.jpg)
So the question: what happened at 23:45 approx and then unhappened at 10:35.
-
So the question: what happened at 23:45 approx and then unhappened at 10:35.
:shrug2:
The revenge of the haggis? :-\
-
Indeed so. That’s about all I have to suggest too. Is it possible that there is some underlying parameter somewhere that changes slowly until some threshold tipping point is reached in a highly nonlinear system, at a point where there is a very very large dy/dx and then a dependent variable’s value jumps sharply, giving us this +/-4.9dB-high upstream SNR jump. Like a transistor being used as a switch perhaps.
Would a semiconducting point-contact dodgy metal-metal semi-make-break contact work for this, a crack or metal-metal joint without sufficient inter-contact pressure, something that expands and contracts with temperature ? But I’m not sure at all that I can believe the timings in that case, as the timings aren’t right for temperature changes vs sunrise/sunset. I can’t think how an rf interference source might get gated on/off on those timings. But perhaps it’s a detector that is changing, not a source: a non-linear RFI receiver that is getting enabled/disabled somehow and is either hearing or not hearing, or relaying vs not relaying detected noise.
-
I've tried to think of anything that might match . . . even inverting the logic to consider that the low SNRM period is good, the high SNRM period is bad.
The fact that we see a very distinct step just keeps "screaming" at me: switched on/off or switched off/on.
-
Im sure you’re right; Only switched on/off really makes sense to me; the rest is speculation that is stretched to breaking point. I just cannot think what it is and why the times. But worst of all, why only that line line #4 ; line #2 sometimes has similar trouble but a different pattern and lower height.
That’s why I like the copper with a bad joint/crack in it idea; it allows line #4 to be different from its brothers. But that fantasy has so many problems.
-
We do know that one out of the four lines, that carry your service, was provisioned differently. A pair was diverted from one cable to another . . . either in Harapul or Broadford.
However we do not know if that situation still exists subsequent to the high energy lightening zap which took out all circuits to Heasta and caused significant mischief in the Broadford <--> Harapul cabling. We have heard (in the third party sense) that some new cables had to be installed somewhere in the afore mentioned section of the route. Hence there is the possibility that your four lines now take a different route though the network to the Broadford exchange building.
-
I see your point but it’s line 2, the last ordered, that has the different route Broadford exchange to Harapul no?
I don’t understand why it is line 3 that is the odd man out though; I could understand it if it was line 2 that was the odd man out, not line 3; well line 2 is odd but that isn’t the point. why is line 4 ok ? Line 3 was the second line ordered historically. That’s what’s worrying me.
What story can we invent that gives a different noise ingress or reception picture for differing E-sides here anyway? How much in general can E-sides differ?
-
Last question first. It's not so much as to how can E-sides, in general, differ but where in the cable does your pair reside. What is the effect of its neighbouring pairs? As a new section of cable has been "patched in", it certainly will not preserve the relative positioning of the pairs which existed in the old cable.
I can never remember the logical ordering of your pairs, hence why you (privately) shared the four BBEU numbers with me. Can you be absolutely sure that what you originally called line 3 (for example) is still line 3?
[OT]Did anything ever come of CarlT's offer to ask somebody, who knows somebody, about the Internet service provision situation for your remote location?[/OT]
-
> I can never remember the logical ordering of your pairs, hence why you (privately) shared the four BBEU numbers with me. Can you be absolutely sure that what you originally called line 3 (for example) is still line 3?
Chronological ordering
- Line 1 first
- Line 3 second
- Line 4 third
- Line 2 2018
I’m not completely sure about the assignments into the individual drop cables.
I don’t understand the point about relative position in the cable. Perhaps you could elucidate?
-
I don’t understand the point about relative position in the cable. Perhaps you could elucidate?
Some circuits can be noisier that others. So perhaps your line was surrounded by telephony-only carrying pairs, in the original cable, but now has xDSL carrying pairs adjacent to it, in the new cable.
-
So a neighbour crosstalker, carrying DSL, which was only switched on half the day, and only produces low-frequency interference not higher frequency - is that what we’re talking about?
Some people do turn their kit off at certain times.
For 02-03 feb, the line #3 upstream pattern would have to be :
- 00:00 - 11:30 :- crosstalker ON
- 11:30 - 21:40 :- crosstalker OFF - SNRM 4.9dB lower
- 21:40 - 00:00 :- crosstalker ON
-
Hi
I had a similar thing, for 2 weeks over the summer holidays on ADSL2+ it would suddenly improve, then drop again exactly 2 weeks later, happened 3 years on the trot. Was it crosstalk or did someone have some noisy electrical equipment that went off when they went away, was it a factory taking a 2 week shutdown over the summer, no way of knowing.
If I was constantly monitoring the stats then no doubt I would be seeing little peaks and troughs constantly. People do turn their stuff off and on and noise comes and go, hence why there is a margin. You will even see changes in noise due to certain weather conditions and how it affects radio waves.
I think you just have to accept that the way the technology is, xDSL is highly variable and it is just constantly shifting sands, especially long lines such as yours that is already optimised to the maximum. I would just stop looking constantly, you'll drive yourself mad ???
Hopefully at some point you will get FTTP or even could take a satellite service, and the issues of noise and cross-talk will become a distant memory.
Regards
Phil
-
I ignore line 2, but line 3 has a 4.9db variation in upstream SNRM, and that is causing a loss of upstream speed of 25%
-
Hi
I ignore line 2, but line 3 has a 4.9db variation in upstream SNRM, and that is causing a loss of upstream speed of 25%
Still kind of within the bounds of design hence a 6db margin. Of course you could look at it another way, you sometimes get an increase of 25%, and the lower speed is the norm for that line.
Also your 25% lower upload speed on one line when taken into account over 3 lines luckily means only a ~8% overall difference in upload speed. Given it is ADSL even with 3 lines it's never going to be a fast upload speed, so it means something large uploading might take 100 minutes sometimes and 92 minutes another, and you would not notice that in day to day use, 92 minutes is painfully slow the same as 100 minutes is painfully slow :'(
Any sign of fibre coming your way or options to move to 4G yet? Satellite might be the best option for you in the coming months as they launch new services.
Regards
Phil
-
I don’t know about FTTC/FTTP but unless they decide to put one or two cabs in the village we are just stuffed, as it’s 7300m from me to the exchange, and after the first mile there’s not a single house, tree or wall
-
Time to stick WiFi repeaters on sheep?
-
The thing that bothers me about the low upstream is that it is a mismatch vs the others, and this may, for all I know, have a bad effect on the workings of the traffic splitting algorithm that the Firebrick’s upstream egress subsystem uses. If the lowest link speed affects the total effective upstream rate disproportionately then that is a bad thing, whether it be because it is mismatched compared with the next-to-slowest, or compared to the fastest link rate. I don’t know what it is that matters, the slowest speed, or the size of the gap, or what.
Upstream is important to me because it’s so slow anyway, it’s a nightmare: uploading photos and doing a backup that can take 40 mins [!]. So I am determined to get the very best upstream effective total rate that I can. I have been through periods when I was for some reason not getting the effective total that I should be when all allowances for overheads are deducted and this is compared with much superior historical rates that are fine comparing the effective combined total rate to that expected from calculations including overheads. Then later on such sub-optimal combined effective performance just goes away. Recently the effective combined vs calculated total has been incredibly good, >%90 even.
-
Off topic and possibly totally irrelevant, but I was reading this evening about the large amount of changes merged into the upcoming 5.6 linux kernel (https://www.phoronix.com/scan.php?page=article&item=linux-56-features&num=1), one that caught my eye (apart from the mainlining of Wireguard) was TCP multipath (https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.6-Starts-Multipath-TCP).
Maybe this could soon alleviate a lot of load balancing issues people with multiple lines face? First I've heard of it, so have no idea, but thought it was interesting enough to post.
Edit: Wireguard not shark
-
I don’t know about FTTC/FTTP but unless they decide to put one or two cabs in the village we are just stuffed, as it’s 7300m from me to the exchange, and after the first mile there’s not a single house, tree or wall
I am worried that from an economic point of view they might think that it is not worth it to do that or at least would not be in a hurry as the service and speeds would really suck given the distance to the exchange...
-
I am worried that from an economic point of view they might think that it is not worth it to do that or at least would not be in a hurry as the service and speeds would really suck given the distance to the exchange...
Eventually they want to remove all copper from the Openreach network, so it is going to go, the only question is when.
They will either run fibre optic cable to the property or do nothing at all I should think. If they do nothing than USO kicks in, so it will be either connection to the net via the mobile phone network or satellite, either way I should think it would be more reliable than a balancing act of 4 ADSL lines that keep getting problems.
Regards
Phil
-
@johnson I know that Apple has TCP multipath. I assumed for no good reason that it was Apple’s invention. They use it for Siri to bind Wi-Fi and 4G together, for uploading audio, and getting the analysis of it and responses to queries back. They way they use it is that whichever works wins, they get double speed or more especially on the terrible upstream and they perhaps send stuff twice to make sure it gets there and very soon.
-
@philipd I never ever get any problems at all. The IP bonding works superbly, it’s extremely reliable even when lines go down and it always just sails through. It’s fast too: 10.5/1.5 Mbps. I’m extremely happy with it. 4G has shocking upload here; 16/0.4 Mbps measured on the iPhone with EE (sometimes get 24-26 Mbps). The lines themselves are spectacularly good considering their length, because the copper is report problems on the forum just in case people are interested in extreme rural DSL.
-
@philipd I never ever get any problems at all. The IP bonding works superbly, it’s extremely reliable even when lines go down and it always just sails through. It’s fast too: 10.5/1.5 Mbps. I’m extremely happy with it. 4G has shocking upload here; 16/0.4 Mbps measured on the iPhone with EE (sometimes get 24-26 Mbps). The lines themselves are spectacularly good considering their length, because the copper is report problems on the forum just in case people are interested in extreme rural DSL.
Hi
Always seems like you are having problems though, it is one thing after another, from lightening strikes to noise :) Even if you have a fail over in place lines going down is a problem isn't it?
I would wager an external mounted antenna pointing in the right direction would get you some pretty decent 4G speeds. I stayed at a converted barn for a couple of weeks in the middle of nowhere where all the coverage charts for the mobile networks said no coverage of anything, but they had Wi-Fi in the barn as well a telephone, so I wondered how they had done that, of course a phone yes, but it was miles and miles from the telephone exchange and no FTTC so wondered how they had done broadband. Turns out it was an external mounted 4G antenna on Three, getting around 30/10 on the speed tests I tried, and the phone was a Cisco VoIP phone. None of us staying there had any coverage on our mobiles, but the mounted antenna pulled in a pretty decent signal.
Obviously if you enjoy all the tinkering and fault finding with the copper lines etc which seems like you do, a bit like keeping an old car running as a hobby rather than a necessity, absolutely fair enough.
Regards
Phil
-
I only get 16-24 / 0.4 Mbps as measured by the thinkbroadband speed tester on an iPhone with EE and 2 ‘bars’ of signal. I can’t live with that upstream. The problems I have with 4G are the unpredictability in speed terms, and poor availability. It just vanishes for several days on end for no reason on occasion and dies when there is a power cut. So I can’t live with something that isn’t close to 100% availability and my DSL lines are highly reliable. The wild weather is part of the charm of living here. DSL is for me the optimal choice given what I practically have. I’d like to investigate combining it with 4G but I don’t know enough about the available kit and I’m too exhausted to research lots of unknown hardware. You need to appreciate that the level of drugs I’m on and yet still I’m in pain much of the time constrain my options practically.
This is just the general experience of living here. Other people in the village have no internet connection at all this week because the lightning (or high wind) has knocked out the local long-range wireless network that they are using. I’m just used to it. I write it up for all your enjoyment in case people are interested. I don’t suffer from RF noise, unless the weird line 3 upstream thing is caused by it but that seems incredible.
-
. . . I would wager an external mounted antenna pointing in the right direction would get you some pretty decent 4G speeds. . . .
At the Weaving Shed's location any externally mounted metal-work would be a definite lightning attractor -- I would advise against having an external aerial.
-
Philip saw 30/10; wonder why my upstream 4G is so dire at 0.4Mbps?
-
At the Weaving Shed's location any externally mounted metal-work would be a definite lightning attractor -- I would advise against having an external aerial.
If things are that bad he needs to get a lightning rod/conductor installed then, besides metal work on that scale doesn't 'attract' lightning it's a myth (https://stormhighway.com/small_metal_objects_attract_lightning_myth.php), in fact it can do the complete opposite, hence metal rods with sharp points are mounted on tall buildings (https://science.howstuffworks.com/nature/natural-disasters/lightning7.htm) .
Also the device is all plastic anyway and you could install it using a plastic fixing under the eves pointing in the best direction if you believed the myth over the science ;D
Regards
Phil
-
Philip saw 30/10; wonder why my upstream 4G is so dire at 0.4Mbps?
Possibly because your phone or dongle has a much lower powered transmitter to send data back to the mast than the mobile phone mast sending you a signal, worse, a phones transmitter and receiver antenna are completely non-optimal in order to give us the form factors we have. Which is why an external powered 4G modem and antenna designed for long distance use will outperform a phone or small dongle.
At the barns location non of us got a phone signal even from the top window and one of those was on Three, yet the external mounted modem/antenna on Three (speedtests identified the network as Three) was giving a steady ~30/10.
Regards
Phil
-
Got it. That makes sense when one thinks about it.
-
[OT]Did anything ever come of CarlT's offer to ask somebody, who knows somebody, about the Internet service provision situation for your remote location?[/OT]
Yes. The ballpark guesstimate figures mentioned to me were eye-watering.
-
Yes. The ballpark guesstimate figures mentioned to me were eye-watering.
That doesn't surprise me at all.
-
Yes. The ballpark guesstimate figures mentioned to me were eye-watering.
Six digits?
-
The guesstimator only went to £39k as I recall. It was a bit academic following up with excess construction charges on top once that was passed.
There are a lot of poles serving very few properties in need of work and/or new ones or duct work needing to be done.
This is probably a task best suited to LTE or LEO satellite for the shorter term. The R100 project had a value for money limit of £1,600-1,700 per premises passed that required individual review. These sites are right at the extreme of the hockey stick.
-
If a business needed a serious feed for a new site then it would just be nothing for them?
-
Given the costs involved in setting up a business of any size in that area a series of microwave relays would seem to be the way to go.
For a small business that can't afford such things stuffed until a wireless technology is provisioned.
Either way you see the theme of wireless technologies.
-
If a business needed a serious feed for a new site then it would just be nothing for them?
We arranged a wireless point to point service for one of our customers who had workshop and stores in a business park outside the city. It was a bit of a pain with maintenance as it had a relay on a commercial mast with all sorts of access restrictions. For that site excess construction charges for a conventional private circuit were over a quarter of a million. The stupid thing was that it was a development with multiple tenants, and the landlord owned a bunch of land all around the park and owned a plant hire operation. Some cooperation from him might have made the connection cost effective and would have added a lot of value to his development.
-
I am getting the usual cyclic upstream line 3 behaviour, 6dB high time, 1-1.5 dB low time and the upstream target is 6dB. I’ve just noticed something. The line dropped for some reason or other, but anyway, it dropped at such a point that the upstream SNRM vales were as stated, with a really low low. And that mean that the upstream rate was really good, at 499 kbps, which is about ~100k better than it usually is.
This time I did some speedtestests, with speedtest2.aa.net.uk and the ookla speed tester, because I wanted to find out what the combined upstream rate was like when all four lines were roughly the same rate upstream, all at or just over 500kbps u/s. To my surprise, I found that the upstream combined rate results were rubbish compared to what I have been getting recently. speedtest2.aa.net.uk was ~1.30Mbps with the 499k upstream line 3 rate and the expected rate was 1.5-1.6Mbps. So as an experiment, I reset the line 3 upstream SNRM so that it was back at the target of 6dB and the upstream rate then went back down to 389k
Live sync rates:
#1: down 2807 kbps, up 519 kbps
#2: down 2700 kbps, up 544 kbps
#3: down 2964 kbps, up 389 kbps 6db upstream SNRM, 6dB upstream target
#4: down 2553 kbps, up 515 kbps
Now at this unequal upstream rate, when you would expect combined upstream to be bad, the result was the reverse: a combined upstream rate that was a big improvement - combined u/s rate =1.65Mbps at an u/s line 3 rate of 389k.
So in a nutshell: upstream equal speeds - bad upstream combined effective performance
Note: The line 3 downstream rate is about 30kbps lower, although I can’t see how that could affect things too much, unless it’s something to do with too many errors slowing things down?
So how can the upstream combined rate be 300k worse when the rates are equal ? All the other upstream rates are unchanged, btw, so that isn’t it.
-
Higher synchronisation speed --> more errors --> more retransmssions --> lower throughput, perhaps?
-
Oh, I see. The higher upstream speed was at a 6dB minimum SNRM and there don’t seem to be any CRCs much at that SNRM. I can’t see any CRC upstream errors before or after the change, but looking at the FEC count instead it is 500-1000 per unit time (whatever the unit is) showing on the FEC count graph before I forced a resync and put the SNRM up to the target of 6dB and put the upstream rate down from 499k to 389kbps, and after the change the u/s FEC count is 10-50 per unit time and as I said zero CRCs upstream after the change.
-
Now the upstream SNRM variations have disappeared. :fingers: :congrats: Unfortunately I didn’t note what time it happened. In recent weeks, I’ve had a lightning near miss and then two engineer visits after that, so perhaps one of these three events fixed it, or perhaps it was fixed somehow earlier than that.
So hopefully the upstream line 3 nightmare is gone for good, settled at a solid 6dB target now. :)
On the other hand, the line 2 irregular variation is still there though, still at 2dB height, and the pattern is not the same every day. Some days multiple transitions within a 24 hour period, but always the same height. It’s not causing any noticeable problems though as the u/s SNRM drops from 6dB to 4dB. Zero CRC errors upstream for the last 24 hour period, and 5 u/s CRC errors + 5 ES for the 24 hrs before that. Engineers came out to line 2 as well as line 3, so the ‘fixed by engineer’ argument is dubious; why isn’t line 2 fixed by whatever fixed line 3?