Hello
@llarsx,
couple of things I noticed whilst reading your post:
- you are good with numbers, but pay close attention to Mb/s, MB, kB and kb/s. A factor 8 in your calculations gives already a world of difference
- internet traffic is a "crazy" business: few protocols use "fire & forget" packet transmission, which means that for X-100 packets, there is always a (less offcourse) amount of Y packets which go retour (at least to stipulate if packets got trunkated, corrupted, need a resend etc). Multicast is for example one which is highly sender-friendly (eg comparable with TV broadcasting: the TV antenna is not making peer-to-peer connections with 1.000s of individual TVs, no, they are "broadcasting" (in TCPIP terminology: multicasting) all the packets for any willingly to listen and pick it up. Your TV will never send stuff back to "acknowledge" the reception. That's the reason why "internet tv"/"setop boxes" are so important (as data harvesting/mining) so now all statistics (are you watching BBC/NatGeo, when, for how long, etc etc) and at least being able to feed you annoying ads etc etc. But we're going off-topic, my point: having 2.7GB uploaded and 0.6GB download, is not that bad, as I suspect that due to the manipulations with your cam, and maybe not that good internet connections, some packets had to be "re-ordered".
- there is a difference between QOS (quality of service) and "bandwidth limiters". Let's give an example: image you have VoIP telephone system for your company. When someone calls you, you want to have a decent video and audio channel (so the other one can hear you crisp and clear). To have this, your VoIP system needs (for example) 4Mbps to work decently. Imagine your ISP provides you 10Mbps up and downlink. Once you open your connection, it might peak to 8Mbps because you twiggled around with resolution, so far so good. But one of your colleagues discovers the world of (illegal)
downloads, and starts downloading stuff. 10Mbps is easily filled. QOS does not interact yet. Until the phone rings: the 10Mbps download is squeezed until the "guaranteed limit" of the VoIP stream, so in theory, the 10Mbps goes down to 6Mbps, and the VoIP gets his "promised" 4Mbps. So back to your example: you first set it to 5Mbps, which is a lot. But when nothing else is "using" the internetz on the remote location, you'll never fill that up. Even with the 0.2Mbps, it will still go up to whatever the camera wants to send out. And to my opinion, the key to your success lies there: each cam has different "streams", for example, my main stream is (always) fullHD, which gets picked up by my NVR. But the substream is much lower resolution, lower bandwidth and less fps. When on-the-road, I instruct iDMSS/gDMSS to hook to the substreams (for obvious reason: my iPhone screen is useless with fullHD footage).
- after some research: asus does have (well hidden) in QoS the feature "bandwidth limit" - this is "new" since 2016 -> do you have Rmerlin running or a version higher than 2016? Source:
Bandwidth limiting? According to the FAQ: you have to ENABLE it first (some do reboot in this step) before adding the clients, otherwise it will not work. Source:
[Adaptive QoS]How to control transmission speed of client device via Bandwidth Limiter? | Official Support | ASUS Global but it remains "flawky"
- your QoS will definetly help if you have one cam which needs priority on another cam, so you can "guarantee" enough bandwidth for him.
Bottom-line:
- mess around with substream settings (eg use the pre-configured D1 setting)
Hope this helps!
CC