Web Squad ISP

Status
Not open for further replies.
Yes completely understandable.

33Mbps isn't great but rather try do a real download from a number of USA servers and see what sort of speeds you get. Speedtest.net is honestly a waste of time and hardly useful for anything else other than e-peen and troubleshooting really obvious issues ( packet loss ).

You will find though that your IPTV stream maxes out at like 12 to 16mbit so definitely more than enough for an IPTV stream.
Try this:
 
So here is the iptv server speedtest, live TV server speed at 21Mbs for what it's worth.
65959c7a5ede13ee7046ef73736411b5.jpg
This weekend has been a bad once again... i can't figure it out. and dunno what to do or what to test.
During daytime it seems fine. around 9pm evenings it goes to crap.

It's also pretty bad over weekends. whole weekend long. Sometimes there's an hour or two that's glitch free. Other times it's pretty bad.


IPTV should be smooth if i could only get 0 packet loss and a solid 20mbit for IPTV. Instead i can't even watch 5seconds of IPTV withouth a pause or a glitch or a Buffering circle on my screen. It is super annoying.

I've uploaded wireshark goodies too. I've uploaded it again for ease of access.
 
Last edited:
This weekend has been a bad once again... i can't figure it out. and dunno what to do or what to test.
During daytime it seems fine. around 9pm evenings it goes to crap.

It's also pretty bad over weekends. whole weekend long. Sometimes there's an hour or two that's glitch free. Other times it's pretty bad.


IPTV should be smooth if i could only get 0 packet loss and a solid 20mbit for IPTV. Instead i can't even watch 5seconds of IPTV withouth a pause or a glitch or a Buffering circle on my screen. It is super annoying.

I've uploaded wireshark goodies too. I've uploaded it again for ease of access.

I've all but given up with foreign IPTV.

I've used Afrihost, Websquad, MTS and Seacom with all pretty similar results.

I've coupled every VPN under the sun for testing. This made it worse or kept things the same mostly.

All tests point to my fiber lines being absolutely perfect with nothing wrong. 0 percent packet loss.

Funny is legit streaming apps like RTP Play, DSTV now, Amazon prime et al never ever buffer at all.

I think SA needs it's own IPTV servers tbh.
 
I've all but given up with foreign IPTV.

I've used Afrihost, Websquad, MTS and Seacom with all pretty similar results.

I've coupled every VPN under the sun for testing. This made it worse or kept things the same mostly.

All tests point to my fiber lines being absolutely perfect with nothing wrong. 0 percent packet loss.

Funny is legit streaming apps like RTP Play, DSTV now, Amazon prime et al never ever buffer at all.

I think SA needs it's own IPTV servers tbh.
Why does it stream perfect even over cheap wifi connections or 3G and 4G even. Ive tested on a 6mbit connection and it streams like a champ.

We didnt see a pause for 4 or 5hours.
 
Why does it stream perfect even over cheap wifi connections or 3G and 4G even. Ive tested on a 6mbit connection and it streams like a champ.

We didnt see a pause for 4 or 5hours.

You tested this at approximately the same time you were seeing buffering on your fiber line?
 
Why does it stream perfect even over cheap wifi connections or 3G and 4G even. Ive tested on a 6mbit connection and it streams like a champ.

We didnt see a pause for 4 or 5hours.
The constant argument I keep having with myself as well lol.. It never buffers over a 3g/4g sim card connection. Can't wait for the day they bring out unlimited data on a sim card contract.
 
The constant argument I keep having with myself as well lol.. It never buffers over a 3g/4g sim card connection. Can't wait for the day they bring out unlimited data on a sim card contract.

Check your speeds to NY again. Picked up on an asymmetry on one of our bonded NLD paths - it was out by 2ms, which in TCP terms is a lifetime. Basically, if packets are split across two asymmetrical paths, they will arrive out of order. Depending on the client rebuilding these packets, some will buffer and re-assemble them correctly; others will discard them every now and again as buffers fill. Combine this effect with NY latency (200+ms) and you have a bit of a headache. We've moved the affected NLD path to a passive role until it's back at 7ms.
 
Why does it stream perfect even over cheap wifi connections or 3G and 4G even. Ive tested on a 6mbit connection and it streams like a champ.

We didnt see a pause for 4 or 5hours.

Not seeing any issues with speeds from US/EU to CPT. No losses, and performance to the networks we monitor is as expected. Thanks for your wireshark results, our team are looking into them now and will reply on your ticket.

To explain the discrepancy in results between networks:

The internet is not one big supercomputer we (ISPs) plug into and voila - there wouldn't be a need for us if it was so. It's a network of billions of hosts (servers) and thousands of networks purchasing transit from one another or peering.

Now one provider (in your case, your mobile operator) might purchase upstream capacity from a network that peers with a particular host's (your IPTV provider's) upstream (and that's pure luck when we're talking thousands of networks), and another might pick up this traffic from a 3rd party (who your IPTV host pays for a limited amount of bandwidth) or the traffic may traverse significantly more hops or there may congested path along the way. Our upstreams peer with other networks and most likely deliver equal or better performance from many other hosts. IPTV providers love blaming ISPs, but most of the time, the issue is on one of their upstreams (limited purchased capacity) or congested peering ports and overloaded servers.

This is why big, credible CDNs/hosts spend they way they do and set up POPs as close to the end user as possible - it eliminates the risk associated with unknown paths and ensures that TCP performs the way it was meant to. So when we ask who the host is or what IP their traffic originates from, it's so we can try see where and how the traffic is being affected. While we can't promise to optimise every single route, we can try track down the bottleneck and reach out to the affected party to remedy the issue.
 
Last edited:
Not seeing any issues with speeds from US/EU to CPT. No losses, and performance to the networks we monitor is as expected. Thanks for your wireshark results, our team are looking into them now and will reply on your ticket.

To explain the discrepancy in results between networks:

The internet is not one big supercomputer we (ISPs) plug into and voila - there wouldn't be a need for us if it was so. It's a network of billions of hosts (servers) and thousands of networks purchasing transit from one another or peering.

Now one provider (in your case, your mobile operator) might purchase upstream capacity from a network that peers with a particular host's (your IPTV provider's) upstream (and that's pure luck when we're talking thousands of networks), and another might pick up this traffic from a 3rd party (who your IPTV host pays for a limited amount of bandwidth) or the traffic may traverse significantly more hops or there may congested path along the way. Our upstreams peer with other networks and most likely deliver equal or better performance from many other hosts. IPTV providers love blaming ISPs, but most of the time, the issue is on one of their upstreams (limited purchased capacity) or congested peering ports and overloaded servers.

This is why big, credible CDNs/hosts spend they way they do and set up POPs as close to the end user as possible - it eliminates the risk associated with unknown paths and ensures that TCP performs the way it was meant to. So when we ask who the host is or what IP their traffic originates from, it's so we can try see where and how the traffic is being affected. While we can't promise to optimise every single route, we can try track down the bottleneck and reach out to the affected party to remedy the issue.
hoping the wireshark can give the IP's or ports where the issues might be coming from. or TCP packets or identify whats being dropped and where.

Maybe it points us to the fix.
 
Quite a few places throw the blame straight to ISP's, I think twitch is one of the biggest examples. They don't try to help one bit and to stop clients constant issues the isp has to setup a relay server. It should be twitch setting it up.

Also @websquadza please don't forget to check out my pm when you have a moment.
 
Octotel Cape Gate clients (Northern Areas): Octotel’s backhaul provider has still not completed maintenance on the backhaul route. Expect some packet loss as traffic levels increase this evening. Octotel have assured us they are doing everything in their power to speed this up.
 
Quite a few places throw the blame straight to ISP's, I think twitch is one of the biggest examples. They don't try to help one bit and to stop clients constant issues the isp has to setup a relay server. It should be twitch setting it up.

Also @websquadza please don't forget to check out my pm when you have a moment.
Yeah ZA Twitch servers are long overdue, especially ingest servers. It would sort out 90% of the problems we have with viewing and streaming to Twitch.
 
Check your speeds to NY again. Picked up on an asymmetry on one of our bonded NLD paths - it was out by 2ms, which in TCP terms is a lifetime. Basically, if packets are split across two asymmetrical paths, they will arrive out of order. Depending on the client rebuilding these packets, some will buffer and re-assemble them correctly; others will discard them every now and again as buffers fill. Combine this effect with NY latency (200+ms) and you have a bit of a headache. We've moved the affected NLD path to a passive role until it's back at 7ms.
Apologies for the delay. Been out all day. Wow the asymmetry issue has made the speedtests incredible, I have never seen these speeds before. Great job thank you!!!
 
Not seeing any issues with speeds from US/EU to CPT. No losses, and performance to the networks we monitor is as expected. Thanks for your wireshark results, our team are looking into them now and will reply on your ticket.

To explain the discrepancy in results between networks:

The internet is not one big supercomputer we (ISPs) plug into and voila - there wouldn't be a need for us if it was so. It's a network of billions of hosts (servers) and thousands of networks purchasing transit from one another or peering.

Now one provider (in your case, your mobile operator) might purchase upstream capacity from a network that peers with a particular host's (your IPTV provider's) upstream (and that's pure luck when we're talking thousands of networks), and another might pick up this traffic from a 3rd party (who your IPTV host pays for a limited amount of bandwidth) or the traffic may traverse significantly more hops or there may congested path along the way. Our upstreams peer with other networks and most likely deliver equal or better performance from many other hosts. IPTV providers love blaming ISPs, but most of the time, the issue is on one of their upstreams (limited purchased capacity) or congested peering ports and overloaded servers.

This is why big, credible CDNs/hosts spend they way they do and set up POPs as close to the end user as possible - it eliminates the risk associated with unknown paths and ensures that TCP performs the way it was meant to. So when we ask who the host is or what IP their traffic originates from, it's so we can try see where and how the traffic is being affected. While we can't promise to optimise every single route, we can try track down the bottleneck and reach out to the affected party to remedy the issue.
Would you be able to check if there isnt any funny business on my side here in CPT "Picked up on an asymmetry on one of our bonded NLD paths - it was out by 2ms, which in TCP" seeing that tcp seems to be where my problems might be too.

As you mentioned speed is not the issue , the bandwidth is there. The tcp packets not arriving in right order or not quick enaugh in specific timeframe causes issues.

I know it might be grasping at straws..
 
Has anything changed the last few days @websquadza?

I can't quantify it, but it feels like internet usage in general has been getting progressively slower. Browsing/streaming feels less "snappy", international download speeds aren't as fast and even local speed tests don't seem right: (this used to be >900mbps - nothing else happening on the line)

 
Has anything changed the last few days @websquadza?

I can't quantify it, but it feels like internet usage in general has been getting progressively slower. Browsing/streaming feels less "snappy", international download speeds aren't as fast and even local speed tests don't seem right: (this used to be >900mbps - nothing else happening on the line)


No changes or issues on our end; usually a sign of some packet loss if you're seeing a drop like that to local. Our on-net CPT speedtest server is down for maintenance (needs a new NIC) - should be up later today or tomorrow so we can check again. In the meanwhile, have you tested bypassing your router and establishing a pppoe directly from your PC?
 
Last edited:
No changes or issues on our end; usually a sign of some packet loss if you're seeing a drop like that to local. Our on-net CPT speedtest server is down for maintenance (needs a new NIC) - should be up later today or tomorrow so we can check again. In the meanwhile, have you tested bypassing your router and establishing a pppoe directly from your PC?

Sorry for the delay - really busy day, haven't had a chance. No change doing that. Speedtests remain unchanged, if anything, slightly deteriorated from this morning.
 
So I f'ed up the previous test as I was distracted. Actually dialing a PPPoE connection from my PC connected straight to the CPE:



Now from the router:



I have no idea anymore :unsure: But the second result is an improvement on earlier.
 
Status
Not open for further replies.
Top
Sign up to the MyBroadband newsletter
X