I've been happily running Openwrt on my Netgear R7800 for the past year and a half. Over the course of this time, I've noticed that whenever I am live streaming to Twitch (~6000 kb/s upload) and start a big download (usually something over 1GB), my streaming bitrate takes a huge blow, and goes down to about 300 kb/s. It is so bad, I typically don't stream when performing these downloads, or am forced to postpone certain software updates that are encountered during stream.
I don't run any QoS software, but I imagine that would be a way towards a solution. I've never used such software. Do you think that would help me?
If anyone could point me in the right direction to solve this issue, I would greatly appreciate it.
P.S. If there is anything logs or anything I should provide from my running router, please let me know! Thanks
Mmmh, how fast is your internet access, and how assymmetric? I ask because TCP will always have packets traversing in both directions, as even for Downloads, the receiver needs to periodically signal the sender about the received data via so called ACKnowledge packets (short ACKs), this reverse traffic for an internet download then causes traffic/load in the upload direction. For TCP Reno the naive expectation is to see ~1/40 of the data traffic as reverse ACK traffic, so for a 1Gbps downlink, that will be 1000/40 = 25 Mbps (most modern systems use fewer ACKs, but even then normal ACK traffic still needs room in the reverse direction). And ACK traffic is not 'elastic' that is dropping ACKs at the bottleneck will not reduce the rate of incoming ACKs in any meaningful way, so typically more responsive traffic will give way...
I performed one of these tests after starting stream with nothing else happening on the network, generally speaking.
And, just as per my previous experiences, while running the test my stream bitrate dipped to the hundreds, and then fluctuates around the low thousands. Once the test was finishing, the bitrate sky rockets to several thousand over the specified bitrate (I assume to 'Catch up'), and eventually comes back to specified bitrate.
I am aware you might prefer further tests from me as specified. I will postpone these a day or two.
Your upload bandwidth is too low. I think you experience exactly what @moeller0 mentioned above. If you're downloading big files and updates that take up the most or whole of your 800Mbit download bandwidth the ACK traffic is using to much of your upload bandwidth.
I don't think QoS will be able to get you better results with this. Either continue to postpone updates and big file downloads while streaming or get a better upload bandwidth. I have never seen someone having a 15Mbit upload and a 800Mbit download. Your ISP is a joke for providing such a low upload bandwidth.
800/15 is not balanced you have way more down than up speed. That is what I meant with asymmetric.
Oh even better, you can go and reserve enough rate for your video streaming, at the cost of potentially somewhat reduced download rates.
The easiest way to get there would be to install SQM (on a ssh shell on the router: opkg update ; opkg install luci-app-sqm', then edit /etc/config/sqm either with your editor of choice (e.g. opkg uddate ; opkg install nano`) or via the luci GUI) to look like:
Then replace pppoe-wan with your treu wan interface, and start that new config: SQM_DEBUG=1 SQM_VERBOSITY_MAX=8 /etc/init.d/sqm restart
copy and paste the output from the terminal here into this thread
Please also post the output of tc -s qdisc ifstatus wan
This config will already implement per internal IP fairness, so if you only use two computers (one for streaming and for downloading each one should get 7000 Kbps for its own use which might already be enough*. If however you have more users internally we would need to play with DSCP marking for the streaming data, but let's first see whether that is required.
*) The calculation is simple each active computer will get its fair share of the capacity so with three fully active machines each can use 14000/3 = 4666.66666667 Kbps of gross upstream.