-
Tony Silanskas problem, and “doing it yourself”
Hi –
not that far down, is a thread about a stuttering Maxx Digital Final Share system that is based on Gigabit ethernet. The “pro” that was hired to upgrade the system ultimately said “aah, this is a piece of crap, you should buy a Fibre system – ethernet shared storage doesnt’ really work” –These were the problems that were created –
1) the “pro” daisy chained a non compatible SAS/SATA drive array to the Maxx Digital array.2) the “pro” attached many other ethernet products to the dedicated shared storage switch, which was operating at a Jumbo Frame rate, along with all the editing systems. Specifically, he attached a Cache-A Prime, and a Final Cut Server system (which operate at a standard ethernet frame rate) to the shared storage switch (which operate at jumbo frames). All of this interfered with the operation of the shared storage system. This was resolved by simply moving this equipment onto an inexpensive dedicated switch for ethernet port 1.
3) Apple QMaster was turned on, on all FCP edit systems. You can’t do that in an ethernet shared storage enviorment.
4) The Media drive arrays (the SATA arrays) had corrupt data on them. By running Disk Utility repair disk, and ultimately Disk Warrior on one problematic drive volume, all the “lockups” went away.
5) because this was a busy company, and I was not willing to work at 2am, it took almost a week for them to allow me to run Disk Warrior on the drive volume (13.5 TB of Media on a 16TB drive array).
And every day, they kept complaining that their system kept crashing, yet would not let me resolve their problem.MORAL – it is very easy for people to say that you must have Fibre for a HD shared storage enviornment, and that ethernet simply does not work”. This is absolute nonsense – if you hire a qualified person who is famiiar with the equipment, it works just fine.
Perfect for ProRes422 and ProRes422HQMaxx Digital’
Small Tree
Apace Systems
EditShare
SNS iSCSI
AVID Unity ISIS 5000Bob Zelin
-
4 Replies
-
3) Apple QMaster was turned on, on all FCP edit systems. You can’t do that in an ethernet shared storage enviorment.
Hi Bob, can you explain why it is not advised to use QMaster in an ethernet shared storage environment?
The only reason I ask is that we have a number of laptops connected over ethernet by MetaLAN to a MetaSAN server. All of these laptops have QMaster enabled and are fortunately not exhibiting any problems, but I would be keen to know what might happen if this doesn’t change.
Thank you.
-
Tom,
Qmaster is a “shared rendering” program. It “harnesses” the entire available pool of CPU’s to split up the rendering chores amongst many computers. This is an EXTREMELY bandwidth intensive activity. Therefore, if you’re trying to edit simultaneously while distributing renders, as Bob says, “You will fail!”.
So, having QMaster enabled isn’t the problem. It’s using it to render while trying to edit that sucks up all your bandwidth and causes dropped frames. In your case, do an experiment. Send an hour long file via QMaster to compressor for distributed rendering, and THEN have your whole team try to edit. Let us know what happens.
Mark
-
Mark said it all.
Bob Zelin
-
I’ve noticed that the qmaster daemon is pretty chatty. When we’re looking at problem tcpdumps and kernel.log files, we can usually spot qmaster right away.
Steve Modica
CTO, Small Tree Communications
Reply to this Discussion! Login or Sign Up