G.inp?

Anyone know how soon after FTTC goes live DLM is likely to bother with G.inp?

Just upgraded my other ADSL line to FTTC, currently syncing at 67Mbit/s , hoping once DLM has done it's thing it will get close to 74 to match the other line.

On the connection day it should sync as fast as it can, with no interleaving at first. In terms of sync speed the only effect of G.INP is to restore any speed loss caused by interleaving.

We will see what happens in the next few days.

Also just found BGP multipath on edgeOS doesn't work for ipv6... doh.

Edit: Got a nice 50/50 split for IPv4, IPv6 not so much due to kernel route cache in edgeOS (It just uses one line for the destination).

Bonding via GRE tunnels.

Edited by dragon2611 (Wed 20-Jan-16 21:38:05)

Last time I migrated, it took at least 2 weeks before G.INP was re-enabled - it seemed longer.

In reply to a post by dragon2611:

Anyone know how soon after FTTC goes live DLM is likely to bother with G.inp?

Just upgraded my other ADSL line to FTTC, currently syncing at 67Mbit/s , hoping once DLM has done it's thing it will get close to 74 to match the other line.

Took around 3-4 weeks after I migrated my FTTC connection...

In reply to a post by RobertoS:

On the connection day it should sync as fast as it can, with no interleaving at first. In terms of sync speed the only effect of G.INP is to restore any speed loss caused by interleaving.

Logically you are right. G.INP (retransmission) applied to a line that doesn't already have some form of DLM shouldn't cause any change in speed.

Likewise, a line running at the full package speed shouldn't see a change in the "attainable" figures either.

But sometimes, reality doesn't follow logic.

On my line, running at full package speed without DLM intervention, the application of G.INP downstream bumped up the attainable speed considerably. Application of G.INP upstream also bumped up the attainable speed - although this disappeared again when upstream G.INP was taken away.

I also recall seeing cases where people experienced real speed increases, even though DLM hadn't intervened before. But I can't even begin to point you at any links...

BTW reported that the majority of lines had seen a small, 1-2Mbps, increase in headline rate - but made no reference to whether this was the effect of removal of DLM. I suspect not, as removal of DLM would normally have a much bigger impact on speed.

You'd imagine this means something else changed somewhere, but less noticeable than "just" FEC and interleaving. Some kind of low-level line coding (such as the trellis coding) perhaps, or the way framing is implemented down at the physical level, but I haven't been able to figure what.

I accept your argument, but feel the way you are using the term "DLM" could confuse some.

DLM is never removed. It is permanently present and monitoring. It is the action it does or doesn't take that is in question.

My previous post was also in the light of the OP hoping for an increase in actual sync of or approaching 7Mbps. That simply is not going to happen unless there was serious noise when it first connected. Which would not be anything to do with G.INP as interleaving would not have been in place at the time. Unless it was introduced between the original sync and the OP being aware of the sync - for instance connected mid-morning and they returned home from work in the evening.

In reply to a post by RobertoS:

the way you are using the term "DLM" could confuse some.

DLM is never removed.

True. I usually use the term "DLM intervention", and did so in a couple of spots. The mistakes are pure acts of lazy-itis.

In reply to a post by RobertoS:

My previous post was also in the light of the OP hoping for an increase in actual sync of or approaching 7Mbps. That simply is not going to happen unless there was serious noise when it first connected.

I tend to agree with you. Most lines are not going to see that kind of change in real line speed just through G.INP - not without it displacing an older intervention.

However, be aware that my line was reporting attainable speeds of around 98/33 before G.INP appeared, which changed to 107/35 after G.INP mk.I was applied. This shifted to 107/33 after G.INP mk.II was applied (ie upstream G.INP was removed again), and has sat there ever since.

I have no certainty whatsoever that this shift in "attainable" could ever be translated into a real sync speed, and I'm not aware of anyone else who has seen a change like this, but it is a pointer that big changes could be possible. Just low probability.

As for the OP: I'm amazed that the original line didn't lose some of its speed when the second line went active. G.INP isn't a fix for crosstalk.

Yes, I know re lazy-itis. I was more concerned about people who wouldn't realise that.

As you know, I often refer posters to yourself and a couple of others over FTTC stats - your skilled analysis of them leaves me at the starting line!

Edited by RobertoS (Fri 22-Jan-16 12:06:13)