I saw this comment from mlord in another thread and now I'm curious...

Taking a look at the system LoadAvg values from the "Hijack Vitals" screen can be very instructive, especially when music is playing and visuals are active.. the system is often around or above 100% load, contrary to early claims of light loading from the makers.

This is very intriguing to me. I believe early quotes were that (something like) 30% of the CPU was used for decoding, visuals, etc. leaving "plenty of headroom" for user apps and the like. Has this changed? Have new visuals, re-vamped decoding engines, etc. increased the amount of CPU the player app is using? I'd like some input from the Empeg guys mainly, but if anyone's done any side-by-side comparison, that'd be neat to see. I have a 2nd Empeg that I might give a couple of test runs with 1.03, but I wanted to see if anyone has any existing information first.

I was wondering the exact same thing... I remember bragging to people about how it only used 30% of it's "brain"... Normally, this wouldn't matter, but for the people working on 3rd party aps like navigation or GPS...

3rd party aps like navigation or GPS...

.. or Trivia games, or lyrics scrollers... :)

Exactly why I posed the question... I have some personal interest in how much CPU will be available for the stuff I'm working on.

This is very intriguing to me. I believe early quotes were that (something like) 30% of the CPU was used for decoding, visuals, etc. leaving "plenty of headroom" for user apps and the like. Has this changed?

If I understand correctly the player software uses real time scheduling. The result of this is that it grabs basically all available CPU in case it needs it. It may only use 30% of the time it takes, but the rest is wasted. In order to get any significant cpu time another app would need to use the same scheduling method. I don't really understand the details though and I always wondered if it could somehow be set to take a fixed percentage of the CPU leaving some time for other apps. FWIW earlier versions of the player software also kept the load near 100%.

-Mike

I ran d.net back on my Mark 1 with Beta 9c, and again now on 2.0 B7. Here are the numbers I got from running it normally:

Mk1 with no player running - ~250kkeys/s
Mk1 with player running ~ 175kkeys/s
Mk2 with no player running ~277kkeys/s
Mk2 with player running (and visuals, not sure about the Mk1 stat) ~ 100kkeys/s

I think the boost in speed from the Mark 1 to the 2 is just the fact that the client has been revised a few times since then.

To put some perspective on this, the HSX109 has a slightly slower processor than the car player and can rip from CD (without DMA) at the same time as playing audio, streaming to receivers and displaying visuals on a much larger screen - or background encode MP3 files while doing those things.

Rob

Hi Rob.

Ok, but at which priorities / scheduling policies do these other processes run? And you had the chance to optimize their cooperation on both sides: Player as well as its concurrent/parallel tasks, we are only able to influence the behaviour of the add-ons, not that of the player. At least if I see all this right.

cu,
sven

I already caught this info when you guys announced it, but everytime I hear it, I just gotta say "Wow!" You guys kick butt.

Now, to humble myself, what is DMA?

Direct Memory Access

To be more specific-

Direct Memory Access (DMA) is a capability provided by some computer bus architectures that allows data to be sent directly from an attached device (such as a disk drive) to the memory on the computer's motherboard. The microprocessor is freed from involvement with the data transfer, thus speeding up overall computer operation.
Usually a specified portion of memory is designated as an area to be used for direct memory access. In the ISA bus standard, up to 16 megabytes of memory can be addressed for DMA. The EISA and Micro Channel Architecture standards allow access to the full range of memory addresses (assuming they're addressable with 32 bits). Peripheral Component Interconnect accomplishes DMA by using a bus master (with the microprocessor "delegating" I/O control to the PCI controller).

OK, you gonna write up a quick howto for distributed.net? I'd love to have it running and i couldn't find anything in the FAQ.

Would it be doable on a consumer image?

The last notes I have about it applied more to the Mark 1. I might try to dig up my old scripts and put something togther for a Mark 2 player. The biggest problem was needing to write to the drive, I got around it by putting the buffers in a ramdisk, then copying them to the drives from time to time.

With hijack, I should be able to do this on a consumer image, and also have some indication on when it's writing to the drives if so desired. (Though my ultimate wish is to have the d.net cow icon flash in a corner similar to the hard drive icon. I'd need a configurable overlay to tap into, similar to Kit's old clock hack.) I'd like to put togther a small C program to manage everything and to tap into hijack for options, not sure how plausable that is with my skills though.

Hijack has a configurable overlayed graphics facility...

Selective overlay to be able to say "Box, 123,26 to 128,32" and display a graphic in it?

Last time I poked around at the hijack code was 80 or so versions ago, so I guess I should again.

Yeah you can specify a rectangle.

/me goes and pokes at the source for hijack for documentation on this.