Frogfoot Gpon FTTH Fibre Performance

I wanted to mention that I am not bashing GPON Fibre. For the record this Frogfoot line was until August as reliable as the active ethernet through DFA, I even commented on this to the MD of Frogfoot. Well his assistant.

My only experience and reference point has been active ethernet though DFA but its not sustainable at its cost, its almost punitive in its costing. I just thought, how do you troubleshoot a connection that splits 64 times through 2 sets of splitters. I get now that the gear costs millions of rands and GPON is tried and tested. So please don't think I'm bashing the technology. It was lack of experience in using it.

I am just a user who's Netflix starts buffering every night @ 20h00 and trying to figure out why.
 
lightpixel said:
So as you know Frogfoot tested the line their fancy testing device and cleared it as "no packet loss". Basically saying that I am full of sh*t with my 0.1% loss. So here't the layer three tests, very basic but best I know how to do from my Mac, wired connection. Cat6. Lan network idle.

Atomic line, 200 Meg connection, testing to Teraco cpt. I'm testing an perf server @ nap Africa in Teraco.

BEFORE PEAK (After 19h00)

Stephens-Mac:~ stephen$ iperf3 -R -4 -V -t 10 -O 3 -c iperf.ct1.napafrica.net

iperf 3.6

Darwin Stephens-Mac.local 19.0.0 Darwin Kernel Version 19.0.0: Tue Jul 23 01:19:36 PDT 2019; root:xnu-6153.0.103.151.1~4/RELEASE_X86_64 x86_64

Control connection MSS 1448

Time: Wed, 21 Aug 2019 17:25:43 GMT

Connecting to host iperf.ct1.napafrica.net, port 5201

Reverse mode, remote host iperf.ct1.napafrica.net is sending

Cookie: m4cbkuegwartrpdnjy4znubt3xi6ymd7gh2e

TCP MSS: 1448 (default)

[ 6] local 10.0.0.154 port 65320 connected to 196.10.99.34 port 5201

Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 3 seconds, 10 second test, tos 0

[ ID] Interval Transfer Bitrate

[ 6] 0.00-1.00 sec 20.4 MBytes 171 Mbits/sec (omitted)

[ 6] 1.00-2.00 sec 22.1 MBytes 186 Mbits/sec (omitted)

[ 6] 2.00-3.00 sec 22.3 MBytes 187 Mbits/sec (omitted)

[ 6] 0.00-1.00 sec 22.8 MBytes 191 Mbits/sec

[ 6] 1.00-2.00 sec 22.6 MBytes 189 Mbits/sec

[ 6] 2.00-3.00 sec 22.6 MBytes 189 Mbits/sec

[ 6] 3.00-4.00 sec 22.6 MBytes 190 Mbits/sec

[ 6] 4.00-5.00 sec 22.7 MBytes 190 Mbits/sec

[ 6] 5.00-6.00 sec 22.7 MBytes 190 Mbits/sec

[ 6] 6.00-7.00 sec 20.9 MBytes 175 Mbits/sec

[ 6] 7.00-8.00 sec 20.5 MBytes 172 Mbits/sec

[ 6] 8.00-9.00 sec 22.6 MBytes 190 Mbits/sec

[ 6] 9.00-10.00 sec 22.3 MBytes 187 Mbits/sec

- - - - - - - - - - - - - - - - - - - - - - - - -

Test Complete. Summary Results:

[ ID] Interval Transfer Bitrate Retr

[ 6] 0.00-10.00 sec 223 MBytes 187 Mbits/sec 130 sender

[ 6] 0.00-10.00 sec 222 MBytes 186 Mbits/sec receiver

CPU Utilization: local/receiver 14.2% (2.6%u/11.6%s), remote/sender 0.0% (0.0%u/0.0%s)

snd_tcp_congestion cubic



iperf Done.

Stephens-Mac:~ stephen$

During PEAK (20h51), still on Atomic, same server.

Stephens-Mac:~ stephen$ iperf3 -R -4 -V -t 10 -O 3 -c iperf.ct1.napafrica.net
iperf 3.6
Darwin Stephens-Mac.local 19.0.0 Darwin Kernel Version 19.0.0: Tue Jul 23 01:19:36 PDT 2019; root:xnu-6153.0.103.151.1~4/RELEASE_X86_64 x86_64
Control connection MSS 1448
Time: Wed, 21 Aug 2019 18:15:38 GMT
Connecting to host iperf.ct1.napafrica.net, port 5201
Reverse mode, remote host iperf.ct1.napafrica.net is sending
Cookie: p3beh2cezqqy72yq7zbakabegpw2t3bvfrh2
TCP MSS: 1448 (default)
[ 6] local 10.0.0.154 port 53524 connected to 196.10.99.34 port 5201
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 3 seconds, 10 second test, tos 0
[ ID] Interval Transfer Bitrate
[ 6] 0.00-1.00 sec 10.6 MBytes 89.1 Mbits/sec (omitted)
[ 6] 1.00-2.00 sec 16.6 MBytes 140 Mbits/sec (omitted)
[ 6] 2.00-3.00 sec 11.4 MBytes 95.4 Mbits/sec (omitted)
[ 6] 0.00-1.00 sec 11.8 MBytes 99.0 Mbits/sec
[ 6] 1.00-2.00 sec 8.07 MBytes 67.7 Mbits/sec
[ 6] 2.00-3.00 sec 14.8 MBytes 124 Mbits/sec
[ 6] 3.00-4.00 sec 10.3 MBytes 86.1 Mbits/sec
[ 6] 4.00-5.00 sec 10.5 MBytes 87.7 Mbits/sec
[ 6] 5.00-6.00 sec 6.84 MBytes 57.4 Mbits/sec
[ 6] 6.00-7.00 sec 6.86 MBytes 57.6 Mbits/sec
[ 6] 7.00-8.00 sec 10.6 MBytes 88.5 Mbits/sec
[ 6] 8.00-9.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 6] 9.00-10.00 sec 9.19 MBytes 77.1 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 6] 0.00-10.00 sec 100 MBytes 84.0 Mbits/sec 387 sender
[ 6] 0.00-10.00 sec 100 MBytes 84.0 Mbits/sec receiver
CPU Utilization: local/receiver 3.1% (0.5%u/2.6%s), remote/sender 0.0% (0.0%u/0.0%s)
snd_tcp_congestion cubic

iperf Done.
Stephens-Mac:~ stephen$

Basically the speed halves during peak times. Draw your own conclusions.
Click to expand...
The FNO needs to post more info of their setup. I assume they are using some CE kit? What is it and how is in configured? If the test they did on the last mile is accurate using RFC2544 then the fault domain is their data centre CE aggregation switch or the ISP cross connect. What flow control, queuing, policing and has been implemented?
With CE kit it is harsh, when a limit is hit it drops packets. Wham bam, no gentle burst allowed. All this can be visualized on the SNMP counters. The ISPs should have NDAs with the FNO and someone can go look at those counters.
 
lightpixel said:
I wanted to mention that I am not bashing GPON Fibre. For the record this Frogfoot line was until August as reliable as the active ethernet through DFA, I even commented on this to the MD of Frogfoot. Well his assistant.

My only experience and reference point has been active ethernet though DFA but its not sustainable at its cost, its almost punitive in its costing. I just thought, how do you troubleshoot a connection that splits 64 times through 2 sets of splitters. I get now that the gear costs millions of rands and GPON is tried and tested. So please don't think I'm bashing the technology. It was lack of experience in using it.

I am just a user who's Netflix starts buffering every night @ 20h00 and trying to figure out why.
Click to expand...

The split is not an equal split - more of a share to a maximum combined throughput on the tx/rx depending on what's implemented. If both ISPs are displaying the same behaviour I would think it's safe to assume theres congestion at some stage between Frogfoot and the ISPs which is apparent at peak times. Since it's highly unlikely that the NAPafrica iperf is congested it supports this theory too.
 
r00igev@@r said:
The FNO needs to post more info of their setup. I assume they are using some CE kit? What is it and how is in configured? If the test they did on the last mile is accurate using RFC2544 then the fault domain is their data centre CE aggregation switch or the ISP cross connect. What flow control, queuing, policing and has been implemented?
With CE kit it is harsh, when a limit is hit it drops packets. Wham bam, no gentle burst allowed. All this can be visualized on the SNMP counters. The ISPs should have NDAs with the FNO and someone can go look at those counters.
Click to expand...

Hopefully they will.
A little bird told me that the FFoot end @ the Milpark node room is a Calix E720 which is apparently the best of the best in GPON. I know nothing about networking so that does not mean much to me.
 
@lightpixel can you try:
Code: 
iperf3 -4 -V -R -t 15 -O 3 -u -b 80M -c iperf.ct1.napafrica.net  -p 3334 -l 1460
Btw wrap your output in code tags please, makes it easier to scroll on the page and it keeps whitespace. Add >> filename.txt to save the output directly to a text file. Note to set it to 80% of line speed (for me 80Mbps of 100Mbps)
The reason I ask that you run the above is that it's a UDP test where you should be able to see the lost/total datagrams (proper packet loss figures)
Code: 
Starting Test: protocol: UDP, 1 streams, 1460 byte blocks, omitting 3 seconds, 15 second test
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-1.00   sec  7.25 MBytes  60.8 Mbits/sec  0.234 ms  1159/6367 (18%)  (omitted)
[  4]   1.00-2.00   sec  9.63 MBytes  80.8 Mbits/sec  0.231 ms  237/7156 (3.3%)  (omitted)
[  4]   2.00-3.00   sec  7.20 MBytes  60.4 Mbits/sec  0.245 ms  1407/6575 (21%)  (omitted)
[  4]   0.00-1.00   sec  9.09 MBytes  76.2 Mbits/sec  0.222 ms  692/7219 (9.6%)
[  4]   1.00-2.00   sec  7.04 MBytes  59.1 Mbits/sec  0.221 ms  1406/6462 (22%)
[  4]   2.00-3.00   sec  9.19 MBytes  77.0 Mbits/sec  0.225 ms  714/7312 (9.8%)
[  4]   3.00-4.00   sec  7.67 MBytes  64.4 Mbits/sec  0.214 ms  859/6367 (13%)
[  4]   4.00-5.00   sec  9.22 MBytes  77.4 Mbits/sec  0.220 ms  701/7325 (9.6%)
[  4]   5.00-6.00   sec  6.88 MBytes  57.7 Mbits/sec  0.213 ms  1411/6354 (22%)
[  4]   6.00-7.00   sec  9.22 MBytes  77.3 Mbits/sec  0.242 ms  704/7325 (9.6%)
[  4]   7.00-8.00   sec  8.58 MBytes  72.0 Mbits/sec  0.242 ms  705/6869 (10%)
[  4]   8.00-9.00   sec  8.63 MBytes  72.4 Mbits/sec  0.222 ms  289/6488 (4.5%)
[  4]   9.00-10.00  sec  8.44 MBytes  70.7 Mbits/sec  0.240 ms  712/6772 (11%)
[  4]  10.00-11.00  sec  7.62 MBytes  64.0 Mbits/sec  0.216 ms  1432/6907 (21%)
[  4]  11.00-12.00  sec  8.53 MBytes  71.5 Mbits/sec  0.224 ms  762/6888 (11%)
[  4]  12.00-13.00  sec  7.49 MBytes  62.9 Mbits/sec  0.208 ms  1406/6784 (21%)
[  4]  13.00-14.00  sec  9.63 MBytes  80.8 Mbits/sec  0.255 ms  92/7010 (1.3%)
[  4]  14.00-15.00  sec  7.33 MBytes  61.5 Mbits/sec  0.206 ms  1411/6676 (21%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-15.00  sec   143 MBytes  80.0 Mbits/sec  0.200 ms  13296/103211 (13%)
[  4] Sent 103211 datagrams
CPU Utilization: local/receiver 12.1% (2.9%u/9.3%s), remote/sender 0.0% (0.0%u/0.0%s)
My issue will hopefully be sorted by next week, it's finally getting a move-on by Peter.
 
quovadis said:
The split is not an equal split - more of a share to a maximum combined throughput on the tx/rx depending on what's implemented. If both ISPs are displaying the same behaviour I would think it's safe to assume theres congestion at some stage between Frogfoot and the ISPs which is apparent at peak times. Since it's highly unlikely that the NAPafrica iperf is congested it supports this theory too.
Click to expand...

Hi, I understand that now. Thanks for pointing that out.

Nap looks like its still got lots of capacity. Granted I don't know what server this is.
Its just from their web site.
nap.png
 
Johnatan56 said:
Btw wrap your output in code tags please, makes it easier to scroll on the page and it keeps whitespace. Add >> filename.txt to save the output directly to a text file. Note to set it to 80% of line speed (for me 80Mbps of 100Mbps)
The reason I ask that you run the above is that it's a UDP test where you should be able to see the lost/total datagrams (proper packet loss figures)
Click to expand...

Thanks for the advice, will do.
 
lightpixel said:
Hi, I understand that now. Thanks for pointing that out.

Nap looks like its still got lots of capacity. Granted I don't know what server this is.
Its just from their web site.
View attachment 703007
Click to expand...

NAP is an open switching platform linking all the ISPs so they can exchange data freely, basically the only constraint is the port capacity that a specific ISP has moving traffic to and from the switch. The switch fabric at NAP Africa is in the Tbps and incredibly scalable. The exchange itself has no actual content of its own or servers delivering content.

under_sky said:
Dam JHB pushes alot compared to anyone else
Click to expand...

Most CDNs have chosen JHB as their home, Google and Netflix being two of the largest only available in JHB (and before an ISP corrects me, yes, I know some ISPs have caches in different regions). So the vast majority of your traffic comes from a server sitting on a network behind NAP Africa JHB.
 
r00igev@@r said:
The FNO needs to post more info of their setup. I assume they are using some CE kit? What is it and how is in configured? If the test they did on the last mile is accurate using RFC2544 then the fault domain is their data centre CE aggregation switch or the ISP cross connect. What flow control, queuing, policing and has been implemented?
With CE kit it is harsh, when a limit is hit it drops packets. Wham bam, no gentle burst allowed. All this can be visualized on the SNMP counters. The ISPs should have NDAs with the FNO and someone can go look at those counters.
Click to expand...

If only we could get access to this information... PCAPs tend to give us enough information to give the FNO grief and push for a resolution. But SNMP access is still far off.

My two cents here, and it's just two cents. While layer 2 is pretty simple at face value, there are a number of factors in build and design which (we've noticed) FNOs simply ignore. The general assumption is that given enough backhaul, the network will simply work. It doesn't.

For example, a successful 56 byte ICMP packet between A and B does not mean that an unfragmented 1500 byte packet will also be successful. Many FNOs (Big names included) will quickly respond to an ISP ticket with a small ping test and say that there is no packet loss). Carrying 1500 (or even larger) byte ISP VLANs within your infrastructure means that you have to correctly manage MTUs throughout - this is the most common error we see on networks. These issues don't present at off-peak periods because the aggregation switching hardware is easily capable of rebuilding fragmented packets and queueing packets inside their tiny memory buffers at low packet volumes. But peak traffic volumes (and the combination of increased packet volume, some of it tiny in size but plentiful, and throughput) (and the longer time it takes to wait for a high latency packet to rebuild) mean the average memory buffers on switches used are insufficient.
 
lightpixel said:
Hopefully they will.
A little bird told me that the FFoot end @ the Milpark node room is a Calix E720 which is apparently the best of the best in GPON. I know nothing about networking so that does not mean much to me.
Click to expand...

I bet Huawei will challenge that claim.

Been on 2 GPON networks so far since getting fibre. Openserve and Aeonova360. Both Huawei rollouts and both pretty damn good. Obviously I don't think it's a hardware thing but maybe Huawei just sets the network up correctly like Wesquad mentioned that it could be a miss configuration
 
websquadza said:
If only we could get access to this information... PCAPs tend to give us enough information to give the FNO grief and push for a resolution. But SNMP access is still far off.

My two cents here, and it's just two cents. While layer 2 is pretty simple at face value, there are a number of factors in build and design which (we've noticed) FNOs simply ignore. The general assumption is that given enough backhaul, the network will simply work. It doesn't.

For example, a successful 56 byte ICMP packet between A and B does not mean that an unfragmented 1500 byte packet will also be successful. Many FNOs (Big names included) will quickly respond to an ISP ticket with a small ping test and say that there is no packet loss). Carrying 1500 (or even larger) byte ISP VLANs within your infrastructure means that you have to correctly manage MTUs throughout - this is the most common error we see on networks. These issues don't present at off-peak periods because the aggregation switching hardware is easily capable of rebuilding fragmented packets and queueing packets inside their tiny memory buffers at low packet volumes. But peak traffic volumes (and the combination of increased packet volume, some of it tiny in size but plentiful, and throughput) (and the longer time it takes to wait for a high latency packet to rebuild) mean the average memory buffers on switches used are insufficient.
Click to expand...
If it was me I'd tell the FNO to shove the ping test where the sun don't shine. I'd ask for the SNMP visualization of at least the ethernet/media and rmon mibs. Heck most have proprietary ones with more info. The answer lies there.
Most of these guys don't have or use a system for visualization (and cacti does not come close!)
Secondly, if they blame the ISP invite their engineers over to your network and ask them to fix your network.
 
This is a very depressing thread. Webafrica swapped my account to something else yesterday which improved my throughput to about 6Mbps during the peak, but completely degraded my EU latency dropped the stability of it. Webafrica are apparently working/blaming Liquid Telecom for the international issues.

So now I have 6 out of a possible 100Mbps at the worst of times and a shitty ping all of the times, versus 1 out of a possible 100Mbps at the worst of times and a great ping 95% of the time... sighhh

Streaming at 1080p and a stable/consistent ping. I can't believe that is such a difficult service to deliver given :(

What exactly happened in Milnerton a month ago to cause this nightmare?
 
I "showed interest" in vumatel, suburb still require 585 "interests". Here's hoping competition helps us get to meaningful solutions faster.
 
FrogFoot is busy digging up our area again after Link Africa has just given us an amazing connection, and making an absolute mess. Link Africa was so tidy we hardly knew they were there.

According to the foreman there will be SEVENTY workers in the area today. Deep south, CT. My dad says he can see green shirts everywhere.

Our Link Africa line has gone down.

I am ready to go on a rampage.

FrogFoot, clearly you don't know what the **** you are doing.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X