[Matt Riley]

After a hint from posting on Reddit as well… It was… The controller batteries!

The batteries displayed a status of “not charging” so I figured they were shot because they are so old. No big deal, I thought. It knows about the status so it should ignore them or whatever. But, after reading a reply on Reddit, I decided to dig into the cli tool some more and saw it had commands to disable the controller batteries manually. I did so, pressed through the warning and rebooted the RAID and now my writes are 415 MB/sec, which is much closer to what I would expect for a RAID 5 setup (two arrays as R5 on the unit, striped together in macOS Disk Utility).

I’m not going to set the world on fire with new performance benchmarks or anything but at least this makes the unit viable for doing some useful things on a short-term project where I need the storage space.

PS – I did pull one of the drives and put it into a USB dock to test it. The drive did 113 MB/sec RW, which is about what I was expecting from this class of drive. Another clue that the drives weren’t the issue.

PSS – Disable battery command (batteries on both controllers): activeadmin -d <raid.ip> battery disable

[Matt Riley]

Nearly 12 years later this is still good advice. Thank you. 😉

-Matt

[Matt Riley]

Thanks for replying.

The part about deleting the existing BRU PE.app prior to the update commands was the part that escaped me.

So, if the instructions had been:


sudo /usr/bin/true
rm -r /Applications/BRU\ UB/BRU\ PE.app
gunzip -c ~/Downloads/BRU_PE_2.3.8.737_GUI-Only.bgz | sudo bru -xvf - -ua


Then that would’ve avoided some frustration. 🙂

Giving the 2.3.8 version a shot at writing some tapes. Fingers crossed.

-Matt

[Matt Riley]

Okay, so I’ve upgraded my system to Lion so I can properly test Premiere.

The upgrade solved my issues with the Kona card and playback stopping, so that’s a plus. However, I am running into something that I’m not sure if it is a driver/hardware issue or just the fundamental way Premiere works.

Say I have a timeline (1080/24p) and I drop a ProRes file in it that is also 1080/24p. I get a yellow bar above it but playback is fine. On the same timeline, I drop in a clip from a RED EPIC (5K). It also gets a yellow bar but I can’t play the clip back for more than a second or two before it drops frames when the viewer resolution is set to full. If I drop the viewer resolution to half, I can play it back OK but then, of course, my ProRes clip looks nasty because it is also playing back at half resolution. It seems Premiere doesn’t have dynamic resolution playback (like FCP 7). OK.

My system is a year-old 8 core Mac Pro, 16 GB RAM, Kona3, QuadroFX 4800 and a RED Rocket card. I thought I would be able to play pretty much whatever, whenever without rendering but that’s not quite happening.

Also, when I play the RED file back at half resolution, the system’s cores (all 16 of them) are maxed – I didn’t expect to see that much CPU activity, thinking it would leverage the GPU/Rocket more for playback.

Am I missing the magic “go fast” switch somewhere? I have my project set to use the Mercury Engine, so I should be getting some good hardware acceleration with this system, right?

I guess the dream was to not have to make proxy files from 5D and RED source material to offline with like I have to now with FCP 7. I was thinking I’d just be able to edit the native files in real-time in a mixed resolution/format timeline in Premiere and move on with life. No?

-Matt

[Matt Riley]

Yeah, I just heard back from AJA support (they were pretty fast!) and they said the same thing. Grrr.

Time to test Lion with the SAN, I guess. I’ve been dreading this day. 😉

-Matt

[Matt Riley]

It seems that Compressor 3.5 (included in Final Cut Studio 3, or whatever Apple is calling it) remedies the TC issue for me. All of my TC issues were with 24p material.

I think Compressor 3 was interpreting all TC as being 29.97 base and there was no way to change the way it was thinking. This was one of the first things I checked after installing FCS3 and it appears the latest version of Compressor can count TC at 24p.

-Matt

[Matt Riley]

I’m willing to give the DS op. the benefit of the doubt and assume he/she’s a purist (i.e. doesn’t want to work with compressed anything). 😉

As good as ProRes is, it is still a lossy compressed codec. Information is being thrown out somewhere to get that data rate down and eventually that will impact quality, perceived or otherwise.

If I were doing a steep color grade and wanted to ensure I had as much information in the files as possible (which is important for grading as well as compositing) I would almost always try to get an uncompressed codec over a compressed one. The DS op. has no idea how many iterations of ProRes compression the images have gone through. All he/she knows is that if you hand off uncompressed files, the compression stops there (at least as far as the DS op. is concerned).

-Matt

[Matt Riley]

Wow, no DS love here…

Speaking as a former (still sometimes) DS user, I can tell you that for a time, those systems were great. They still are, in many ways, wickedly powerful. Way back when, the DS was ahead of its time and had some interesting ideas of how an all-in-one box should work.

Unfortunately, Avid chose to crap all over its DS customers when it acquired Soft Image. You see, I wouldn’t really classify DS as an Avid product. It wasn’t Avid’s to begin with and it looks/acts very differently from a traditional Avid (Composer, Symphony, etc). DS is the red-headed stepchild that Avid chose to ignore after adoption. They let it languish for too long while the competition continued to improve. That’s part of the reason we moved to Smoke from DS… There have been more updates and added features to Smoke in the year that we’ve owned one than in over five years combined of owning a DS.

DS users very much got the shaft from Avid. They were led to believe (and in some cased outright told) that DS was THE high-end solution from Avid, their flagship product. It was meant to replace the Symphony and much more. I think at the start, Avid really saw the DS as a potential competitor to Flame, and almost certainly Smoke. And there was a time when this could’ve been close to reality. However, instead of innovate and make the DS what it should’ve been, Avid instead caved to pressure of whiny old-school Avid users and attempted to graph a Media Composer interface onto DS. They did this instead of integrating 3D compositing or modeling or any number of other advanced features – and the feature set of DS (and its users) suffered for it.

While Avid was busy letting DS die a slow and painful death, an interesting thing happened: they released a new version of Symphony that used the EXACT SAME Nitris hardware DS users had exclusively for a year or two prior. In effect, Avid was using DS users as beta testers for the new Nitris hardware and then slapped them in the face with a release of a product they were told was dead and that their DS boxes were replacing. It was a sad, sad day at that NAB DS user group meeting when one of the speakers broke the news that Symphony Nitris was being released. I was there and it wasn’t pretty.

Before you knock DS users, understand what some of the die-hards have been through with the system. Before we got a Smoke, I always kept up with the DS user group. It was easily the best user group I’ve ever belonged to. There were a core group of really smart, really dedicated and passionate owner/operators in the group. I’m convinced that if it weren’t for the actions of a few remarkable users in that group the DS would’ve been killed off years ago.

What you might be experiencing is the disgruntled old-school Avid editor who got shoe-horned into running a DS. This caught more than a few companies by surprise: Avid marketing tells you to upgrade to their flagship product (DS) and then you get it and it is NOTHING like the Avid you were used to. That sucks. But you spent so much money on it that you are going to use it, whether you know what you are doing or not.

Long live the DS spirit,
Matt

[Matt Riley]

Good point, Jef.

-Matt

[Matt Riley]

I think there is some confusion here from using the terms “VPN” and “VNC” interchangeably. They are definitely not synonymous.

VPN is Virtual Private Network, which allows remote computers to connect to a host and then have access to the host’s network as if the remote computer were part of the host’s local network. This is what Bob’s original post was referring to (L2TP, no Cisco, etc.) so I’ll assume that’s the kind of access he’s after here.

VNC is Virtual Network Computing. It’s essentially a remote access protocol for viewing and interacting with remote computers as if one had physical access to the computer. To most, it is simply another screen sharing protocol (which is mostly true).

Every version of OS X (client or server) has shipped with a VNC server since, I believe, Tiger (10.4). It might have even been present in 10.3 but I’m not certain. Doesn’t matter. All you need to know is that every modern Mac has VNC capability already built-in by Apple and it is only a check-box away to enable it (10.5 Leopard: System Preferences > Sharing > Remote Management). This enables a VNC server that you can use most VNC clients to connect to and control the Mac’s screen. That VNC client software can be running on another Mac, Linux or Windows as long as it supports the protocol.

VPN, on the other hand, is bundled with every Mac client, but only as client software (i.e. the software portion that lets you connect to VPN hosts/servers). To host a VPN server, you need additional software for OS X client (like the aforementioned iVPN) or you can use OS X Server, which has a VPN server built-in and works quite well. And it is very secure, which is important when dealing with remote access.

So, I think what you really want here, Bob, is to have a combination of both. You want VPN to allow you access to your client’s network and then you want to use VNC to control their screens (very Orwellian!). However, if they are blocking iChat/AIM with a firewall then I highly doubt they are going to let VPN traffic through, either. And yes, setting up a VPN behind a firewall requires certain ports to be forwarded to get through the firewall, which probably involves getting their IT people involved. Opening up a VNC port directly to a computer is a very bad idea as VNC is not encrypted by itself, so it would be unsafe. However, using VPN in conjunction with VNC should make you safe but, like I mentioned, it does take more work that just installing something and pressing the big green GO button.

There are other things you can do as well, such as ssh tunnels. The ssh protocol is very, very flexible and allows you to get into all sorts of situations that drive network administrators nuts. SSH on your client’s side can even be used to circumvent their firewall, which would be good for you but would freak out any competent network admin (the idea of bypassing a security device such as a firewall by making an outgoing tunnel to some person on the Internet should be a cause for concern, if not a full-on geek tantrum).

So, I guess what I’m saying is that you tried a VPN setup once and liked it. It apparently worked pretty seamlessly for you BECAUSE someone on the other end made it easy to use. It just didn’t fall out of the box that way. VPNs require setup, but if it is something you need then it is worth the investment in time and money. Getting your clients to cooperate and share your vision in needing this kind of access to their networks is probably a bigger challenge than setting up the software.

-Matt

PS–OpenVPN might help, but unless I’m mistaken I didn’t see an OS X binary for it. A server running OpenVPN would, I believe, require a different VPN client than what is built into OS X, so that’s another piece of the puzzle to deal with if you go that route.