Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Dray]

After being quiet for ages, DLM has suddenly started taking an interest in INP on my connection.

On 23/8 09:11 B0 INP went from 48 to 51
On 24/8 18:40 B0 INP went from 51 to 48
On 27/8 06.58 B0 INP went from 48 to 51

I wonder why?

[ejs]

Can't really be sure without looking at the full stats, and even then, it might not really show anything.

I wouldn't even be sure that it is the DLM's doing. The DLM will set a line profile with a minimum INP value, the exact value achieved will vary.

[Dray]

All the stats are on MyDslWebStats, user Dray.

It certainly looks like DLM to me, with the retrain reason of 1.

[ejs]

I do not use MyDslWebStats.

I think the DLM has two settings for retransmission, low and high. If the retransmission profiles in BT SIN 498 reflect what's actually in the network (I'm not convinced they do), the min INP value for retransmission low is 8 and for high it's 32.

I'd guess the change between 48 and 51 is insignificant and is secondary to something else. I don't think the DLM will be changing the minimum INP between say 40 and 50.

[NewtronStar]

If it's any help in the evening time this line becomes more noisy, if I rebooted the modem at 9pm the INP will rise to 48 if I rebooted the modem at 10am the quiet time INP will fall to 46.

So something is monitoring the line conditions at modem boot time it could be the SNRM that has input into the INP state that is the only thing that changes at my end.

[ejs]

Exactly the same bandwidth and all framing parameters (all those letters N, R, V etc.)?

[NewtronStar]

Exactly the same bandwidth and all framing parameters (all those letters N, R, V etc.)?

A change of sync will occur due to the SNRM being different by 1dB from 9PM to 10:am and never checked(all those letters N, R, V etc) 

[ejs]

So it's probably because the bandwidth is different, and so the exact framing arrangement is different, resulting in an insignificant change in the actual INP level achieved while the minimum INP value as specified by the line profile set by the DLM remains the same.

[ejs]

The minimum INP value is the main parameter that sets the 'x' level of protection.

Even for FEC+interleaving without retransmission, the line profile sets a minimum INP value. Between the DSLAM and your modem, the actual INP level achieved may exceed the minimum. Without retransmission, it would likely be very costly in terms of the FEC overheads to wildly exceed the minimum INP value, so there probably tends to be little variance in the actual INP levels achieved. With retransmission, there's probably nothing much to lose by configuring the retransmission to provide the maximum amount of protection possible within the maximum delay and the available memory.

It would be useful if there were a modem that reported the min INP, max delay etc. values specified in addition to the actual values achieved. Then we'd be able to see the profile set by the DLM.

[Ixel]

For non-G.INP connections I've had as high as INP 8 and delay 16ms when I had an internal fault that caused DLM to intervene multiple times in a short timeframe.

EDIT: Not sure if what I've originally replied with is still relevant as the post I quoted appears to have vanished. I can't comment on G.INP connections as ECI DSLAM's don't have G.INP support enabled.

[WWWombat]

Even for FEC+interleaving without retransmission, the line profile sets a minimum INP value. Between the DSLAM and your modem, the actual INP level achieved may exceed the minimum. Without retransmission, it would likely be very costly in terms of the FEC overheads to wildly exceed the minimum INP value, so there probably tends to be little variance in the actual INP levels achieved. With retransmission, there's probably nothing much to lose by configuring the retransmission to provide the maximum amount of protection possible within the maximum delay and the available memory.

Bing. With that explanation, I find an answer to every query that I've had about the observed behaviour of reported INP values: that they are an "actual INP" rather than the "INP set by DLM" ... which is, as you mentioned, explicitly written in the specs as a "minimum INP" value.

Thanks @ejs.

It nicely dovetails with the observation that (with G.INP retransmission active), we do see minor variations in INP, even when a resync has been triggered at the customer end, not the DSLAM end.

Other observations are that the interleaving depth can vary between resyncs, and obviously depends on the sync-by-sync line conditions prevailing. In old-style FEC+interleaving, these values are high hundreds, low thousands. If adaption is necessary, they can change by a little. In new-style retransmission+FEC+interleaving, the choice appears to be either 4 or 8 - which is not very granular. It probably means that the modems are forced to add significantly more protection than is being strictly required.

[Dray]

So I had another resync this morning

On 23/8 09:11 B0 INP went from 48 to 51
On 24/8 18:40 B0 INP went from 51 to 48
On 27/8 06.58 B0 INP went from 48 to 51

On 29/8 06:45 B0 INP went from 51 to 52

I think what is happening is that DLM is moving me from a 6dB snrm target to a lower target as my sync speed is now at the maximum 80/20

[lee111s]

What's your current noise margin?

[Dray]

It's 4.5dB

[ejs]

Other observations are that the interleaving depth can vary between resyncs, and obviously depends on the sync-by-sync line conditions prevailing. In old-style FEC+interleaving, these values are high hundreds, low thousands. If adaption is necessary, they can change by a little. In new-style retransmission+FEC+interleaving, the choice appears to be either 4 or 8 - which is not very granular. It probably means that the modems are forced to add significantly more protection than is being strictly required.

Without retransmission, the interleaving depth tends to vary with the bandwidth, 8ms (or the max. interleaving delay) worth of data to shuffle around.

With retransmission, I don't believe the FEC+interleaving that tends to be used with it adds any INP. The FEC+interleaving is probably there to increase the bandwidth from the coding gain it provides. With retransmission, it's always done as either D=1 (like how the ECI cabinets did it), or D=Q (as the Huawei cabinets do it). Q being the DTU size in RS codewords, so the DTU size changes, and the interleaving covers one DTU.