In my case, as I said, I'm pretty sure disk I/O is the bottleneck, not the LAN. and the large transfer I am talking about is RSYNC backing up /var/snd one a week, which I have tamed using command line options.
> *The LAN it's connected to is part of your airchain*. > > *You have to treat it that way*. Absolutely agree. > 1) Is there anything on that physical switch besides the Rivendell > servers and workstations? NOPE, and there shouldn't be. > 2) Do you have dual Ethernets in each machine? In the machines, yes, but currently I do not have a redundant network, it's part of the plan though. > 3) Is that switch on its own long-runtime UPS or protected tech power? Yes. > 4) Are the Ethernet cables a different color? (Usually, red is reserved > for your unfirewalled public IP connection, but it's probably still the > best choice, here. Or magenta, if you can find it.) OK, Guilty here, but I agree with the principle. I used what we had laying around though. should change them out someday... > There is, > I have found, a tendency to forget that network engineers spent as much > time learning our trade as you studio and RF engineers did learning yours, > and we can't pick yours up in 6 months anymore than you can pick up ours. I take no offense here, it's true to a degree. I personally am an Audio engineer first, Computers/networks second and RF third (a distant third at that)...But I recognize that and don't pretend o be an expert where I'm not. sometimes we end up being the expert in the eyes of management though (because we know more than they do). I don't hesitate to warn them when theyre asking me to work beyond my expertise, I"ll do it, I"ll learn what I need to, but I at least tell them that. We area non profit so hiring some one else to do it s usually not an option. Nathaniel C. Steele Assistant Chief Engineer/Technical Director WTRM-FM / TheCrossFM On 2/25/2013 11:22 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Brooks Whiteford" <[email protected]> >> If you're finding dropouts are common during big data transfers, perhaps a >> new network switch is in order. We didn't have a lot of cash to spend, but >> an enterprise grade Cisco switch has made network issues a thing of the >> past. > The implications underneath this point to something that's always sort of > irritated me. > > <rant> > I've only worked in a live-to-air facility once; a cable > TV sales network. But even there, in the truly miserable, amateur plant > I got handed, I always treated the air path as sacred, and did everything > I could to make it as reliable as possible. > > If you're running Rivendell live-to-air (and by this, I mean that R proper > is playing live to air, not that you're not in full-automation mode)... > > *The LAN it's connected to is part of your airchain*. > > *You have to treat it that way*. > > People are shaking their heads at me now, but it appears that this is > *not* a message from Captain Obvious: > > 1) Is there anything on that physical switch besides the Rivendell > servers and workstations? > > 2) Do you have dual Ethernets in each machine? > > 3) Is that switch on its own long-runtime UPS or protected tech power? > > 4) Are the Ethernet cables a different color? (Usually, red is reserved > for your unfirewalled public IP connection, but it's probably still the > best choice, here. Or magenta, if you can find it.) > > I understand that part of the point is that Rivendell is "free", but free > means as little here -- or less -- than it does in any other environment > where you can get FOSS software to replace commercial stuff. There is, > I have found, a tendency to forget that network engineers spent as much > time learning our trade as you studio and RF engineers did learning yours, > and we can't pick yours up in 6 months anymore than you can pick up ours. > > [ On re-reading, that sounds unnecessarily combative, but I can't think > of a better way to phrase it; please don't take it personally, Any Given > Reader. :-} ] > > The biggest offender here, amusingly, is Broadcast Engineering magazine, > which regularly publishes IP networking articles which were clearly > written by people who don't have the first (or occasionally, second or > third) clue what they're talking about, and mislead their broadcast > engineer readers into thinking they've become experts. > > Well, perhaps it's slightly easier to pick up the first 30% of network > engineering than it is RF engineering, but that last 70% is critical. > > But I don't mean to go off on a </rant> or anything. :-) > > Cheers, > -- jr 'apologies to Fred for the noise' a _______________________________________________ Rivendell-dev mailing list [email protected] http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
