Kitz Forum
Broadband Related => Broadband Technology => Topic started by: re0 on August 13, 2019, 03:02:54 AM
-
Not really so much of an issue but more of a curiosity. Checked my stats when I got back tonight and noticed the downstream rate on bearer 0 is exceeding 330 Mbps by about 5 Mbps. Tiny? Yes. But why? The most I have witnessed before is 330011 Kbps from what I can remember.
Stats taken at approx. midnight:
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 200000
Last initialization procedure status: 0
Max: Upstream rate = 66431 Kbps, Downstream rate = 346084 Kbps
Bearer: 0, Upstream rate = 50133 Kbps, Downstream rate = 335116 Kbps
Link Power State: L0
Mode: G.fast Annex A
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 4.5 8.1
Attn(dB): 31.1 0.0
Pwr(dBm): 0.0 4.0
G.fast framing
Bearer 0
R: 8 6
N: 228 254
Q: 8 5
L: 9112 6832
Lrmc: 0 0
Ldoi: 0 7000
Rrmc: 191 155
Drmc: 14 3
Mf: 36 36
M(ds/us): 29 6
MNDSNOI: 2 2
ackWindowShift: 11 2
Ldr: 8188 6096
etru: 334747 49671
ETRminEoc: 12470 0
Counters
Bearer 0
OHF: 19256350 447830
OHFErr: 42 6
RS: 666315703 1553714680
RSCorr: 827852 27833
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 44857 1779
rtx_c: 27869 0
rtx_uc: 52383 165
G.fast Counters
minEFTR: 310788 51002
errFreeBits: 1182854546 89810668
NOI
BSW: 843/843 162/162
SRA: 14/14 31/31
FRA: 15/15 10/10
RPA: 0/0 3/3
TIGA: 4/4 0/0
DOI
BSW: 0/0 0/0
SRA: 0/0 0/0
FRA: 0/0 0/0
RPA: 0/0 0/0
TIGA: 0/0 0/0
eocBytes: 119264067 354566697
eocPkts: 6218570 1527258
eocMsgs: 6218570 1527258
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 17060851 7409101
Data Cells: 14103541 6695788
Drop Cells: 0
Bit Errors: 0 0
LORS: 0 0
LOSS: 0 0
ES: 24 945
SES: 4 7
UAS: 173 172
AS: 115535
Bearer 0
INP: 550.00 607.00
INPRein: 0.00 2.00
delay: 0 0
PER: 0.00 132.57
OR: 793.53 379.55
AgR: 35032.27 26578.63
Stats from previous night:
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 200000
Last initialization procedure status: 0
Max: Upstream rate = 67744 Kbps, Downstream rate = 347569 Kbps
Bearer: 0, Upstream rate = 49981 Kbps, Downstream rate = 328907 Kbps
Link Power State: L0
Mode: G.fast Annex A
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 5.0 8.9
Attn(dB): 31.1 0.0
Pwr(dBm): 0.0 4.0
G.fast framing
Bearer 0
R: 8 10
N: 228 155
Q: 8 9
L: 8944 7120
Lrmc: 0 0
Ldoi: 0 7000
Rrmc: 191 155
Drmc: 14 3
Mf: 36 36
M(ds/us): 29 6
MNDSNOI: 2 2
ackWindowShift: 11 2
Ldr: 8026 6384
etru: 328545 49521
ETRminEoc: 12470 0
Counters
Bearer 0
OHF: 4856284 113043
OHFErr: 20 0
RS: 1189090703 669190099
RSCorr: 110004 508
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 24625 61
rtx_c: 16428 0
rtx_uc: 2769 0
G.fast Counters
minEFTR: 305039 50980
errFreeBits: 775164019 22648388
NOI
BSW: 107/107 21/21
SRA: 4/4 1/1
FRA: 4/4 0/0
RPA: 0/0 1/1
TIGA: 4/4 0/0
DOI
BSW: 0/0 0/0
SRA: 0/0 0/0
FRA: 0/0 0/0
RPA: 0/0 0/0
TIGA: 0/0 0/0
eocBytes: 82113571 237151826
eocPkts: 4007447 996968
eocMsgs: 4007447 996968
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 7556756 3784234
Data Cells: 6810569 3601211
Drop Cells: 0
Bit Errors: 0 0
LORS: 0 0
LOSS: 0 0
ES: 14 940
SES: 0 7
UAS: 173 172
AS: 29137
Bearer 0
INP: 550.00 607.00
INPRein: 0.00 2.00
delay: 0 0
PER: 0.00 504.73
OR: 778.90 296.66
AgR: 34386.37 26538.91
Have also attached most recent speed and SNRM snapshots. Weird upstream SNRM spike can be observed, but at the same time the sync rate and attainables for both downstream and upstream and impacted - probably a burst of noise? But it is weird how the downstream is above that of what I thought the DSLAM would allow at least on two occaisons now.
I do wonder whether this was intended for G.fast, or if this is a weird problem (perhaps with how SRA/FRA works?). Can anyone speculate?
At the time of finishing this post, the sync is quite happy at 335125 Kbps; it's not looking like it wants to go anywhere.
-
And back at 330011 Kbps after a resync - DLM removed INPRein on upstream:
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 2000
Last initialization procedure status: 0
Max: Upstream rate = 66680 Kbps, Downstream rate = 346084 Kbps
Bearer: 0, Upstream rate = 49967 Kbps, Downstream rate = 330011 Kbps
Link Power State: L0
Mode: G.fast Annex A
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 4.3 8.8
Attn(dB): 31.4 0.0
Pwr(dBm): 0.0 4.0
G.fast framing
Bearer 0
R: 10 10
N: 191 238
Q: 9 6
L: 9144 6952
Lrmc: 0 0
Ldoi: 0 6832
Rrmc: 191 238
Drmc: 14 3
Mf: 36 36
M(ds/us): 29 6
MNDSNOI: 2 2
ackWindowShift: 11 2
Ldr: 8222 6216
etru: 329647 49912
ETRminEoc: 11330 0
Counters
Bearer 0
OHF: 24826 378
OHFErr: 0 0
RS: 33907482 2176188
RSCorr: 19 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 0 0
rtx_c: 0 0
rtx_uc: 0 0
G.fast Counters
minEFTR: 330926 50962
errFreeBits: 1247802254 115055
NOI
BSW: 14/14 6/6
SRA: 0/0 1/1
FRA: 0/0 0/0
RPA: 0/0 0/0
TIGA: 2/2 0/0
DOI
BSW: 0/0 0/0
SRA: 0/0 0/0
FRA: 0/0 0/0
RPA: 0/0 0/0
TIGA: 0/0 0/0
eocBytes: 125126016 374728253
eocPkts: 6568653 1612982
eocMsgs: 6568653 1612982
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 4905 4283
Data Cells: 1097 978
Drop Cells: 0
Bit Errors: 0 0
LORS: 0 0
LOSS: 0 0
ES: 24 945
SES: 4 7
UAS: 227 226
AS: 150
Bearer 0
INP: 550.00 535.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 479.81
OR: 755.48 289.66
AgR: 34526.15 26535.94
I guess I will have to keep an eye on the situation and hopefully uncover what conditions cause the sync rate to exceed 330 Mbps. I do not know how IP profiles work with SRA, but I would presume going above 330 Mbps would not benefit throughput?
-
Should you be dividing the Kbps by 1000 or 1024 to get the Mbps rate? If 335116 Kbps = 327 Mbps you would not be exceeding 330!
-
Dividing by 1000 in this case. Of course, that also puts 330011 Kbps at 330.011 Mbps, but that's only 11 Kbps over and not more than 5000.
-
It is certainly interesting and worth noting. What puzzles me is the down-spike in the synchronisation speed with a corresponding up-spike in SNRM (at approximately 2155 hours.)
-
It is certainly interesting and worth noting. What puzzles me is the down-spike in the synchronisation speed with a corresponding up-spike in SNRM (at approximately 2155 hours.)
I seem to be getting those occasionally. They don't seem to coincide with any particular event that I can observe from my vicinity. A few days I was getting a lot of spikes on upstream SNRM, which caused a situation where INPRein was enabled on upstream due to the amount of errors created; this is something very recent, I believe.
This situation is a bit more odd since downstream sync took a dive as well, even if the SNRM for downstream itself wasn't massively changed.
Finally, if you add that the sync was above 330011 Kbps on two occaisons in that time frame, then it is very odd. I think there is just something with the way SRA/FRA works that caused this - and perhaps it isn't supposed to happen?
Interestly enough, talking specifically regarding the spike, I had another situation like it yesterday with a slightly different spin on it. Slight upstream SNRM spike at approx. 14:30 followed by a slight drop with no discernible oddities in relation to sync rate. Then at approx. 21:15, there was a small down-spike on upstream SNRM which caused a drop in sync rate for both downstream and upstream, and a resync occurred.
At the moment I am just monitoring it. This thread is more focused on the oddity of the higher-than-presumably-possible sync on the downstream. I may decide to create a new thread in the appropriate category regarding the spikes, since there may be a pattern to observe (and because this is the wrong category).
-
I may decide to create a new thread in the appropriate category regarding the spikes, since there may be a pattern to observe (and because this is the wrong category).
Just let me know, "as & when", and I'll split off any specific posts and merge them into a new topic.
-
Should you be dividing the Kbps by 1000 or 1024 to get the Mbps rate? If 335116 Kbps = 327 Mbps you would not be exceeding 330!
As with most things sync/speed related they tend to use 1000.
80Mb is 80,000Kbps sync after all.
I do not know how IP profiles work with SRA, but I would presume going above 330 Mbps would not benefit throughput?
You should try making a new PPP session when the sync is higher, if possible.
Not sure if you are using the Zyxel as an all in 1 or with a separate router, or of the zyxel allow the PPP to be killed while remaining in sync.
My theory is the IP profile is set at the current sync when PPP is established and doesn't change with SRA.
-
You should try making a new PPP session when the sync is higher, if possible.
Not sure if you are using the Zyxel as an all in 1 or with a separate router, or of the zyxel allow the PPP to be killed while remaining in sync.
My theory is the IP profile is set at the current sync when PPP is established and doesn't change with SRA.
I'm using the Zyxel and it does allow for the PPP session to be killed while in sync.
The thing I actually forgot to mention is that I disconnect PPP and reconnect, but I didn't notice any change in the download speed at all. The problem was I only had about an hour window between when I made my initial post and when there was a resync, and I didn't think to kill PPP and reconnect until a short while before the DLM decided to intervene by disabling INPRein on upstream... so I didn't have much time to play.
At least in the Zen customer portal, the line rate data doesn't seem to change with PPP, only syncs. So I really do wonder. I will try and put the theory to test again if I experience the oddity.
-
Okay well, got an update.
So, it looks like the "oddity" of 335125 Kbps downstream appeared again not long after midday, then it returned to normal for a brief moment, followed by the "oddity" again around 13:45. This is still persisting. ??? No resyncs.
Anyway, I disconnected the PPP session and left it for about an hour (had a few things to do, made sense to leave it). Came back, reconnected PPP, and now I'm getting ~299 Mbps as opposed to 293 Mbps throughput. ;D Perhaps I could have gotten away with a shorter disconnection time, but didn't seem have much success with leaving seconds in between last time.
I have attached snapshots for sync speed, CRC and SNRM since there is definitely something going on here and I think it has something to do with the rate adaption. I would speculate that there was a burst of noise that SRA/FRA had to compensate for, but somehow caused the sync rate to exceed what was presumably possible. Though I really question what the prupose of the 335125 Kbps hard cap is because it seems this is the max. rate possible.
Just let me know, "as & when", and I'll split off any specific posts and merge them into a new topic.
Will do, just don't know right now.
-
For the record, the line data did update in the Zen portal this time unlike previously when giving mere seconds between reconnects. So, it may be the case where a PPP drop quickly followed by a new PPP session is insufficient to trigger a change in profile. I do not know the intervals, but perhaps the time a resync takes is above the threshold.
-
I still haven't been able to come to a conclusion on this one in the last week. I considered contacting OR about it but right now it's not peaking my interest, and I imagine this would probably be the least of their concerns. I will let this rest and perhaps the future will bring answers.