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:

Author Topic: G.fast - what is going on with the downstream rate?  (Read 605 times)

re0

  • Reg Member
  • ***
  • Posts: 609
G.fast - what is going on with the downstream rate?
« 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:
Code: [Select]
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:
Code: [Select]
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.
Logged

re0

  • Reg Member
  • ***
  • Posts: 609
Re: G.fast - what is going on with the downstream rate?
« Reply #1 on: August 13, 2019, 04:01:25 AM »

And back at 330011 Kbps after a resync - DLM removed INPRein on upstream:
Code: [Select]
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?
Logged

jelv

  • Helpful
  • Kitizen
  • *
  • Posts: 1350
Re: G.fast - what is going on with the downstream rate?
« Reply #2 on: August 13, 2019, 09:05:07 AM »

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!
« Last Edit: August 13, 2019, 09:07:43 AM by jelv »
Logged
Line rental: Pulse8, Broadband: AAISP Home::1 FTTC 80/20, Mobile: id Mobile

re0

  • Reg Member
  • ***
  • Posts: 609
Re: G.fast - what is going on with the downstream rate?
« Reply #3 on: August 13, 2019, 03:17:46 PM »

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.
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 27123
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: G.fast - what is going on with the downstream rate?
« Reply #4 on: August 13, 2019, 05:01:19 PM »

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.)
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

re0

  • Reg Member
  • ***
  • Posts: 609
Re: G.fast - what is going on with the downstream rate?
« Reply #5 on: August 14, 2019, 12:28:15 AM »

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).
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 27123
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: G.fast - what is going on with the downstream rate?
« Reply #6 on: August 14, 2019, 12:37:34 AM »

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.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

j0hn

  • Kitizen
  • ****
  • Posts: 2541
Re: G.fast - what is going on with the downstream rate?
« Reply #7 on: August 14, 2019, 01:28:26 PM »

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.

Quote from: re0
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.
Logged
Plusnet FTTC 80/20 -  ECI now Huawei cab
retx low @ 3dB target SNRM
Zyxel VMG1312-B10A bridged with 1508 MTU + Asus RT-AC68U running Asuswrt-Merlin

re0

  • Reg Member
  • ***
  • Posts: 609
Re: G.fast - what is going on with the downstream rate?
« Reply #8 on: August 14, 2019, 01:51:37 PM »

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.
Logged

re0

  • Reg Member
  • ***
  • Posts: 609
Re: G.fast - what is going on with the downstream rate?
« Reply #9 on: August 14, 2019, 03:13:36 PM »

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.
Logged

re0

  • Reg Member
  • ***
  • Posts: 609
Re: G.fast - what is going on with the downstream rate?
« Reply #10 on: August 15, 2019, 02:29:36 AM »

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.
Logged

re0

  • Reg Member
  • ***
  • Posts: 609
Re: G.fast - what is going on with the downstream rate?
« Reply #11 on: August 22, 2019, 12:39:29 AM »

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.
Logged
 

anything