Cool Ideas Fibre ISP - Feedback

[Armizael]

Your argument is what exactly though? My ISP is responsible for that peering as well, I used to get my 90Mbps to Europe on Vox + OpenServe, on CI I can only get over 30Mbps consistently if I use the proxy, meanwhile I get barely 15Mbps:

And my upload is way higher, and that should be suffering due to poor scaling as well.

I know how TCP/IP scaling works, and it has a huge impact on single-threaded, but on multi-threaded, that window of time changes substantially since we're talking 3-8 threads scaling, with TCP/IP starting its scaling at about 5Mbps per thread if over 90ms, with it definitely increasing past that point if going higher, so I should see a minimum starting scaling of ~15Mbps and I should definitely be able to max my line with 8 threads.

I think you have a line problem though - my result to CoreIX London from the same area as you:

Are you having trouble getting the line problem acknowledged?

 

[bHOLDher]

Your argument is what exactly though? My ISP is responsible for that peering as well, I used to get my 90Mbps to Europe on Vox + OpenServe, on CI I can only get over 30Mbps consistently if I use the proxy, meanwhile I get barely 15Mbps:

And my upload is way higher, and that should be suffering due to poor scaling as well.

I know how TCP/IP scaling works, and it has a huge impact on single-threaded, but on multi-threaded, that window of time changes substantially since we're talking 3-8 threads scaling, with TCP/IP starting its scaling at about 5Mbps per thread if over 90ms, with it definitely increasing past that point if going higher, so I should see a minimum starting scaling of ~15Mbps and I should definitely be able to max my line with 8 threads.

How is your speed when testing to CoreIX server? That Community Fibre Limited server you tested against seems to max out at 15mbps.

 

[DeatheCore]

TCP/IP was invented in the early seventies for initial use on a wireless network. It is the same thing we use today and an analogy would be that we are using a method that works for throwing bean bags but we expect the same reliability using paint ball guns. It is well past its sell by date.
Thus the stack on your PC, router, interconnecting devices and destination host all play a part. As an example, if you are on Windows 7, use a cheap router with realtek chips then don't be alarmed at poor speeds.
So besides the fibre operator's network which itself might have an access, distribution and core with different capacities, the ISP network would also be dependent on cross connects to peering partners. There are more than a dozen points of congestion along the path which could include dodgy fibre, dodgy chips, as well as misconfiguration and even buffer bloat. All these factors contribute to it be known as broadband and best effort.
I'll stick out my head on the irrationality of the logic being presented. Most people are prepared to accept the evidence of their cr@ppy speedtest conducted off the end of a cr@ppy broadband connection as the ISP being a problem but won't accept a speedtest on the ISP core network which shows no symptoms of problems? Why?

What is your point though? Regardless of when TCP/IP was invented, it is capable of speeds far greater than what I am using at home on my fibre connection. While I agree with you that there are numerous variables with customer setups and interconnects along the route, there is no excuse for performance <10% of advertised speeds, I would not consider that "best effort". Especially if the line has been proven to perform optimally in the past with no changes to hardware or cabling. To further eliminate variables, ISPs request tests directly from the FNO's CPE, and in my case this proved to yield the exact same results as when cabled to my MikroTik router, proving that the fault lay outside of my property. To respond to your last point, I, among others, are consumers paying for a certain level of service and we only have one point of contact for all issues - our ISP. If the ISP ensures us that there is definitely no issues on their core network regarding international transit I do believe them, however it changes nothing being on the consumer end as the fault still exists at the end of the day and all we can do is run speedtests and iperfs to various locations to assist the ISP in fault-finding.

 

[Johnatan56]

I think you have a line problem though - my result to CoreIX London from the same area as you:

Are you having trouble getting the line problem acknowledged?

If I had a line problem, then why have I still not gotten a single techie sent out by @PBCool? It's been over a month since I logged my ticket, in that time I've gotten 9 replies,
First reply: Run MTR (as I had already supplied an iPerf and speedtest results on the 25th March)
by the next day I'd replied with an MTR, no reply until April, where support states international issue identified and resolved, which was the DDoS, my issue obviously preades that.
Third reply was asking about a screenshot I sent of my speedtest showing low speeds in reply, that was 2 April. I sent multiple speedtest, WinMTR and an http download test while directly connected to my ONT to rule out my router on the 2nd of April.
4 April my "issue is escalated" (this after I called in and complained)
8 April I asked what escalation means, showed an 8Mbps speedtest.
9th reply from them asking if time of day degradation, and what servers. So person obviously didn't check the timestamps on all the tests I did showing it happening at all times of the day or read through the ticket where I stated any international.
10th my comment of line drops get acknowledged that I had once a day, think this was connection re-establishment. Support states continuous ping test on my line will be done to monitor it. Nothing came of this, and haven't heard of anything about it since then,
12th April reply is that they would send me a Mikrotik router. Note I recevied a garbage archer C3 with 100Mbps ethernet ports on a 100Mbps line. Can't actually use it as it slows down my internal network.
17th reply on me asking when I would get the mirkotik is that they want me to confirm I never got one from them. This is great, since they can read from my account profile that I don't have one. Nice hold-up for over 4 days waiting for them to actual send it.
18th reply that I will receive the router after the long weekend
29th I replied (about two days after getting the router) in regards to router making no difference, but using proxy showing improvement.
On the 2nd of May I got asked if I can take a call in the afternoon, the Staff person messaged me at 14h29 to ask if I can take a call in the afternoon. That's got to be a joke. How am I supposed to plan about being at home if you give me a notice of less than 2 hours. Plus no indication of what the actual call is about.
I replied right away that I will only get home way later and am at work, and stated that I will be available on Monday in regards to any calls about the international issue as I am at home. I have never gotten a reply same-day from them, so I can't think of them even having called me that afternoon if I had replied.

So basically my entire "support" experience (notice the quotes on support) is me running after them with pretty much no actual support given. The only actual support I got was sending the router, which was a joke when I already proved the issue is at hand when directly connected to the ONT.

Here on the forum I thought @PBCool would help out since recently he replied to some of my comments (for the first time not ignoring me), but that died quite quickly. Support on CISP is horrendous at best. It's fun to be paying over a grand for a 100Mbps line when I can barely get 15% of that most days, and the usual being about half of it. Might as well downgrade to 50Mbps, but that might still be too much. That's why my cancellation is handed in, and I will be gone end of this month and if anyone asks about CISP, I will show them the copy of my ticket that I made.

Oh and CoreIX:

Was when I started writing the post, and now after ending it:

Has nothing to do with the speedtest server, it's CISP.

EDIT:
And for the fun of it, here is the proxy trcprx01.cisp.co.za :

Look at the lovely 90Mbps, but barely 10Mbps upload, so my choice is either use a proxy which has a small delay and can get overloaded with terrible upload, or use mediocre download and goodish upload. Very fun.

 

[Zophos]

Hi. Just got home from a week away and the fiber went telly bye bye. [Ticket ID: COOL-20190504-261793]. Randburg area. If @PBCool can maybe escalate? Thanks

 

[Armizael]

If I had a line problem, then why have I still not gotten a single techie sent out by @PBCool? It's been over a month since I logged my ticket, in that time I've gotten 9 replies,
First reply: Run MTR (as I had already supplied an iPerf and speedtest results on the 25th March)
by the next day I'd replied with an MTR, no reply until April, where support states international issue identified and resolved, which was the DDoS, my issue obviously preades that.
Third reply was asking about a screenshot I sent of my speedtest showing low speeds in reply, that was 2 April. I sent multiple speedtest, WinMTR and an http download test while directly connected to my ONT to rule out my router on the 2nd of April.
4 April my "issue is escalated" (this after I called in and complained)
8 April I asked what escalation means, showed an 8Mbps speedtest.
9th reply from them asking if time of day degradation, and what servers. So person obviously didn't check the timestamps on all the tests I did showing it happening at all times of the day or read through the ticket where I stated any international.
10th my comment of line drops get acknowledged that I had once a day, think this was connection re-establishment. Support states continuous ping test on my line will be done to monitor it. Nothing came of this, and haven't heard of anything about it since then,
12th April reply is that they would send me a Mikrotik router. Note I recevied a garbage archer C3 with 100Mbps ethernet ports on a 100Mbps line. Can't actually use it as it slows down my internal network.
17th reply on me asking when I would get the mirkotik is that they want me to confirm I never got one from them. This is great, since they can read from my account profile that I don't have one. Nice hold-up for over 4 days waiting for them to actual send it.
18th reply that I will receive the router after the long weekend
29th I replied (about two days after getting the router) in regards to router making no difference, but using proxy showing improvement.
On the 2nd of May I got asked if I can take a call in the afternoon, the Staff person messaged me at 14h29 to ask if I can take a call in the afternoon. That's got to be a joke. How am I supposed to plan about being at home if you give me a notice of less than 2 hours. Plus no indication of what the actual call is about.
I replied right away that I will only get home way later and am at work, and stated that I will be available on Monday in regards to any calls about the international issue as I am at home. I have never gotten a reply same-day from them, so I can't think of them even having called me that afternoon if I had replied.

So basically my entire "support" experience (notice the quotes on support) is me running after them with pretty much no actual support given. The only actual support I got was sending the router, which was a joke when I already proved the issue is at hand when directly connected to the ONT.

Here on the forum I thought @PBCool would help out since recently he replied to some of my comments (for the first time not ignoring me), but that died quite quickly. Support on CISP is horrendous at best. It's fun to be paying over a grand for a 100Mbps line when I can barely get 15% of that most days, and the usual being about half of it. Might as well downgrade to 50Mbps, but that might still be too much. That's why my cancellation is handed in, and I will be gone end of this month and if anyone asks about CISP, I will show them the copy of my ticket that I made.

Oh and CoreIX:

Was when I started writing the post, and now after ending it:

Has nothing to do with the speedtest server, it's CISP.

EDIT:
And for the fun of it, here is the proxy trcprx01.cisp.co.za :

Look at the lovely 90Mbps, but barely 10Mbps upload, so my choice is either use a proxy which has a small delay and can get overloaded with terrible upload, or use mediocre download and goodish upload. Very fun.

More than likely they need all of that info to present to Frogfoot before they can ask for a technician to be dispached - some of the FNOs are just absolutely horrible in terms of making things the ISP's problem.

I don't know if that's the case here, but all I know is that I had the same problem as you and it took a month and a half of providing tests to Frogfoot before they would even consider that the problem was on their end.

@PBCool @TheRoDent Maybe you can give some more feedback here? It does seem like his experience with your support hasn't been that stellar.

Edit: Since you've handed in your cancellation, it would be interesting if you could report back if swapping ISPs solved your problem - please report back after you're online with the new provider.

 

[blunt]

More than likely they need all of that info to present to Frogfoot before they can ask for a technician to be dispached - some of the FNOs are just absolutely horrible in terms of making things the ISP's problem.

I don't know if that's the case here, but all I know is that I had the same problem as you and it took a month and a half of providing tests to Frogfoot before they would even consider that the problem was on their end.

@PBCool @TheRoDent Maybe you can give some more feedback here? It does seem like his experience with your support hasn't been that stellar.

Edit: Since you've handed in your cancellation, it would be interesting if you could report back if swapping ISPs solved your problem - please report back after you're online with the new provider.

How is your experience on frogfoot with CISP? My parents area is launching on FF and I was thinking of putting them on CISP. Are you in CT?

 

[r00igev@@r]

Your argument is what exactly though? My ISP is responsible for that peering as well, I used to get my 90Mbps to Europe on Vox + OpenServe, on CI I can only get over 30Mbps consistently if I use the proxy, meanwhile I get barely 15Mbps:

And my upload is way higher, and that should be suffering due to poor scaling as well.

I know how TCP/IP scaling works, and it has a huge impact on single-threaded, but on multi-threaded, that window of time changes substantially since we're talking 3-8 threads scaling, with TCP/IP starting its scaling at about 5Mbps per thread if over 90ms, with it definitely increasing past that point if going higher, so I should see a minimum starting scaling of ~15Mbps and I should definitely be able to max my line with 8 threads.

No argument. If the ISP runs a speedtest from their core to London consistently and it is clean then the problem is the requesting node or last mile. Finish and klaar. You are looking at the problems with your glasses smeared with vaseline.
TCP scaling works the same on a single or multi threads. Here is the method to calculate http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/ and here is the graph:


You definitely have a problem but the speedtest results are insufficient evidence to prove a crime. It seems you are not getting multiple threads on the downlink. Do a wireshark and send me the capture if you want.

 

[r00igev@@r]

What is your point though? Regardless of when TCP/IP was invented, it is capable of speeds far greater than what I am using at home on my fibre connection. While I agree with you that there are numerous variables with customer setups and interconnects along the route, there is no excuse for performance <10% of advertised speeds, I would not consider that "best effort". Especially if the line has been proven to perform optimally in the past with no changes to hardware or cabling. To further eliminate variables, ISPs request tests directly from the FNO's CPE, and in my case this proved to yield the exact same results as when cabled to my MikroTik router, proving that the fault lay outside of my property. To respond to your last point, I, among others, are consumers paying for a certain level of service and we only have one point of contact for all issues - our ISP. If the ISP ensures us that there is definitely no issues on their core network regarding international transit I do believe them, however it changes nothing being on the consumer end as the fault still exists at the end of the day and all we can do is run speedtests and iperfs to various locations to assist the ISP in fault-finding.

I agree the the ISP takes ownership and needs to resolve the problem. I think it is great if the the community assists and helps. All good.
My point is that poor performance over the last mile is amplified by long distance link statistics. It does not mean the long distance link is the problem.

 

[jannier]

Here you can see there is nothing wrong with the ISP. The ISP (CISP) is fine and there is adequate bandwidth available.
The issue is somewhere on your fibre line with you Fibre provider. ie. Frogfoot

Vuma trenched, Brackenfell CPT, 1Gbps/100Mbps

With Downloading I can easily max out my line using a download manger.

Coreix London:


Local Coolideas;


Local VOX:

 

[wingnut771]

Here you can see there is nothing wrong with the ISP. The ISP (CISP) is fine and there is adequate bandwidth available.
The issue is somewhere on your fibre line with you Fibre provider. ie. Frogfoot

Vuma trenched, Brackenfell CPT, 1Gbps/100Mbps

With Downloading I can easily max out my line using a download manger.

Coreix London:


Local Coolideas;


Local VOX:

can you do one to durban please

 

[stefan9]

So how long after receiving the black box for testing can I expect my frogfoot issue to be solved.

My international speeds are still abysmal. Issue been going since July 2018, with only poor responses from the support tickets. Only @TheRoDent & @PBCool have made any true effort to try and solve.

 

[Loppas]

can you do one to durban please

Mweb:

Vox:

Websquad:

 

[jannier]

can you do one to durban please

MWEB
[URL=https://www.speedtest.net/result/8235779575][/URL]

VOX:


WebSquad:

 

[Johnatan56]

No argument. If the ISP runs a speedtest from their core to London consistently and it is clean then the problem is the requesting node or last mile. Finish and klaar. You are looking at the problems with your glasses smeared with vaseline.
TCP scaling works the same on a single or multi threads. Here is the method to calculate http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/ and here is the graph:
View attachment 653162

You definitely have a problem but the speedtest results are insufficient evidence to prove a crime. It seems you are not getting multiple threads on the downlink. Do a wireshark and send me the capture if you want.

Your argument fails that as that's starting scaling, the window goes up, and speedtest starts at 8 threads, so 140ms is about 5Mbps each * 3 to 8, so starting 15Mbps.

Here you can see there is nothing wrong with the ISP. The ISP (CISP) is fine and there is adequate bandwidth available.
The issue is somewhere on your fibre line with you Fibre provider. ie. Frogfoot

Vuma trenched, Brackenfell CPT, 1Gbps/100Mbps

With Downloading I can easily max out my line using a download manger.

Coreix London:


Local Coolideas;


Local VOX:

Who is my contact for any FF issue? CI right? They take the sole blame, and they are the ones who still haven't sent anyone out. It is their fault, and their fault alone for nothing having been done yet.

 

[PBCool]

Your argument fails that as that's starting scaling, the window goes up, and speedtest starts at 8 threads, so 140ms is about 5Mbps each * 3 to 8, so starting 15Mbps.


Who is my contact for any FF issue? CI right? They take the sole blame, and they are the ones who still haven't sent anyone out. It is their fault, and their fault alone for nothing having been done yet.

As mentioned previously we have some Frogfoot anomalies that can't be explained via packetloss etc, if we do the same test from customer vs core we get very different results. We have deployed a SDWAN optimisation device to another customer on Frogfoots network which is proving to resolve his issues. We had to import it and setup an endpoint in our core which has taken some time. Sending someone out is a waste of time. We are waiting to see what this device does to the traffic that is resolving the Frogfoot issues. Then will take it from there. Apologies this has taken so long but it's quite a process.

 

[Johnatan56]

As mentioned previously we have some Frogfoot anomalies that can't be explained via packetloss etc, if we do the same test from customer vs core we get very different results. We have deployed a SDWAN optimisation device to another customer on Frogfoots network which is proving to resolve his issues. We had to import it and setup an endpoint in our core which has taken some time. Sending someone out is a waste of time. We are waiting to see what this device does to the traffic that is resolving the Frogfoot issues. Then will take it from there. Apologies this has taken so long but it's quite a process.

Do you think it will be completed before month end? You can apologize for it taking so long, I am still being billed over a thousand rand a month for your service. How long is waiting enough? Over two months?

Do your competitors have the same issue? No? Do you even have a time frame that you've assigned to this issue? Why is this the first I hear about this issue after complaining about throughput for over a month?

 

[r00igev@@r]

Your argument fails that as that's starting scaling, the window goes up, and speedtest starts at 8 threads, so 140ms is about 5Mbps each * 3 to 8, so starting 15Mbps

I'm not arguing boet, just trying to understand your logic. TCP scaling works like this:
https://www.auvik.com/franklymsp/blog/tcp-window-size/

The TCP window size is controlled by the end devices, not by the routers, switches, or firewalls that happen to be in the middle. The devices actively and dynamically negotiate the window size throughout the session.

Please capture a wireshark of this dodgy speedtest, post it and let us have a look. Or not.

 

[Furbz]

Wonderful. Sunday night and no connection.
@PBCool anything happening in Kyalami?

 

[Johnatan56]

I'm not arguing boet, just trying to understand your logic. TCP scaling works like this:
https://www.auvik.com/franklymsp/blog/tcp-window-size/

Please capture a wireshark of this dodgy speedtest, post it and let us have a look. Or not.

It can't start its service since I can't restart my PC, have work open I can't close off until I finish.
And I understand how window scaling works, that graph you have is the basically what the scaling window starts at before ramping up. I should still be able to hit 100Mbps internationally on a multi threaded speed test.