Upload on infinity

Hi all.

Why would the upload be so limited and in regards to download so low?

See below please..

Featured Products

Downstream Line Rate(Mbps)

Upstream Line Rate(Mbps)

Downstream Handback Threshold(Mbps)

WBC FTTC Availability Date

WBC SOGEA Availability Date

Left in Jumper

High Low High Low
VDSL Range A (Clean) 26.7 16.9 3.7 1.9 15 Available Available --
VDSL Range B (Impacted) 26.3 15.9 3.7 1.7 13 Available Available --




VDSL Training Status: Showtime
Mode: VDSL2 Annex B
VDSL Profile: Profile 17a
G.Vector: Disable
Traffic Type: PTM Mode
Link Uptime: 0 day: 0 hour: 15 minutes
====================================================================================
VDSL Port Details Upstream Downstream
Line Rate: 1.852 Mbps 21.081 Mbps
Actual Net Data Rate: 1.833 Mbps 21.031 Mbps
Trellis Coding: ON ON
SNR Margin: 6.1 dB 5.8 dB
Actual Delay: 0 ms 8 ms
Transmit Power: 6.1 dBm 12.3 dBm
Receive Power: -11.5 dBm -24.7 dBm
Actual INP: 0.0 symbols 3.0 symbols
Total Attenuation: 0.0 dB 27.3 dB
Attainable Net Data Rate: 1.833 Mbps 24.592 Mbps
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 12.0 61.2 N/A N/A N/A 24.6 73.3 N/A
Signal Attenuation(dB): 12.0 60.1 N/A N/A N/A 36.1 73.9 N/A
SNR Margin(dB): 6.3 6.0 N/A N/A N/A 5.8 5.8 N/A
TX Power(dBm): 0.4 4.8 N/A N/A N/A 11.3 5.6 N/A
====================================================================================

VDSL Counters

Downstream Upstream
Since Link time = 15 min 31 sec
FEC: 3829 0
CRC: 3 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 1 min 4 sec
FEC: 534 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: 3295 0
CRC: 3 0
ES: 1 0
SES: 0 0
UAS: 33 33
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 16 min 4 sec
FEC: 3829 0
CRC: 3 0
ES: 1 0
SES: 0 0
UAS: 33 33
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 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
Total time = 16 min 4 sec
FEC: 3829 0
CRC: 3 0
ES: 1 0
SES: 0 0
UAS: 33 33
LOS: 0 0
LOF: 0 0
LOM: 0 0
====================================================================================

In reply to a post by kazeus:

Why would the upload be so limited and in regards to download so low?

Almost certainly because you are a long way from the cabinet.

In reply to a post by kazeus:

VDSL Range A (Clean) 26.7 16.9 3.7 1.9 15 Available Available --
VDSL Range B (Impacted) 26.3 15.9 3.7 1.7 13 Available Available --

Your predicted speed downstream is 15.9 - 26.7, and upstream is 1.7 - 3.7.

In reply to a post by kazeus:

VDSL Port Details Upstream Downstream
Line Rate: 1.852 Mbps 21.081 Mbps

Both speeds you get are within the predicted range. Certainly the upstream is at the low end of this range, but it's still within the range. This is not unusual.

For comparison, here are mine:

VDSL Range A (Clean) 37.5 25 7 4.9 22.4 Available Available --
VDSL Range B (Impacted) 35.8 22.4 6.9 4 18 Available Available --

My actual sync speed is 30.93 / 4.34 - so my upload is right at the bottom of the range too.

The speed estimates are based on a mathematical model based on things like copper thickness and line length, but in the real world there are a bunch of other variables which it can't take account of, hence the wide range of possible speeds. Crosstalk from other VDSL users is one of those - you'd probably only get the highest speeds if nobody else on your cabinet was using VDSL.

Thanks for that. I was hoping that upload should mirror download. As the download is rather in the middle and not on the low end I was hoping same for upload. Instead it is below the clean line prediction and on the low end of impacted one. Yup so far only had good fibre lines and not drop wires from poles lol.

Also looks like I might be in trouble at some point. Line has got quite a few errors but not sure if it should worry me at all at this point? Also stuck zyxel instead HH and download improved by 3meg. Upload not really. Tried hg612 too but nothing doing.

Total time = 8 hours 57 min 37 sec
FEC: 211824 0
CRC: 80 6
ES: 35 5
SES: 0 0
UAS: 33 33
LOS: 0 0
LOF: 0 0
LOM: 0 0

For reference I had the opposite conundrum on my last property.

I got 19.5 as download (so bottom end), however i got 5.6 upload (so near top end) howeverr the line estimates were:

VDSL Range A (Clean)
Download: High 30.4 Low 19.5
High: 5.9 Low: 3.7

Distance approx 1.1km
Cabinet: ECI

In reply to a post by gary333:

For reference I had the opposite conundrum on my last property.

Thanks Gary. Seems like there is nothing to be done and we are at a mercy of the wiring god haha.

Upload/download uses different frequency ranges. So you can have line conditions/faults that impact one more than the other, hence you can end up with good download speeds and worse upload.

In reply to a post by andynormancx:

Upload/download uses different frequency ranges. So you can have line conditions/faults that impact one more than the other, hence you can end up with good download speeds and worse upload.

Thanks, that makes sense. So obviously nothing to be done here as it is still within a range and upload is not guaranteed anyway.

Cheers all
Kam

Also looks like I might be in trouble at some point. Line has got quite a few errors but not sure if it should worry me at all at this point?

That's relatively few errors.

FEC's (Forward Error Correction) are errors that were corrected.
I get 100,000 a minute, it's not a problem.

ES are Error Seconds and 35 in 8 hours is low, particularly on a long line.

In reply to a post by j0hn83:

FEC's (Forward Error Correction) are errors that were corrected.
I get 100,000 a minute, it's not a problem.

ES are Error Seconds and 35 in 8 hours is low, particularly on a long line.

j0hn83 thanks for that mate. Looks like I am settling for what i have lol

In my opening post stats show delay of 8ms and INP at 3. Now last night I have found my connection with different set of stats. Download has increased but upload still no budge. Any knowledgeable guys can shed some light on the changes mentioned above? Ping better but when tested via cmd I got something in region of 2k ms so not really improvement
Okay went to router and changed the MTU to 1442 from 1492.. Now ping 15ms to bbc site.
What is going on? Is the MTU the problem?? Or was it the ip I had previously. If so why the hell would ip make such a difference. Never used bt before for fibre so don`t know the works..

See new stats below to compare with the op.

Cheers
Kam

VDSL Training Status: Showtime
Mode: VDSL2 Annex B
VDSL Profile: Profile 17a
G.Vector: Disable
Traffic Type: PTM Mode
Link Uptime: 0 day: 10 hours: 4 minutes
====================================================================================
VDSL Port Details Upstream Downstream
Line Rate: 1.724 Mbps 23.754 Mbps
Actual Net Data Rate: 1.705 Mbps 23.755 Mbps
Trellis Coding: ON ON
SNR Margin: 6.6 dB 6.3 dB
Actual Delay: 0 ms 0 ms
Transmit Power: 6.2 dBm 12.1 dBm
Receive Power: -11.5 dBm -24.8 dBm
Actual INP: 0.0 symbols 48.0 symbols
Total Attenuation: 0.0 dB 27.3 dB
Attainable Net Data Rate: 1.705 Mbps 23.627 Mbps
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 12.0 61.1 N/A N/A N/A 24.5 73.1 N/A
Signal Attenuation(dB): 12.0 59.5 N/A N/A N/A 36.0 73.7 N/A
SNR Margin(dB): 6.8 6.6 N/A N/A N/A 6.3 6.4 N/A
TX Power(dBm): 0.4 4.8 N/A N/A N/A 11.1 5.6 N/A
====================================================================================

VDSL Counters

Downstream Upstream
Since Link time = 4 min 31 sec
FEC: 24666 4
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 8 min 17 sec
FEC: 117 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: 201 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 = 11 hours 38 min 17 sec
FEC: 65544 4
CRC: 1958 1
ES: 18 1
SES: 11 0
UAS: 193 182
LOS: 1 0
LOF: 7 0
LOM: 0 0
Previous 1 day time = 0 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
Total time = 11 hours 38 min 17 sec
FEC: 65544 4
CRC: 1958 1
ES: 18 1
SES: 11 0
UAS: 193 182
LOS: 1 0
LOF: 7 0
LOM: 0 0

And forgot to add bqm since last night. some issues at the beginning and obvious packet loss since resync last night as dynamic ip.

However after updating new ip this morning packet loss evident. Then pinging eventually changing mtu caused resync. It seems better now I would like to think. Any ideas what the hell was happening before I changed the mtu?

My Broadband Ping

Edited by deleted (Wed 12-Jun-19 12:32:31)

Can you give a rough time to the sequence of events you described?

Looking at BQM guess you updated IP at approx 7:40am
The packet loss at 11.15 to 11.45 is suggestive of you uploading or downloading a lot across the connection.

An MTU of 1442 is NON standard, generally best to leave it at the usual default of 1500. Bad MTU values cause fragmentation which can cause problems.

IP addresses do not have extra latency, but you may have moved from a congested to an uncongested network segment.

G.INP (ReTx) has been applied to the downstream.

This lowers latency by 8ms and reduces downstream errors significantly.

edit: downstream may increase further if DLM lowers the target SNR margin from 6dB. It can lower it to 5dB, 4dB or 3dB in 1dB increments. Each step would be worth a couple Mb.

Wether this happens or not is entirely automated by DLM and depends on the lines stability.

Edited by j0hn83 (Wed 12-Jun-19 14:05:56)

In reply to a post by MrSaffron:

Can you give a rough time to the sequence of events you described?

Looking at BQM guess you updated IP at approx 7:40am
The packet loss at 11.15 to 11.45 is suggestive of you uploading or downloading a lot across the connection.

I would say from midnight until 1 ish I was trying different settings etc. Then when I woke up this morning I found ip has changed so updated that on bqm.

After updating I discovered the graph later on and tried pinging so response from bbc was around 2000ms Even on congested segments it is a bit too much I feel?

Around 11.30 all I was doing was pinging, no downloads or uploads going on at all. Then at the end of this bit of packet loss I resynced with the mtu at 1442. I know it is non standard but what should I do now. Zyxel max is 1492 so should I set this back up?

Going forward now I can see there is more packet loss at around 1.30pm.

Sorry I have never had this with fibre before. Always pretty good connection and minimal dot of packet loss if anything.

I will reset mtu to 1492 if you believe this is what I should do. However I found a post by someone that said they had to use mtu of 1442 with drytek on infinity so I am confused now lol

My Broadband Ping

In reply to a post by j0hn83:

G.INP (ReTx) has been applied to the downstream.

This lowers latency by 8ms and reduces downstream errors significantly.

edit: downstream may increase further if DLM lowers the target SNR margin from 6dB. It can lower it to 5dB, 4dB or 3dB in 1dB increments. Each step would be worth a couple Mb.

Wether this happens or not is entirely automated by DLM and depends on the lines stability.

Thanks, yes and no so confused again.
Initially delay of 8ms was applied to DS with inp figure of 3

Now it sits on 0 ms delay but DS inp figure of 48

The above are from zyxel gui.

On a side note according to hg612 modem logs viewer:
DS is interleaved to the tune of 8ms as you said right now in contrary to zyxel`s gui
and in addition inp is at 48.

Hehe, haven`t had so much fun in a long time.

Delay: 8

compared to new stats of

Delay: 0

Show the added latency from Interleaving is now removed.

The HG612 should also now show delay: 0 since G.INP was enabled, unless you are on a very very old HG612 firmware.

It should be D: 8 which is the Interleaving depth, on both the Zyxel and the HG612. That's different to delay.

The changes in stats between old style Interleaving/INP and G.INP(ReTx) can be confusing if you don't understand them.

An example of old style Interleaving stats:

INP = 3/3.5
D = 900 (Interleaving Depth)
delay = 8

My G.INP stats are:

INP = 46
D = 8
delay = 0

A good resource is here:
https://kitz.co.uk/adsl/linestats_errors.htm

In reply to a post by j0hn83:

Delay: 8

compared to new stats of

Delay: 0

Show the added latency from Interleaving is now removed.

The HG612 should also now show delay: 0 since G.INP was enabled, unless you are on a very very old HG612 firmware.

It should be D: 8 which is the Interleaving depth, on both the Zyxel and the HG612. That's different to delay.

The changes in stats between old style Interleaving/INP and G.INP(ReTx) can be confusing if you don't understand them.

An example of old style Interleaving stats:

INP = 3/3.5
D = 900 (Interleaving Depth)
delay = 8

My G.INP stats are:

INP = 46
D = 8
delay = 0

A good resource is here:
https://kitz.co.uk/adsl/linestats_errors.htm

Sorry, I am not using hg612 only the stats program. But I confused few things I believe.

This is from zyxel gui :
Actual Delay: 0 ms 0 ms (before on DS was 8ms)

Inside stats program I ge interleaving on (8) so thats the depth then inp at 48 and delay at 0

So looks like we are at the same spot now. Thanks for the Kitz page too. I confused the D`s lol depth with actual delay so assumed D stands for delay which it does not.

Many thanks for your input.

Should normally be no need to change the MTU from the default on the router, i.e. 1492 or 1500

It may be due to a quirk that the 1442 works best with your hardware combination, what you need to do is settle things down and wait, and change just one thing every couple of days so you can see what the long term effect is.

NOTE: If your changes are resulting in resync's the DLM system may think the line is unstable and react in ways you don't like

As for the packet loss, need to see a period of a few hours with all ethernet and wireless devices disconnected so you can establish your baseline.

In reply to a post by MrSaffron:

Should normally be no need to change the MTU from the default on the router, i.e. 1492 or 1500

It may be due to a quirk that the 1442 works best with your hardware combination, what you need to do is settle things down and wait, and change just one thing every couple of days so you can see what the long term effect is.

NOTE: If your changes are resulting in resync's the DLM system may think the line is unstable and react in ways you don't like

As for the packet loss, need to see a period of a few hours with all ethernet and wireless devices disconnected so you can establish your baseline.

Thank you for your input.

I shall proceed with the testing over next few days. I am curious as to what will happen if I disconnect everything indeed.

Will report back in few days time. I suspect DLM will intervene before then as this is a new line. I suspect things will settle in not so distant future.

Cheers
Kam

The MTU depends on the ISP.

Set it to 1500 if Sky or Talktalk.
1492 for everyone else as they use PPPoE which uses 8 bytes.
The Zyxel should only offer 1492 automatically if you set PPPoE.

The days of having to manually tweak MTU for different sites or OS compatibility are long gone.