I have raised an issue on the bug tracker, but, at the moment there is no one to look at it. There will be an update to app-qos soon but it will not cover this.

I got a tad busy for a while but I have not had a single problem since I commented out those rules in the qos.conf file.

I've even had luck now with multiple PCs downloading and not causing any issue with the Fire TV.

I eventually want to try possibly modifying those rules but haven't gotten a chance yet.

It’s a somewhat rare one but “N_m3u8dl-cli”.

It probably didn't like multiple flags. You could perhaps try "-p tcp --tcp-flags ACK --tcp-flags ! --syn". I guess I was trying to exclude the SYN-ACK.

I have no expertise in the QoS detailed set up. I can file a bug for you, but don't expect anything soon.

What is the downloader you are using, so I can add it to the bug report

Wow Nick! It looks like you hit the nail on the head basically as to what the issue is.

At first the Firewall didn't seem to like that exact format but online it said to try "-p tcp --tcp-flags SYN,ACK,FIN,RST ACK" but that still seemed to have the exact same issue.

Then out of curiosity I decided to comment out both the Up & Down ACKs just to see what happens.

All the sudden the PC doing the downloading seems to have properly moved to Priority 7 (Web)/Priority 6 in the command. Still tons of "dropped packets" but I guess like you said it's to have the server/sender slowdown.

The PC was downloading and the Fire TV Stick was watching content as expected without non-stop buffering.

All I can figure is the download maybe floods the ClearOS PC with so many 64-byte packets that it drove the QoS wild?

That command is for downloads only. Have a look in /etc/clearos/qos.conf for the rules. As far as I can see prio 1 (which equates to Priority 2 in the webconfig) is set up for downstream TCP ACK's only. Actually, technically it is set up for downstream packets up to 64 bits which includes ACK's. I am not sure why they used packet length as this may include other packets such as SYN and some SYN-ACK's and maybe others. If ACK only was intended you could try changing the "-p tcp -m length --length :64" to "-p tcp --tcp-flags ACK ! --syn" which would exclude SYN-ACK's, or try leaving off the "! --syn", but this is beyond my knowledge. Could it be that QoS is rejecting the packets to force the sender to slow down?

Well I finally think I found evidence of the exact issue, but now I just need to actually find a fix.

I found in another post to run:

tc -s -g class show dev ifb0

I noticed I got this response:

+---(1:1) htb rate 43038Kbit ceil 43038Kbit burst 1592b cburst 1592b

     |    Sent 1277932923 bytes 1508865 pkt (dropped 0, overlimits 0 requeues 0)

     |    backlog 0b 0p requeues 0

     |

     +---(1:11) htb prio 1 rate 6455Kbit ceil 43038Kbit burst 1598b cburst 1592b

     |          Sent 1211177832 bytes 1156062 pkt (dropped 19159, overlimits 0 requeues 0)

     |          backlog 0b 0p requeues 0

     |

     +---(1:10) htb prio 0 rate 6455Kbit ceil 43038Kbit burst 1598b cburst 1592b

     |          Sent 1902197 bytes 13603 pkt (dropped 0, overlimits 0 requeues 0)

     |          backlog 0b 0p requeues 0

     |

     +---(1:13) htb prio 3 rate 6025Kbit ceil 43038Kbit burst 1598b cburst 1592b

     |          Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

     |          backlog 0b 0p requeues 0

     |

     +---(1:12) htb prio 2 rate 6025Kbit ceil 43038Kbit burst 1598b cburst 1592b

     |          Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

     |          backlog 0b 0p requeues 0

     |

     +---(1:15) htb prio 5 rate 6025Kbit ceil 43038Kbit burst 1598b cburst 1592b

     |          Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

     |          backlog 0b 0p requeues 0

     |

     +---(1:14) htb prio 4 rate 6025Kbit ceil 43038Kbit burst 1598b cburst 1592b

     |          Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

     |          backlog 0b 0p requeues 0

     |

     +---(1:16) htb prio 6 rate 6025Kbit ceil 43038Kbit burst 1598b cburst 1592b

                Sent 64852894 bytes 339200 pkt (dropped 221, overlimits 0 requeues 0)

                backlog 0b 0p requeues 0

Every time the PC does it's download, the "-(1:11) htb prio 1" section, drops packets like crazy.

It seems that that helped to a degree but then still acts up somewhat.

I noticed it does seem like the downloader isn't using 6mbit+ when downloading with the rule, but more like 3-5mbit.

Not nice. Although it is in priority 7 by default, have you tried adding your PC to priority 7 explicitly.

Well I finally stumbled on what definitely appears to be what causes the problem, but finding the solution is what I need to find next.

It appears that it's something with the download program I am using on the PC, which is downloading a DASH Video over HTTPs. It downloads in fragments and then combines the video.

Anyway, when that downloader is running, the network acts weird.

I tried doing a 1GB wget test download at full speed, the network acts fine with or without QoS on.

It seems like for some reason, the downloading in fragments is what appears to be causing the network issue.

It does it with or without QoS on and it doesn't seem to matter even if you set QoS to an even lower Internet speed than 90% of your Max.

Well that was a fast fail!

It's definitely improving but if you start a downloading on the PC then go back to Fire TV and rewind the video, it will start buffering and skipping.

The video plays normal once you stop the PC from downloading.

I may have figured out the issue.

I think my ISP must have changed something with the config files of modems or something similar with their systems.

I turned QoS off entirely and did a bunch of speed tests. (To be safe I also verified all coaxial connections to verify nothing was loose).

For years now, my 50/6 would typically test about 52-53/6.5.

For some reason lately, I am lucky for the speed test to reach 51.5 now.

The ClearOS Speedtest came up with 47820 so I did 90% (43038) and 5742 for upload.

It actually appears to be working but I figure I better let time pass before I consider it actually solved.

That is OK. I was just checking for the RTL8111/8168/8411 NIC which works better with a driver not included in the kernel.

00:14.0 Bridge: NVIDIA Corporation MCP51 Ethernet Controller (rev a3)

        Subsystem: Hewlett-Packard Company Device 2a3e

00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration

00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] Address Map

--

03:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10)

        Subsystem: Netgear GA311

        Kernel driver in use: r8169

        Kernel modules: r8169

03:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10)

        Subsystem: Netgear GA311

        Kernel driver in use: r8169

        Kernel modules: r8169

I don't use the NVIDIA card at all, only the two GA311s.

Can you do an "lspck -k | grep Eth -A 3"?

So far I tested with giving the Fire TV (Wired) a priority of 3 in Downstream.

The weird part is, I checked with jnettop and while I have the download on the PC going, I am not maxing out my up or down.

I generally see 5.75mbit and 2mbit up bring used.

I luckily have a smaller ISP that I almost always get 100% paid for speed.

I also checked CPU and Disk usage just to make sure nothing was wrong there.

QoS, by default gives all devices the same priority. Have you set any rules within the app to prioritise devices such as the firestick, or to prioritise certain ports or IP's? Note you should set your interface speed slightly lower than what you can measure and certainly not higher. This makes it a bit tricky when the interface speed changes a bit.