Poor ping performance this evening

[#1]

Been on ptw-ag04 since Friday.  This evening the ping graphs look yucky - a definite stepped effect with notable packet loss.  The connection still gets good speed test results.
Anyone else suffering this evening?  I am on EANCC exchange.
Edit: here is the night before, quite a difference.

[#2]

Thanks or making us aware but I'm glad that's not affecting the use of your connection all the same. Obviously let us know if it is though.
Adam

[#3]

Just out of interest jimbof, what's your Plusnet 'Current Line speed': https://portal.plus.net/my.html?action=data_transfer_speed
The initial default setting is 78Mbps but the maximum BT profile IIRC is 77.4 (ish), probably not but could a slight mis-match cause your packet loss?
I know when my Plusnet line speed was higher than my BT profile for a short while I was seeing a (very small but existent) packet loss on my TBB graph.

[#4]

My connection info is the same as yours (77.44 BT / 78 plusnet) though I had though that perhaps it was a rounding error on the plusnet webpage - why would they ever set a profile higher than the maximum BT profile?  Has yours lowered now?  Mine has remained the same in the month since installation.
It was definitely different last night to what I had seen every evening of the month before.  If it is like that again tonight I'd be tempted to gateway hop, but Kelly mentioned that makes it hard for you to debug as the gateway session is then gone and you can't trace it back to a node?
Could this also represent contention at the exchange?

[#5]

Mine's lower anyway - I wish I did have 77.44 BT IP  but I do think it makes better sense if the PN one is set correctly (even if it just rules out one possible cause for packet loss).
Perhaps PN can set your 'Current line speed' to 77.4 (I think they round down to nearest 0.1).

[#6]

Perhaps your packet loss was just due to the process of the DLM getting to your line's stable rate?  As I say, this is the first time I've seen a graph like this on my line.  I've edited the topmost post to include a previous day.  Most notable is the lack of any losses or the stepped nature around peak time.

[#7]

Quote from: jimbof

My connection info is the same as yours (77.44 BT / 78 plusnet) though I had though that perhaps it was a rounding error on the plusnet webpage - why would they ever set a profile higher than the maximum BT profile?  Has yours lowered now?  Mine has remained the same in the month since installation. It was definitely different last night to what I had seen every evening of the month before.  If it is like that again tonight I'd be tempted to gateway hop, but Kelly mentioned that makes it hard for you to debug as the gateway session is then gone and you can't trace it back to a node? Could this also represent contention at the exchange?

The plusnet IP profile being 78 and you BT IP profile being 77.44  wouldn't cause packet loss, and if it did it wouldn't be only from 8pm to 11.30pm (Peak time) The yellow spiking with some blue underneath( Jitter) seems quite common place,during these hours if you look at other plusnet customers  Ping graphs, although it varies across the plusnet gateways, Your graph is the 1st  Plusnet Graph I've seen with low level packet loss at the same time as the jitter , and even the green(base latency) was beginning to increase too, where you downloading at the time ?
It looks similar to what congestion would look like, the only difference being that the base latency isn't also elevated, Which may mean something else is responsible, ideally  the yellow spikes shouldn't be present at all My  Entanet Based connection  Displayed similar issue during office hours (BE wholesale) which was their peak time,

[#8]

Your PN profile should be below your BT profile.  Do you know what your BT profile was the day before when you didn't have those latency spikes?

[#9]

Yes, neither has changed since I've been with Plusnet; BT has always been 77.44 (reported via their tester) and the plusnet linespeed in the web portal has always been 78.
This does beg the question - if it is the case that the plusnet "line speed" has to be less than the BT profile, then why do plusnet ever set a value of 78?  As 77.44 is the maximum BT profile as far as I am aware... (80*0.9679=77.432)
I am not the only person with the profiles set as above - I know of at least one other forum member with 77.44 (BT) and 78 (plusnet)

[#10]

Quote from: deathtrap

where you downloading at the time ?

Other than any auto updates that might have downloaded, no.  Late in the evening I started BBC streaming (SD), and crashplan was uploading at a fairly constant 4Mb/sec.
It is the first time in a month I've seen the graph do this (packet loss + such obvious blue&yellow steps) - and I've given the connection a much harder time in the past with no such phenomenon seen.

[#11]

Quote from: jimbof

This does beg the question - if it is the case that the plusnet "line speed" has to be less than the BT profile, then why do plusnet ever set a value of 78?  As 77.44 is the maximum BT profile as far as I am aware... (80*0.9679=77.432)

It's wrong.  We should be setting it at 77400.  Dave is looking at how we prevent it being set at 78000.

[#12]

Thanks Kelly.
So what is the next step on that matter then of incorrect line speed at plusnet - wait for the global fix or can it manually be set to the correct speed?  If it is set manually, will it revert to 78 eventually?
Does it only affect people lucky enough to have a 77.44 BT profile, or is everyone's profile a bit too high?

[#13]

Most people will have profile speed change which sets it. If you are lucky to get a super stable line from day one, it may stay too high.
I've manually adjusted yours to be correct.

I'm not convinced this caused those little latency spikes though.  There is nothing wrong with the gateway I can see though.  It could be exchange side of course.

[#14]

I'm not convinced either, but at least it is correct now.  Do I need to disconnect or is it updated on the fly?
I'll see what tonight is like.

[#15]

It should force you to disconnect/reconnect at some point following the change.