[Steve Modica]

Try this:

Create a new account on the system and login to it. Then try. The new account will have clean preferences.
If that works, go back to the old account and delete all the Aja prefs and try again. If it fails, you know you have a systemic problem like a driver issue.

Steve

Steve Modica
CTO, Small Tree Communications

[Steve Modica]

[James Bayliss-Smith] ”
[Steve Modica] “I’d find the disk utility process using ps and get its PID. Then dtruss it:”

Any chance of explaining this in plain english? Cheers”

Sorry.

If you run ps -ef in a terminal you’ll see a list of running processes. One of them will be the disk utility:

502 774 167 0 10:39AM ?? 0:00.43 /Applications/Utilities/Disk Utility.app/Contents/MacOS/Disk Utility -psn_0_421991

In my case, it’s Process ID (PID) is 774.

I can see what this guy is doing using one of the most powerful tools invented for operating system debugging. It’s called dtrace and Apple had the foresight to port it to OS X (from Solaris).

“dtruss” is a script that uses dtrace to capture data about processes like the old “truss” command from BSD.

So you would run this (using my example):

sudo dtruss -p 774 (replace 774 with the correct PID for your disk utility).

You’ll see a lot of stuff like this:

psynch_mutexdrop(0x7FFEE40CB4D0, 0x1A4303, 0x1A4200) = 0 0
psynch_mutexwait(0x7FFEE40CB4D0, 0x1A4403, 0x1A4200) = 1721347 0
psynch_mutexdrop(0x7FFEE40CB4D0, 0x1A4503, 0x1A4400) = 0 0
psynch_mutexwait(0x7FFF77055558, 0xB4303, 0xB4100) = 738051 0
geteuid(0x10655BF00, 0x0, 0x10655C058) = 502 0
geteuid(0x7FFF77FF8848, 0x7FFF8F0D8A82, 0xFFFFFFFF) = 502 0
psynch_mutexwait(0x7FFEE40CB4D0, 0x1A4B03, 0x1A4900) = 1723139 0
psynch_mutexdrop(0x7FFEE40CB4D0, 0x1A4C03, 0x1A4B00) = 0 0
geteuid(0x7FFEE8939770, 0xA0, 0x7) = 502 0
open(“/Library/Preferences/SystemConfiguration/preferences.plist\0”, 0x0, 0x1A4) = 10 0
close(0xA) = 0 0
open(“/Library/Preferences/SystemConfiguration/preferences.plist\0”, 0x0, 0x1A4) = 10 0
fstat64(0xA, 0x10655BE70, 0x0) = 0 0
read(0xA, “<?xml version=\”1.0\” encoding=\”UTF-8\”?>\n<!DOCTYPE plist PUBLIC \”-//Apple//DTD PLIST 1.0//EN\” \”https://www.apple.com/DTDs/PropertyList-1.0.dtd\”>\n\n\n\tCurrentSet\n\t/Sets/FF7F8FB9-4B14-469D-8D56-BF59150944B4\n\t”, 0x377B) = 14203 0
close(0xA) = 0 0
__sysctl(0x10655BA58, 0x2, 0x10655BA60) = 0 0
__sysctl(0x10655BAF8, 0x2, 0x10655BB00) = 0 0
psynch_mutexdrop(0x7FFF77055198, 0x6FE03, 0x6FD00) = 0 0

All that psynch stuff is the app sitting around waiting for you to do something.

When you click “erase” or repartition or whatever, a bunch of system calls will spit out (similar to the open/read/close stuff you see above). It’ll be interesting to see what it’s trying to do and why it fails.

If you absolutely know the disk is going to be erased and you don’t care, you could do this too:

Select the disk in disk utility and click the info button (not the partition but the disk).
Look at the “Disk Identifier”. On my backup drive, it’s “disk1”. That’s the device file that is used to talk to the disk.

I could manually overwrite this like so:

$ sudo dd if=/dev/zero of=/dev/disk1 count=10000 bs=1m

This will write 10GB of zeros over the front portion of the disk and should wipe out the partition table. Then the disk won’t be recognized anymore and you can reinitialize it.

Steve

Steve Modica
CTO, Small Tree Communications

[Steve Modica]

The main difference between the two is the “real-time” requirement of video apps.

IT infrastructures tend to focus on redundancy. Then the system is loaded heavily, performance will be slower, but it still “working”

Video servers need to push video streams in realtime. The drives matter, the raid controller matters, how the network is setup matters. If you don’t have it all correct, it won’t work.

Some key elements:

Drives and raids can’t retry too much. If there are tons of retries, the drive needs replacing
Networks have to be lossless. You need flow control so TCP isn’t dropping packets (this is often incompatible with larger edge/core network configurations)
Machines need to be tuned for optimal performance. Your desktop/laptop isn’t set up to push or pull data over a 10Gb port. They are setup for GUI response (so the mouse is smooth) and having lots of applications open. To really drive a 10Gb port in either direction, there’s some kernel tuning required.

I’m not sure this is documented anywhere, but we sure focus on it! 🙂

Steve

Steve Modica
CTO, Small Tree Communications

[Steve Modica]

[John Davidson] “I’d like to add additional users to a computer that accesses our NAS through the Peg 6 in a mac-mini server. I just need to set up each user the same way, with the same login into the server system, right? Or does accessing the NAS through one login apply to all users of the same computer? Would each user on the same computer need it’s own login into the NAS server? That would result in a ridiculous amount of users added….”

GACK! I’m sorry I didn’t see this.

I’ve generally advised people to have multiple user accounts on the server for each user or workstation. The issue we ran into in the past was that people would assign one user to everyone and a single workspace. People would connect with FCP 7 and assign that workspace as their scratch disks. FCP 7 creates a ton of temp files in that directory to track its state. These files are not well named. They are not uniquely named.

The result of this was FCP 7 would do weird things like save files in the wrong format and crash. This is because other sessions were overwriting previous session’s temp files.

I think if you assure that you aren’t going to run into this particular issue, you can get away with a single user, but you have to be careful.

One model I’m starting to like more and more is the sparse disk image model. It works well over a NAS, and it works with Avid and FCPX. You create a large (2TB) disk image on the shared storage, double click to mount it local, and BOOM, you have protected, volume locked space that the apps see as local. With Avid, you can do AMA volumes for the media.

Anyhow, I’m really sorry I didn’t see this sooner.

Steve Modica
CTO, Small Tree Communications

[Steve Modica]

That’s about right. I would expect 2 drives striped to max out at around 100MB/sec (minus overhead for parity and the bus). So 1MB in 10msec sounds right to me.

Steve Modica
CTO, Small Tree Communications

[Steve Modica]

[Thomas Morter-Laing] “10024 501 1998 W 318081566 1048576 DiskSpeedTest ??/G-RAID 001/DiskSpeedTestTemp
and
10155 501 1998 R 317863890 286720 DiskSpeedTest ??/G-RAID 001/DiskSpeedTestTemp”

This says that it takes about 10msec for an IO. These IOs are roughly 1MB and 256K. 10msec for 1MB isn’t fast enough for uncompressed stuff, but it’s OK for Pro Res. If all the IOs are 1MB, that’s not usually very efficient (although it depends on your raids stripe size). We aim for 4MB.

Obviously one or two IOs isn’t going to break a stream (the app reads ahead), but if you see a lot of smaller IOs that take 10msec, that’s not a good thing. As you might imagine, doing a 4MB IO isn’t going to take 40msec. It might finish in 16msec. That would mean roughly 4msec per MB instead of 10msec.

Steve

Steve Modica
CTO, Small Tree Communications

[Steve Modica]

I wouldn’t worry about things like this. Those are little configuration file touches. There’s nothing going on there.

I’d run this while your benchmark app is running. Then you’ll see some much larger time numbers and you can compare.

Steve Modica
CTO, Small Tree Communications

[Steve Modica]

[Thomas Morter-Laing] “when you run “iosnoop -D” (I had to run mine as sudo to allow it to work), how the heck am I supposed to make sense of the mountains of writing which happens after?”

DELTA UID PID D BLOCK SIZE COMM PATHNAME
218 0 83 W 434557744 4096 mds ??/68CF91E8/tmp.spotlight.state

This little snippet is the header that’s printed along with one line of output. I trimmed the file path down a little to fit.

“DELTA” is the time it took to complete the IO. This is measured from the disk driver strategy routine to the driver interrupt routine (a very good indicator of the hardware speed). So this IO took 218 usec. The IO was issued by root (UID 0) and by process id 83 (mds daemon). It was a write command (“w”) and it was 4096 bytes long.

If you start up an actual playout (or an IO benchmark) you can watch a little of this to get some idea if the disks are performing as you would expect.

For example, you would like to see all the IOs be very quick and about the same duration (give or take). If you see some jump way up, you might have a problem. It’s easy to dump iosnoop’s output into a file (iosnoop -D > filename) and then sort it later with “sort” to see if some IOs were really long.

iosnoop is part of the dtrace toolkit. It’s eztremely useful and it’s amazing that Apple ported it into MaC OS. That was huge.

Steve

Steve Modica
CTO, Small Tree Communications

[Steve Modica]

I’d get a new one. I have the same laptop as you and I’m starting to consider it.
Upgrading the disks is good and SSDs will go much much faster (and the heat won’t be an issue), but your GFX card is old and won’t support the newer GPU offload stuff in Adobe.

The newer Ivy Bridge CPU also pulls in the Northbridge IO, so that’s all sped up. The last time a major architecture like this happened was with Nehelam and Westemere. It was a huge leap in network performance for Small Tree. I think you’ll see similar gains with Ivy Bridge

Steve

Steve Modica
CTO, Small Tree Communications

[Steve Modica]

open a terminal and run the following:

$ sudo tail -f /var/log/kernel.log

Try to partition the drive again as HFS/journaled. I’m guessing something useful will pop out on the terminal.
When done, hit control-C in the terminal and post the messages.

Steve

Steve Modica
CTO, Small Tree Communications