Post by: Jason Lavoie on July 04, 2007, 08:23:13 PM
the only location that will work is in a drop ceiling air plenum space. is there any way to install a hub in a ceiling that won't violate fire regulations?
any cobranet recommended hubs that are nice and small and can be installed right in a pull box?
I wish there was a better option, but it seems this is the only place I can put it.
Post by: Phil LaDue on July 04, 2007, 08:27:04 PM
Post by: Don Boone on July 04, 2007, 09:34:27 PM
Extron has plenum rated audio amplifiers that don't require an enclosure, so they breath free without having to have a sweat chamber box.
We need a plenum rated switch.
Don
Post by: Ron Hebbard on July 04, 2007, 11:33:31 PM
| Jason Lavoie wrote on Thu, 05 July 2007 01:23 |
I have a situation where I'm running Cobranet from rack to rack and it may be a bit over the 100m maximum length and the only option seems to be to put a switch somewhere in between. the only location that will work is in a drop ceiling air plenum space. is there any way to install a hub in a ceiling that won't violate fire regulations? any cobranet recommended hubs that are nice and small and can be installed right in a pull box? I wish there was a better option, but it seems this is the only place I can put it. |
Hello Jason;
This may be a little rude but it's a methodology that's worked for me many times in the past.
When companies state suggested maximum cable runs they play it safe.
Measure the length you require, triple it and run a few tests.
If it works error free, install your "bit over the 100m maximum length" and sleep well.
If the triple length doesn't work, try a double length.
If the double length works, great, if not try 150m.
You've got the idea.
Don't send out anything that's barely shy of the ratty edge but if it works reliably at 3x, 2x or 1.5x the length you need you're probably safe to go with it.
Back in my computer controlled a/c servo drive days, I found I could run RS-232 75' and resolver cable 200'.
The IT folks were telling us that 25' was the max for serial and the servo drive manufacturers were telling us that 40' was their absolute maximum length for resolver cables but only when ran in dedicated conduits.
When we were shipping a/c servos to Germany for 'Tommy', all of our drive cables were off the shelf grey vinyl jacketed control cables.
We'd typically have a 12/4 shielded motor cable, a double shielded resolver cable, a 16/2 shielded DC brake cable and an 18/4or5 shielded hard limit cable bundled together with a few wraps of electrical tape every 2 or 3 feet and no conduit in sight.
Prior to 'Tommy' Frankfurt, our longest cables were 100'.
When we needed 150' and 200' cables for Germany, we took full 1,000' put-ups and connectorized both ends for testing.
We found 1,000' was pretty ratty, pardon the technical word, but cutting the 1,000' in half to 500' seemed to work pretty well as far as we could tell by test running the rig in the shop.
After that, we sent the 200' lengths to Frankfurt and figured we'd be safe to send out anything up to 300' if / when the need were to arise.
Bottom Line: Don't believe all you read, conduct your own exhaustive tests and form your own conclusions.
Toodleoo!
Ron Hebbard
Post by: Jason Lavoie on July 04, 2007, 11:42:06 PM
number one is that the 100m limit is imposed by the computer industry, who can afford a few errors and dropped packets here and there, so if they could go over 100m without too much loss they probably would (and I haven't found many hits on the web of people recommending it)
With cobranet (correct me if I'm wrong) even a few errors could be pretty bad right?)
add to that the fact that 120m or more of cat5 strewn around my shop could behave very differently once it is installed and in a different environment
and if I do get it in and there's a problem, it'll be too late to ask for the necessary stopover point.
Jason
Post by: John Birchman, CTS on July 04, 2007, 11:58:40 PM
If it is over the distance for copper, and putting a switch in the ceiling looks to be problematic, you should look at running fiber instead of copper, and put in media converters at each end.
John
Post by: Ron Hebbard on July 05, 2007, 12:01:12 AM
| Jason Lavoie wrote on Thu, 05 July 2007 04:42 |
I was ready to try pushing the limits of cobranet, but a few things have me scared away from that. number one is that the 100m limit is imposed by the computer industry, who can afford a few errors and dropped packets here and there, so if they could go over 100m without too much loss they probably would (and I haven't found many hits on the web of people recommending it) With cobranet (correct me if I'm wrong) even a few errors could be pretty bad right?) add to that the fact that 120m or more of cat5 strewn around my shop could behave very differently once it is installed and in a different environment and if I do get it in and there's a problem, it'll be too late to ask for the necessary stopover point. Jason |
Hi again Jason;
Let me give this one last kick but only you know your situation and comfort level.
If you need 120m, test 360m and 240m.
Run it around your shop, take a couple of passes around serious power transformers and a couple of passes around your welders if you have some.
If things appear to be working but you're still concerned, install an accessable pull-box and route your cable, un-cut, through it. Be sure to have power provided in / near your pull-box just in case.
Access could be via a proper, hinged, access door or by temporarily removing a fluorescent fixture to reach your pull-box.
Your pull box could be something standard with it's cover plate replaced by a piece of expanded metal / speaker grille material.
The box could be mounted on edge so as to put the grille on a side to lessen dust accumulation.
If you opt to play the 'push the limits' game, either play until you find where the ratty edge is or prove to your self that triple your required length works adequately.
I'll go 'way now.
Toodleoo!
Ron Hebbard
Post by: Austin Parker on July 08, 2007, 06:18:01 PM
Service access? fire protection? ventilation?
Post by: Robert Sims on July 08, 2007, 07:36:51 PM
You may want to look at a conversion from copper to fiber back to copper to get you the distance you need. Attached is an inexpensive stand alone solution.
http://www.milan.com/TransitionNetworks/Products2/Family.asp x?Name=SGFEB101x-100
http://www.blackbox.com/Catalog/Detail.aspx?cid=308,1416,149 9&mid=4715
Many versions and costs.
Just another option.
Robert
Post by: Jason Lavoie on July 09, 2007, 11:56:44 AM
and although it might come in a bit more expensive to go with fiber it means I won't have to change any conduits or as for power at a stopover point.
thanks for the tip. anyone know if they have a reseller in Canada? and where is the best place to get pre-terminated fiber?
Jason
Post by: Phil LaDue on July 09, 2007, 12:08:51 PM
| Jason Lavoie wrote on Mon, 09 July 2007 11:56 |
thanks for the tip. anyone know if they have a reseller in Canada? |
Try calling some of these numbers, or the US headquarters.
http://www.blackbox.com/Contact_Us/country-offices.aspx?ccod e=CA
Post by: John Birchman, CTS on July 09, 2007, 01:11:32 PM
http://www.blackboxcanada.ca/
2225 Sheppard Ave. E.
16th Floor.
Toronto, ON M2J 5C2 - Canada
Ph: (416) 490-7100/ 1-800-667-6625, Tech Support 1-800-355-8002
If you know the exact distance of Fiber that you need, you can get that through Black Box as well, with the connectors already on ready to go. They have OPTISOK sleeves that you use to pull connectorized fiber through conduit (as long as the conduit is big enough).
Black Box may be a bit more in price (they say they will beat any price), but most items include FIDO protection. So if it is accidentally damaged during installation, you can get a free replacement from them, not many companies do this. And pre-sale and tech support is great as well. They are happy to help you with anything that you are not sure of, or they may even suggest a better way to solve the problem.
Good luck!
John
Post by: Jason Lavoie on July 09, 2007, 02:12:43 PM
I assume someone has tried these devices with Cobranet before? I hear sometimes it can be picky.
Post by: Robert Sims on July 12, 2007, 09:55:57 PM
Hotels here in Vegas use the fiber method a lot. They just have enough money to use real fiber switches. Cobranet is actually the only thing that seems to be stable me when operating in the IP world. Just keep other traffic off the path.
One lesson learned about cobranet. If you loose the primary, secondary kicks in with no drop out. Just hope the primary doesn't reconnect during anything important. It'll drop out during the re-negotiation period. (a few seconds). It would be nice to offer a manual reset on the primary.
Robert
Post by: Jason Lavoie on July 12, 2007, 11:11:23 PM
although there are only four boxes in the whole system, and with those blackbox media converter/switches that were recommended I can have two cobranet boxes at each end of my fiber without the use of any additional network hardware. so it should be a pretty simple and stable network.
Jason
Post by: Jason Lavoie on July 25, 2007, 02:53:49 PM
everyone I ask gives me wishy washy answers, and either says only to use really expensive switches, or only switches from brand X
the problem is, I really don't want to put an expensive switch (most of which are 48 ports) at each end only two plug in two devices each.
Does the amount of traffic affect things? the traffic will be limited to 4 multicast bundles (9 channels total) and 3 unicast bundles (5 channels total) if that helps.
Any experience would be appreciated, or even if someone has one of these switches they could try out to save me buying one just to find out it won't work.
Thanks.
Jason
Post by: Kent Clasen on July 27, 2007, 10:59:20 PM
| Jason Lavoie wrote on Wed, 25 July 2007 19:53 |
Sorry to drag this up again, but I had decided to go with the media converter/switch from blackbox mentioned above, but I would like to hear from at least one person who has used their switches successfully with Cobranet. everyone I ask gives me wishy washy answers, and either says only to use really expensive switches, or only switches from brand X the problem is, I really don't want to put an expensive switch (most of which are 48 ports) at each end only two plug in two devices each. Does the amount of traffic affect things? the traffic will be limited to 4 multicast bundles (9 channels total) and 3 unicast bundles (5 channels total) if that helps. Any experience would be appreciated, or even if someone has one of these switches they could try out to save me buying one just to find out it won't work. Thanks. Jason |
Jason, I haven't used that box. This is one that is good and is not very big, it would fit in an 8x8 pull box:
HP J4097B ProCurve Switch 408
I didn't read all of the posts. I believe that CN states that the maximum recommended multicast bundles is 4, so you are at the max, but would need to see your setup to be sure.
Have you tried calling Symetrix and asking them for a recommendation?
Post by: Jason Lavoie on July 28, 2007, 12:30:51 PM
if that is the case then it may well work for me.
as for bundles. that's the total number of bundles in my network. not necessarily from one box, so I think I'm still well under the max.
I have called Symetrix but they are very hesitant to recommend anything (especially since they didn't design cobranet they just license it)
Jason
Post by: Kent Clasen on July 28, 2007, 02:27:44 PM
| Jason Lavoie wrote on Sat, 28 July 2007 17:30 |
thanks for the recommendation. does that box run on DC? ie: can I feed DC down the conduit instead of having to add an outlet near the pull box? if that is the case then it may well work for me. as for bundles. that's the total number of bundles in my network. not necessarily from one box, so I think I'm still well under the max. I have called Symetrix but they are very hesitant to recommend anything (especially since they didn't design cobranet they just license it) Jason |
Jason, yes it has a wall wart.
As far as Multicast bundle limits, what I have been told is that all units (if they are all on the same network) receive the multicast bundles, regardless of if they have the been programmed to receive it, then they look at it and ignore it if not, but this is what eats up your bandwidth. I believe all of the specs for Cobranet can be found at www.cobranet.info
This is also good reading:
http://www.yamahaproaudio.com/downloads/documents/yss/yss_wp 2_en.pdf
Post by: Jason Lavoie on July 28, 2007, 06:00:48 PM
| Kent Clasen wrote on Sat, 28 July 2007 14:27 |
Jason, yes it has a wall wart. As far as Multicast bundle limits, what I have been told is that all units (if they are all on the same network) receive the multicast bundles, regardless of if they have the been programmed to receive it, then they look at it and ignore it if not, but this is what eats up your bandwidth. I believe all of the specs for Cobranet can be found at www.cobranet.info |
I guess it would be good to know if I have a network with 4 devices and a signal that has to get to two of the 4, am I better off with one multicast bundle, or two unicast bundles with only one channel each? I'm using more channels but fewer bundles. it seems like duplication, but if it keeps the data flow to only the 2 boxes that require it then it may be better right?
I understand how bundles work, but I don't understand why it is important to bundle signals together other than keeping track.
Post by: Kent Clasen on July 28, 2007, 06:34:34 PM
| Jason Lavoie wrote on Sat, 28 July 2007 23:00 | ||
I guess it would be good to know if I have a network with 4 devices and a signal that has to get to two of the 4, am I better off with one multicast bundle, or two unicast bundles with only one channel each? I'm using more channels but fewer bundles. it seems like duplication, but if it keeps the data flow to only the 2 boxes that require it then it may be better right? I understand how bundles work, but I don't understand why it is important to bundle signals together other than keeping track. |
See below from Yamaha:
Note: Unicast bundles are only transmitted to single devices which have been set to the same
bundle number as the transmitting device. Multicast bundles are transmitted to all devices on the
network regardless of their settings, but only bundles with the specified bundle number(s) are
processed. For this reason, multicast bundles make heavy use of network bandwidth and it is
recommended that the maximum number of multicast bundles be limited to 4 (32 channels).
Multi-unicast bundles are only transmitted to up to four devices simultaneously, saving network
bandwidth compared to multicast bundles.
Post by: Jason Lavoie on July 28, 2007, 07:10:43 PM
are two single-channel multicast bundles any different (traffic wise) than one two-channel multicast bundle?
am I wrong in assuming that since 4 multicast bundles (@32 channels) is a good limit, then my 4 multicast bundles with only 9 channels should be 1/3 as much traffic. leaving me with lots of network headroom?
here is my network:
Box1: Sending 1 multicast bundle (4ch)
Box2: Sending 1 multicast bundle (1ch), 1 unicast bundle (3ch, and 2 unicast bundles (1ch each)
Box3: Sending 1 unicast bundle (2ch)
Box4: Sending 2 multicast bundles (2ch each), 1 unicast bundle (1ch), and 1 unicast bundle (2ch)
There are some places where I could combine a few things together into one bundle, but I had them separated to make it easier to keep track of what is what.
As for receiving:
Box1: receives 12 channels
Box2: receives 8 channels
Box3: receives 7 channels
Box4: receives 6 channels
(not counting the unwanted channels that arrive as a result of multi-cast bundles)
Jason
Post by: Jason Lavoie on July 28, 2007, 07:11:46 PM
Jason
Post by: Jason Lavoie on July 28, 2007, 09:13:51 PM
from http://www.cirrus.com/en/pubs/appNote/CobraNet_BundleAssignm ents.pdf
"For most efficient utilization of network bandwidth, use of maximum size Bundles is suggested when possible."
so it does sound like X channels spread out over multiple bundles is worse than X channels grouped together into larger bundles whenever possible (it doesn't say by how much though)
I'm assuming this is due to overhead, which may be really high if they are expecting people to be using bundles for more than one or two channels most of the time.
"This entire document was based on the use of full Bundles. If Bundles containing less than the maximum number of audio channels are used, it is possible in some cases to exceed the limit of 8 Bundles on Fast Ethernet."
they are refering to each port on a switch being able to handle a max of 8 (full) bundles in each direction.
Sorry if I'm answering my own questions and supplying info that may not be new to you, but I figure someone else may be searching later and find it useful.
Jason
Post by: Josh Millward on August 03, 2007, 12:45:08 AM
Basically, looking at the few number of channels you are looking at moving from one point to another, you will be fine with pretty much whatever you do.
Keep this one detail in mind... the bandwidth utilization is dependent on the total number of audio channels on the link, regardless to the number of bundles they are broken into. So, by multicasting bundles around you are needlessly increasing the network load IF all those channels are not needed by all the receivers.
Multi-Unicast is an interesting thing, it is a great way to have a unicast bundle go to up to 4 devices without wasting network bandwidth by multicasting unnecessary crap everywhere.
I am not certain what configurations are available in the Symnet boxes. I'm just familiar with Cobranet since I work at MediaMatrix. For more fun and exciting reading, if you REALLY want to know all the details about how Cobranet works, download the "Cobranet Programmer's Reference Guide" from the Cobranet website. You will also need Cobranet Discovery (aka Disco - yes, it comes with a virtual mirror-ball!) to really look at how your devices are operating on the Cobranet network.
Oh yeah, one last thing, you aren't doing something silly like using one of the "low latency" modes, right???
Post by: Jason Lavoie on August 03, 2007, 08:08:47 AM
| Josh Millward wrote on Fri, 03 August 2007 00:45 |
Oh yeah, one last thing, you aren't doing something silly like using one of the "low latency" modes, right??? |
WELL! that statement just begs more explanation.. (you knew that was coming didn't you?)
certain people at an undisclosed company told me that the higher latency modes were only really for compatibility with other equipment and that unless there's a reason not to, that I should set it to the lowest (1-1/3ms)
in my application the extra 4ms to up it to higher latency likely won't negatively affect anything but I'm curious now..
Jason
Post by: Josh Millward on August 04, 2007, 07:48:51 PM
| Jason Lavoie wrote on Fri, 03 August 2007 08:08 |
WELL! that statement just begs more explanation.. (you knew that was coming didn't you?) |
I suppose I should have seen that coming...
| Jason Lavoie wrote on Fri, 03 August 2007 08:08 |
certain people at an undisclosed company told me that the higher latency modes were only really for compatibility with other equipment and that unless there's a reason not to, that I should set it to the lowest (1-1/3ms) in my application the extra 4ms to up it to higher latency likely won't negatively affect anything but I'm curious now.. Jason |
This has to do with how many channels of audio you can move. The standard latency is 5.33 milliseconds (mS). Using this latency you can move 32x32 channels on Cobranet. If you switch to the next lowest latency which is half that, you also halve the number of channels you can move to 16x16. You can again halve the latency, but it will again halve the channel count down to 8x8.
So, I would again suggest that you download CobraCAD and draw up your configuration to see if it will work or not and to see what the utilization of the links is.
I can understand why a low latency mode would be required for personal in the ear type monitoring situations, however, even the higher latency mode of 5.33 mS is about the equivalent of the loudspeaker being an additional 5.87 feet away.
The biggest problem is when you start running the signal across more than one link of Cobranet is that you incur the latency penalty each time you run your signal across a Cobranet link. So, if you were to send the signal down the Cobranet to FoH and process it, THEN send it down the Cobranet again to get it back to FoH, you have incurred 10.66 mS of latency, which could be too much for critical monitoring situations. However, if you were able to do your processing at the stage you could then use the Cobranet to feed lobby, backstage, and other zones around the facility. These zones would not be critical of the latency.
There are some Cobranet devices out there that will not do lower latencies and can only do the 5.33mS speed, but whoever mentioned that latency on Cobranet has to do with interoperability isn't really on the right track. It has more to do with channel count.
Post by: Jason Lavoie on August 05, 2007, 05:24:22 PM
| Quote: |
This has to do with how many channels of audio you can move. The standard latency is 5.33 milliseconds (mS). Using this latency you can move 32x32 channels on Cobranet. If you switch to the next lowest latency which is half that, you also halve the number of channels you can move to 16x16. You can again halve the latency, but it will again halve the channel count down to 8x8. |
thanks for the info. it is definitely not in any of the documentation I have come across.
I'm confused though because we're still moving the same quantity of data, just encoding and decoding faster right?
maybe I'm missing something here..
I have tried my design in Cobracad and it does seem like a useful exercise, however I can't find any settings for latency, and a search through the help file generates zero hits on the word latency.
Jason
Post by: Josh Millward on August 06, 2007, 01:55:07 AM
Again, this is just a guess on my part since I haven't personally ever set up a low latency Cobranet network. I might have to try that this week, if I can eek out some time.
Good luck!
Post by: Jason Lavoie on August 06, 2007, 07:55:17 AM
| Josh Millward wrote on Mon, 06 August 2007 01:55 |
I haven't tried setting to lower latency settings in CobraCAD either, but I figured it would be in there somewhere. If it isn't, have a look at the network utilization. If you are under 50% utilization, I would guess you would be okay with the middle latency and if it is under 25% utiliziation, you should probably be okay with the lowest latency. |
that sounds reasonable. although I would hate to push data transfer to the max and risk audible problems just for the sake of a few miliseconds. I think giving up some latency to gain bandwidth headroom is a good trade.
Jason
Post by: Greg Bellotte on August 25, 2007, 11:47:41 AM
| Jason Lavoie wrote on Sat, 28 July 2007 18:11 |
... or does a bundle take up the same amount of network traffic even if it's not full? Jason |
for the most part, a bundle takes the same bandwidth regardless of its content. a bundle with one channel of audio still contains seven channels of silence, repesented by a boatload of digital zeroes.
as for maximum bundles to transmit, i have successfully set up a system with nine broadcast (multicast) bundles for a total of 72 channels of audio (actually we had two parallel systems for 144!). everything was moving in one direction, and we had three sets of units to receive in three different locations. this seems to be about the limit for multicast, as the bandwidth of our 100mbit switch was pretty much at its limit. gigabit switches DO NOT help, as the 100 mbit ports on the cobranet units will still get clogged with multicast traffic.
as for cat5 length, 100m *IS* the number, and existed long before cobranet. longer runs require a repeater, switch, or media converter/fiber extension. the above system was originally on <100m cat5 and worked very reliably. we set up this same system again, with 100mbit fiber links between the sending and receiving units about 3000ft apart. we found we lost enough bandwidth through the media converters to limit us to eight broadcast bundles. still a lot of signals.
as noted before, you should really limit the use of multicast bundles when possible. the switch is required to pass these packets to all rx units, even if they wont be needing them. a unicast bundle will only be passed to the unit that needs it, so you can have many more bundles than 9 if you plan it out right.
Post by: Josh Millward on August 26, 2007, 01:16:06 AM
| Jason Lavoie wrote on Sat, 28 July 2007 18:11 |
... or does a bundle take up the same amount of network traffic even if it's not full?Jason |
This really depends on how you set up your bundles. Like Greg said above, if you set the bundle up as an 8 channel bundle, then use only 2 channels on it, you will still use up a full 8 channel bundle's bandwidth, since you are still transmitting 6 empty channels. However, if you set up that bundle as a 2 channel bundle, it will take up less network bandwidth since the bundle is smaller.
Of course, this depends on having the ability to set up advanced Cobranet mapping. Many devices can not do this. Some can. Actually, if you use the latest version of Disco, you can do advanced mapping with any Cobranet device. However, this is fairly advanced and the manufacturer of the products you are using may not support you in doing this. There are some fun settings to get worked out to enable it to not forget these settings on a reboot and to modify the settings you HAVE to use Disco since you are bypassing the manufacturer's setup.
| Greg Bellotte wrote on Sat, 25 August 2007 11:47 |
as for maximum bundles to transmit, i have successfully set up a system with nine broadcast (multicast) bundles for a total of 72 channels of audio (actually we had two parallel systems for 144!). everything was moving in one direction, and we had three sets of units to receive in three different locations. this seems to be about the limit for multicast, as the bandwidth of our 100mbit switch was pretty much at its limit. gigabit switches DO NOT help, as the 100 mbit ports on the cobranet units will still get clogged with multicast traffic. |
Greg, I am stunned that system worked. You must have had some serious network hardware and no other network traffic. I mean, that is just a LOT of network traffic since they are all multicasting! Wow. Very cool. This is awesome information to know! Thanks for sharing!
-Josh
Post by: Ron Hebbard on August 26, 2007, 06:05:07 AM
| Greg Bellotte wrote on Sat, 25 August 2007 16:47 | ||
for the most part, a bundle takes the same bandwidth regardless of its content. a bundle with one channel of audio still contains seven channels of silence, repesented by a boatload of digital zeroes. as for maximum bundles to transmit, i have successfully set up a system with nine broadcast (multicast) bundles for a total of 72 channels of audio (actually we had two parallel systems for 144!). everything was moving in one direction, and we had three sets of units to receive in three different locations. this seems to be about the limit for multicast, as the bandwidth of our 100mbit switch was pretty much at its limit. gigabit switches DO NOT help, as the 100 mbit ports on the cobranet units will still get clogged with multicast traffic. as for cat5 length, 100m *IS* the number, and existed long before cobranet. longer runs require a repeater, switch, or media converter/fiber extension. the above system was originally on <100m cat5 and worked very reliably. we set up this same system again, with 100mbit fiber links between the sending and receiving units about 3000ft apart. we found we lost enough bandwidth through the media converters to limit us to eight broadcast bundles. still a lot of signals. as noted before, you should really limit the use of multicast bundles when possible. the switch is required to pass these packets to all rx units, even if they wont be needing them. a unicast bundle will only be passed to the unit that needs it, so you can have many more bundles than 9 if you plan it out right. |
Hello Greg;
May I ask what you were using this for?
Toodleoo!
Ron Hebbard
Post by: Karl P(eterson) on August 26, 2007, 10:53:42 AM
| Jason Lavoie wrote on Sun, 05 August 2007 17:24 |
I'm confused though because we're still moving the same quantity of data, just encoding and decoding faster right? maybe I'm missing something here.. |
It would seem like that would be the case, doesn't it? - Unfortunately though, it isn't. By lowering the latency, you are actually sending the data more frequently, hence increasing the data transfer traffic flow, thus a higher network saturation.
Help?
Karl P
Post by: Karl P(eterson) on August 26, 2007, 11:31:01 AM
| Greg Bellotte wrote on Sat, 25 August 2007 11:47 |
we set up this same system again, with 100mbit fiber links between the sending and receiving units about 3000ft apart. we found we lost enough bandwidth through the media converters to limit us to eight broadcast bundles. still a lot of signals. |
In order to have gotten that much signal on the net in the first place, I will assume that you needed to use pro level switching (HP, Cisco) to start with. If that is the case, you should have used gigabit fiber cards in the switches and this would have given you enough inter-switch bandwidth to tolerate the loss from the conversion process. Since you would be using internal switch cards on both sides, the latency in the line itself would have been much more conducive to (safely) running the system on the limits of its capabilities than with media converters.
Karl P
Post by: Greg Bellotte on August 26, 2007, 02:57:10 PM
@ron-the system mentioned was audio distribution for network television coverage of several major golf events. the origination of signals and the first receive point was for the domestic coverage, the secondary receive points were international broadcast units.
@karl-as mentioned above, no, we are not using pro level switching hardware of any kind so we don't have any internal uplinking ports. I do think that gigibit fiber would have helped. once again, the equipment vendor kind of killed us. they sent evertz wdm media converters, but sent units of the same kind-not ones with reciprocal tx/rx so nothing talked to each other. i ended up using some of my own MC's that i usually just use to grab some internet. apparently they are of the "store and forward" design and the latency was just enough to kill the ninth bundle. curiously, it's the last bundle to check in that gets hammered. the problem wasn't terrible, but audio at this level must be perfect.
my future specs will call for managed switches and gigibit fiber links. we can then split the switches into vlans and use one physical cat5 system for even more channels than we use now. i'm shooting for 256 channels on a single fiber run!
Post by: Karl P(eterson) on August 26, 2007, 07:43:09 PM
| Greg Bellotte wrote on Sun, 26 August 2007 14:57 |
my future specs will call for managed switches and gigibit fiber links. we can then split the switches into vlans and use one physical cat5 system for even more channels than we use now. i'm shooting for 256 channels on a single fiber run! |
With proper use of VLAN's and trunking architecture, the sky is (almost) the limit. It would not be crazy to assume that you could get 640 channels on a single fiber run with proper VLAN isolation techniques. Of course, assuming that the hardware cooperated and the layout was conducive, you could theoretically have 13 thousand channels running on a system comprised of a core 10Gigabit ring network with smart VLANS and real time in-switch routing.
Karl P