Hello,
I am new to openwrt. I use a Linksys wrt32x and would like to have separate Download and Upload (Switch). Could someone give me a link, where I can find some info or explain it to me. I haven´t found nothing about that. Thanks a lot.
Regards
are we talking DSA LACP? what is your OS version?
Thanks for the fast request. I didn´t know what you mean but I am using Openwrt. I am at the beginning, just have info of SQM and some basic.
understood... what i'm asking is if you know what OpenWrt version you have installed ( 19.x etc. )?...
it's likely important in getting you the right answers you need.
also... do you mean that you want one physical cable to carry traffic up, and another physical cable to carry traffic down? it is not very clear to us yet what you are asking...
if not what do you mean? if so, what is at the other end or intended purpose... explaining more about the reasons and setup will only help others to give you the information you need...
1 Like
Thanks again. I try to explain it.
We have just one possibility to get DSL connection. Our provider delivers 22MB Down ond 5,5MB UP. Everything looks stable. Netflix and Youtube vids runs good and there are no problems. But real time applications are terrible. It starts with phonecalls and ends with gaming. There ist a delay of some seconds. For example in Battlefield the enemies still shooting when they are dead or I am hitted behind coners. It ist even worse with Skype or Videophonecalls. This is the overview of the connection (DSL_Info_Fritzbox)
I am not sure what is responsible for this delay, but research over 3 years now and don´t finde any solution. I tried diffrent routers with diffrent chipsets, like
- Fritzbox 7360, 7490, 7480 and now 7590
- different Asus Router (saled)
- Netduma R1 (saled)
- Fritzbox bridged with Netgear XR 300
- Allnet Modem with Linksys WRT32x
- Fritzbox birdge with Linksys WRT32x
- Smart 2 Speedport Router
The problem seemed to be the asynchronic DSL connection in combination with the forward error correction which produces a lot of FEC Errors.
This shows the satus of the Speedport Router after 1 Minute in use. You can see that the correction mostly intervent on the Downloadside. It also happens on the Fritzboxes. In this case, the modem tries to correct the date and this course a delay. My guess.
My last option is Openwrt. So I bought the Linksys WRT32x. Installed Openwrt on it and tried SQM and DSCP mark. But it doesn´t work well. I research a lot but haven´t find any possible solution.
I know, that it will be not a fancy connection but I try to control this problem a bit. But like I said, it is just what I guess.
Here how the Allnet modem preform:
1 Like
Uncorrectable errors kill the speed. Correctable errors are corrected on the fly so data does not need to be retransmitted.
With no other users (modem to router to one PC) run multiple speed tests to see if you have consistent speed at the subscribed rate. If the line speed is not consistent or data drops out it will be hard to work around.
Some speedtest:
and Pingplotter:
there is some varianz in pingtimes. I get good control with the Netgear XR300 of the pingspikes, but it didn´t solve the problem with the delay.
This is the FEC count per Minute:
It is not always the same. It varries between 1000 and 20.000 FECs in Minute. I have read that it depend on the depth of the FEC correction and of the number of correctable Errors itself. So deaper FEC correction, with more Bytes to correct, than higher delay. The Modem can´t correct the amount of FEC and couse a delay. I have read some studies about forward error correction and realtime applications and this was, what I get in conclusion.
I tried some tests with netem and delayed the connection to see if it will worsen the delay and it of course does. My intention was to separate Up- and Download (not physicaly) to see who is cousing the problem. My guess is, that the download is far to asynchron to the upload and this couse a delay. But till now, I had any evidence to prove it.
This seems wrong, FEC expands to forward error correction, and that means that the modems send some redundant information that allows decoding of the correct symbol even with a few bit errors. As far as I can tell the the FEC decoding should not be optional but happen all the time, so this is not a reasonable cause of your issues.
Could you post the output of the following commands run on the openwrt router please:
cat /etc/config/sqm
tc -s qdisc
ifstatus wan
Please copy and paste the text from the terminal window and paste it here in the editor window, make sure to put lines containing just three backticks "```" before and after your pasted text to get fixed-font formatting (which makes terminal output much more readable).
That is not how DSL works. VDSL2 uses frequency domain division, that is there are different frequencies used concurrently for up and downstream.
Looking at the different stats you posted, it seems like your synchronization speeds differ quite a lot:
allnet: 18.693/6.191
FB7490: 22.441/5.499, 23.480/5.499
I really wonder what kind of rates and overhead you configured in sqm?
1 Like
Thanks a lot for your help. Yes, all the devices synchronize differently. Normaly the Allnet modem had the best sync due to the Broadcom chipset (DSLAM also Boradcom) but not on our connection.
I have tested different overheads and watched it up in Wireshark with my isp Modem router. I tried them from 24 to 56. I saw some recomedation here in the forum on PPPoE connections with 44 bytes. For me SQM course more delay, so I thought I have a mistake somewhere in my settings.
I am so sorry but the format with backticks didn´t worked in putty well. I am not used to ssh and tried it serveral times can´t get it in the format you wanted. So sorry for that. Here are the information.
login as: root
root@192.168.1.1's password:
BusyBox v1.30.1 () built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 19.07.3, r11063-85e04e9f46
-----------------------------------------------------
root@OpenWrt:~# cat /etc/config/sqm
config queue
option debug_logging '0'
option verbosity '5'
option linklayer_advanced '1'
option tcMTU '2047'
option tcTSIZE '128'
option linklayer_adaptation_mechanism 'cake'
option tcMPU '64'
option upload '0'
option linklayer 'ethernet'
option enabled '1'
option download '19000'
option interface 'pppoe-wan'
option qdisc 'cake'
option script 'piece_of_cake.qos'
option qdisc_advanced '0'
option overhead '44'
config queue
option debug_logging '0'
option verbosity '5'
option enabled '1'
option qdisc 'cake'
option script 'piece_of_cake.qos'
option linklayer 'ethernet'
option linklayer_advanced '1'
option tcMTU '2047'
option tcTSIZE '128'
option tcMPU '64'
option linklayer_adaptation_mechanism 'cake'
option interface 'eth0.1'
option download '4350'
option upload '0'
option qdisc_advanced '0'
option overhead '44'
root@OpenWrt:~# tc -s qdisc
qdisc noqueue 0: dev lo root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc mq 0: dev eth1 root
Sent 2056774 bytes 12171 pkt (dropped 0, overlimits 0 requeues 2)
backlog 0b 0p requeues 2
qdisc fq_codel 0: dev eth1 parent :8 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth1 parent :7 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth1 parent :6 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth1 parent :5 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth1 parent :4 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth1 parent :3 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth1 parent :2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth1 parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 2056774 bytes 12171 pkt (dropped 0, overlimits 0 requeues 2)
backlog 0b 0p requeues 2
maxpacket 1434 drop_overlimit 0 new_flow_count 1 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc mq 0: dev eth0 root
Sent 12131485 bytes 19340 pkt (dropped 0, overlimits 0 requeues 1)
backlog 0b 0p requeues 1
qdisc fq_codel 0: dev eth0 parent :8 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth0 parent :7 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth0 parent :6 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth0 parent :5 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth0 parent :4 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth0 parent :3 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth0 parent :2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth0 parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 12131485 bytes 19340 pkt (dropped 0, overlimits 0 requeues 1)
backlog 0b 0p requeues 1
maxpacket 325 drop_overlimit 0 new_flow_count 2 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc noqueue 0: dev br-lan root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: dev eth0.1 root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc ingress ffff: dev eth0.1 parent ffff:fff1 ----------------
Sent 3599556 bytes 21407 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: dev br-wan root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: dev eth1.7 root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc fq_codel 0: dev pppoe-wan root refcnt 2 limit 10240p flows 1024 quantum 1506 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 1644836 bytes 10062 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc ingress ffff: dev pppoe-wan parent ffff:fff1 ----------------
Sent 8611792 bytes 11419 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc cake 8005: dev ifb4eth0.1 root refcnt 2 bandwidth 4350Kbit besteffort triple-isolate nonat wash no-ack-filter split-gso rtt 100.0ms noatm overhead 44 mpu 64
Sent 3906293 bytes 21399 pkt (dropped 8, overlimits 7986 requeues 0)
backlog 0b 0p requeues 0
memory used: 124416b of 4Mb
capacity estimate: 4350Kbit
min/max network layer size: 46 / 1492
min/max overhead-adjusted size: 90 / 1536
average network hdr offset: 14
Tin 0
thresh 4350Kbit
target 5.0ms
interval 100.0ms
pk_delay 9.3ms
av_delay 1.9ms
sp_delay 4us
backlog 0b
pkts 21407
bytes 3916454
way_inds 1987
way_miss 725
way_cols 0
drops 8
marks 0
ack_drop 0
sp_flows 0
bk_flows 2
un_flows 0
max_len 13510
quantum 300
qdisc mq 0: dev wlan2 root
Sent 495381 bytes 4876 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc fq_codel 0: dev wlan2 parent :4 limit 10240p flows 1024 quantum 1614 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 3534 bytes 50 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev wlan2 parent :3 limit 10240p flows 1024 quantum 1614 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 73445 bytes 223 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev wlan2 parent :2 limit 10240p flows 1024 quantum 1614 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 418402 bytes 4603 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev wlan2 parent :1 limit 10240p flows 1024 quantum 1614 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc cake 8008: dev ifb4pppoe-wan root refcnt 2 bandwidth 19Mbit besteffort triple-isolate nonat wash no-ack-filter split-gso rtt 100.0ms noatm overhead 44 mpu 64
Sent 8583624 bytes 11400 pkt (dropped 19, overlimits 11659 requeues 0)
backlog 0b 0p requeues 0
memory used: 99200b of 4Mb
capacity estimate: 19Mbit
min/max network layer size: 40 / 1484
min/max overhead-adjusted size: 84 / 1528
average network hdr offset: 0
Tin 0
thresh 19Mbit
target 5.0ms
interval 100.0ms
pk_delay 2.0ms
av_delay 1.6ms
sp_delay 2us
backlog 0b
pkts 11419
bytes 8611792
way_inds 1263
way_miss 1028
way_cols 0
drops 19
marks 0
ack_drop 0
sp_flows 3
bk_flows 1
un_flows 0
max_len 1484
quantum 579
root@OpenWrt:~# ifstatus wan
{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 2635,
"l3_device": "pppoe-wan",
"proto": "pppoe",
"device": "br-wan",
"updated": [
"addresses",
"routes"
],
"metric": 0,
"dns_metric": 0,
"delegation": false,
"ipv4-address": [
{
"address": "92.201.98.77",
"mask": 32,
"ptpaddress": "213.148.133.233"
}
],
"ipv6-address": [
],
"ipv6-prefix": [
],
"ipv6-prefix-assignment": [
],
"route": [
{
"target": "0.0.0.0",
"mask": 0,
"nexthop": "213.148.133.233",
"source": "0.0.0.0/0"
}
],
"dns-server": [
"212.202.215.1",
"212.202.215.2"
],
"dns-search": [
],
"neighbors": [
],
"inactive": {
"ipv4-address": [
],
"ipv6-address": [
],
"route": [
],
"dns-server": [
],
"dns-search": [
],
"neighbors": [
]
},
"data": {
}
}
root@OpenWrt:~#
**I have tried a lot of combiantions which I found here in the forum but nothing helped with the delay. **
Ah, it seems my intended instructions turned out to be more of obstructions, sorry.
It is here in the forum edit field where if you put text between lines only containing three backticks "```" the whole text will be rendered in fixed font like:
this example text, that
wraps over mutiple lines...
(I manually inserted returns to force the line break)
So your work flow is almost perfect, run command in terminal window, copy and paste into the forum editor here. The only missing bonus feature is add lines with only three backticks before and after the pasted text 
I notice you split the up and downstream shaping into two independent shapers (pppoe-wan for ingress, and eth0.1 for upload) which given all other options are similar does not make too much sense, as you will be running two IFBs (each costing around 5% top performance, not your issue, but certainly sub-optimal).
I would propose you try the following /etc/config/sqm (keep a copy of your existing one):
config queue
option ingress_ecn 'ECN'
option egress_ecn 'NOECN'
option itarget 'auto'
option etarget 'auto'
option verbosity '5'
option qdisc 'cake'
option script 'piece_of_cake.qos'
option qdisc_advanced '1'
option squash_dscp '1'
option squash_ingress '1'
option qdisc_really_really_advanced '1'
option eqdisc_opts 'nat dual-srchost'
option linklayer 'ethernet'
option linklayer_advanced '1'
option tcMTU '2047'
option tcTSIZE '128'
option linklayer_adaptation_mechanism 'default'
option debug_logging '1'
option enabled '1'
option iqdisc_opts 'nat dual-dsthost ingress'
option interface 'pppoe-wan'
option download '19000'
option upload '4350'
option overhead '38'
option tcMPU '68'
This will add the following bells and whistles:
- it will only use one IFB saving some CPU cycles for other work
- "ingress" instructs the shaper that this side is an ingress post-bottleneck shaper and the shaper will try to shape the speed of its incoming side instead of the traditional control of outgoing speed (this makes ingress shaping more robust against multiple concurrent flows)
- "nat dual-xxxhost" these two incantations will enforce per internal IP fairness, which might not be what you need, but something good to test, because it should defang any potential rouge machine in your internal network that might contribute to the observed delays, in case you do not want that, simple leave out the "nat dual-dsthost" and "nat dual-srchost" parts (the "nat" keyword instructs cake to consult conntrack's database to get the internal IP addresses of incoming packets, which at that stage have not passed the NAT yet and hence all carry your router's external IP-v4 address).
- "overhead 38" which should be sufficient for a PPPoE link like yours (but 44 is also fine, the trick about per packet overhead is to rather overestimate it).
The delays reported from the cake instances:
and
indicate that what ever delay variations you see are not visible for cake...
But about ping RTTs at your upload of 4350 a single full sized packet will take:
((1500+38) [Bytes/Paket] *8 [Bits/Byte])/(4350000 [bps/sec])*1000 [ms/sec] = 2.82850574713 ms
So you can expect to see at least a ping variance of ~3ms unless your link is completely unused by any other application that your ping. (And under load I would expect cake's default acceptable 5ms per direction standing queues, resulting in a latency-under-load-increase for ping plotter of >= 10ms under saturating loads).
How does it look if you direct pingplotter to 1.1.1.1 for say 10 minutes?
(alternatively to ping plotter you can also use mtr on the router itself:
opkg update ; opkg install mtr to install mtr unless it is installed already and then from a ssh window mtr -ezb4w -c 300 1.1.1.1 this will run for 5 minutes before showing something, if you use just mtr -ezb4 1.1.1.1 you get an interactively updated display that will run forever or until you stop it by pressing q to quit it.
)
Hello,
when I try to enter the config I get this:
root@OpenWrt:/etc/config# /etc/config/sqm
-ash: /etc/config/sqm: Permission denied
root@OpenWrt:/etc/config#
Can someone explain how I manage this?
Mmh, so there are two options I can recommend:
- use the nano editor (
opkg update ; opkg install nano) to edit /etc/config/sqm (nano /etc/config/sqm) - use WinSCP which I have been told allows to directly edit files with its built-in editor.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.