dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
1330
share rss forum feed

bjcsoln

join:2013-08-03

Using RT-N65U with Actionnet - TV pixelating

Well, I am getting closer. Managed to get a v.48 Actiontecv1000H into bridge mode, and then hooked up an ASUS N65U which I used as the primary router.

STB still connected to Actiontec.

Internet and TV worked fine for about 10 minutes, then the TV started getting really pixelated / choppy to the point of unwatchable.

I read that if you are hooking up your STB to the second router (via network cable) you need to enable IGMPproxy, but do you need to do that if it is connected the the first router (Actiontec)?

Is there something else I need to configure?

B.



nss_tech

join:2007-07-29
Edmonton AB

Besides not being supported or recommended, there is a chance you messed up when configuring the Actiontec. If your TV was working fine before the change, it's likely something with the gateway that went wrong when bridging it.

Does your router pull a 192.* IP address from the Actiontec or does it have an external IP?
Is your STB using ethernet or coax?
Have you actually called tech support before posting here?


bjcsoln

join:2013-08-03

Well, I am not sure if this approach is not "recommended", or at least not recommended by TELUS (although I am not sure if there is any technical merit to them not wanting people do to it), but all of that aside:

1) I will check to see what the second router's IP was - I believe it's supposed to get an IP directly from TELUS
2) STB is running coax from the Actiontec - Another posing mentioned that this was still an option (basically leave it connected with the default settings and just run the rest of the network off of the second router)
3) I did not call TELUS tech support (yet) as this is an unsupported configuration (for TELUS) and as many people can attest, TELUS tech support probably would not be able to support this

I should also clarify when I mentioned that my TV worked fine, then went all pixelated, it was working fine in the new configuration, then after 10 minutes or so it got really bad with the pixelation.

I guess I will do some more research, compare the configurations (as best as possible) between the two routers, and also try running my STB off of the second router (through ethernet) as it has a configuration setting for IPTV.

B


twixt

join:2004-06-27
North Vancouver, BC
reply to bjcsoln

said by bjcsoln:

Well, I am getting closer. Managed to get a v.48 Actiontecv1000H into bridge mode, and then hooked up an ASUS N65U which I used as the primary router.

STB still connected to Actiontec.

Internet and TV worked fine for about 10 minutes, then the TV started getting really pixelated / choppy to the point of unwatchable.

I read that if you are hooking up your STB to the second router (via network cable) you need to enable IGMPproxy, but do you need to do that if it is connected the the first router (Actiontec)?

Is there something else I need to configure?

B.

-

There is a known configuration change required to Asus Routers to have them peacefully coexist with Telus TV when using a Router in Bridge Mode.

See the following: »[BC] Turning on Telus TV kills Airport Extreme WiFi (bridge mode

Turning on IGMP Snooping should prevent the Multicast traffic from being routed where it's not supposed to go. This should prevent "Multicast Chaos" - which makes life difficult for both the Router and the STBs.

-

If the above is not the "magic bullet" - you'll need a Third-Party firmware for your Router which properly handles IPTV. This will ensure your STBs get the packets they are supposed to receive - without creating so much overhead on the rest of the network that your STBs are "starved" by latency.

An example: »Re: asus rt-n65u bridge help

Note: As far as I am aware - the defaults are adequate to resolve the situation. You'll have to google the forums for third-party Asus firmware for info on how to customize this page more fully if required.

-

Hope this helps.

bjcsoln

join:2013-08-03

Twixt,

I have been running my RT65 (connected to bridged Actiontec running v.48) for about a week now with no problems. Optic TV is still connected to the Actiontec.

After the first experience of doing this, and then the tv going extreme pixelated after about 10 minutes, I took some of nss_tech's notes above and did the following:
1) set the RT65 to a different IP (10.0.0.1) so it was out of the Actionent range (of 192?.x.x.x) - I forgot to do this the first time
2) Under WAN/IPTV (I think this was the setting) enabled IGMP Multicast (or I need to go back and confirm the setting)

To be honest, I am not sure what piece fixed the TV problem - I thought you only needed to mess with the IPTV settings (on the second router) is you had your STB hooked up to it, as opposed to my config where it is still hooked up to Actionnet.

So all in all this looks like this is a success. Running ping/bandwidth tests I am getting much better performance (I suspect as part of the 5Ghz WiFi) through the new router, now its time to do more reading to understand more of what I can do with this new configuration.

Thanks for the support/comments!
B



jtl999
CEO of Actiontec Dev Team

join:2012-11-24
In the GVRD
kudos:4

I believe its the IGMP being the solution


twixt

join:2004-06-27
North Vancouver, BC
reply to bjcsoln

said by bjcsoln:

Twixt,

I have been running my RT65 (connected to bridged Actiontec running v.48) for about a week now with no problems. Optic TV is still connected to the Actiontec.

After the first experience of doing this, and then the tv going extreme pixelated after about 10 minutes, I took some of nss_tech's notes above and did the following:
1) set the RT65 to a different IP (10.0.0.1) so it was out of the Actionent range (of 192?.x.x.x) - I forgot to do this the first time
2) Under WAN/IPTV (I think this was the setting) enabled IGMP Multicast (or I need to go back and confirm the setting)

To be honest, I am not sure what piece fixed the TV problem - I thought you only needed to mess with the IPTV settings (on the second router) is you had your STB hooked up to it, as opposed to my config where it is still hooked up to Actionnet.

So all in all this looks like this is a success. Running ping/bandwidth tests I am getting much better performance (I suspect as part of the 5Ghz WiFi) through the new router, now its time to do more reading to understand more of what I can do with this new configuration.

Thanks for the support/comments!
B

-

If you look at the Wikipedia entry for IGMP Snooping, it will tell you why this is necessary for IPTV.

What I think was happening to you before - was that you were forwarding the multicast packets from the Actiontec to the Asus - where they were duly broadcast to all the network ports on all the machines on your LAN (which is what multicast is all about).

This means the link between your Actiontec and the Asus was carrying *all* the multicast traffic for your IPTV - even though there was absolutely nothing connected to the Asus which was actually going to process those packets.

-

This meant several things:

1. The transmit/receive buffers for the LAN port connecting the Actiontec to the Asus had lots and lots of traffic. Thus, there was substantial load on the Actiontec simply to route those packets.

2. The Asus WAN port had to absorb those packets and dole them out to each machine on your LAN - even though there was nothing that was going to process them. Thus, there was also substantial load imposed on the Asus to distribute those packets as well.

3. Each network card on each machine on your LAN had to absorb those packets and discard them.

4. The Asus router had no means of knowing those packets were entirely irrelevant to its operations (IGMP Snooping was off). Thus, the transmit/receive buffers on the LAN side of the Asus were hard at work distributing those packets to each individual machine's network port on your LAN - using flow control to ensure the packets were reliably delivered.

5. Each network port on each machine was dutifully using flow control to tell the Asus router to slow down multicast packet flow to a rate that network card was capable of reliably discarding those irrelevant multicast packets (and handling the "real" traffic). Thus, the buffers on each of the network ports on the LAN side of the Asus were filling up as each network card was throttling its own flow so each network card could handle the multicast and the other normal network card packet flow to that particular machine.

6. The flow-control on the LAN side of the Asus was being properly reflected back to the WAN side of the Asus - thus the receive buffers in the WAN port of the Asus were eventually becoming saturated.

7. The WAN port on the Asus router was then dutifully telling the LAN port on the Actiontec to modulate the flow of packets from the Actiontec to the Asus - so the Asus could dole them out to the network cards at a rate the network cards could accept reliably (without dropping packets).

7. The Actiontec's receive buffers for the LAN port were therefore filling up - because the Asus WAN port was telling the Actiontec to modulate its transmit buffers to match the Asus receive buffers - so the Asus could properly distribute packets to each LAN card in each machine on your network according to that LAN card's ability to drop the irrelevant multicast packets without dropping "the good stuff" as well.

8. I suspect the Actiontec's implementation of flow control is poor - such that full receive buffers on the LAN port on the Actiontec slows down responsiveness for *all* ports on the Actiontec. This means the STB ports were also experiencing the same level of flow control the LAN port was experiencing.

9. Thus your STBs' input buffers were *underflowing* - because the Actiontec was causing the output to the STB ports to slow down to match the flow-control scenario imposed by the LAN port - causing stutter, framedrop and so on.

-

Solution:

1. The moment you implemented IGMP Snooping, the Asus router's WAN port would no longer forward multicast packets to the LAN side of the router - because there was nothing on the LAN side of the ASUS router that was "listening" for multicast packets.

2. This freed up the Asus to accept all other TCP/IP traffic normally - and thus the transmit/receive buffers on both the LAN and WAN ports on the Asus were freed up to work without choking on distributing the multicast packet stream to the LAN nodes.

3. With the LAN port on the Actiontec and the WAN port on the Asus now passing only relevant traffic - the transmit/receive buffers for the LAN port on the Actiontec were freed up because there was no need for flow-control to "throttle-back" the packet-traffic on the Actiontec's LAN port to the level the Asus was being forced to accept because the Asus could go no faster than your Network cards in your machines on your LAN could drop the multicast packets.

4. With the LAN port on the Actiontec no longer stalled by flow-control restraints on the WAN port of the Asus - the transmit/receive buffers in the Actiontec were "relaxed" by the lower packet-forwarding-load - to the point where proper traffic to the STBs could be maintained at a level where the buffers in the STBs would no longer underrun. Thus, your TV picture and sound returned to normal.

-

And you thought this flow-control-management-stuff was only relevant to backbone routers, eh? Well, IPTV puts the lie to that...

Note: Google "bufferbloat" for more info on how poor transmit/receive buffer management in Home routers affects real-world speed. There's lots of routers where buffer management is done poorly - causing "packet-stall" - and therefore lower transfer rate than should actually be possible.

-

Hope this helps.

bjcsoln

join:2013-08-03

Wow - thanks for the very thorough explanation. Its going to take me awhile to go through it and fully digest it, but I will take the time as I want to get a better understanding of all of the different pieces / technologies related to networking, IP and IPTV.

I know one of the next avenues I want to explore is trying to understand and quantify exactly how well my internet connection performs - I am d/t Vancouver in a somewhat new building (12 years old) paying for TELUS 15/1. Reading some of the other threads here it sounds like if you do know what you are talking about, and provide some real data, you can get TELUS to buck up and provide a service that is closer to what they advertise (well, closer to the higher end of the range that is).

Anyway, again thanks for the feedback. This new configuration appears to be running very smoothly (its been a week) so now time to understand what I can do next and give it a whirl!

B.