Okay, I decided to play around with task manager and the “Reliability and Performance monitor” to see what I could find and I think I may have isolated the problem. Jessica, this post will be kind of long I expect, but if you could forward it to the extender team I think we may be a lot closer to fixing it. As “mpickup” suggested I’m pretty sure the problem is in ehshell.exe (someplace in those ~34 threads!) but I think it is more of a CPU problem that a disc I/O problem.
I started with a single 12 minute video clip encoded at 2 pass 10mbit/sec average VBR with windows media encoder (I mentioned this profile in the previous post). This was originally DV camcorder video so it is 720x480. This clip has a “glitch” at precisely 8 minutes 15 seconds every single time it is played through the 360 MCE interface. I decided to play this clip 3 different ways and watch the CPU usage and I/O rates coming off disk and going over the network. The first way was locally on the Vista machine through Windows Media Player. The second way was streamed to the 360 through the dashboard media connect interface. Lastly, of course, was the problematic streaming to the 360 through MCE.
In all three cases the I/O rates off disc looked appropriate averaging ~10mbit/sec over the whole clip but rising to nearly 16 mbit/sec for around 60 seconds in the area of the glitch (the glitch is roughly centered in this area). There is fast motion in this area (kids on a merry-go-round) so that’s expected with VBR. The two streaming cases saw the same data rate across the network. Ehshell.exe seems to be doing 10-50 disc IOs/sec during the MCE case – that may be just fine I expect. The problem is with CPU usage:
2.4 Ghz Core 2 Duo (Intel E6600) - Vista Ultimate (32 bit)
Avg. CPU % CPU % near 3 second glitch/freeze area
Local WMP playback 10% 13% (mostly in mfpmp.exe)
360 stream from dashboard 4% 5% (mostly in wmpnetwk.exe)
360 stream from Vista MCE 20% 40% (all in ehshell.exe)
Check out those numbers. It takes several times the CPU power to stream that data to the 360 MCE extender as it does to decode and play it back locally! That’s wacky. The CPU numbers to stream to the 360 dashboard seem fairly reasonable and there is never any glitch with this path (or local playback of course). Things then get even stranger.
After I hit the glitch point at 8:15 into the video the CPU number slowly drops until around 9 minutes it is now down to < 2% yet the data rate is still at or above 10 mbits/sec. The CPU stays at 2% until the video ends. Now at the MCE interface on the 360 I have the 3 options DONE, RESTART, or DELETE. If I choose RESTART right there the video replays again streaming the same data rate off disc and across the network as before but the CPU usage in ehshell.exe stays at 2% for the whole video – needless to say there is no glitch. But if I do *anything* else in the MCE U/I like click DONE and then restart the video, then it’s back to 20-40% CPU usage in ehshell.exe and the glitch returns. Wacky huh? The 2% CPU number sounds about right for simply grabbing 1-2mbytes/sec data off my SATA-2 disc and shunting it to the gigabit network port – this should take very little CPU. And it looks like in certain cases ehshell.exe is capable of doing this. But usually it takes 10+ times as much CPU to accomplish the same task. I did try changing the priority of ehshell.exe from “above normal” to “high” but this didn’t fix the problem.
If someone figures out where that mystery CPU power is being wasted in ehshell.exe, I’ll bet you’ll have solved this problem for everybody.
Jessica, please let us know what the extender team thinks of this and let me know if I can provide any more details.
Thanks again!