Status
Not open for further replies.
Not sure really, our monitoring shows a maximum of 2% packet loss from JHB to CPT over the past 30 days. What happens if you drop the throughput to 50M?

iperf3 -u -R -b 50M -p 17001 -c lnms.cisp.co.za -l 1400 -O 2
[ 4] 0.00-10.00 sec 60.0 MBytes 50.3 Mbits/sec 0.027 ms 1987/44741 (4.4%)
[ 4] Sent 44741 datagrams
[SUM] 0.0-10.0 sec 1979 datagrams received out-of-order

There's something odd with the iperf to JHB though, the constant stream of out of order packet messages..
 
iperf3 -u -R -b 50M -p 17001 -c lnms.cisp.co.za -l 1400 -O 2
[ 4] 0.00-10.00 sec 60.0 MBytes 50.3 Mbits/sec 0.027 ms 1987/44741 (4.4%)
[ 4] Sent 44741 datagrams
[SUM] 0.0-10.0 sec 1979 datagrams received out-of-order

There's something odd with the iperf to JHB though, the constant stream of out of order packet messages..
Yeah, I mentioned this a week or 2 ago. It is just that one specific test UDP from JHB to CPT. IT only stops around 10M. Looking for my post.

Here is the one with the tests: https://mybroadband.co.za/forum/threads/cool-ideas-fibre-isp-feedback.793061/post-23327790

Original post: https://mybroadband.co.za/forum/threads/cool-ideas-fibre-isp-feedback.793061/post-23326206

CC @PBCool
 
iperf3 -u -R -b 50M -p 17001 -c lnms.cisp.co.za -l 1400 -O 2
[ 4] 0.00-10.00 sec 60.0 MBytes 50.3 Mbits/sec 0.027 ms 1987/44741 (4.4%)
[ 4] Sent 44741 datagrams
[SUM] 0.0-10.0 sec 1979 datagrams received out-of-order

There's something odd with the iperf to JHB though, the constant stream of out of order packet messages..

Yours look good compared to mine!
Vuma trenched, Brackenfell, CPT, 1Gbps/100Mbps

iperf3 -u -R -b 50M -p 17001 -c lnms.cisp.co.za -l 1400 -O 2

Code:
iperf3: OUT OF ORDER - incoming packet = 53687 and received packet = 53688 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 53691 and received packet = 53692 AND SP = 4
[  4]   9.00-10.00  sec  5.96 MBytes  50.0 Mbits/sec  0.105 ms  1694/4463 (38%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  59.8 MBytes  50.1 Mbits/sec  0.097 ms  11789/44736 (26%)
[  4] Sent 44736 datagrams
[SUM]  0.0-10.0 sec  11552 datagrams received out-of-order

iperf Done.

iperf3 --port 17001 --bandwidth 30M -l 1400 --omit 2 -R -u -c lnms.cisp.co.za

Code:
iperf3: OUT OF ORDER - incoming packet = 32298 and received packet = 32299 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 32300 and received packet = 32301 AND SP = 4
[  4]   9.00-10.00  sec  3.57 MBytes  30.0 Mbits/sec  0.122 ms  824/2677 (31%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  36.0 MBytes  30.2 Mbits/sec  0.121 ms  6624/26844 (25%)
[  4] Sent 26844 datagrams
[SUM]  0.0-10.0 sec  6623 datagrams received out-of-order

iperf Done.

iperf3 --port 17001 --bandwidth 10M -l 1400 --omit 2 -R -u -c lnms.cisp.co.za

Code:
iperf3: OUT OF ORDER - incoming packet = 7799 and received packet = 7801 AND SP = 4
[  4]   6.00-7.00   sec  1.19 MBytes  9.99 Mbits/sec  0.197 ms  5/891 (0.56%)
[  4]   7.00-8.00   sec  1.19 MBytes  10.0 Mbits/sec  0.041 ms  0/895 (0%)
[  4]   8.00-9.00   sec  1.19 MBytes  9.99 Mbits/sec  0.099 ms  1/893 (0.11%)
[  4]   9.00-10.00  sec  1.19 MBytes  10.0 Mbits/sec  0.057 ms  0/892 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  12.0 MBytes  10.1 Mbits/sec  0.037 ms  22/8948 (0.25%)
[  4] Sent 8948 datagrams
[SUM]  0.0-10.0 sec  21 datagrams received out-of-order

iperf Done.


lnms.cisp.co.za

Code:
|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                              router.lan -    0 |   24 |   24 |    0 |    0 |    0 |    0 |
|                           102.132.248.1 -    0 |   24 |   24 |    2 |    4 |   25 |    2 |
|                         102.132.175.109 -    0 |   24 |   24 |    1 |    1 |    1 |    1 |
|                              154.0.1.13 -    0 |   24 |   24 |    1 |    1 |    1 |    1 |
|                              154.0.2.57 -    0 |   24 |   24 |    1 |    1 |    1 |    1 |
|                              154.0.2.93 -    0 |   24 |   24 |   20 |   20 |   21 |   21 |
|                              154.0.5.97 -    0 |   24 |   24 |   21 |   21 |   22 |   21 |
|                             154.0.1.138 -    0 |   24 |   24 |   21 |   21 |   22 |   21 |
|                             154.0.5.198 -    0 |   24 |   24 |   21 |   21 |   22 |   21 |
|                             154.0.1.254 -    0 |   24 |   24 |   21 |   21 |   22 |   21 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider
 
Last edited:
Yeah, I mentioned this a week or 2 ago. It is just that one specific test UDP from JHB to CPT. IT only stops around 10M. Looking for my post.

Here is the one with the tests: https://mybroadband.co.za/forum/threads/cool-ideas-fibre-isp-feedback.793061/post-23327790

Original post: https://mybroadband.co.za/forum/threads/cool-ideas-fibre-isp-feedback.793061/post-23326206

CC @PBCool

Same behaviour here if I drop the speed to 10M the results appear to normalize?

Although it seems that even TCP speeds are unstable. And this shouldn't be the case from CPT -> JHB

iperf3 -R -b 80M -p 17001 -c lnms.cisp.co.za -l 1400 -O 2
Connecting to host lnms.cisp.co.za, port 17001
Reverse mode, remote host lnms.cisp.co.za is sending
[ 4] local 192.168.1.100 port 21192 connected to 154.0.1.254 port 17001
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 8.87 MBytes 74.4 Mbits/sec (omitted)
[ 4] 1.00-2.00 sec 8.44 MBytes 70.9 Mbits/sec (omitted)
[ 4] 0.00-1.00 sec 6.70 MBytes 56.2 Mbits/sec
[ 4] 1.00-2.00 sec 4.69 MBytes 39.3 Mbits/sec
[ 4] 2.00-3.00 sec 4.75 MBytes 39.9 Mbits/sec
[ 4] 3.00-4.00 sec 5.65 MBytes 47.4 Mbits/sec
[ 4] 4.00-5.00 sec 7.14 MBytes 59.9 Mbits/sec
[ 4] 5.00-6.00 sec 6.74 MBytes 56.5 Mbits/sec
[ 4] 6.00-7.00 sec 5.73 MBytes 48.0 Mbits/sec
[ 4] 7.00-8.00 sec 4.80 MBytes 40.3 Mbits/sec
[ 4] 8.00-9.00 sec 6.09 MBytes 51.2 Mbits/sec
[ 4] 9.00-10.00 sec 7.60 MBytes 63.7 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 60.1 MBytes 50.4 Mbits/sec 53 sender
[ 4] 0.00-10.00 sec 60.0 MBytes 50.3 Mbits/sec receiver
 
Vuma trenched, Brackenfell, CPT, 1Gbps/100Mbps

iperf3 --port 17001 --bandwidth 70M -l 1400 --omit 2 -R -u -c queen.cisp.co.za

Code:
iperf3: OUT OF ORDER - incoming packet = 50440 and received packet = 50495 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 50441 and received packet = 50495 AND SP = 4
[  4]   5.00-6.00   sec  9.53 MBytes  80.0 Mbits/sec  0.014 ms  90/7141 (1.3%)
[  4]   6.00-7.00   sec  9.54 MBytes  80.0 Mbits/sec  0.014 ms  0/7143 (0%)
iperf3: OUT OF ORDER - incoming packet = 70324 and received packet = 70337 AND SP = 4
[  4]   7.00-8.00   sec  9.54 MBytes  80.0 Mbits/sec  0.019 ms  2/7145 (0.028%)
[  4]   8.00-9.00   sec  9.53 MBytes  80.0 Mbits/sec  0.018 ms  1/7142 (0.014%)
[  4]   9.00-10.00  sec  9.53 MBytes  80.0 Mbits/sec  0.020 ms  0/7140 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  97.1 MBytes  81.5 Mbits/sec  0.011 ms  268/72463 (0.37%)
[  4] Sent 72463 datagrams
[SUM]  0.0-10.0 sec  242 datagrams received out-of-order

iperf Done.

Code:
|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                              router.lan -    0 |   43 |   43 |    0 |    0 |    0 |    0 |
|                           102.132.248.1 -    0 |   43 |   43 |    2 |    5 |   34 |    2 |
|                         102.132.175.109 -    0 |   43 |   43 |    1 |    1 |    1 |    1 |
|                              154.0.1.13 -    0 |   43 |   43 |    1 |    1 |    1 |    1 |
|                             154.0.4.162 -    0 |   43 |   43 |    1 |    1 |    1 |    1 |
|                            196.26.90.82 -    0 |   43 |   43 |   19 |   20 |   22 |   20 |
|     mi-za-cpt-p7-te0-0-0-0.ip.isnet.net -    0 |   43 |   43 |   19 |   19 |   20 |   20 |
|                          168.209.201.28 -    0 |   43 |   43 |  141 |  143 |  155 |  143 |
|              be20.asr01.thn.as20860.net -    0 |   43 |   43 |  141 |  142 |  147 |  143 |
|              po150.dc9core1.as20860.net -    0 |   42 |   42 |  144 |  151 |  333 |  144 |
|        94.zone.4.r.dc9.redstation.co.uk -    0 |   43 |   43 |  146 |  149 |  166 |  148 |
|                        queen.cisp.co.za -    0 |   43 |   43 |  144 |  144 |  145 |  144 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider


iperf3 --port 17001 --bandwidth 500M -l 1400 --omit 2 -R -u -c cptspeedtest.cisp.co.za

Code:
Connecting to host cptspeedtest.cisp.co.za, port 17001
Reverse mode, remote host cptspeedtest.cisp.co.za is sending
[  4] local 192.168.88.254 port 61419 connected to 154.0.15.181 port 17001
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-1.00   sec  59.8 MBytes   501 Mbits/sec  0.025 ms  1619/46391 (3.5%)  (omitted)
[  4]   1.00-1.00   sec  59.6 MBytes   250 Mbits/sec  0.032 ms  1/89297 (0.0011%)
[  4]   1.00-2.00   sec  59.6 MBytes   500 Mbits/sec  0.029 ms  11/44639 (0.025%)
[  4]   2.00-3.00   sec  59.6 MBytes   500 Mbits/sec  0.032 ms  1/44645 (0.0022%)
[  4]   3.00-4.00   sec  59.6 MBytes   500 Mbits/sec  0.025 ms  6/44652 (0.013%)
[  4]   4.00-5.00   sec  59.6 MBytes   500 Mbits/sec  0.034 ms  0/44623 (0%)
[  4]   5.00-6.00   sec  59.6 MBytes   500 Mbits/sec  0.041 ms  1/44642 (0.0022%)
[  4]   6.00-7.00   sec  59.6 MBytes   500 Mbits/sec  0.033 ms  10/44666 (0.022%)
[  4]   7.00-8.00   sec  59.6 MBytes   500 Mbits/sec  0.029 ms  0/44645 (0%)
[  4]   8.00-9.00   sec  59.6 MBytes   500 Mbits/sec  0.030 ms  24/44643 (0.054%)
[  4]   9.00-10.00  sec  59.6 MBytes   500 Mbits/sec  0.020 ms  0/44614 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec   599 MBytes   502 Mbits/sec  0.014 ms  53/446496 (0.012%)
[  4] Sent 446496 datagrams

iperf Done.
 
Hi,

SADV Fibre Opertator
location Johannesburg, east rand.
50/50 Mbps connection.

Download/upload local perfect.
Download international good.
Upload international poor. (~10Mbps)

Ticket logged with Cool Ideas. (they say they can't guarantee international speeds)

I've got the iperf3 tool. what tests should I do to test the international upload further?

Kind regards,
chris
 
Hi,

SADV Fibre Opertator
location Johannesburg, east rand.
50/50 Mbps connection.

Download/upload local perfect.
Download international good.
Upload international poor. (~10Mbps)

Ticket logged with Cool Ideas. (they say they can't guarantee international speeds)

I've got the iperf3 tool. what tests should I do to test the international upload further?

Kind regards,
chris
Hi Chris, as per my last post to your other thread, if you are using Windows as your OS it's network stack is quite dumb and doesnt scale outbound TCP window size, hence the poor upload. Please try using our Proxy stuprx01.cisp.co.za which will then push you through a linux network stack.
 
Same behaviour here if I drop the speed to 10M the results appear to normalize?

Although it seems that even TCP speeds are unstable. And this shouldn't be the case from CPT -> JHB

iperf3 -R -b 80M -p 17001 -c lnms.cisp.co.za -l 1400 -O 2
Connecting to host lnms.cisp.co.za, port 17001
Reverse mode, remote host lnms.cisp.co.za is sending
[ 4] local 192.168.1.100 port 21192 connected to 154.0.1.254 port 17001
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 8.87 MBytes 74.4 Mbits/sec (omitted)
[ 4] 1.00-2.00 sec 8.44 MBytes 70.9 Mbits/sec (omitted)
[ 4] 0.00-1.00 sec 6.70 MBytes 56.2 Mbits/sec
[ 4] 1.00-2.00 sec 4.69 MBytes 39.3 Mbits/sec
[ 4] 2.00-3.00 sec 4.75 MBytes 39.9 Mbits/sec
[ 4] 3.00-4.00 sec 5.65 MBytes 47.4 Mbits/sec
[ 4] 4.00-5.00 sec 7.14 MBytes 59.9 Mbits/sec
[ 4] 5.00-6.00 sec 6.74 MBytes 56.5 Mbits/sec
[ 4] 6.00-7.00 sec 5.73 MBytes 48.0 Mbits/sec
[ 4] 7.00-8.00 sec 4.80 MBytes 40.3 Mbits/sec
[ 4] 8.00-9.00 sec 6.09 MBytes 51.2 Mbits/sec
[ 4] 9.00-10.00 sec 7.60 MBytes 63.7 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 60.1 MBytes 50.4 Mbits/sec 53 sender
[ 4] 0.00-10.00 sec 60.0 MBytes 50.3 Mbits/sec receiver
Let's put the IPerf aside for a moment, is there an issue with a service you are accessing in JHB?
 
Also just a heads up we have moved our local transit in Cape Town from eNetworks to IS, this shouldn't have any noticeable effect.
 
Hi Chris, as per my last post to your other thread, if you are using Windows as your OS it's network stack is quite dumb and doesnt scale outbound TCP window size, hence the poor upload. Please try using our Proxy stuprx01.cisp.co.za which will then push you through a linux network stack.
I've answer this already.
1. National speed tests are fine? so why would the TCP window size behavior differently when doing a international speed test compared to a local one?
2. Using my phone which is using a different OS results in the same results. (Poor INTERNATIONAL uploads)
3. I was getting accetable upload speeds internationaly a couple of weeks back, did MS make changes to their TCP window size recently?

regards,
chris
 
I've answer this already.
1. National speed tests are fine? so why would the TCP window size behavior differently when doing a international speed test compared to a local one?
2. Using my phone which is using a different OS results in the same results. (Poor INTERNATIONAL uploads)
3. I was getting accetable upload speeds internationaly a couple of weeks back, did MS make changes to their TCP window size recently?

regards,
chris
TCP window size is relative to throughput on higher latency connections, so locally it doesn't need to scale. The higher the latency the more the effect. It's possible you have packet loss in one direction as well, but let's try test the proxy first.

What service are you uploading to that gives you poor performance?
 
These look normal as well, Vox will obviously not use our transport to get to UK. But the rest seem fine, latency from London to Austria seems to be ~30ms from London, and I see packet loss on their network from my traces.
I'll do one to somoene else when I get home, but that's quite interesting considering that from the office here, I can manage to hit 45Mbps down from them on a 50Mbps line.

Are you sure it's not your network link/peering partner? I managed 34Mbps with your proxy, and 8Mbps without, I highly doubt that is caused by what you claim to be on their side.
 
I'll do one to somoene else when I get home, but that's quite interesting considering that from the office here, I can manage to hit 45Mbps down from them on a 50Mbps line.

Are you sure it's not your network link/peering partner? I managed 34Mbps with your proxy, and 8Mbps without, I highly doubt that is caused by what you claim to be on their side.
Usually if the proxy helps it's packet loss related, we peer with CoreIX directly for example, what do IPerfs look like to London? Apologies if you have done that already.
 
TCP window size is relative to throughput on higher latency connections, so locally it doesn't need to scale. The higher the latency the more the effect. It's possible you have packet loss in one direction as well, but let's try test the proxy first.

What service are you uploading to that gives you poor performance?

onedrive.live.com for example. Uploading a 50MB file, expecting to take about 10seconds. It takes over a minute.

edit: or doing a speedtest.net to any international server gives <15Mpbs up.
 
Last edited:
Usually if the proxy helps it's packet loss related, we peer with CoreIX directly for example, what do IPerfs look like to London? Apologies if you have done that already.
Can't right now as at the office, can this evening.
Mind giving me a specific address to iperf test to?
 
Let's put the IPerf aside for a moment, is there an issue with a service you are accessing in JHB?
Nope. I do however have a ticket that's been open for a couple weeks now regarding slow international throughput during the evenings (see my previous posts) and just noticed this behaviour recently and thought to bring it to your attention.

The slow int throughput issue is somewhat intermittent and I only report it on the evenings when it's really bad (Twitch unwatchable, etc).
 
@PBCool any idea why my MTR's packet loss sucks so much a** all the time?

Can't say my connection is noticeably affected - no issues, just see all these great mtrs with no packet loss posted here and mine are always around 80-90% loss, over gigabit LAN not wifi..

$ sudo mtr -r speedtest.your-server.de
HOST: macserver.ibox.za.net Loss% Snt Last Avg Best Wrst StDev
1.|-- router.ibox.za.net 0.0% 10 0.5 0.5 0.4 0.6 0.1
2.|-- u33m-cust.coolideas.co.za 90.0% 10 2.8 2.8 2.8 2.8 0.0
3.|-- u33l-cust.coolideas.co.za 90.0% 10 3.2 3.2 3.2 3.2 0.0
4.|-- uwy-cust.coolideas.co.za 80.0% 10 3.9 3.5 3.1 3.9 0.5
5.|-- uvu-cust.coolideas.co.za 80.0% 10 143.4 143.4 143.4 143.4 0.0
6.|-- v1000.core1.lon3.he.net 80.0% 10 143.5 143.6 143.5 143.7 0.2
7.|-- 100ge14-1.core1.lon2.he.n 80.0% 10 145.7 144.2 142.7 145.7 2.1
8.|-- 100ge7-1.core1.fra1.he.ne 90.0% 10 154.6 154.6 154.6 154.6 0.0
9.|-- decix2-gw.hetzner.de 80.0% 10 155.4 155.4 155.4 155.5 0.1
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11.|-- juniper3.dc1.nbg1.hetzner 80.0% 10 158.6 160.2 158.6 161.8 2.2
12.|-- speedtest.your-server.de 90.0% 10 158.8 158.8 158.8 158.8 0.0

$ sudo mtr -r netflix.com
HOST: macserver.ibox.za.net Loss% Snt Last Avg Best Wrst StDev
1.|-- router.ibox.za.net 0.0% 10 0.6 0.5 0.4 0.6 0.1
2.|-- u33m-cust.coolideas.co.za 90.0% 10 3.0 3.0 3.0 3.0 0.0
3.|-- u33l-cust.coolideas.co.za 80.0% 10 3.5 3.1 2.7 3.5 0.5
4.|-- 196-10-140-105.ixp.capeto 80.0% 10 3.3 18.7 3.3 34.1 21.8
5.|-- 52.93.57.88 90.0% 10 5.0 5.0 5.0 5.0 0.0
6.|-- 52.93.57.99 90.0% 10 3.2 3.2 3.2 3.2 0.0
7.|-- 54.239.46.83 80.0% 10 156.0 155.5 155.0 156.0 0.7
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
9.|-- 54.239.44.140 90.0% 10 154.8 154.8 154.8 154.8 0.0
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11.|-- 52.93.6.128 90.0% 10 172.7 172.7 172.7 172.7 0.0
12.|-- 52.93.101.5 80.0% 10 154.2 154.3 154.2 154.3 0.0
13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0

$ sudo mtr -r cisp.co.za
HOST: macserver.ibox.za.net Loss% Snt Last Avg Best Wrst StDev
1.|-- router.ibox.za.net 0.0% 10 0.4 0.5 0.4 0.6 0.1
2.|-- u33m-cust.coolideas.co.za 90.0% 10 3.7 3.7 3.7 3.7 0.0
3.|-- u33l-cust.coolideas.co.za 90.0% 10 2.9 2.9 2.9 2.9 0.0
4.|-- c1l-backbone.coolideas.co 90.0% 10 3.3 3.3 3.3 3.3 0.0
5.|-- c2l-backbone.coolideas.co 80.0% 10 23.0 23.0 22.9 23.0 0.1
6.|-- u129-cust.coolideas.co.za 70.0% 10 23.8 23.6 23.4 23.8 0.2
7.|-- urm-cust.coolideas.co.za 60.0% 10 23.1 23.3 22.9 24.1 0.5
8.|-- u2n3-cust.coolideas.co.za 90.0% 10 24.3 24.3 24.3 24.3 0.0
 
So Frogfoot was at my home, installed the fibre, did the splicing.
CISP ticet says:
"This Zone is still in WIP.
Order checked, accepted and progressed.
A contractor will be assigned to this build when the zone goes live."

Thats weird... why do a install on a zone that is still @wip?
So I asked Frogfoot on facebook:

"Frogfoot Hi there Meyr, Zone 3.1 is definitely live. Please ask your ISP to double check "

What do you think I can do to get connected....?
 
So Frogfoot was at my home, installed the fibre, did the splicing.
CISP ticet says:
"This Zone is still in WIP.
Order checked, accepted and progressed.
A contractor will be assigned to this build when the zone goes live."

Thats weird... why do a install on a zone that is still @wip?
So I asked Frogfoot on facebook:

"Frogfoot Hi there Meyr, Zone 3.1 is definitely live. Please ask your ISP to double check "

What do you think I can do to get connected....?
Send this information to [email protected] on the ticket, or phone in.
 
@PBCool any idea why my MTR's packet loss sucks so much a** all the time?

Can't say my connection is noticeably affected - no issues, just see all these great mtrs with no packet loss posted here and mine are always around 80-90% loss, over gigabit LAN not wifi..
What are you using as a router? Looks like that is dropping your ICMP
 
Status
Not open for further replies.
Top
Sign up to the MyBroadband newsletter
X