[mythtv-users] Way out idea on watchingsame thinginmultiplerooms

Gareth Glaccum gareth.glaccum at btopenworld.com
Thu Jan 7 11:14:43 UTC 2010


>>But in the case where I have a TV plugged into a GB network, and the TV 
>>only
>>has a 10Mb/s interface implemented, it means that it is getting a 
>>broadcast
>>stream of an HD channel that it doesn't need. Its switch on the port 
>>starts
>>to drop packets because the TV cannot receive data fast enough (10Mb/s 
>>ports
>>being half duplex as well). This means then that the TV can no longer
>>receive perfectly all the data that it was expecting. My TV is only 1 year
>>old, I have no wish to upgrade it just because the network port stops
>>working because a program is flooding its network port.
>>This is an edge case example, but a problem none-the-less.

_______________________________________________

>I guess that implies the switch is not up to the job if that happened, so 
>replacing the switch with a multicast compliant switch (cheaper than a TV I 
>would speculate!) would surely fix that? (Or not enabling the multicast 
>option)  Out of interest what is the TV brand and model?  What is the 
>Ethernet port there for, I assume with that level of performance its for 
>firmware upgrades only and surely not for DLNA?

This is a Sony TV. The port is for internet guide data, and UPNP browsing to 
allow the telly to be a (very) large digital photoframe. This was an example 
I made up as an analogy to show that the problem exists. I have not done the 
multicast broadcast on my network, but this is what /should/ happen. If a 
port is running slower than the incomming traffic, then once the switch port 
buffers are full, they will drop packets going to that port. However, the 
multicast traffic can go to other ports, so the receiving port on the switch 
does not increment the error count, only the transmitting ones which are too 
slow. If you have a 10G computer unicasting (without error checking) to a 1G 
computer, you would see the same errors.

Yes, the switch is not up to the job, in that multicast is not properly 
handled, or it is not configured correctly. What I am saying, is that we 
don't want to be in the situation where someone complains that their network 
no longer works, because they installed MythTV. "It was working perfectly 
fine before, therefore it must be MythTV at fault.". Many seemingly 
intelligent IT professionals often do not understand the reasoning that 
something could have been broken before-hand, but they just didn't realise. 
As I said previously, I have in the past had to get switch companies to fix 
their firmware, because they didn't understand how to configure/use 
multicast properly either, enough to test it. The difference here is, the 
switches I often come across, are Tier 1/Tier 2. So long as I can get to 
talk to someone technical enough, show them the configuration and the 
packets going to the wrong places, they care enough about their products to 
actually fix the firmware, and provide custom coded firmwares whilst the 
rest of the code goes through QA. Unfortunately IT proffesionals sometimes 
get a little, protective, if someone suggests there is a problem somewhere 
else in their domain.

(With home users, sometimes getting enough information to actually diagnose 
the problem can be very difficult. Do you know the IP address of the managed 
switches in your home network? What are the chances that 20% of the people 
on this list do?)
Unfortunately, consumer products just don't care.

Unfortunately, with consumer products, the manufacturers often don't care. 
One of the reasons why I doubt I will ever buy a Belkin product ever again. 
I found a bug in one of their wireless products, which made the product 
incompatible with one of their other wireless products. I sent in the bug 
report, spent two weeks getting suggestions from their technical staff which 
didn't solve the problem (even one which suggested using a competitors 
product instead, which did work). Got a call from their technical manager, 
he said it was a known problem/bug. I asked when they were likely to release 
a new firmware (one of the workarounds suggested wasn't possible due to a 
hard-coded variable, would have been easy to change that variable), was told 
that they wouldn't be (product was less than 3 months after release). I 
asked them to put this down in an email to me, so I could at least take it 
back and get a refund, as the product was useless to me with this bug (was a 
wireless print server, which if it didn't get a particular packet every 30 
minutes [which their router only sent out every hour], would shut down its 
wireless interface), and was told that they would never consider making a 
new firmware available.

A real life example that I have tested, was with a VOIP network I 
investigated. The telephones were 10Mbs/half. Normal calls were unicast. 
Conference calls, turned to multicast. This is sensible given the situation, 
and is very close to what we are discussing really (apart from the need to 
synchronise).
Unfortunately one of the switches in the network was not configured 
correctly, so they (they were GB switches to desktop), started broadcasting 
the multicast traffic instead of unicasting it. Up to 4 conference calls on 
the network were fine. However, once you went to 5 conference calls, all 
phones on this switch only started to get crackling/distortion.
Looking at the logs on the switches, immediately you started the 5th call, 
you could see the ports with phones (only those, as the rest of the 
computers could code with the bandwidth), started to drop packets due to 
buffer full errors.
Running a tcpdump on the network showed that the multicast was going to 
everyoneon the mis-configured switch. Turning on snooping and proper igmp 
handling allowed the phones to only receive the data they were meant to (and 
ensured that desktops couldn't snoop on calls).



More information about the mythtv-users mailing list