Page 3 of 4
Re: QOSMON v2.3 Released to repo (ACC)
Posted: Sat Dec 30, 2017 7:27 pm
by d3fz
ispyisail wrote:
Will keep monitoring
How's testing so far, ispyisail? Did you try a different ping target? Got better results?
One thing I just noticed though, by default your ping target is pointing to your LAN side, i.e. 192.168.88.1. The same happened to me with default settings.
Is this the case when running a double NAT? Because unfortunately, I am. Can't put my ISP router/modem into Bridge Mode without breaking HPNA/TV.
And a question to the Devs, does running a double NAT affects WAN speed throughput? Even if slightly? I tend to believe so after running a couple download tests with ISP router in Bridge Mode. Got slightly higher download speeds (maybe +3mbps?).
Is there any explanation for that?
Happy New Year to all!!
Re: QOSMON v2.3 Released to repo (ACC)
Posted: Sat Dec 30, 2017 8:18 pm
by Lantis
Yes this happens where you have double NAT.
The problem with using that as the target is that you will very rarely get congestion between your modem and router, so it isn’t an accurate target to use.
I expect there is overhead yes.
@pbix,
Without digging into the code, does the custom ping target handle URLs rather than IP addresses?
This would allow us to use a DDNS address representing the gateway. Just a thought. We can do the same thing with Openvpn gateway
Re: QOSMON v2.3 Released to repo (ACC)
Posted: Sun Dec 31, 2017 10:06 am
by pbix
Without digging into the code, does the custom ping target handle URLs rather than IP addresses?
qosmom requires an IP address and I pretty sure the web interface also does. Also, I am not aware of a DDNS address that references my ISP's gateway that could be used. Presently there is no good way to determine a target which is optimum in all cases. Users should inspect the target they are using to make sure it is appropriate. A target like 192.168.x.x is not going to work. An idea would be for qosmon to run a tracert and find the congested segment itself but that seems very complex to me and more that I am willing to sign up for.
Re: QOSMON v2.3 Released to repo (ACC)
Posted: Sun Dec 31, 2017 2:32 pm
by ispyisail
Code: Select all
C:\Users\user>tracert 8.8.8.8
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:
1 1 ms <1 ms <1 ms Gargoyle.lan [192.168.10.1]
2 1 ms 1 ms 1 ms 192.168.88.1
3 18 ms 7 ms 13 ms 180.222.67.75
4 7 ms 4 ms 7 ms pe-10g.uber.co.nz [180.222.67.66]
5 34 ms 35 ms 32 ms as15169.sydney.megaport.com [103.26.68.56]
6 33 ms 33 ms 36 ms 108.170.247.49
7 34 ms 35 ms 34 ms 209.85.244.15
8 31 ms 31 ms 34 ms google-public-dns-a.google.com [8.8.8.8]
Trace complete.
In my case 180.222.67.75 is the ideal target?
Code: Select all
C:\Users\user>ping 180.222.67.75
Pinging 180.222.67.75 with 32 bytes of data:
Reply from 180.222.67.75: bytes=32 time=10ms TTL=62
Reply from 180.222.67.75: bytes=32 time=2ms TTL=62
Reply from 180.222.67.75: bytes=32 time=3ms TTL=62
Reply from 180.222.67.75: bytes=32 time=13ms TTL=62
Ping statistics for 180.222.67.75:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 13ms, Average = 7ms
Re: QOSMON v2.3 Released to repo (ACC)
Posted: Sun Dec 31, 2017 2:34 pm
by ispyisail
A target like 192.168.x.x is not going to work.
Can we change the default to something like 8.8.8.8?
Re: QOSMON v2.3 Released to repo (ACC)
Posted: Sun Dec 31, 2017 3:09 pm
by d3fz
ispyisail wrote:A target like 192.168.x.x is not going to work.
Can we change the default to something like 8.8.8.8?
That would probably make ACC work correctly right out-of-the-box, especially in those cases where the user is behind a Double NAT (common scenario?), as discussed here.
Thoughts?
Re: QOSMON v2.3 Released to repo (ACC)
Posted: Sun Dec 31, 2017 5:30 pm
by ispyisail
How's testing so far, ispyisail? Did you try a different ping target? Got better results?
Using 8.8.8.8 and haven't noticed anything. Just works.
That is a good sign
When using the default it was rubbish? (had to turn QOS off)
Re: QOSMON v2.3 Released to repo (ACC)
Posted: Mon Jan 01, 2018 7:41 pm
by mgoo
> Thoughts?
the default should at least be first hop/gateway on the isp side (not ideal, as I have found out, and surely problematic to auto-detect), or the gargoyle ACC user should be more/better informed about ACC setup, gateways possibly down-prioritizing icmp responses, and the double NAT issue.
another thought is how many ACC enabled routers are/will be deployed? surely icmp ping is very low on server resources, but would the proposed default be ok, seen from the perspective of 8.8.8.8 ?
-mgoo
Re: QOSMON v2.3 Released to repo (ACC)
Posted: Sat Feb 17, 2018 12:27 pm
by Volaris
Just wanted to add my 2 cents.
Been using the 1/22 beta and ACC is significantly much more stable compared to 1.10. Fair link limit doesn't drop much compared to before.
As for using alternative ping targets; I've always had to do this because my ISPs IP address (default IP) sometimes seems to be exempt from bandwidth/congestion because sometimes it keeps pings low even when the connection is clearly congested. Because of that I just set it to a DNS server like OpenDNS.
Re: QOSMON v2.3 Released to repo (ACC)
Posted: Sat Feb 17, 2018 10:53 pm
by d3fz
Volaris wrote:As for using alternative ping targets; I've always had to do this because my ISPs IP address (default IP) sometimes seems to be exempt from bandwidth/congestion because sometimes it keeps pings low even when the connection is clearly congested. Because of that I just set it to a DNS server like OpenDNS.
The exact same case here:
d3fz wrote:mgoo wrote:currently it seems ping responses from my isp gateway fluctuates noticably more, than the ping responses from my preferred dns server. I have located a public ntp server within my isp network, and I see the same relatively low variation in response.
Exactly. Even though the average ping responses from the gateway were way lower (<20ms) if compared to other alternatives (e.g. Google DNS, >60ms), I've noticed that under heavy congestion/load conditions, the ping responses from my gateway showed values somewhat "unrealistic"? Like it wasn't being the best "reference" to indicate/detect whether my line was fully congested or not. I don't know if I'm making myself clear, but I hope you get the idea.
It's also important to notice that this is
my case, so it might not apply to everyone.
I've took this screenshot just now, as I was hammering my connection to the limits by torrenting and streaming Spotify. You can also notice ACC being awesome and keeping my average ping low, as usual.
