BT TV (Multicast IPTV) problems with Adaptive QoS

[brummygit]

I'm UK based and have my Internet and TV service from BT. The TV service offers a number of channels broadcast over the internet as (so I believe) multicast streams.

I've noticed for a long time that when I have Adaptive QoS enabled, the IPTV stream is registered by the Upload Bandwidth Monitor and this causes issues that QoS throttles this stream when I quickly run out of upstream bandwidth (I have around 13mbps and an HD stream is around 8mbps). I reported this to Asus who promised a long time ago that "it would be fixed in the next version".

Since upgrading to 382 and now 384 code releases I now notice that sometimes QoS doesn't register the multicast stream, and sometimes it still registers as as upload still. I initially thought some channels must be delivered differently, however I now realise that the same channel has produced both results.

I know that @HeadBanger has reported different issues with BT TV, and wonder if anyone cleverer than me can either work out how to reclassify the multicast traffic, or at least fathom out if anything can be done to minimise the problems. Unfortunately QoS is a deal breaker for me so I can't just turn it off.

 

[JDB]

Take a look at FreshJR’s QOS script. It helps a lot of this stuff.


Sent from my iPhone using Tapatalk

 

[brummygit]

Take a look at FreshJR’s QOS script. It helps a lot of this stuff.


Sent from my iPhone using Tapatalk

Thanks, however I'm already running it and sadly it doesn't influence the behaviour of the multicast traffic

 

[HeadBanger]

I’ve an RT-AC68U / 384 and have issues with BT’s IPTV via their YouView box.

I’ve used AiProtection since it’s launch without issue. The recent firmwares and AiP cause issues with IPTV. If I watch/record more than one IPTV channel CPU 1 maxes out, IPTV freezes and all LAN Internet traffic is throttled until I drop to one IPTV channel or less.

I don’t run any QoS but it is the same with it switched on or off. I have tried excluding the YouView box from DNS protection but it makes no difference. I have factory reset and tried Merlin’s versions - no difference. Merlin has confirmed that AiP by Trend Micro is closed source so he cannot look at the code.

I have fired off an email to both Trend Micro and ASUS and await their feedback and will post back if I hear from them.

I don’t want to have to switch off AiP as I have young daughters and their friends using my network all the time.

Any ideas/thoughts very welcome!

HB




Sent from my iPhone using Tapatalk

 

[brummygit]

I've not seen the issue with CPU maxing out. Is it all channels?

I assume you use the standard settings for IPTV?

 

[skeal]

I'm UK based and have my Internet and TV service from BT. The TV service offers a number of channels broadcast over the internet as (so I believe) multicast streams.

I've noticed for a long time that when I have Adaptive QoS enabled, the IPTV stream is registered by the Upload Bandwidth Monitor and this causes issues that QoS throttles this stream when I quickly run out of upstream bandwidth (I have around 13mbps and an HD stream is around 8mbps). I reported this to Asus who promised a long time ago that "it would be fixed in the next version".

Since upgrading to 382 and now 384 code releases I now notice that sometimes QoS doesn't register the multicast stream, and sometimes it still registers as as upload still. I initially thought some channels must be delivered differently, however I now realise that the same channel has produced both results.

I know that @HeadBanger has reported different issues with BT TV, and wonder if anyone cleverer than me can either work out how to reclassify the multicast traffic, or at least fathom out if anything can be done to minimise the problems. Unfortunately QoS is a deal breaker for me so I can't just turn it off.

I can't address how QOS classifies traffic but if you manually set your bandwidth to both up and down being the same value as your download speed it could help. A common mistake is to fill in actual speed test results and find that a lot of heavy traffic is classified as upload. Increasing the ceiling should help.

 

[HeadBanger]

Yes, same IPTV settings. It will just about cope with one HD and one SD channel but with two CPU 1 maxes out. Even with one HD channel it runs around 75%.

1 HD IPTV

2 HD IPTV

2 HD IPTV with AiP off

Do you have AiP switched on?

HB


Sent from my iPhone using Tapatalk

 

[brummygit]

I can't address how QOS classifies traffic but if you manually set your bandwidth to both up and down being the same value as your download speed it could help. A common mistake is to fill in actual speed test results and find that a lot of heavy traffic is classified as upload. Increasing the ceiling should help.

I'm not convinced about this. Unless I correctly tune my upload bandwidth setting to real values the QoS engine doesn't know what is available and when to throttle back lower priority traffic classes. This is seen in reality if I over-state it. Download isn't as susceptible but is still impacted.

If the traffic classification is working correctly no download traffic would be marked as upload, although I would agree that heavy download generates more upload traffic particularly in the Net Control class.

 

[brummygit]

Do you have AiP switched on?

Yes and adaptive QoS. With 2 HD streams running (1 recording, 1 viewing) I get the following. The step is when I added the second stream

 

[HeadBanger]

And with AiP off does it drop right down?

HB


Sent from my iPhone using Tapatalk

 

[brummygit]

Can't check that until tomorrow now, but I will

 

[Vexira]

Have you set your per packet overhead for your connection type?
Also have you done a factory reset?

 

[HeadBanger]

Trend Micro came back just to say take it up with ASUS. At least they responded!

HB


Sent from my iPhone using Tapatalk

 

[HeadBanger]

@Wilson_Deng
Hi Wilson. Is this something you can help troubleshoot please?

HB


Sent from my iPhone using Tapatalk

 

[brummygit]

And with AiP off does it drop right down?

HB


Sent from my iPhone using Tapatalk

With 1 HD stream recording and 1 HD stream playing I'm seeing high utilisation on CPU 1 but not 100% flat line. If I knock off both AiP and QoS (which also uses the Trend engine) I see very low CPU usage. Just running AiP gives the following busy but not maxed out result

 

[FreshJR]

I think i might know what's going on. (But I am not an IT person or network engineer so this is just a wild guess)

Take a look at netstat -anr

If says that if any destination IP leaving your router matches your current WAN address, it will be routed through the eth0 interface.

It then says if any destination IP matches your LAN address range, it will be routed through br0 interface.

The issue here with multicast streams and these rules is that their destination IP is 224.0.0.0 through 239.255.255.255 (not your actual device like regular internet traffic)

With that different approach to the destination IP it does not match either of two the interface routing rules mentioned before.

I also believe that the rules are executed from top to bottom. With that said I believe the last rule listed as 0.0.0.0 with a gen mask 0.0.0.0 is a catch all for all IP's not matched by all of the multiple beginning rules. Aka it takes all IP's not yet caught (0.0.0.0 - 255.255.255.255) and chooses route them through the eth0 interface.

As you know that is the defined upload interface for the QOS engine when the traffic finally has to pass through there.

If my thinking is correct, I wounder if we can change the last routing rule to default to br0 (makes more sense QOS purposes), or if we could include the multicast IP range and send only that through br0.

Note this is not my field and I am clueless as to the feasibility my statements. Maybe it has to be eth0 for some technical reason or another.

What I do know is you can create a QOS rule so that multicast traffic will not be throttled against your QOS upload limit at all. (While it is impossible to have it properly count as your download QOS limit since it's on the eth0 interface the best we can do is 0 rate it and pretend it doesn't exist.)


Maybe someone will chime and see if they could fix what interface the kernel is routine through to allow QOS to properly pick it up.

Good luck.

 

[HeadBanger]

I tried the new ASUS 3.0.0.4.384.20287 firmware today - same. With AiP off it’s fine and with AiP on it has the same very high CPU usage and eventual traffic failure.

I’ve not heard anything back from ASUS [emoji20]

HB


Sent from my iPhone using Tapatalk

 

[brummygit]

I think i might know what's going on..............

..............What I do know is you can create a QOS rule so that multicast traffic will not be throttled against your QOS upload limit at all. (While it is impossible to have it properly count as your download QOS limit since it's on the eth0 interface the best we can do is 0 rate it and pretend it doesn't exist.)

Maybe someone will chime and see if they could fix what interface the kernel is routine through to allow QOS to properly pick it up.

Thanks, your explanation makes perfect sense. I tried adding routes through the GUI to point the traffic towards the LAN interface but haven't got anywhere.

I wonder if you can help me develop the configuration in your script (I'm running the old one not the Beta) to just ignore all multicast traffic? QoS on my download is less necessary compared to upload, so I don't mind missing that traffic out if I'm getting my upload bandwidth back. Worst case is I adjust my download bandwidth in the QoS configuration to always give myself enough headroom for my IPTV streams.

 

[brummygit]

Thanks again @FreshJR, I should have added that if you can help me take my IP TV traffic outside of QoS, I'd also be happy to move to your beta script if that's easier or more sustainable moving forwards.

 

[Vexira]

@Wilson_Deng
Hi Wilson. Is this something you can help troubleshoot please?

HB


Sent from my iPhone using Tapatalk

You need to private message him.