Cool Ideas Fibre ISP - Feedback

Status
Not open for further replies.
sand_man said:
For the last couple of days I'm getting connection refused errors trying to run iperf,
iperf3.exe -R -u -b 485M -l 1452 -p 17001 -c queen.cisp.co.za

What could the reason for this be?

TIA
Click to expand...
server related i computed in my head
 
r00igev@@r said:
There are two entities at play. The fibre provider and the ISP. The fibre provider backhauls to a POP and the fibre ISP takes over from the POP.
Any congestion on the fibre provider backhaul will result in packet loss which impacts latency. This results in slower throughput to hosts further away than those that are closer. This lowers throughput on international versus local as you have described.
Fibre providers give limited or no troubleshooting information to the ISPs. You basically need to glove up and stick your arm - well you know what I mean....
It is no different in actual fact than DSLAM congestion (just a bigger fire hose). This is called broadband as there is no quality and packets are dropped typically based on capacity being exceeded. Not always on the upstream ISP side.
The ISP takes ownership of the process so just give them a gap to glove up.
Click to expand...

Too true, and while I am aware of most of these concepts, my knowledge lacks minor details. The issues @image132 and I have dealt with are inconsistent and difficult to pin down (could be more than one issue simultaneously) such as very low international throughput BUT latency does not suffer, nor does local throughput, with little to no packetloss locally and internationally. To me, if there was congestion on my fibre circuit to Vumatel's PoP, local latency and throughput should suffer too, not just international throughput, right? This leads me to believe that there is a problem with the ISPs network or upstream providers (imo), but as I said earlier I do not have enough knowledge to point fingers with complete confidence.

DSLAM congestion was easier to combat as local latencies would spike to 100-300ms and throughput would drop to dialup levels during peak hours. These fibre issues seem more difficult to identify as mentioned above. The strangest part of this is that @image132 and I live in different parts of CPT on different FNOs (Vumatel vs. Octotel) and have encountered the same issues at the same times.

But anyway, the past week/few days have actually been pretty damn good in general. No complaints my side! For now... ;)
 
Sodan said:
So, who do we switch to? I had heard great things about Cool Ideas when I decided to go with them. My experience so far is nowhere close to great. Who out there offers a decent service without insisting on traceroutes from wired connections.
Click to expand...
xefor said:
Getting full line speed here, 200/200 mbps on Vumatel with Cool Ideas
Click to expand...
pics or it didnt happen
 
cavedog said:
Referred someone else that is covered by Openserve to signup with Cool Ideas. Connect team on the phone is 30min+ waiting time. So helped him at work to sign up yesterday morning. 2 working days no response from Cool Ideas.... :rolleyes:
Click to expand...
Can you give me any reference to investigate?
 
PBCool said:
Can you give me any reference to investigate?
Click to expand...

Ill ask but just the automated confirmation of application after submitting online application. Not a word after that. Will whatsapp him and ask. Connect team letting you down a bit on online applications tbh especially if they need to confirm everything in the application anyways so there is essentially no need for that application form.
 
cavedog said:
Ill ask but just the automated confirmation of application after submitting online application. Not a word after that. Will whatsapp him and ask. Connect team letting you down a bit on online applications tbh especially if they need to confirm everything in the application anyways so there is essentially no need for that application form.
Click to expand...
If I have the reference number I can investigate, if the application was submitted the next response is then usually from the fibre provider. So please send me the ref if you can?
 
DeatheCore said:
Too true, and while I am aware of most of these concepts, my knowledge lacks minor details. The issues @image132 and I have dealt with are inconsistent and difficult to pin down (could be more than one issue simultaneously) such as very low international throughput BUT latency does not suffer, nor does local throughput, with little to no packetloss locally and internationally. To me, if there was congestion on my fibre circuit to Vumatel's PoP, local latency and throughput should suffer too, not just international throughput, right? This leads me to believe that there is a problem with the ISPs network or upstream providers (imo), but as I said earlier I do not have enough knowledge to point fingers with complete confidence.

DSLAM congestion was easier to combat as local latencies would spike to 100-300ms and throughput would drop to dialup levels during peak hours. These fibre issues seem more difficult to identify as mentioned above. The strangest part of this is that @image132 and I live in different parts of CPT on different FNOs (Vumatel vs. Octotel) and have encountered the same issues at the same times.

But anyway, the past week/few days have actually been pretty damn good in general. No complaints my side! For now... ;)
Click to expand...
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?
 
r00igev@@r said:
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?
Click to expand...
and fast fiber shows this up if OS is scaling incorrectly and being on the tip of africa doesnt help, at least its not australia
 
r00igev@@r said:
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?
Click to expand...

Generally people don't actually care about the reason behind their problems. They just want them sorted out.
 
Clients shouldn't need to be IT buffs to have decent internet and the onus should be on the people getting paid to provide support and a good service. This isn't to say CISP isn't doing just that (theyre doing a fantastic job at it) - the issue is the fibre network provider that gets paid (via CISP, from the client) and doesn't care about their clients' complaints because most (if not all) of the complaints go to CISP.
 
r00igev@@r said:
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?
Click to expand...
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.
 
Status
Not open for further replies.
Back
Top
Sign up to the MyBroadband newsletter
X