[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