It gets more interesting...

All's still basically well, however, it seems as though there's something truly funky going on with Ableton Live 6 (6.0.3). The project I was having most problems with before is behaving in a similar way -- not as bad, but nowhere near as good as a new project. So apparently, some sort of corruption is possible with Live projects. I'm not necessarily surprised, as lots of x.0.x apps have bugs, but it's a little worrying...

On another, related note. I've got the old problem of a laptop with only 1 firewire port, but having to connect a fw drive AND a fw interface. Now, I've run it with the usb 2 port on the case, and it's basically been okay, but I decided to try out the idea of a shared volume. I went through the tedious process of setting up an NFS share on my G5, and automounting it on the Macbook. It works, but I do get the occasional pop, particularly with a newly-loaded articulation. Any thoughts, anybody? It's being shared over a gigabit switch, and the G5 and Macbook, of course, both have gigabit interfaces. Does anyone know if there's any way to optimize such a system?

thanks,

J.

...in case cm pops his head in here...

ifconfig on the G5 reads (for the relevant port and info):
"media: autoselect (1000baseT <full-duplex>[;)] status: active"

which sounds about as good as I'm gonna get...

I'm assuming NFS is faster for this than AFP, but is there another option?

J.

jbm, I've read this with great interest and thanks. Tell me, am I right to assume that a "full erase" means only the system drive and not the VI data drives, which I were likely on externals drives? Whoo boy, rebuilding VI loads would probably take me more than a day.

Also, did you initially re-format with whichever latest OSX you had on on disk and then use downloaded upgrades? I'm assuming that the latest OSX update isn't available on disk. And if you incrementally built back up to date, I'm wondering why (if it ever was the upgrading) the degraded performance didn't re-occur.

You are definitely stoking the "start from scratch" instinct in me. But I'd have to bring up my computer housekeeping first.

Hey Plowman,

Yeah, just the system drive. I thought about wiping the data drive, but the VIs were the first things on there, so there's no way they could be fragmented.

I reformatted from the Tiger installer DVD. The nice thing about this whole process, and I suspect what might have fixed the problem, is that there were no incremental upgrades at all -- just straight from 10.4.0 to 10.4.8 (yes, I actually have a 10.4.0 disk!), using the 10.4.8 Combined. Mind you, I used Software Update -- I didn't download anything independently. I really feel like something evil happened somewhere in the 10.4.2 to 10.4.6 range -- I remember some of those incremental upgrades were only out for a couple of months, which isn't a great sign, IMO. Anyway, it's definitely a whole lot better. I have to figure out the issue with Live, though. I don't use it that much, but for certain projects it offers a really refreshing approach. We'll see. Kid gloves, for the time being... I don't want to just mess it up again.

J.

jbm, not sure now why you decided to use an NFS share instead *nomal* filesharing (of course not using AFP over apple talk but simply TCP/IP).
unfortunately the last occasion i've mounted an NFS share is some time ago and was between W2K and IRIX (which is generally not the best combination) but what i've noticed (and heard from current NFS shares on OS X too) the performance is ... modest.
i'm certain your gigabit connection is not the bottleneck - AFP (over apple talk), SMB and NFS are handy protocols to share data, but not well known for great performance ... besides permissions are handled on a per-user basis instead of using file-permissions with these protocols.

maybe you can track the issue comparing CPU load for a defined data-transfer (>10 GB) using NFS vs. TCP/IP, compare performance using a few large files vs. many small files ... you may run into the well-known streaming vs. caching issue here
christian

@Another User said:

maybe you can track the issue comparing CPU load for a defined data-transfer (>10 GB) using NFS vs. TCP/IP, compare performance using a few large files vs. many small files ... you may run into the well-known streaming vs. caching issue here
christian

Yeah, I'll try to do a more definitive test -- I suppose it could help others decide which to use in future. Just out of curiousity, is the .dat file streamed over the network as one big file, or many small files? I guess that may be a stupid question, but it certainly appears to us as one big file... (though, in sample terms, it would be many small ones)

cheers,

J.

OUCH!

cm, I'm glad you recommended this test... I didn't even bother letting NFS finish!

Just rough figures:

AFP - single 9 GB .dmg file: 05:24.27 - ave. process cpu 28%, fluctuation approx. 3%

NFS - single 9 GB .dmg file: approx. 8 min - CPU cumulative % for 6 processes around 40%

Holy smokes! I guess the NFS sharing is just handy for mixed environments, yes? Anyway, one thing that was interesting is that there are 6 nfsd processes, vs. 1 AppleFileSharing process, which I thought would be a bonus, but I don't really know why when I look at the actual numbers.

Also, on the AFP side, a 9 GB folder of samples copied at 05:29.27, which was to be expected. The CPU was around 30% on average, but the fluctuation was quite high, jumping from 25% right up to 35%. Not a tremendous surprise, but kind of interesting anyway.

So, I'm obviously going back to regular old AFP.

Thanks for the heads-up!

J.

jbm, since Vienna Instruments Player uses streaming (like exs also does) only small portions of a file are requested from a file on the disk. remember even exs calls only a portion from a wav-file.
this brings up the question of streaming vs. caching - as i've already pointed out in another context (RAID) caching behaviour of a drive is important, and it is similar with file-access by the operating system: how are portions of a file cached at which location in the stream of bytes (harddisk - hosting filesystem - network-driver, network-interface - guest-filesystem - streaming software).
so if a filesystem (or connection) does not allow efficiently *grabbing through* and requesting (and receiving) only a defined number of bytes this does affect performance probably more than anything else.
christian

update.

As I get back into the flow of things, I'm finding I'm running into the old performance problems again... I just don't get it. Too frustrating. I'm going to dump this machine later this year, but I don't want to do it until PCIe 2, and new RAM, and so on, and so on...

I'm looking into building another slave instead. So, I'll scan the forum for tips on how to build the ultimate VI Frankenbox. Any suggestions welcome.

Sorry for the false hopes, Plowman... it doesn't look like I really cured it at all. Just a blip of blue sky behind the clouds. Ouch. I'm totally stumped. And I'm also giving up, after 8 months of torture. Enough.

J.

I just wanted to pop in a quick update on this, mostly for Plowman's sake (a fellow original G5 dual 1.8 owner).

A couple of days ago I decided to do another clean install, but this time to a new drive. The idea this time was to make a totally dedicated audio boot, not an account, but a boot. I did a lot of searching around for 10.48 reports and found a *lot* of people having problems. So, I partitioned my drive into two equal partitions - one for audio only and one for graphics, web design, and general crap - and installed a new system to the audio partition. I downloaded and ran *only* the 10.4.7 combo updater, then did all the updates. I re-installed only my essential audio apps. And yes, I am back to the snappy system that prompted the original "like a new machine" comment. Victory!

Unfortunately, without going through installing all those extra apps one at a time, I will probably never know what exactly brought the system down. But I will note that the one thing that made me absolutely certain that something was *very* wrong is that when playing back audio files from the Finder, using the Preview column, i would get a delay of around 700 ms before playback would start. This was also the case for locating to different points in the file (still in Finder) and for iTunes as well. So, Plowman, if your system is doing this then you probably have the same issue, conflict, whatever, that I had. I wish I could tell you what particular app brought the system down, but I can tell you this it appears *not* to have been an audio app.

cheers,

J.