Sign up with GoogleJip, more than happy, I'll be using ADSL for my normal network, this test is important to me.
-
Ask a question and get free supportUnlock new privileges and see hidden discussionsWin prizes and earn reputation
-
Question of the day ~ How often do you braai?
-
Afristay giveaway.Win a 2-night stay for two people at an establishment of your choice with R1,000 in spending money. Enter here.
Charting Fibre speed over time.
- Thread starter jacof
- Start date
Jip, more than happy, I'll be using ADSL for my normal network, this test is important to me.
- Joined
- Jan 11, 2016
- Messages
- 13,304
No picture formed as yet, if these issues were across the network of thousands of users it wouldn't be usable. Octotel has had known issues the past few days.
This is our smokeping graph for the past 10 days, which is from the same hosted environment in JHB where our Speedtest server is hosted to the edge where Octotel and Frogfoot meet.
Last edited:
So here's my test results for the past 7 hours:
http://imgur.com/a/3gAoR
Looks like ping is all over the place, but speed is looking fairly good, save for one dip which looks like my phone was downloading updates at the time.
I'm wondering if the speedtest-cli ping isn't too reliable - see my results when pinging the CI randburg speedtest server:
Ping statistics for 154.0.13.125:
Packets: Sent = 81, Received = 81, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 22ms, Maximum = 103ms, Average = 32ms
It spiked up to >100ms once or twice, but the average is still 32.
Don't know what to make of that.
I'll keep the test running and see how it goes through the day.
http://imgur.com/a/3gAoR
Looks like ping is all over the place, but speed is looking fairly good, save for one dip which looks like my phone was downloading updates at the time.
I'm wondering if the speedtest-cli ping isn't too reliable - see my results when pinging the CI randburg speedtest server:
Ping statistics for 154.0.13.125:
Packets: Sent = 81, Received = 81, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 22ms, Maximum = 103ms, Average = 32ms
It spiked up to >100ms once or twice, but the average is still 32.
Don't know what to make of that.
I'll keep the test running and see how it goes through the day.
- Joined
- Jan 11, 2016
- Messages
- 13,304
Yeah that ping graph cant be accurate, if your average via a regular ping was 32ms but the graph says your lowest ping was 60ms? There is a fault on gfmalans link with huge packet loss. Chatting to Octotel about the line.
I agree that the ping may not be correct, traceroute does show me similar times but it could be wrong. I know the download is correct as I can compare the speed I see on the router (the mikrotik pppoe wan port) with the test results I get.
Last edited:
- Joined
- Jan 11, 2016
- Messages
- 13,304
Yeah which is the IPC handoff, but either way to the destination the latency is fine.
You are picking up 10ms of latency at your routers hop with the linux machine which is arb.
The Ookla speedtest ping does not work the same way as the normal ICMP ping. It uses HTTP.
https://support.ookla.com/hc/en-us/...it-is-when-I-run-it-from-command-prompt-ICMP-
https://support.ookla.com/hc/en-us/...it-is-when-I-run-it-from-command-prompt-ICMP-
Last edited:
- Joined
- Jan 11, 2016
- Messages
- 13,304
Yes but even still the graphing doesn't even correlate to the latency seen in a test via a browser.
I have now seen that if I run the speedtest in the browser and then the command line after that then the ping will be fast. If I leave it for the 10 min the ping is slow again. I will see if I can find something why it is doing that. It may be a bug in the code, not saying it is, I will ask on Git what can be the issue. I will see if I can find something. But ping is not our problem, it is the downloads that dip.
Latest graphs:
http://imgur.com/a/z9TqA
Seems like I get some drops as well, but it's not too bad, here and there.
I've set up a smokeping docker container to track the latency to the CI Randburg Speedtest server, so I'll let that gather up some data as well, since the speedtest-cli latency results simply aren't accurate.
I'm going away for the weekend, but I'll leave both running so we can get some results over a longer period - I'll post my results on Sunday when I'm back.
Edit: Before I forget - I still have one of those old Mikrotik hapLITE models that only have 100mbps ports, so it's understandable I don't get the full 100mbps. I haven't been arsed to upgrade yet as the difference will be minimal.
http://imgur.com/a/z9TqA
Seems like I get some drops as well, but it's not too bad, here and there.
I've set up a smokeping docker container to track the latency to the CI Randburg Speedtest server, so I'll let that gather up some data as well, since the speedtest-cli latency results simply aren't accurate.
I'm going away for the weekend, but I'll leave both running so we can get some results over a longer period - I'll post my results on Sunday when I'm back.
Edit: Before I forget - I still have one of those old Mikrotik hapLITE models that only have 100mbps ports, so it's understandable I don't get the full 100mbps. I haven't been arsed to upgrade yet as the difference will be minimal.
OK we can ignore the speedtest-cli ping.
"Inconsistency
It is not a goal of this application to be a reliable latency reporting tool.
Latency reported by this tool should not be relied on as a value indicative of ICMP style latency. It is a relative value used for determining the lowest latency server for performing the actual speed test against."
We are testing against a selected server so the ping value is then not used in our case.
"Inconsistency
It is not a goal of this application to be a reliable latency reporting tool.
Latency reported by this tool should not be relied on as a value indicative of ICMP style latency. It is a relative value used for determining the lowest latency server for performing the actual speed test against."
We are testing against a selected server so the ping value is then not used in our case.
Last edited:
- Joined
- Jan 11, 2016
- Messages
- 13,304
It would be interesting to throw in someone using Active Ethernet, because OS, Octotel and Frogfoot are all PON.
- Joined
- Jan 11, 2016
- Messages
- 13,304
The spikes aren't there on the core network, so no.Here are the ping charts so far, should those spikes be there ?
Remember the network monitor does 5 pings and uses the best ones.
Ping
Http Ping
Global Ping
Paul not sure what you did but the network seems a lot more stable from yesterday around 4pm. I have not seen any big dips in speed on my end and the other test site is also stable at this stage. We will still monitor for the rest of the weekend.
When you say the spikes should not be there then what is causing it. Before you say it is OS, we see the same spikes from the other sites around the world pointing to that server via the global cloud ping. They are not all on the OS network. The only thing in common is your network.
When you say the spikes should not be there then what is causing it. Before you say it is OS, we see the same spikes from the other sites around the world pointing to that server via the global cloud ping. They are not all on the OS network. The only thing in common is your network.
