Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: mofa2020 on January 18, 2020, 04:15:20 PM
-
Hello Kitzens, I really have a weird issue "as I assume it is an issue" that is internet speed vs interleave delay and INP.
In the pictures are my line stats for plans 100mb/10mb, 70mb/7mb (line sync. higher but the actual speed is 70/7) and 30mb/3mb (sync. like 70mb plan higher but actual speed is 30/3) what makes me wondering is how with higher download sync. speed I get lower download interleave delay but at the same time with the higher upload speed I get higher interleave delay, actually I understand the upload part (higher speed, higher work on the line so it can be stable and achieve such speed) but it is not the same for higher download sync. and it is reversed in the 30/3 plan where lower sync speed leads to higher Interleave delay on download side but lower Interleave delay on the upload side, for me it looks like the upload is tending to fastpath as speed closer to 1mb but the download speed side is the real mystery for me (low speed/higher delay and high speed/low delay)....
I am considering to but a draytek vigor 2762 to force upload speed of 1mb (fastpath I hope) I do not upload much, while subscribing to 100mb plan so I get the least Interleave delay possible.
And one more thing,line is FTTC on Huawei cabinet about ~80 meters or less from my building and I am not from UK. how can the line achieve this 95mb speed and capable of more while on just VDSL2? as this router and other routers state no sign of vectoring at all (VDSL routers I have all has basic dsl stats not much details.)
*The 3 line stats are from the same router, just the firmware changed.
-
I think I got it somehow, so the 30mbs is available from all ISPs in my country and it is the cheapest/basic plan so there must be so many many subscribers to it this means that there will be so much much cross-talk between lines (or errors) at the same sync. speed that explains the higher interleave delay/g.inp and I think just because upload speed of 4mbs is nothing for fttc that would explain the low interleave delay/g.inp for upload speed.
For higher speeds (70 and 100) where not much subscribers, since there is much difference in speeds from 30 that means less cross-talk and thus it needs little interleave/g.inp for the errors that may be generated by being synced to higher speeds both on download and upload.
I know g.inp do not cause delays (about 4ms both ways) and is a better way to correct errors than interleaving, but somehow both are kept enabled nation wide on all lines so lines be stable as much as possible at the expense of latency and sync. speed over fastpath ::)
-
I'm sorry that no one has been able to give you any sort of reasonable interpretation to your observations. As you hint in your follow-on post, it is probably something that relates to the country in which the service is provided.
-
I'm sorry that no one has been able to give you any sort of reasonable interpretation to your observations. As you hint in your follow-on post, it is probably something that relates to the country in which the service is provided.
Thanks for your reply,
The main co. here (like Openreach) actually still rolling out fttc in country so maybe when the thing finished things will change, but in the meantime I believe getting rid of upload interleaving is possible, but do you know how I can get 95mb? I read that vdsl can reach 100mb in perfect lab conditions which can be noway my line or almost any other line.
-
That's an interesting theory, I've never really seen any comparisons of bitloading between different sync rates on a line capable of a high speed.
The question is, does it prioritise the lower frequencies over the higher ones when syncing below maximum or does it spread them across the whole spectrum just loading each frequency less? I could certainly see a logic in the former, but surely crosstalk could be lower in both scenarios?
-
. . . but do you know how I can get 95mb?
No, sorry, I don't.
I read that vdsl can reach 100mb in perfect lab conditions which can be noway my line or almost any other line.
Under laboratory conditions I have managed to achieve the following --
> xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 48545 Kbps, Downstream rate = 156668 Kbps
Bearer: 0, Upstream rate = 48545 Kbps, Downstream rate = 97762 Kbps
Link Power State: L0
Mode: VDSL2 Annex A
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 20.2 10.2
Attn(dB): 1.8 0.0
Pwr(dBm): 10.7 5.3
The VTU-C was configured for profile 17a, interleaving and with a target SNR margin of 6dB.
Quite artificial, of course.
-
That's an interesting theory, I've never really seen any comparisons of bitloading between different sync rates on a line capable of a high speed.
The question is, does it prioritise the lower frequencies over the higher ones when syncing below maximum or does it spread them across the whole spectrum just loading each frequency less? I could certainly see a logic in the former, but surely crosstalk could be lower in both scenarios?
Sorry all my vdsl routers lack of/do not support anything that can report tones or anything to monitor it, but from what I understood from what you said I believe your first assumption "priorities the lower frequencies" that explains the higher interleave delay and higher g.inp on lower download speeds they are needed more to correct the errors, but on 70mb or 100mb although I get many fec errors and sometimes crc errors the interleave delay/g.inp is lower than 30mb ones so I believe that the lower frequencies are loaded less (the ones with many people actually using them <cross-talk>) and the higher frequencies that are not much used allocated normally though I get much higher fec errors and some crc errors with lower delay/g.inp compared to 30mb but the connection remains stable.. the "gap" between 30mb and higher speeds maybe it is the key reason for lower delay/g.inp on higher speeds.
I have bitswap, sra, sos, vectoring and g.inp all enabled in router UI and it is a ZTE h168n with mediatek chipset.
Do not know if any of this makes sense or not..
-
No, sorry, I don't.
Under laboratory conditions I have managed to achieve the following --
> xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 48545 Kbps, Downstream rate = 156668 Kbps
Bearer: 0, Upstream rate = 48545 Kbps, Downstream rate = 97762 Kbps
Link Power State: L0
Mode: VDSL2 Annex A
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 20.2 10.2
Attn(dB): 1.8 0.0
Pwr(dBm): 10.7 5.3
The VTU-C was configured for profile 17a, interleaving and with a target SNR margin of 6dB.
Quite artificial, of course.
This is weird because actually my line can sync. at 99999kbps though the actual speed is shy 93mbs when downloading 92.xmb is what I get and snr keeps around 8db with little fluctuation, maybe something is enabled like vectoring but router is not reporting it enabled!?
-
. . . maybe something is enabled like vectoring but router is not reporting it enabled!?
That could be a possibility but as I don't have any knowledge of the ZTE H168n, I am unable help.
-
That could be a possibility but as I don't have any knowledge of the ZTE H168n, I am unable help.
Thank you anyway :), I believe I understood the missing piece of the puzzle I will get the vigor 2762 soon and will update if vectoring is enabled to make things clear.
That's an interesting theory, I've never really seen any comparisons of bitloading between different sync rates on a line capable of a high speed.
The question is, does it prioritise the lower frequencies over the higher ones when syncing below maximum or does it spread them across the whole spectrum just loading each frequency less? I could certainly see a logic in the former, but surely crosstalk could be lower in both scenarios?
And will look into the frequency loading for different speeds because it is really interesting to discover..
Thanks for both of you :thumbs:
-
No, sorry, I don't.
Under laboratory conditions I have managed to achieve the following --
> xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 48545 Kbps, Downstream rate = 156668 Kbps
Bearer: 0, Upstream rate = 48545 Kbps, Downstream rate = 97762 Kbps
Link Power State: L0
Mode: VDSL2 Annex A
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 20.2 10.2
Attn(dB): 1.8 0.0
Pwr(dBm): 10.7 5.3
The VTU-C was configured for profile 17a, interleaving and with a target SNR margin of 6dB.
Quite artificial, of course.
would love to see bitloading and SNR per tone graphs :) thanks.
Also do you get any errors at all?
-
would love to see bitloading and SNR per tone graphs :) thanks.
Also do you get any errors at all?
I get fec errors mostly on download side while on 100mb or 70mb and little on the upload side also on these speeds I get crc errors on download but things improved after I enabled SOS feature from connection settings before it sometimes snr decreases suddenly and errors starts to jump higher.
-
yes i think delay and interleaver depth affect attainable rate and it depends on ISP if they want to turn it off or not. In my country you can request to turn it off and it is advertised as fast path for gaming. But i think 10-20ms not gonna make much a difference
-
yes i think delay and interleaver depth affect attainable rate and it depends on ISP if they want to turn it off or not. In my country you can request to turn it off and it is advertised as fast path for gaming. But i think 10-20ms not gonna make much a difference
Unfortunately in my country we can not choose to turn it off, the ping in online games is usually 65-80ms apart from some spikes and packet loss..
-
Unfortunately in my country we can not choose to turn it off, the ping in online games is usually 65-80ms apart from some spikes and packet loss..
if i may ask where are you from?
-
if i may ask where are you from?
I am from Egypt.
-
So from the screenshots, it seems that you are located in Egypt. (te)
If I may ask, which area are you located in? And which router are you using?
I changed my line in 2018 to VDSL and my line was performing very well with ds rate ~75Mbps until September. Something went wrong and the rate went down below 28Mbps. Just today I cannot achieve 26Mbps. The attenuation jumped from 11 to 23! How is this even possible?!
Anyways, the profiles pushed to all VDSL lines are interleaved. To my knowledge WE didn't push the fast profiles yet.
-
So from the screenshots, it seems that you are located in Egypt. (te)
If I may ask, which area are you located in? And which router are you using?
I changed my line in 2018 to VDSL and my line was performing very well with ds rate ~75Mbps until September. Something went wrong and the rate went down below 28Mbps. Just today I cannot achieve 26Mbps. The attenuation jumped from 11 to 23! How is this even possible?!
Anyways, the profiles pushed to all VDSL lines are interleaved. To my knowledge WE didn't push the fast profiles yet.
I am from Alexandria, and the router is ZTE H168N but with unlocked firmware and yes no fast profiles are available yet. can you post the line stats? but for the attenuation to jump from 11 to 23 this means that something wrong happened to the phone line either in box under building or at the cabinet, if you are with WE call 111 and make a complaint about the speed drop and increased attenuation they will make someone to check it.
-
Located in Cairo (Mokattam). Already politely bugging them almost every week since the fault started. The technicians are saying something is wrong with the line grounding, they are very secretive about it (like everything in the country ;)).
I recently (20 days ago) raised a ticket complaining from a high noise on the voice channel. It hasn't been fixed till now.
Below are the line stats as reported by dslstats. I have the tp-link Archer VR400v2. Which I didn't like for now showing stats, but after hacking it, I was able to get dslstats to report everything about the line.
Stats summary
Stats recorded 22 Jan 2020 21:54:05
DSLAM type / SW version: HISI:0x3412 (52.18) / v0x3412
Modem/router firmware: AnnexA version - A2pv6F039v2.d26m
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 1 hour 5 min 34 sec
Resyncs: 3 (since 22 Jan 2020 18:04:18)
Downstream Upstream
Line attenuation (dB): 27.7 0.0
Signal attenuation (dB): Not available on VDSL2
Connection speed (kbps): 33099 10014
SNR margin (dB): 4.4 7.2
Power (dBm): 14.2 8.8
Interleave depth: 279 89
INP: 2.00 2.00
G.INP: Not enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
RSCorr/RS (%): 0.0545 0.0032
RSUnCorr/RS (%): 0.0009 0.0000
ES/hour: 12.6 11.0
-
Another weird thing also reported:
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 12420 Kbps, Downstream rate = 28607 Kbps
Bearer: 0, Upstream rate = 10014 Kbps, Downstream rate = 33099 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x1)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 4.4 7.2
Attn(dB): 27.7 0.0
Pwr(dBm): 14.2 8.8
VDSL2 framing
Bearer 0
MSGc: 19 25
B: 237 124
M: 1 1
T: 64 64
R: 16 16
S: 0.2288 0.3963
L: 8880 2846
D: 279 89
I: 254 141
N: 254 141
How could the max be less than the current?
-
HISI DSLAM? any kitzen could help with that!! anyway 3 resync. I believe that SNR 4 is really bad that is the cause it resync. so I believe you are WE Space, do have any of its routers? I have the VR400 v2 and the ZTE h168n but the ZTE is much better, did you try any other router? also check with neighbor about the connection see if it is a problem in your area/cabinet.
-
How could the max be less than the current?
The "max" line is just an intelligent guess, a prediction, as to how the circuit could perform, if everything was as it should be, which includes a target SNRM of 6 dB.
In your case, we can see that the SNRM was 4.4 dB when those statistics were obtained. That would be enough to push the actual DS rate above that of the predicted max DS rate.
-
If you have the ticket number call 155 and make a complaint, that is the last thing you can do.... or as I told you check with others in your area if the thing is common take a group of you and visit the nearest branch with technical support or visit the central and meet someone from administration maybe it an issue with a main cable for the area.
-
May I ask how did you hack the vr400? because it is a pain in the .....!!
-
I will raise a complaint on 155 as soon as I land in Cairo.
For hacking the VR400, I followed the same instructions for the Archer VR600 detailed here:
https://forum.kitz.co.uk/index.php/topic,14377.msg357441.html#msg357441 (https://forum.kitz.co.uk/index.php/topic,14377.msg357441.html#msg357441)
-
Mode: VDSL2 Annex B
vr400 supports vdsl annex A only, how is it showing annex B?
edit:please see this post
https://community.talktalk.co.uk/t5/Product-Archive/Annex-A-or-B-with-FTTC-fibre/m-p/1213937#M810355
could be your cabinet supports annex B and your router supports only annex A, that whats causing your issues, try getting a router that supports annex b to test
-
Some routers for some reason reports Annex A as Annex B so it is basically a router thing but it will work normal either way.
-
We have to remember that there are annexes to various standards and recommendations that apply to xDSL hardware and xDSL services.
The first annex to consider is that at the hardware level, which specifies the underlying telephony service (if any). Here Annex A signifies xDSL over POTS and Annex B signifies xDSL over ISDN. In the U.K. it is Annex A. In Germany it is Annex B.
Then there is the annex of a VDSL2 service's software configuration, for example. In the U.K. it is Annex B.
The above, considerably simplified, is what usually causes confusion for users of a U.K. based VDSL2 service.
-
So I ended up with D-link dsl-2888a which uses Triductor vspm340 (as I believe) line is stable with these stats:
xdsl_cli info --status
Mode: Vdsl2_ANNEX_B
State: Showtime
Power state: 1
Data path: Interleaved
Downstream max rate: 142704
Upstream max rate: 35621
Downstream current rate: 35999
Upstream current rate: 4015
Downstream power: 144
Upstream power: 5
Downstream attenuation: 32
Upstream attenuation: 5
Downstream SignalAttn: 1023
Upstream SignalAttn: 1023
Downstream SNR margin: 288
Upstream SNR margin: 392
Downstream line coding: 1
Upstream line coding: 1
UpBokle: 43
Downstream Trellis: 1
Upstream Trellis: 1
Downstream Actual SNRMode: 1
Upstream Actual SNRMode: 1
ActualCE: 5
Downstream SNRMpb: -153.6,921.7,1049.7,25.4,25.4
Upstream SNRMpb: 25.4,-2867.1,-3199.9,25.4,0.0
TotalStart: 3454
STStart: 3418
AturVendor: 54524944
AturCountry: b500
AtucVendor: 48495349
AtucCountry: 3412
DownstreamInterleaveDepth: 1799
UpstreamInterleaveDepth: 41
Profile: 17a
Upstream INP: 0.00
Downstream INP: 0.00
Upstream Interleave Delay: 5
Downstream Interleave Delay: 12
Downstream Data Path: Interleaved
Upstream Data Path: Interleaved
xdsl_cli info --stats
Total time = 50 min 11 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 35 35
LOS: 0 0
LOF: 0 0
Latest 15 minutes time = 5 min 11 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 50 min 11 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 35 35
LOS: 0 0
LOF: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Since Link time = 49 min 35 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
with *Total time = 50 min 11 sec
UAS 35 35
it is just before the line sync. every time it shows 35 but since link time is 0, I believe things are stable though I will try faster plan and see how things go..
-
with *Total time = 50 min 11 sec
UAS 35 35
it is just before the line sync. every time it shows 35 . . .
Yes, agreed.
With a ZyXEL VMG1312-B10A I see --
UAS: 59 59
It is only seen directly after a power-on, whilst the device is initialising, and can be ignored as it is not service affecting.
-
I am now on 100/10 with sync. speed @ 92/10 and here is how it looks,
~ # xdsl_cli info --stats
Total time = 6 days 21 hours 33 min 35 sec
FEC: 13236 133
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 28 28
LOS: 0 0
LOF: 0 0
Latest 15 minutes time = 3 min 34 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 9 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 21 hours 33 min 34 sec
FEC: 1626 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 1218 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Since Link time = 6 days 21 hours 33 min 7 sec
FEC: 13236 133
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
how does it look like?
-
Nice and stable :cool:
-
:dance: I found that choosing the chipset DOES really matter.