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