Frogfoot Port Elizabeth

Vorastra said:
This fibre over in PE, is it only in the larney areas or normal areas too?
Click to expand...
Seems like they are rolling out mostly everywhere, but it does take time:

Blue - Live
Red - Planned no ETA
Yellow - WIP
Black - Orders not allowed

1592477817486.png
 
Second night and speeds don't seem too good. Getting 1.38 down and 1.28 up. Disconnecting and reconnecting the pppoe session didn't seem to change anything.

Anyone else having trouble tonight?

Edit: back up and running again @ 23:00
 
Last edited:
PhireSide said:
Second night and speeds don't seem too good. Getting 1.38 down and 1.28 up. Disconnecting and reconnecting the pppoe session didn't seem to change anything.

Anyone else having trouble tonight?

Edit: back up and running again @ 23:00
Click to expand...
Your isp going via capetown or Johannesburg
 
Some iperf3 results on my 20/20 line with CapeConnect-

To iperf.ct1.napafrica.net (Cape Town):
Bash: 
pi@pi:~ $ iperf3 -R -V -t 30 -O 3 -c iperf.ct1.napafrica.net
iperf 3.6
Linux pi 4.19.118-v7+ #1311 SMP Mon Apr 27 14:21:24 BST 2020 armv7l
Control connection MSS 1428
Time: Fri, 19 Jun 2020 17:03:48 GMT
Connecting to host iperf.ct1.napafrica.net, port 5201
Reverse mode, remote host iperf.ct1.napafrica.net is sending
      Cookie: mg3rbrkdo7v6vjekrpjxu7ypinfrtmxnadti
      TCP MSS: 1428 (default)
[  5] local 10.0.0.5 port 35098 connected to 196.10.99.34 port 5201
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 3 seconds, 30 second test, tos 0
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  1.22 MBytes  10.2 Mbits/sec                  (omitted)
[  5]   1.00-2.00   sec   692 KBytes  5.67 Mbits/sec                  (omitted)
[  5]   2.00-3.00   sec   414 KBytes  3.39 Mbits/sec                  (omitted)
[  5]   0.00-1.00   sec   572 KBytes  4.68 Mbits/sec
[  5]   1.00-2.00   sec   630 KBytes  5.16 Mbits/sec
[  5]   2.00-3.00   sec  1022 KBytes  8.37 Mbits/sec
[  5]   3.00-4.00   sec  1.05 MBytes  8.84 Mbits/sec
[  5]   4.00-5.00   sec   731 KBytes  5.99 Mbits/sec
[  5]   5.00-6.00   sec   784 KBytes  6.42 Mbits/sec
[  5]   6.00-7.00   sec  1.23 MBytes  10.3 Mbits/sec
[  5]   7.00-8.00   sec  1.37 MBytes  11.5 Mbits/sec
[  5]   8.00-9.00   sec  1.72 MBytes  14.5 Mbits/sec
[  5]   9.00-10.00  sec  1.15 MBytes  9.63 Mbits/sec
[  5]  10.00-11.00  sec  1.20 MBytes  10.1 Mbits/sec
[  5]  11.00-12.00  sec   901 KBytes  7.38 Mbits/sec
[  5]  12.00-13.00  sec  1.31 MBytes  11.0 Mbits/sec
[  5]  13.00-14.00  sec  1.36 MBytes  11.4 Mbits/sec
[  5]  14.00-15.00  sec  1.79 MBytes  15.0 Mbits/sec
[  5]  15.00-16.00  sec  1.89 MBytes  15.9 Mbits/sec
[  5]  16.00-17.00  sec  1.70 MBytes  14.2 Mbits/sec
[  5]  17.00-18.00  sec  2.02 MBytes  17.0 Mbits/sec
[  5]  18.00-19.00  sec  1.82 MBytes  15.3 Mbits/sec
[  5]  19.00-20.00  sec  1.71 MBytes  14.4 Mbits/sec
[  5]  20.00-21.00  sec  1.63 MBytes  13.7 Mbits/sec
[  5]  21.00-22.00  sec  1.55 MBytes  13.0 Mbits/sec
[  5]  22.00-23.00  sec  2.03 MBytes  17.0 Mbits/sec
[  5]  23.00-24.00  sec  1.37 MBytes  11.5 Mbits/sec
[  5]  24.00-25.00  sec  2.01 MBytes  16.9 Mbits/sec
[  5]  25.00-26.00  sec  1.41 MBytes  11.9 Mbits/sec
[  5]  26.00-27.00  sec  1.77 MBytes  14.8 Mbits/sec
[  5]  27.00-28.00  sec  1.87 MBytes  15.7 Mbits/sec
[  5]  28.00-29.00  sec  1.83 MBytes  15.4 Mbits/sec
[  5]  29.00-30.00  sec  2.00 MBytes  16.8 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-30.05  sec  43.4 MBytes  12.1 Mbits/sec  292             sender
[  5]   0.00-30.00  sec  43.3 MBytes  12.1 Mbits/sec                  receiver
CPU Utilization: local/receiver 3.5% (0.3%u/3.3%s), remote/sender 0.0% (0.0%u/0.0%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic

iperf Done.

To bouygues.iperf.fr (France):

Bash: 
pi@pi:~ $ iperf3 -R -V -t 30 -O 3 -c bouygues.iperf.fr
iperf 3.6
Linux pi 4.19.118-v7+ #1311 SMP Mon Apr 27 14:21:24 BST 2020 armv7l
Control connection MSS 1448
Time: Fri, 19 Jun 2020 17:16:06 GMT
Connecting to host bouygues.iperf.fr, port 5201
Reverse mode, remote host bouygues.iperf.fr is sending
      Cookie: xcq4mc5rm5fqqzevy5jjaffhyutkg4tyb52j
      TCP MSS: 1448 (default)
[  5] local 10.0.0.5 port 33080 connected to 89.84.1.222 port 5201
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 3 seconds, 30 second test, tos 0
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  41.0 KBytes   336 Kbits/sec                  (omitted)
[  5]   1.00-2.00   sec  42.3 KBytes   346 Kbits/sec                  (omitted)
[  5]   2.00-3.00   sec  55.8 KBytes   457 Kbits/sec                  (omitted)
[  5]   0.00-1.00   sec  68.3 KBytes   560 Kbits/sec
[  5]   1.00-2.00   sec  48.8 KBytes   400 Kbits/sec
[  5]   2.00-3.00   sec  51.6 KBytes   423 Kbits/sec
[  5]   3.00-4.00   sec  60.0 KBytes   491 Kbits/sec
[  5]   4.00-5.00   sec  51.6 KBytes   423 Kbits/sec
[  5]   5.00-6.00   sec  54.4 KBytes   446 Kbits/sec
[  5]   6.00-7.00   sec  46.0 KBytes   377 Kbits/sec
[  5]   7.00-8.00   sec  57.2 KBytes   468 Kbits/sec
[  5]   8.00-9.00   sec  68.3 KBytes   560 Kbits/sec
[  5]   9.00-10.00  sec  58.6 KBytes   480 Kbits/sec
[  5]  10.00-11.00  sec  58.6 KBytes   480 Kbits/sec
[  5]  11.00-12.00  sec  55.8 KBytes   457 Kbits/sec
[  5]  12.00-13.00  sec  50.2 KBytes   411 Kbits/sec
[  5]  13.00-14.00  sec  60.0 KBytes   491 Kbits/sec
[  5]  14.00-15.00  sec  53.0 KBytes   434 Kbits/sec
[  5]  15.00-16.00  sec  64.1 KBytes   525 Kbits/sec
[  5]  16.00-17.00  sec  57.2 KBytes   468 Kbits/sec
[  5]  17.00-18.00  sec  65.5 KBytes   537 Kbits/sec
[  5]  18.00-19.00  sec  58.6 KBytes   480 Kbits/sec
[  5]  19.00-20.00  sec  71.1 KBytes   583 Kbits/sec
[  5]  20.00-21.00  sec  60.0 KBytes   491 Kbits/sec
[  5]  21.00-22.00  sec  53.0 KBytes   434 Kbits/sec
[  5]  22.00-23.00  sec  39.0 KBytes   320 Kbits/sec
[  5]  23.00-24.00  sec  51.6 KBytes   423 Kbits/sec
[  5]  24.00-25.00  sec  47.4 KBytes   388 Kbits/sec
[  5]  25.00-26.00  sec  43.2 KBytes   354 Kbits/sec
[  5]  26.00-27.00  sec  33.5 KBytes   274 Kbits/sec
[  5]  27.00-28.00  sec  29.3 KBytes   240 Kbits/sec
[  5]  28.00-29.00  sec  43.2 KBytes   354 Kbits/sec
[  5]  29.00-30.00  sec  66.9 KBytes   548 Kbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-30.19  sec  1.58 MBytes   439 Kbits/sec   49             sender
[  5]   0.00-30.00  sec  1.59 MBytes   444 Kbits/sec                  receiver
CPU Utilization: local/receiver 0.2% (0.0%u/0.2%s), remote/sender 0.0% (0.0%u/0.0%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic

iperf Done.

I also tried to some public iperf servers in Kazakhstan, Estonia, Jakarta, USA, Ukraine and Germany, unfortunately they all timed out before connecting. During the day local iperf servers give close to the claimed 20mbit, but it drops to around half that after 18:00. I haven't tested international during the day, but as can be seen the peak time speeds are quite awful at about 440kbps
 
So I am a little new to the whole FTTH thing, I have a few questions, and was hoping someone here can answer them for me.

How does one determine via traceroute which hops are FF and which hops are on your ISP's infra?

What is an acceptable packet loss % to local (within SA) hosts?

Is slow international throughput 'normal' or is it a symptom of network congestion? I'm talking 40KB/s downloads from Sourceforge.
 
PhireSide said:
So I am a little new to the whole FTTH thing, I have a few questions, and was hoping someone here can answer them for me.

How does one determine via traceroute which hops are FF and which hops are on your ISP's infra?

What is an acceptable packet loss % to local (within SA) hosts?

Is slow international throughput 'normal' or is it a symptom of network congestion? I'm talking 40KB/s downloads from Sourceforge.
Click to expand...

I think only Vumatel FNO have hops that are not the ISP's
Frogfoot present the network to us and ISP via VLAN so its transparent to us

my last 10 days pl ave to 1.1.1.1 is 0.06%

if its single thread then its probably packet loss (which can be caused by congestion)
 
Leno said:
I think only Vumatel FNO have hops that are not the ISP's
Frogfoot present the network to us and ISP via VLAN so its transparent to us

my last 10 days pl ave to 1.1.1.1 is 0.06%

if its single thread then its probably packet loss (which can be caused by congestion)
Click to expand...
Thanks for the feedback, much appreciated.

I guess that makes troubleshooting a bit harder, and more difficult to determine who has a fault (currently my understanding is regardless of fault, it gets logged to the ISP who then escalates to FF if necessary) and perhaps easier for the FNO and the ISP to pass the buck in terms of liability for an issue.

I've checked my PL to 1.1.1.1 as well, and it's currently sitting on 3.2% over 3 hours, 1.02% over 30 hours and 0.85% over 3 days (only setup Smokeping this weekend)
 
So I'm going to be a bit active here as I seem to have some very weird issues going on, all pointing to DNS as a probable cause - however, I don't think that it actually is.

Issue 1:

Our Ematic AGT419 TV Box can't load Netflix when connected to either our WiFi or with an Ethernet cable. Netflix app troubleshooting says that Netflix servers 1 and 2 are available, 3 is not, and it says the internet connectivity looks good. I have tried giving the TV Box static DNS entries of 8.8.8.8 and 8.8.4.4, to no avail. Connecting the Ematic to my phone hotspot, works just fine and it loads as expected. Netflix also loads on all the other devices in the house (tested on two Android phones, and a laptop running Windows 10). It's worth noting that the other applications on the box also work flawlessly (YouTube, Tubi, Plex, Spotify, Play Store). I've done everything except reset the box to factory defaults, which is my last resort.

Issue 2:

I have a Xiaomi 360 Camera that has been working fine and dandy on my previous Telkom LTE connection, but has a very strange issue with the Fibre connection. When my phone is connected to the same WiFi SSID as the camera, I cannot log in using the Xiaomi Home app. I can bypass this by connecting to WireGuard VPN while still connected to my internal WiFi, or switching to mobile data - which means that the camera seems to have a good connection to whatever cloud server it needs to connect to. It just seems like the App on our phones is not happy being on the same subnet as the camera after the fibre went live. For reference, the WiFi range is 10.0.0.x and the WireGuard range is 10.7.0.0.

For what it's worth, I have PiHole setup as well, and I can see that there are many, many queries going to sg.business.smartcamera.api.io.mi.com that I didn't see before moving to fibre. Very strange indeed. I've tried using cloudflared to wrap the DNS requests in HTTPS, to rule out an issue that may be blocking port 53 traffic, and tried various other DNS servers (I have tried Quad9, OpenDNS, CloudFlare, GoogleDNS, Level3 and Comodo).

This ended up being a bit longer than I thought it would be, but if anyone has had similar issues on Frogfoot and wouldn't mind posting, I would really appreciate it. I've tried the usual troubleshooting steps - reset the Access Point, reset the router to factory defaults, plugged the ONT out for a couple of minutes, bypassed the PiHole, etc etc.
 
PhireSide said:
So I'm going to be a bit active here as I seem to have some very weird issues going on, all pointing to DNS as a probable cause - however, I don't think that it actually is.

Issue 1:

Our Ematic AGT419 TV Box can't load Netflix when connected to either our WiFi or with an Ethernet cable. Netflix app troubleshooting says that Netflix servers 1 and 2 are available, 3 is not, and it says the internet connectivity looks good. I have tried giving the TV Box static DNS entries of 8.8.8.8 and 8.8.4.4, to no avail. Connecting the Ematic to my phone hotspot, works just fine and it loads as expected. Netflix also loads on all the other devices in the house (tested on two Android phones, and a laptop running Windows 10). It's worth noting that the other applications on the box also work flawlessly (YouTube, Tubi, Plex, Spotify, Play Store). I've done everything except reset the box to factory defaults, which is my last resort.

Issue 2:

I have a Xiaomi 360 Camera that has been working fine and dandy on my previous Telkom LTE connection, but has a very strange issue with the Fibre connection. When my phone is connected to the same WiFi SSID as the camera, I cannot log in using the Xiaomi Home app. I can bypass this by connecting to WireGuard VPN while still connected to my internal WiFi, or switching to mobile data - which means that the camera seems to have a good connection to whatever cloud server it needs to connect to. It just seems like the App on our phones is not happy being on the same subnet as the camera after the fibre went live. For reference, the WiFi range is 10.0.0.x and the WireGuard range is 10.7.0.0.

For what it's worth, I have PiHole setup as well, and I can see that there are many, many queries going to sg.business.smartcamera.api.io.mi.com that I didn't see before moving to fibre. Very strange indeed. I've tried using cloudflared to wrap the DNS requests in HTTPS, to rule out an issue that may be blocking port 53 traffic, and tried various other DNS servers (I have tried Quad9, OpenDNS, CloudFlare, GoogleDNS, Level3 and Comodo).

This ended up being a bit longer than I thought it would be, but if anyone has had similar issues on Frogfoot and wouldn't mind posting, I would really appreciate it. I've tried the usual troubleshooting steps - reset the Access Point, reset the router to factory defaults, plugged the ONT out for a couple of minutes, bypassed the PiHole, etc etc.
Click to expand...

I figured it out, was reading up a bit about how VPN connections can alter MTU size, so I enabled MSS clamping on my PPPoE connection - suddenly, everything was working fine again. Odd that the default 1500 - 8 for the PPPoE header wasn't enough. The largest MTU I could set was 1432 bytes; any larger would cause issues again.
 
PhireSide said:
I figured it out, was reading up a bit about how VPN connections can alter MTU size, so I enabled MSS clamping on my PPPoE connection - suddenly, everything was working fine again. Odd that the default 1500 - 8 for the PPPoE header wasn't enough. The largest MTU I could set was 1432 bytes; any larger would cause issues again.
Click to expand...
Was This For Both NETFLIX and the Xiaomi issue?
 
Incoming maintenance for Port Elizabeth tomorrow evening:

1593019679391.png
 
Noticed the same on my graphs, I was wondering what the issue was

1593337398872.png
 
Is not only Frogfoot. I am on SADV in East London and my latency jumped from 35ms to 82ms at 12 midday yesterday as well.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X