ESXI help

[sflamm]

modern drives should be fast enough especially when in a raid 0 or raid 5 config to no longer need 64K blocks. Are you sure that is the issue?

[sflamm]

btw, here is a a quote from the SageTV 7 feature list:

"Removed the need for formatting disks with 64k clusters in order to get optimal disk performance on Windows Previously, we had recommended formatting Windows disks with 64k clusters in order to get optimal recording performance. This is no longer needed due to optimizations in the Windows capture system."

[Skirge01]

I can only go by test results. That was precisely why I didn't bother formatting them to 64k initially. Then, I forgot about that decision during troubleshooting. It'll be a few days before I finish copying the data off, reformatting to 64k, and copying the data back and can fully test the results. Do keep in mind that I'm not using a real RAID setup anywhere and that the hypervisor certainly is adding some overhead to all subsystems; perhaps it's enough to negate the optimizations. Clearly, I'm guessing here, but we'll know soon enough.

[sflamm]

Report back your results please.

I am running a real hardware raid 5 (using Adaptec 3405) with 4 Drives. I do see some delay (spinning) but I dont think it is attributable to the drives or block sizes as the drives read/write at > 100MB/s at steady state.

I have attributed the 'spinning' delay on 'stop' to the time it takes SageTV to stop / breakdown the recording stream. As you said it only happens on 'stop' - which means it isnt really disk related, right? If it was disk related then while watching the stream would stutter - and it is silky smooth for me.

[Skirge01]

Originally Posted by sflamm

Report back your results please.

I am running a real hardware raid 5 (using Adaptec 3405) with 4 Drives. I do see some delay (spinning) but I dont think it is attributable to the drives or block sizes as the drives read/write at > 100MB/s at steady state.

I have attributed the 'spinning' delay on 'stop' to the time it takes SageTV to stop / breakdown the recording stream. As you said it only happens on 'stop' - which means it isnt really disk related, right? If it was disk related then while watching the stream would stutter - and it is silky smooth for me.

Will do. Watching the copying back and forth, I'm getting close to 150MB/s, pretty consistently. Your scenario sounds exactly like mine, but my delay may be longer (~15-30 seconds). Playback has always been perfect. I'm no expert on the technical details, but, obviously, reading and writing still requires disk access in some form. What the hard drive (and Sage) actually needs to do when you stop playback is a complete mystery to me, but with my admittedly limited knowledge, it seems conceivable that it could be faster to do that "mystery stuff" to a multi-GB file with fewer clusters (when using 64k) than if there were exponentially more clusters (when using 4k).

[sflamm]

When it 'stops' SageTV cannot be doing much related to the file. As it has continously been streamed to disk and only needs to the buffer flushed.

I think/guess most of the delays is related to tear down of the video source.

But I look forward to hearing if in fact that makes a difference.

[Skirge01]

Converting to 64k did not resolve the issue. As this is completely OT at this point, I'm going to post a new thread to start some discussions going on how to figure this out.

[sflamm]

Sorry to hear that.

Did you notice any improvement at all? (it would be easy enough for me to convert my media directories to 64K sectors if it did...)

Have you moved up to Java 7? It is a lot faster than Java 6 and I have noticed an improvement:

http://geeknizer.com/java-7-whats-ne...k-1-5-1-6-1-7/

My Windows 8 clients seem faster also than my Windows 7 clients.
I am planning on moving my server to Windows 2012 now that I have managed to separate out my 32-bit firewire tuning into a network encoder server (yay). Windows 2012 should be a lot faster as well.

[Skirge01]

Nope. No change at all. I've got the new thread going so everyone can throw some ideas out there. Back to basics time...