I have checked our notes and I can see where the confusion arose. The customer queried our FUP asking if it was OK to run a business on a Home FTTC service.

He was told that that is fine and his account would be handled in line with our Business FUP, we did not insist that he purchased a business service.

Seeing 2017 in the date threw me. That email was actually on the 8th of February and not the 17th.

I never suggested I was being forced onto any package, but requested the business package with unlimited traffic after receiving an email from CloudScape outlining prices on the previous day.

Later in the same email I asked about the FUP, since it seemed to preclude anybody working from home who might need the connection for both domestic and business use, irrespective of which package was chosen. I was assured it wouldn't be a problem. From what I was told earlier today, it seems there would be no performance benefit from having the business package.

We can go back and forth like this all day long, but frankly I would rather be concentrating on my work, than losing time on this. For the first two days it was fine. Then my login was changed following 10 minutes of downtime and I've been troubleshooting ever since for over 2 weeks.

OK, just my 5 pence worth.........

Firstly my reasoning .... you say all was well and as expected until their login details were remotely changed by the CP since then it's all gone Pete Tong.

Suggestion, especially since a rep for the ISP is reading and posting in this thread ...... Ask them to completely delete your account from their remote access servers, strip it right out, every last bit of detail then have them rebuild, preferably with new log in details, a whole new account on their systems.

Doing this will hopefully resolve the issue, and if it doesn't you can be 100% sure it's not their end of things,

The change of username is a red herring.

When the customer went live our new interconnect was not yet active, so the new username just moved him onto the new pipe.

The problem is with WiFi.

I think enough has been said unless anyone can engage with him on how to improve his WiFi performance.

In reply to a post by cloudscape:

The change of username is a red herring.

When the customer went live our new interconnect was not yet active, so the new username just moved him onto the new pipe.

The problem is with WiFi.

I think enough has been said unless anyone can engage with him on how to improve his WiFi performance.

And yet there was no wifi issue a minute before that red herring was introduced.

Sorry, but how are you discounting my suggestion, especially when your reply states ....

When the customer went live our new interconnect was not yet active, so the new username just moved him onto the new pipe.

That would imply to me that the poster has only had issues since his circuit was shifted to your new 'interconnect' service.

Perhaps the ISP should try putting the customer onto a login that is on the old interconnect?

The speed tests run over Ethernet shown a distinct issue issues, and things like slow single thread issues feel worse once you add Wi-Fi to the mix.

What date was the new interconnect live? If might be interesting to look at all the speed tests we can see before that date and after that date.

Perhaps the ISP should try putting the customer onto a login that is on the old interconnect?

An even better suggestion than mine, since it moves the connection back 'as was'.

It is all too much of a coincidence to me that all was well until the ISP put the OP onto the 'new pipe'.

Edited by Zarjaz (Mon 20-Mar-17 19:31:16)

In reply to a post by cloudscape:

That one is performing fine, no complaints.

There is clear congestion throughout these speed tests.

The op has slow speeds over wired as well as wireless.

They may be blaming the wireless when they contact support, but all of us here can see the underperformance even using wired. With the best wireless in the world this issue would not be resolved.

It would appear you have the op on a congested link.

The rep probably doesn't realise that even if the user is "on a new under-contended interconnect on our network", that doesn't mean there cannot be congestion somewhere between the Openreach handover at the fibre headend exchange and where it reaches that interconnect.

For instance, if that interconnect were a shared BT Wholesale MSIL at a WBMC node, with Cloudscape buying plenty of capacity (a pipe) for their own customers, it could still be congested. Cloudscape could simply fail to get the throughput they expect. Even if their "interconnect" is one such.

That turned out to be a major problem for Plusnet a couple of years or so ago. Causing them to have to move to dedicated MSILs. Most of this Kitz section is relevant.

AIUI the same sort of troubles can arise on non-BT Wholesale backhaul networks.