QOSMON v2.3 Released to repo (ACC)

Report issues relating to bandwith monitoring, bandwidth quotas or QoS in this forum.

Moderator: Moderators

d3fz
Posts: 277
Joined: Sun Aug 28, 2016 7:34 pm

Re: QOSMON v2.3 Released to repo (ACC)

Post by d3fz »

ispyisail wrote: Will keep monitoring

Image
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!! 8-)
TP-Link Archer C7 v2 - Gargoyle 1.12.X
TP-Link WR842ND v2 - Gargoyle 1.10.X
TP-Link RE450 AC v2 - Stock FW 1.0.4
TP-Link WA850RE v1.2 - LEDE 17.01.1

Lantis
Moderator
Posts: 6735
Joined: Mon Jan 05, 2015 5:33 am
Location: Australia

Re: QOSMON v2.3 Released to repo (ACC)

Post 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
http://lantisproject.com/downloads/gargoyle_ispyisail.php for the latest releases
Please be respectful when posting. I do this in my free time on a volunteer basis.

pbix
Developer
Posts: 1373
Joined: Fri Aug 21, 2009 5:09 pm

Re: QOSMON v2.3 Released to repo (ACC)

Post 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.
Linksys WRT1900ACv2
Netgear WNDR3700v2
TP Link 1043ND v3
TP-Link TL-WDR3600 v1
Buffalo WZR-HP-G300NH2
WRT54G-TM

ispyisail
Moderator
Posts: 5180
Joined: Mon Apr 06, 2009 3:15 am
Location: New Zealand

Re: QOSMON v2.3 Released to repo (ACC)

Post 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

ispyisail
Moderator
Posts: 5180
Joined: Mon Apr 06, 2009 3:15 am
Location: New Zealand

Re: QOSMON v2.3 Released to repo (ACC)

Post 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?

d3fz
Posts: 277
Joined: Sun Aug 28, 2016 7:34 pm

Re: QOSMON v2.3 Released to repo (ACC)

Post 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?
TP-Link Archer C7 v2 - Gargoyle 1.12.X
TP-Link WR842ND v2 - Gargoyle 1.10.X
TP-Link RE450 AC v2 - Stock FW 1.0.4
TP-Link WA850RE v1.2 - LEDE 17.01.1

ispyisail
Moderator
Posts: 5180
Joined: Mon Apr 06, 2009 3:15 am
Location: New Zealand

Re: QOSMON v2.3 Released to repo (ACC)

Post 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)

mgoo
Posts: 22
Joined: Sun Jan 11, 2015 7:00 pm

Re: QOSMON v2.3 Released to repo (ACC)

Post 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

Volaris
Posts: 177
Joined: Thu May 01, 2014 1:02 pm

Re: QOSMON v2.3 Released to repo (ACC)

Post 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.
QoS Tip: Don't complicate your QoS settings. Gargoyle evenly splits available bandwidth between active devices as needed. Just delete all your classification rules and leave only one normal service class and you're done. No more arguing over bandwidth.

d3fz
Posts: 277
Joined: Sun Aug 28, 2016 7:34 pm

Re: QOSMON v2.3 Released to repo (ACC)

Post 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. :D

Image
TP-Link Archer C7 v2 - Gargoyle 1.12.X
TP-Link WR842ND v2 - Gargoyle 1.10.X
TP-Link RE450 AC v2 - Stock FW 1.0.4
TP-Link WA850RE v1.2 - LEDE 17.01.1

Post Reply