Well, the overhead you configure should be a correct description of the applicable overhead on the rate-limiting hop, so typically this link will be the internet access link and those typically operate with the same overhead in both directions so yes, for all shapers that try to "model" that link the overhead most likely needs to be identical (please note that recent cake will take care of the variable part of the overhead that the kernel automatically adds, so you only need to specify the overhead on top of IP packets (or equivalent)).
Note that there can be situations like uplink and downlink running over different physical links where the overhead can be different, but I expect such situations to be really really rare...
Yes you have to tag packets based on network ip's (i read in a forum that MWO is using this network 70.42.29.0/24), check if the game ip's in this range.then you need something like this:
iptables -t mangle -A PREROUTING -p udp -d 70.42.29.0/24 -j DSCP
--set-dscp-class CS6
iptables -t mangle -A PREROUTING -p udp -s 70.42.29.0/24 -j DSCP
--set-dscp-class CS6
it's easy to setup, you just need some packages and a few command lines.
let me see how it will going. i think 50 overhead seems to much for this connection?!
but is it necessary to use overhead for eth0(lan side)?
Why? On the ethernet layer that really is the overhead on top of IP packets, no ifs and buts...
As I understand it you basically shape on LAN(egress) instead of WAN(ingress) so you can use iptables to set the dscps instead of having to use tc filter, so the link that you want to account for is still the link to the ISP, so sure you need to use the same overhead relevant on that link. Now, as I indicated above the true overhead is somewhere North of 50 Bytes, but all you need to account for is the overhead your ISPs uses to configure its down- and upstream shapers. If the ISP knows what they are doing AND tries to assure fair sharing under worst-case conditions their shaper will need to be set to >= 50 bytes of overhead. But that are two ifs that I am not wiling to vouch for. You could try to get in contact with your ISPs technical side and get the information about the shaper setting directly instead of trying to second-guess them (for what it is worth, I failed ot get this information from my ISP, but was lucky to find sufficient hints distributed along a number of technical documents to come up with a pretty good estimate).
1 Like
i'm using veth0 method to tag ingress packets on egress side of veth0. instead of using tc filter.
on eth0 it's only a shaper that will help queuing on lan side, or is it better to use lan-tripleisolate ?
hahaha, usually isp's tech support here is useless,only a dumb people, they don't know anything about even basic things!.so the only possible way is to try the estimations.
there's no good fair sharing, especially on download side, i'm still facing spikes on download side,but upload is very stable 0~12ms. i'm even tried to shap download to 700kbit,500kbit still the same.and this problem is in all isp's here.
what about RTT, how can i measure it?, i'm using android app called https://play.google.com/store/apps/details?id=at.alladin.rmbt.android&hl=en
i see that my RTT is between 150ms and 200ms.
Ah, yes that's what I meant; pretty clever, but a source port based filter should also work with tc...
A matter of taste, for many realistic situations triple-islolate and the correct combination of dual-srchost and dual-srchost should behave quite similar, the biggest advantage of the dual-modes is that they offer easier predictions in extreme speedtest situations. Personally I prefer that to tripl-isolate, but again a matter of taste.
Since triple-isolate works independent of traffic direction it will do the right thing on both ingress and egress, but at the cost of offering slightly different guarantees than the strict per-internal-IP isolation that can be achieved by combining the dual-modes correctly.
Not uncommon, that the first-level customer contact personnel is not too deeply involved in the technical underpinnings, yet sometimes one gets lucky and either finds a first level person with clue or can convince someone to escalte the request to a higher level with someone in the know. Then again, deducing from the outside is also a fun project...
This would be one of the consequences of configuring the shaper with too low an overhead...
People typically just use ping or ping6 to sent ICMP echo requests to the desired IP-addresses. Personally I like mtr better (which will give you min/max/averade RTT to all the hops between the endpoints over multiple measurements).
That means that you are located in the more rural part of the internet, but if that is the RTT than it is, nothing much you can do (except hoping for SpaceX's starlink, which should cut down RTT considerably, assuming there will be base-stations in your neck of the woods).
i see, how to combining the dual-modes correctly?
i see that lan-tripleisolate make my download more stable(less spikes).
is it ok?
config queue 'wan'
option ingress_ecn 'ECN'
option egress_ecn 'ECN'
option enabled '1'
option debug_logging '0'
option verbosity '5'
option qdisc 'cake'
option qdisc_advanced '1'
option qdisc_really_really_advanced '1'
option squash_dscp '0'
option squash_ingress '0'
option download '0'
option interface 'veth0'
option shaper_burst '1'
option script 'layer_cake.qos'
option iqdisc_opts 'diffserv4 nat dual-srchost rtt 200ms'
option eqdisc_opts 'diffserv4 nat dual-dsthost rtt 200ms'
option itarget '7.5ms'
option etarget '7.5ms'
option linklayer 'ethernet'
option linklayer_advanced '1'
option tcMTU '2047'
option tcTSIZE '128'
option tcMPU '64'
option linklayer_adaptation_mechanism 'default'
option upload '16000'
option overhead '38'
config queue
option debug_logging '0'
option verbosity '5'
option ingress_ecn 'ECN'
option tcMTU '2047'
option tcTSIZE '128'
option enabled '1'
option download '0'
option qdisc 'cake'
option qdisc_advanced '1'
option squash_dscp '0'
option squash_ingress '0'
option egress_ecn 'ECN'
option qdisc_really_really_advanced '1'
option linklayer 'ethernet'
option linklayer_advanced '1'
option tcMPU '64'
option linklayer_adaptation_mechanism 'cake'
option shaper_burst '1'
option script 'layer_cake.qos'
option interface 'pppoe-wan'
option itarget '7.5ms'
option etarget '7.5ms'
option iqdisc_opts 'diffserv4 nat dual-dsthost rtt 180ms'
option eqdisc_opts 'diffserv4 nat dual-srchost rtt 180ms'
option upload '7000'
option overhead '38'
config queue
option debug_logging '0'
option verbosity '5'
option qdisc 'cake'
option qdisc_advanced '1'
option ingress_ecn 'ECN'
option qdisc_really_really_advanced '1'
option enabled '1'
option squash_dscp '0'
option squash_ingress '0'
option egress_ecn 'ECN'
option shaper_burst '1'
option interface 'eth0'
option linklayer 'none'
option upload '16000'
option script 'test_LAN_triple-isolate__piece_of_cake.qos'
option iqdisc_opts 'nat dual-srchost autorate-ingress'
option eqdisc_opts 'nat dual-dsthost'
option download '16000'
So, I believe that cake automatically selects target based on the specified interval, only fq_codel/codel will interpret these values from the GUI.
On WAN eqdisc_opts "dual-dsthost" makes sure that bandwidth is evenly shared by the destination addresses, so per-external-IP-fairness, probably not what you want, I would set:
option iqdisc_opts 'diffserv4 nat dual-dsthost rtt 200ms'
option eqdisc_opts 'diffserv4 nat dual-srchost rtt 200ms'
On internally facing interfaces I would use:
option iqdisc_opts 'diffserv4 nat dual-srchost rtt 200ms'
option eqdisc_opts 'diffserv4 nat dual-dsthost rtt 200ms'
Now it seems that both wan and pppoe-wan face outward, and I assume that eth0 faces inward?
BTW, I would not use test_LAN_triple-isolate__piece_of_cake.qos, but rather piece_of-cake.qos and simply use the internally facing interface options from above, AND I would make sure to plug the internet-upload rate into the download field of the internally facing interface and vice versa for the internet-downloadrate...
The idea about the dual-XXXhost options is that you select either source or destination based on whether the current interfaces egress side points towards the internet (dual-srchost) or towards the internal LAN (dual-dsthost), for the ingress side (if you use an ingress shaper at all) use the opposite you selected for the egress side.
i just forget to remove when i was on fq_codel/simple.qos
if i understand correctly:
my wan is pppoe-wan so i should use:
option iqdisc_opts 'diffserv4 nat dual-dsthost rtt 200ms'
option eqdisc_opts 'diffserv4 nat dual-srchost rtt 200ms'
veth0 is responsible about wan ingress (lan) should be:
option iqdisc_opts 'diffserv4 nat dual-srchost rtt 200ms'
option eqdisc_opts 'diffserv4 nat dual-dsthost rtt 200ms'
eth0 is my lan side(Ethernet switch), it's not responsible about anything,i'm just use it to make lan stable, i think i should change it to wlan0?
so for eth0:
option iqdisc_opts 'diffserv4 nat dual-srchost rtt 200ms'
option eqdisc_opts 'diffserv4 nat dual-dsthost rtt 200ms'
should i use diffserv4 for eth0 with piece_of_cake.qos, i think this will introduce 4 tin's.
Mmmh, you should not use diffserv4 there, good catch,.
1 Like
Aahah,thanks!
BTW: every time i run dslreports speedtest i got this error(your firewall doesn't byte request range) ?
Thanks thats helpful! Yeah I see my UDP packets flow from my PC to external IP address 5.135.129.220. For anything other than actual matches the game uses TCP but im not really caring for those.
I'm gonna setup veth tonight, lets see what happens 
Hey!
you need the following:
opkg update
opkg install kmod-veth
the following script:
name it as /root/veth.sh
## set up a 2 pair of veth devices to handle inbound and outbound traffic
ip link show | grep veth0 || ip link add type veth
## get new veth interfaces up
ip link set veth0 up
ip link set veth1 up
## trun on promisc mode,sometimes it's needed to make bridge work
ip link set veth1 promisc on
## add veth1,veth3 to bridge
brctl addif br-lan veth1
## just to make sure there's nothing inside those 2 tables
ip rule del priority 100
ip route flush table 100
## flush mangle table
$IPT -t mangle -F PREROUTING
## add routing for veth0 this will handle all slow traffic
ip route add default dev veth0 table 100
ip rule add iif pppoe-wan table 100 priority 100
#Clear interface dscp marks, we don't trust ISP marks(also to use our own marks).
$IPT -t mangle -A PREROUTING -i pppoe-wan -j DSCP --set-dscp 0
Ok, I've setup something here.
My script
IPT="iptables"
## set up a 2 pair of veth devices to handle inbound and outbound traffic
ip link show | grep veth0 || ip link add type veth
## get new veth interfaces up
ip link set veth0 up
ip link set veth1 up
## trun on promisc mode,sometimes it's needed to make bridge work
ip link set veth1 promisc on
## add veth1,veth3 to bridge
brctl addif br-lan veth1
## just to make sure there's nothing inside those 2 tables
ip rule del priority 100
ip route flush table 100
## flush mangle table
$IPT -t mangle -F PREROUTING
## add routing for veth0 this will handle all slow traffic
ip route add default dev veth0 table 100
ip rule add iif eth1.2 table 100 priority 100
#Clear interface dscp marks, we don't trust ISP marks(also to use our own marks).
$IPT -t mangle -A PREROUTING -i eth1.2 -j DSCP --set-dscp 0
$IPT -t mangle -A PREROUTING -p udp -m iprange --src-range 5.135.129.0-5.135.129.255 -j DSCP --set-dscp-class EF
$IPT -t mangle -A PREROUTING -p udp -m iprange --src-range 198.27.85.0-198.27.85.255 -j DSCP --set-dscp-class EFI'm getting one 'error' RTNETLINK: File or directory not found
Once I done this script, I see activity on my Veth0 and 1 in ifconfig, both seem to be reversed? As in TX on one is reflected on RX on the other, and vice versa?
Furthermore, on my Windows PC, pinging keeps going but seems Firefox is intermittent, one time i can open a page next time i get 'not found'.
If i didnt know better it was a DNS issue.
Any ideas?
This might be where you delete a rule, if it doesn't exist it will say this, this is normal.
Not sure about intermittence. How is CPU idle percent during intermittence period?
Pretty much 0.0 0.0 0.0
99 to 100% Idle when it happens.
So the thing is, I changed the original script from ppoe-wan to eth1.2 because my WAN interface is static.
I'm using a 4G modem without bridge mode so the best I can do is use DMZ (Modem is 192.168.8.1) and DMZ's to 192.168.8.2 (Which is router)
And in Router I set WAN to Static (thus changes to eth1.2) and put WAN IP at 192.168.8.2 255.255.255.0 and gateway back to 192.168.8.1.
Works like a charm otherwise. Firewall and any other function is pretty much disabled on the modem itself so its almost identical to bridge mode other than being double NAT.
Could this be the culprit? Its definately DNS related as my Veth0 and 1 seem to be behaving as expected, data goes through and any opened socket/stream is uninterrupted.
Before I can start applying SQM to the Veth interfaces i definitely gotta try nailing down this issue. I pretty much reverted back to stock settings on OpenWRT when i retried, sadly same result.
If it really is DNS related perhaps you have starvation on DNS packets? Try giving them say CS3 dscp tag.
No I dont think so. The WAN line is literally unsaturated at this point. Less than 0.1%.
What do you use as your upstream DNS, Google? 1.1.1.1? Some ISP junk?
Always 1.1.1.1 and 8.8.8.8, even on Windows client forced on adapter.
Ill try some more stuff.