Is there such a thing as good and bad PPP sessions

I've been struggling with single thread speed results ever since I joined Pulse8 in November and very definitely thinking of migrating elsewhere.

Whilst speaking to potential ISPs last week, one of them mentioned that it might be worth trying different MTU settings.

Dropping the MTU to 1432 or 1400, appeared to do the trick initially and I suddenly had a connection that was maxing out on the TBB test tester and doing so across al my other chosen testers as well.

As I did a bit more analysis it became evident the results weren't at all consistent and thoughts moved onto whether it was just the PPP session restarts that were producing the improved performance.

Having reset the MTU back to 1492 and manually dropped and restarted the PPP session from the router's interface, it didn't take long for the results to move from:

http://www.thinkbroadband.com/speedtest/results.html...

to

http://www.thinkbroadband.com/speedtest/results.html...

Not sure why there should be good and not so good PPP sessions, but that appears to be the case.

However is there such a thing as good and bad PPP sessions?

Presumably not and there is some underlying cause to this which is escaping me

If you have any ideas, I would appreciate your thoughts.

Thanks.

PPP is a pretty "dumb" protocol, it is really only encapsulation.

Does your ISP use BT Wholesale such that you can also test with their speed tester?
http://speedtest.btwholesale.com/

I am wondering if the tests would be aligned compared to the ones you shared?

Not so much a bad 'PPP session' as a bad 'PPP end point'.

As I understand it PPP carries your data to a gateway server. From there it enters your ISP's network and gets routed appropriately. It is possible that one or more of your ISP's gateway servers is having problems and that by bouncing your session you get put on a better server.

PlusNet have suffered this a couple of times (for over six months a couple of years ago).

In reply to a post by cleeve555:

PPP is a pretty "dumb" protocol, it is really only encapsulation.

Does your ISP use BT Wholesale such that you can also test with their speed tester?
http://speedtest.btwholesale.com/

I am wondering if the tests would be aligned compared to the ones you shared?

In mid Feb, I posted these results:

Spedtest.net (multi thread): 74.3Mbps
TBB (multi thread): 69.5Mbps
BT Wholesale test (Multi thread): 65.8Mbps
TTB Ookla Test (multi thread): 65.Mbps
TestMy.Net (single thread): 62.3Mbps
TBB Speed test (single thread): 41.0Mbps

TBB IGB Test file: 48.5Mbps s

This morning the results are:

Spedtest.net (multi thread): 74.3Mbps
TBB (multi thread): 73.7Mbps
BT Wholesale test (Multi thread): 74.8Mbps
TTB Ookla Test (multi thread): 74.3Mbps
TestMy.Net (single thread): 73.5Mbps
TBB Speed test (single thread): 72.5Mbps

TBB 1GB Test file: 66.1Mbps

As part of my migration discussions, Uno let me have the URL for their tester and on a bad session I was only getting circa 55 Mbps from their Sheffield based multi thread tester and circa 65 Mbps from their single thread tester, whilst pulling circa 73Mbps from their Reading based multi thread tester.

This morning the results were:

Uno single thread 74.3Mbps
Uno multi thread (Sheffield) 73.8Mbps
Uno multi thread (Reading) 74.3Mbps

The bottom line here is that there is a very noticeable improvement across the board.

By the way my connection is TTB, but this doesn't stop you testing the BTW speed tester.

In reply to a post by Andrue:

Not so much a bad 'PPP session' as a bad 'PPP end point'.

As I understand it PPP carries your data to a gateway server. From there it enters your ISP's network and gets routed appropriately. It is possible that one or more of your ISP's gateway servers is having problems and that by bouncing your session you get put on a better server.

PlusNet have suffered this a couple of times (for over six months a couple of years ago).

I have performed over 50 PPP resets over the last few days and performed a traceroute for each of them.

There appear to be four different gateway servers I bounce between and I have good and bed sessions on each of them. Only a third of the PPP resets result in a good session.

So it definitely isn't as simple as good and bad gateways.

I still suspect there are some routing issues within the TTB network, as there is some significant variability in the results from one of the bad sessions.

(Bad only being a relative term here, as they are still better than many are able to achieve.)

In reply to a post by jaydub:

I have performed over 50 PPP resets over the last few days and performed a traceroute for each of them.

There appear to be four different gateway servers I bounce between and I have good and bed sessions on each of them. Only a third of the PPP resets result in a good session.

So it definitely isn't as simple as good and bad gateways.

You can't rely on a traceroute. Your traceroute packets are encapsulated within PPP so they can't tell you every server your data actually passes through. PN staff said much the same thing, that it wasn't the visible gateways but was servers not visible to end users. But there did seem to be some gateways that were far, far more likely to be a problem than others.

Of course it might not be the same issue but unfortunately unless you have the help of Pulse8 support you may not be able to diagnose any further.

Truth is that as end users we can't see the real network. A traceroute might show 12 hops when in fact there are double that.

In reply to a post by Andrue:

You can't rely on a traceroute. Your traceroute packets are encapsulated within PPP so they can't tell you every server your data actually passes through. PN staff said much the same thing, that it wasn't the visible gateways but was servers not visible to end users. But there did seem to be some gateways that were far, far more likely to be a problem than others.

Of course it might not be the same issue but unfortunately unless you have the help of Pulse8 support you may not be able to diagnose any further.

Truth is that as end users we can't see the real network. A traceroute might show 12 hops when in fact there are double that.

Interestingly if I do a traceroute of the Mac Terminal app it shows three IP addresses on several hops, which I assume is load balancing, but I take your point.

Unfortunately one of the limitations of Pulse8 is that they only act as first line support and then handover to TTB and I have no confidence in TTB ever getting to the bottom of what their network is doing.

I'm sure the expertise is there in TTB, but Pulse8 don't seem to be able to access it.

This is one of the principle reasons for me considering migrating. Not so much to improve performance as the best I can do is match what I get now on a good session, but to have a level of confidence that I can access some decent technical support should I need it.

In reply to a post by jaydub:

This is one of the principle reasons for me considering migrating. Not so much to improve performance as the best I can do is match what I get now on a good session, but to have a level of confidence that I can access some decent technical support should I need it.

Good luck finding that. For sure it won't be easy at the Pulse8 price point. I'm not sure where you can get good support these days other than AAISP and possibly IDNet neither of which operate at the cheap end of the market (which is probably not a coincidence).

Oh, how ironic

In reply to a post by Andrue:

Good luck finding that. For sure it won't be easy at the Pulse8 price point. I'm not sure where you can get good support these days other than AAISP and possibly IDNet neither of which operate at the cheap end of the market (which is probably not a coincidence).

I approached Pulse8 with an it's worth a try attitude, knowing that I wasn't tied in for 12 months.

As a past customer of IDNet and Zen, I am not unhappy to happy a bit more for better service. These two now form the short list as Aquiss, A&A and Uno are all not able to offer me a migration option; it would have to be a new line with a new phone number, which is not an option I wish to take.

IDNet have a much larger migration fee, but work out roughly the same over 12 months once call costs are taken into account, as long as I pay for the 12 months up front. Zen does offer me a free Zyxel 1312 or discounted 8924 though.