Yes, I'm talking about FTTC and I've experienced it and seen it reported several times, I'll have a search later on when I get home, unless someone beats me to it (please!)

Well a quick search hasn't revealed anything that wasn't written by me but I'm pretty certain I've seen it reported by others. Perhaps it's my "senior moment!" I can't be certain that I checked the IP profile before and after rebooting the router, if it happens again I'll have to be more methodical.

This is what I was thinking of:-

CPs should be aware that the mechanism for reporting the downstream and upstream line rates relies on a line re-train causing the CP, or the CPE, to initiate a new PPP session or a new DHCP request. The success of this method of line rate reporting is down to the CP's choice of timers used around PPP/DHCP handling.

If the PPP/DHCP survives a re-train, then the CP will be unaware of any change in the line rate and will not be able to shape appropriately.

The line re-train time for VDSL2 can be anywhere between 10 and 60 seconds, with typical values in the 20-30 second range. As DHCP typically uses lease timeouts in the order of days rather than seconds, CPs intending to use DHCP are advised to consider the impact of downstream line rate changes on their service and any strategies they could adopt if they wish to shape downstream traffic in close relationship to the active line rate.

I'm wondering if the WBC IP Profile can fail to be updated if the re-sync is faster than the Plusnet setting for killing the PPP session. This used to, (still does?), happen on ADSL2x with many ISPs, where the user had resync's he (a) witnessed, and (b) could often show in router logs, but the ISP was not aware of any line drops.

If that means the OR DLM does not report to the WBC one that the speed has changed, the WBC IP Profile will be unchanged. The situation presumably being corrected within 24 hours, as just happened to you, by the following mechanism.

Where Openreach have provided and are managing the Modem, daily status reports will be generated and transmitted consisting of no more than 8k Bytes (64k bits) of data upstream at full line rate.

I expect the WBC DLM reacts to that as well as passing it on to the ISP.

If you have a line that is re-sync'ing very quickly, this could be happening, and your rebooting the router would of course cause a long PPP drop, sufficient to trigger the update.

Or my thoughts could be garbage. They do at least provide a possible explanation.

Thanks - that was it!

In reply to a post by RobertoS:

...This used to, (still does?), happen on ADSL2x with many ISPs, where the user had resync's he (a) witnessed, and (b) could often show in router logs, but the ISP was not aware of any line drops...

That was definitely the case late last year when I had problems with DSL dropping for a few seconds due to a line fault and PN were not aware of a loss of connection (session?) at their end - that was ADSL MAX though and I don't think it had any effect on the IP Profile (or whatever they called it) as displayed on the PN web site when I logged-in to my account.

Well my profile was stuck at 13.2 Meg for a few weeks and reported it to Plusnet and they tweaked it up to 13.8 Meg in next to no time. After a couple of reboots over the weekend, it's down to 13.3 Meg.

As far as I'm concerned, Plusnet are not putting any priority into the upward adjustment of profiles. If you phone them, no problem, but you'll need to phone them, it seems.

The reason for the re-boots were due to speeds and profiles not matching, and I was getting confusing info. Speed tests were jagged until the phone call, then they were good. Add to that, once the speeds were fine, the gateway I was on was of a higher ping than other gateways, so I re-booted to get a better ping. It seems I can't get a good ping and a high sync, which I find completely strange.

Frankly, their internal systems are hit and miss. I haven't nailed it completely, but it's either a lack of balancing / routing issues, or some of their kit is less up to the job as others, and users are re-booting to get the better gateways (or that's how it comes across).

I think a lot of it is also that the FTTC growth is side-lining non-FTTC connections.


For what it's worth, see these trace tests, last hop ping shown, 20 samples (with slowest hop in brackets):

bbc.co.uk/news (11 hops) - 24ms (link12-central10.ptw-gw02.plus.net : 47ms)

fast.co.uk (9 hops) - 23ms (link11-central10.ptw-gw01.plus.net : 34ms : 5% packet loss)

aa.net.uk (8 hops) - 24ms (link7-central10.ptw-gw01.plus.net : 31ms)

idnet.net (8 hops) - 23ms (lo0-central10.ptw-ag04.plus.net : 46ms)

plus.net (9 hops) - 36ms (vlan2658.ptp-elb02.plus.net : 38ms)

forums.thinkbroadband.com (7 hops) - 23ms (link14-central10.ptw-gw02.plus.net : 31ms)

In all cases the slowest hop in the chain is a plusnet hop. In fairness, the majority of the hops in a tracert are plusnet. However, given that I'm on the plusnet network, one would think the trace to the plusnet website would be as fast or faster than the other sites. This suggests internal issues (capacity or routing though?).

Make of that what you can. Something else that's occurred to me. The Plusnet DNS servers I use are both 23ms. I've never considered it before, but is a tracert minimum ping dictated by the ping to the DNS server? (i.e. my best ping to any site is never lower than my best ping to a DNS server).

In all cases the slowest hop in the chain is a plusnet hop. In fairness, the majority of the hops in a tracert are plusnet

That doesn't actually mean anything. All most tracert intermediate lines really show, if higher than the final line, is how quickly that router responded to a ping when it is handling throughput from thousands of genuine data routing tasks. Simple multiple pings to the target are generally more useful.

Where tracert is useful is when there is a step jump within it which is maintained and/or exceeded for all subsequent hops. Thus showing the bottleneck.

Make of that what you can. Something else that's occurred to me. The Plusnet DNS servers I use are both 23ms. I've never considered it before, but is a tracert minimum ping dictated by the ping to the DNS server? (i.e. my best ping to any site is never lower than my best ping to a DNS server)

I would expect DNS servers to be particularly loath to respond to pings, for exactly the reason you surmise, they are a primary factor in any real response times. Though if you have no pings ever better than them, that is interesting.

What happens when you use IP addresses in pings/tracerts rather than URLs?

In reply to a post by RobertoS:

That doesn't actually mean anything. All most tracert intermediate lines really show, if higher than the final line, is how quickly that router responded to a ping when it is handling throughput from thousands of genuine data routing tasks. Simple multiple pings to the target are generally more useful.

In reply to a post by RobertoS:

What happens when you use IP addresses in pings/tracerts rather than URLs?

>ping www.plus.net -n 20

Pinging portal.plus.net [212.159.9.2] with 32 bytes of data:
Reply from 212.159.9.2: bytes=32 time=32ms TTL=247
Reply from 212.159.9.2: bytes=32 time=33ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=32ms TTL=247
Reply from 212.159.9.2: bytes=32 time=32ms TTL=247
Reply from 212.159.9.2: bytes=32 time=33ms TTL=247
Reply from 212.159.9.2: bytes=32 time=32ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=30ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=30ms TTL=247
Reply from 212.159.9.2: bytes=32 time=30ms TTL=247
Reply from 212.159.9.2: bytes=32 time=72ms TTL=247
Reply from 212.159.9.2: bytes=32 time=46ms TTL=247
Reply from 212.159.9.2: bytes=32 time=32ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247

Ping statistics for 212.159.9.2:
Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 30ms, Maximum = 72ms, Average = 34ms


>ping 212.159.9.2 -n 20

Pinging 212.159.9.2 with 32 bytes of data:
Reply from 212.159.9.2: bytes=32 time=33ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=30ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=30ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=79ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=32ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=32ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=30ms TTL=247
Reply from 212.159.9.2: bytes=32 time=32ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247

Ping statistics for 212.159.9.2:
Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 30ms, Maximum = 79ms, Average = 33ms


>ping www.aa.net.uk -n 20

Pinging www-server.co.uk [81.187.30.81] with 32 bytes of data:
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=24ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=26ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=24ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=24ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=33ms TTL=57
Reply from 81.187.30.81: bytes=32 time=24ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57

Ping statistics for 81.187.30.81:
Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 24ms, Maximum = 33ms, Average = 25ms


>ping 81.187.30.81 -n 20

Pinging 81.187.30.81 with 32 bytes of data:
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=26ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=24ms TTL=57
Reply from 81.187.30.81: bytes=32 time=24ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=24ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=24ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=24ms TTL=57

Ping statistics for 81.187.30.81:
Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 24ms, Maximum = 26ms, Average = 24ms


That's using dos. Previous traces were using Pingplotter. Using pingplotter I get no difference with pure IPs.

So to sum up, ping or trace, pingplotter or tracert, I get similar results.

FWIW, I have spent quite a few hours studying FTTC connection stats etc. (not just my own).

I have mentioned quite a few times that BT's IP Profile (also known as BRAS Rate) is not usually updated unless a new PPP session is initiated.

Before my line was eventually physically repaired, I saw many "on the fly" resyncs, logged by the unlocked HG612 MODEM as typically taking around 16 seconds.

Plusnet couldn't see these frequent resyncs as they were too quick for their timers & thus a new PPP session that would have updated the IP profile was not iniatiated.
On that basis, Plusnet initially kept claiming that my connection was stable.
It took quite a while to convince them that these resyncs actually happened frequently & that my connection was nowhere near as stable as they believed it to be.

I saw resyncs that caused both upward & downward sync speeds & ALWAYS had to force the Netgear ROUTER to initiate a new PPP session to update the IP profile.

On occasions I was left with a higher IP Profile than sync speed & on other occasions the speeds achievable from an increased sync speed were not delivered as IP Profile was still shown as the lower value.

This must have caused quite some confusion for many users who reported high IP profiles yet were only seeing low throughput speeds.

Certain Plusnet staff members are aware of this "issue", but I'm not convinced that all CS staff are aware of it from various comments I have read from time-to-time.

A MODEM reboot (not resync) ALWAYS initiates a new PPP session as it takes substantially longer & is therefore detected accordingly.

The above relates purely to my extensive observations of FTTC (VDSL2) connections. It may or may not apply to ADSL connections, that "usually" use combined modem/routers.

Edited by deleted (Tue 18-Sep-12 18:43:57)

That's good.

It ties in exactly with what I was saying about those BT SIN quotes. Clearly PN have their timing set to too high a figure for the Openreach modem. The question is, have they got to have it like that for some other reason, or could they lower it?