An advice from a former client of Netduma, dont by Netduma products.
I have a R1 and XR500, the XR500 now i have openwrt with nss custom build.
1 Like
Now i play mainly COD, with MT6000 custom build from pesa and use Qosify and its going great.
God and Bad days with COD servers, COD is COD.
They stay with the same servers CHOPPA and VULTR
1 Like
Thanks for the advice 
They seem to have good ideas I guess they don't always work out the way you would expect
The big problem is a buffer on your router is very close to one end of the path. So imagine for game packets sent by your client to the server, the router has to somehow estimate the delay being experienced on the remaining 90% of the path and then dynamically adjust its buffer to send your packets in such a way that they arrive fairly evenly spaced by the time they've traversed "the rest of the internet". That's a nearly impossible task. On the other hand, in the other direction, server to client, it can control the remaining small path very easily, but so can the client with a normal jitter buffer... there's not any clear advantage to adding an extra jitter buffer right before the client one since you'll just be outputting your packet directly into the client jitter buffer.
1 Like
Yes this makes sense. I think this is why game servers have packet buffers. Traveling from client to server, the client cannot account for the variables in the path like you stated. However, the server compensates for this variable packet rate by using a packet buffer to ensure the packets arrive in the correct order at the correct time when recieving packets from client.
Are you saying by default the client has a built in jitter buffer? I assumed client did not have a packet buffer by default. If there is a packet buffer built into client by default, then the benefit of having your own client packet buffer would be to handle a larger amount of packet rate flutuation.
or
If you are saying the packets sent from the client to the server would go into the server packet buffer therefore the client side packet buffer would have no benefit, this seems correct there would not be any benefit in this regard.
The benefit of a client side packet buffer would be to benefit the client in regard to receiving packets from the server at the rate at which they were intended. Similar to how the server has a packet buffer for the benefit of the server when receiving packets from client. The server packet buffer does not benefit the client and vice versa.
Well, there are too opposing constraints here: timeliness and proper spacing... for VoIP the data is replayed at a constant rate, so if delaying all packets up to say 10ms to even out the inter packet spacing that is a win, as this allows up to 10ms jitter without resulting in noticeable audible distortions/blips. But for an on-line game typically we only see small control packets that synchronize the game state in the client with the server, and in that direction arguably ASAP is the best option how to deliver this information to the game client. On the server this is different as in multiplayer games you really really do not want to make the game harder for more remote players...
The main benefit of a jitter buffer on the client would be to present to the user a fairly smooth representation of the world. So, for example, if there's a delay in getting state updates to the client, the client still has to show something to the user, and then when the update arrives it can discover what it showed wasn't right, and can "rubberband". So having a slightly longer delay but a smoother set of updates can be beneficial... It's up to the designers of the game to figure this stuff out, usually we shouldn't be fiddling with the delivery of packets trying to second-guess their code.
Yeah, if a game client wants to do that it should be well within its powers to simply do that, my gut feeling is though, that at this point in time you really want to roll-back speculative errors you might have made ASAP, so not sure delaying is worth it...
But I had wondered in the past whether one could not use NTP to introduce a notion of absolute time and best-effort synchrony into games (that is have all clocks reasonably synced and the use buffer on all sides to assure that information reaches all client and server world code form all users simultaneously, completely eradicating any advantage from RTT/OWDs to between client and server, not sure how feasible that is though, after all on-line games are not someones science project ,) )
Sorry for the delayed response... I’ve been busy the last few days. Are you possibly running a non-official version of OpenWrt? Whats the output of:
ubus call system board
Also, what happens or what output do you get when you manually run the auto setup via the terminal?
service qosmate auto_setup
{
"kernel": "5.15.162",
"hostname": "OpenWrt",
"system": "xRX200 rev 1.2",
"model": "BT Home Hub 5A",
"board_name": "bt,homehub-v5a",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "23.05.4",
"revision": "r24012-d8dd03c46f",
"target": "lantiq/xrx200",
"description": "OpenWrt 23.05.4 r24012-d8dd03c46f"
}
}
Do you want to run a speed test or enter speeds manually? [test/manual]
test/manual
This will run a speed test to configure qosmate. Do you want to continue? [y/N]
y
speedtest-go is not found. Checking for python3-speedtest-cli...
python3-speedtest-cli is already installed. Using it for the speed test.
Running speed test... This may take a few minutes.
Killed
Speed test results:
Download speed: Mbit/s
Upload speed: Mbit/s
QoS configuration:
DOWNRATE: 0 kbps (90% of measured download speed)
UPRATE: 0 kbps (90% of measured upload speed)
Configuration updated. New settings:
option WAN 'pppoa-wan'
option DOWNRATE '0'
option UPRATE '0'
Would you like to add a gaming device IP for prioritization? [y/N]
N
No gaming device IP added.
Auto-setup complete. qosmate has been configured with detected settings.
To apply these changes, please restart qosmate by running: /etc/init.d/qosmate restart
Unless you are on a very low rate link, I doubt the HH5A has reserves for running the speed test (actually better called capacity test) and doing its normal routing and firewalling duties, let alone DSL.
1 Like
As @moeller0 mentioned, your device is likely too weak to run a meaningful speed test. The function is really only intended as a starting point, and the results can vary or be inaccurate, as indicated by several warnings in the UI. Simply perform a speed test with QoSmate disabled, note your upload and download speeds and enter 90% of the mesured values into the UI before restarting the application.
However, I would still be interested to see what message you get when you run the speed test manually. Could you show me the output of the following command?
speedtest
Yh I have terrible speeds so no suprises but Qosmate has helped me.
The output:
root@OpenWrt:~# speedtest
Retrieving speedtest.net configuration...
Testing from Plusnet (31.185.141.183)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Mauritius Telecom Ltd (London) [262.28 km]: 31.984 ms
Testing download speed................................................................................
Download: 4.10 Mbit/s
Testing upload speedKilled
With QoS off, can you run a waveform bufferbloat test on a desktop or laptop and give us a link to the results page?
Sure, but its going to be a sore sight so beware 
https://www.waveform.com/tools/bufferbloat?test-id=106a43c6-883c-432e-be46-6e095f4b3332
1 Like
This is typical of something like an ADSL connection. Never fear, one of the primary targets of the original simple HFSC gamer script was to enable ADSL gaming!
You should start by setting your down and up rates to 4850 and 530, and the GAMEUP rate to probably 480.
QoSMate doesn't try to even out everything and it will not necessarily mean you get a better bufferbloat score. But after doing that it would be interesting to see how the score looks.
@hudra are the bits to adjust the MSS of TCP connections still a thing in your modified version? Because he should set a smaller MSS, something like 500 bytes.
Also with QoSMate running, try playing your game and see what happens.
Your link will always take something like 1500*8/500 =24 ms to send one 1500 byte MTU packet, so jitter can never go less than about that amount. But QoSmate should let you get close to that size jitter.
2 Likes
I concur with @dlakelan that smells like ADSL.
Try
to figure out the exact overhead and whether you have ATM/AAL5. At your access rates it tends to matter to get even the samll details right. But even then, your can really only manage the suffering (and avoid inflating it) as sqm/qos-mate will not magically offer more capacity...
I just checked, and it appears that MSS clamping was only implemented in your devel branch and there only in the iptables version of the SimpleHFSCgamerscript. Somehow, these changes never made it into your official branch or the nftables branch, which is why I didn't incorporate them and overlooked it. However, it shouldn't be too difficult to implement the logic and even make the MSS adjustable.
Something like this:
tcp flags syn,rst syn oifname "'"$WAN"'" tcp option mss set 500 counter;'
tcp flags syn,rst syn oifname "'"ifb-$WAN"'" tcp option mss set 500 counter;'
2 Likes
Yes adjustable is desirable, please note that there was a time when TCP RFCs assumed that for IPv4 the minimal MSS one had to expect on a path was 536, so there might be software out there that naively assumes that. Macos has a (configurable IIRC) limit for the minimal MSS it accepts around 216 bytes, and IIRC Linux also grew some minimal requirements as response to some resource exhaustion attacks using smallish MSS values... So I guess 536 likely is save, but pushing out down further can result in surprises...
Thank you, ill apply these changes right away and give it a try. Can you show me how to implement this mss clamping thing that Hudra responded with? I am a newbie, apologies.