Looking For Significantly-Faster Setup

Windows XP Pro SP3
EP45-UD3L with 4 gigs
Intel Quad CPU Q8400 @2.66GHz

With a media server and a 4 security cameras hanging on this
thing, it is about maxed out: 80-100% CPU usage.

The Question:

Is there anything I can do to get, say, 20+ percent more
horsepower?

I'm willing to buy a new mobo/CPU if the cost isn't crazy-high.
--
Pete Cresswell

(PeteCresswell) wrote:
> Windows XP Pro SP3
> EP45-UD3L with 4 gigs
> Intel Quad CPU Q8400 @2.66GHz
>
> With a media server and a 4 security cameras hanging on this
> thing, it is about maxed out: 80-100% CPU usage.
>
> The Question:
>
> Is there anything I can do to get, say, 20+ percent more
> horsepower?
>
> I'm willing to buy a new mobo/CPU if the cost isn't crazy-high.

Are you using a BT848/BT878 capture card with uncompressed
data capture on this thing, for the cameras ?

Perhaps you're capturing around 20MB/sec from a camera, then
compressing to MPEG in software ? That could smother a processor.

If the cameras produce their own MPEG compressed streams of some
sort, that might be written out to disk with fairly
light CPU loading.

If you had incoming MPEG, and were doing scene extraction and
searching for "activity", that too might chew up the cycles.

*******

The Gigabyte page lists compatible processors for your LGA775.

http://www.gigabyte.com/support-down....aspx?pid=3285

For a ridiculous sum, you could get 3.2GHz. 3.2/2.66 = 1.2x
That just barely meets your objective, without changing motherboards.

Intel Core2 Extreme QX9770 3.20GHz 12MB Yorkfield 45nm C0 135W 1600 F2

But for the price of one of those processors, you might be able to buy a
2600K and new motherboard and new RAM, for less. 4GB of DDR3 RAM now,
costs close to zero. A 2600K is around $330.

2600K 3.4GHz
http://www.newegg.com/Product/Produc...82E16819115070

Motherboard (picked to be similar in brand to your current one) ~$150
You should sort through the LGA1155 ones, to find one with a
good rep. You could probably spend up to $400 or so, for a bunch
of gizmos you don't need, or look for one that has reasonably
good reviews.

http://www.newegg.com/Product/Produc...82E16813128512

But before doing that, I'd want to review what features you need
from the cameras, and whether the current setup is optimal. It's
possible another piece of software, would remove the need
to upgrade the processor.

Paul

Per Paul:
>Are you using a BT848/BT878 capture card with uncompressed
>data capture on this thing, for the cameras ?
>
>Perhaps you're capturing around 20MB/sec from a camera, then
>compressing to MPEG in software ? That could smother a processor.
>
>If the cameras produce their own MPEG compressed streams of some
>sort, that might be written out to disk with fairly
>light CPU loading.
>
>If you had incoming MPEG, and were doing scene extraction and
>searching for "activity", that too might chew up the cycles.

I know next to nothing about surveillance cam stuff. Basically
I'm fooling around with 4 cameras trying to learn enough to set
up a surfcam for a guy who owns a windsurfing shop down on a
local bay.

What I do know, though, is that these are IP cams. One of them
is sending h.264 and the other two are doing MJPEG.
--
Pete Cresswell

Per Paul:
>
>But before doing that, I'd want to review what features you need
>from the cameras, and whether the current setup is optimal. It's
>possible another piece of software, would remove the need
>to upgrade the processor.

Sounds to me like I should drop this for now.

To wit:

- What I was trolling for was some super-new development
in mobos/CPUs that rendered my current setup obsolete.

Sounds like that hasn't happened and isn't about to
happen soon.


- The camera thing is dynamic. I'm just experimenting
and that won't be forever. The immediate issue is
butting heads with the media server as it records TV
shows. But that's not exactly a big deal, since
cameras can be selective shut down anytime... and even
on a schedule.


- The muy-expensivo upgrade cited for only 20% could probably
be compared unfavorably with the additional electricity
cost of just putting another PC online 24-7 to handle
the cameras.

In round approximate numbers: .18/KwHr.... 120 watts for a
second 24-7 PC...
((120 * 24) / 1000) * .18 = approx fifty cents a day...
365 days.... $180 per year...

--
Pete Cresswell

(PeteCresswell) wrote:
> Per Paul:
>> Are you using a BT848/BT878 capture card with uncompressed
>> data capture on this thing, for the cameras ?
>>
>> Perhaps you're capturing around 20MB/sec from a camera, then
>> compressing to MPEG in software ? That could smother a processor.
>>
>> If the cameras produce their own MPEG compressed streams of some
>> sort, that might be written out to disk with fairly
>> light CPU loading.
>>
>> If you had incoming MPEG, and were doing scene extraction and
>> searching for "activity", that too might chew up the cycles.
>
> I know next to nothing about surveillance cam stuff. Basically
> I'm fooling around with 4 cameras trying to learn enough to set
> up a surfcam for a guy who owns a windsurfing shop down on a
> local bay.
>
> What I do know, though, is that these are IP cams. One of them
> is sending h.264 and the other two are doing MJPEG.

I bet if you record the streams, without "previewing" them, the
load would go down. But you already know that.

*******

With the BT878, and a non-IP camera, I can preview "for free". (The image
comes across the PCI bus, in uncompressed form.) Because the feed on
my camera isn't compressed, the preview doesn't cost anything,
while the recording side does cost me something. Whereas, with the IP
camera, the recording is free, while preview or playback require
decompression (and CPU cycles).

There are a number of options for video playback. You can use
a software decoder (and CPU cycles). For some video standards,
a new video card can decode virtually the whole stream, leaving
little for the CPU to do. The video decoder in a video card,
is a dedicated logic block. While the programmable
shaders, can be used for additional things. The computer
actually has a few tricks up its sleeve, if you have the
right software to harness it.

The 2600K processor, has enough internal horsepower, to decode
five video streams at the same time, while using zero CPU cycles.
That is done via the GPU built into the processor. The only caveat
with that feature, is the GPU can only be used, if the processor
is fooled into thinking you're actually using the GPU for driving
the screen. The Z68 chipset/motherboard, for example, has DVI and HDMI
connectors on the back, and is an example of a way to convince
the software to allow you to use the 2600K GPU for functions like that.
This feature is a gimmick, in the sense that you may need to find
a brand new program, to make use of it. A lot of these acceleration
features, if you own some older software, there may be no way to
get the acceleration to be harnessed by the program.

Even the little things can help. Video cards, for a number of years,
have had IDCT (inverse discrete cosine transform), which can help
with video decompression during playback. But the dedicated video
block in the video card now, can do the whole thing, and IDCT ends
up less used, because of the even better options available instead.

The format most likely to benefit from stuff like this, is the
H.264. I'm not sure what would help with MJPEG. The decoding
functions tend to focus on things used for commercial movies,
and not every format ends up accelerated (which is a shame).

Paul

Per Paul:
>
>I bet if you record the streams, without "previewing" them, the
>load would go down. But you already know that.

I'm using a utility called "BlueIris" which, I guess, is
continually previewing them looking for motion to trigger
recording.

Disabling cams one-by-one, I see that the biggest load comes from
an EdiMax 1280x1024 that is sending MJPEG.

The two FosCams at 640x480/MJPEG aren't nearly as intensive.

Neither is the SONY SNC-CH260 that's sending 1920x1080 at h.264.

Interesting stuff.

I guess the end game for lots of cameras without a lot of
dedicated computing power is figuring out how to use each
camera's built-in motion detection and built-in ability to write
to a LAN drive.
--
Pete Cresswell

Per Paul:
>There are a number of options for video playback. You can use
>a software decoder (and CPU cycles). For some video standards,
>a new video card can decode virtually the whole stream, leaving
>little for the CPU to do. The video decoder in a video card,
>is a dedicated logic block. While the programmable
>shaders, can be used for additional things. The computer
>actually has a few tricks up its sleeve, if you have the
>right software to harness it.

I'm still trying to digest this part.....

So far, I've got "the right new video card = somebody to take
over the decoding task"....

Next thing I have is that, when buying multiple IP cams, h.264 is
the way to go.
--
Pete Cresswell

(PeteCresswell) wrote:
> Per Paul:
>> There are a number of options for video playback. You can use
>> a software decoder (and CPU cycles). For some video standards,
>> a new video card can decode virtually the whole stream, leaving
>> little for the CPU to do. The video decoder in a video card,
>> is a dedicated logic block. While the programmable
>> shaders, can be used for additional things. The computer
>> actually has a few tricks up its sleeve, if you have the
>> right software to harness it.
>
> I'm still trying to digest this part.....
>
> So far, I've got "the right new video card = somebody to take
> over the decoding task"....
>
> Next thing I have is that, when buying multiple IP cams, h.264 is
> the way to go.

The point is, there are other computing resources in your computer,
besides the CPU. The video card GPU has programmable shaders, as
well as a dedicated video decoder (can do H.264). The video decoder
seems to be fixed function, so you wouldn't expect an MJPEG acceleration
feature to show up unannounced in a driver update.

The programmable shaders can function to add processing power to your
computer. An example, is BitCoin mining, which is a math function
involving SHA256 hashing. The most expensive video card has a rating
of around 600, compared to a $1000 processor being able to do about 20
in equivalent units. So about a factor of 30x the performance. But
a programmable shader, would have a simplified instruction set, and
there are also going to be situations where not much of its power
can be brought to bear. In this example of computing SHA256 on small
messages, the problem is almost infinitely scalable, as each computation
is independent of its neighbor (mainly compute bound, with little I/O).
A good video card has 2048 programmable shaders inside it, compared
to the 4 or 8 cores in the CPU. Massive parallelism only works, if
the job can be sub-divided over many computing devices.

The trick with all of this, is how do you harness it in your own system ?
Windows video CODECS (coder/decoder) are arranged in a decoding tree,
when a decoding job needs to be done. Graphedit is a tool for looking
at such trees. But I wouldn't expect to find ready-made CODECs you could
install, which would offload your CPU and magically fix this.

If you were writing your own code, there would be many more possibilities
for unloading the CPU, yet being able to record all the streams.

Older video cards, aren't nearly as useful in this regard. The video
card I've got, is a non-starter, so I can't play with this stuff. A
modern low end card might have 80 programmable shaders, and at least allow
using the SDK (software development kit) provided by the manufacturer.
(You can play with code, even on cheaper cards.)

Even some of AMDs high end processors can participate. The AMD Llano
has a GPU inside the processor chip, with 400 programmable shaders running
at a lower speed than on a video card. So even a motherboard with one
of those processors, can do GPGPU computing, without a video card
being present. (With AMD, their library is OpenCL, while with NVidia,
the library is CUDA. So separate development paths for things like
SDKs if you were a programmer.)

Many programming problems, can't be broken down into 2048 pieces, for
a large speedup. For example, when post-processing movie output from
a video editor, some of these things when run through the GPGPU method,
get a 3x speedup, which is still worthwhile, but not awe inspiring. There
are also examples, where a computing algorithm is loaded onto programmable
shaders in a video card, and runs slower than a CPU based algorithm.
On average, hardly any problems see 30x speedup. It's like winning the
lottery when it happens.

Even if you only have a CPU to work with, some software decoders work
better than others. Not many software developers spend the time to
optimize stuff like this, perhaps rewrite the decoding loop in assembler.
And it's much easier to get an extra 20% by fixing the code, than
by buying another CPU for the machine. Well written packages, will detect
the CPU type, and use different code for each CPU.

Paul

PeteCresswell wrote:> Sounds to me like I should drop this for now.
>
> To wit:
>
> - What I was trolling for was some super-new development
> in mobos/CPUs that rendered my current setup obsolete.
>
> Sounds like that hasn't happened and isn't about to
> happen soon.
>
>
> - The camera thing is dynamic. I'm just experimenting
> and that won't be forever. The immediate issue is
> butting heads with the media server as it records TV
> shows. But that's not exactly a big deal, since
> cameras can be selective shut down anytime... and even
> on a schedule.
>
>
> - The muy-expensivo upgrade cited for only 20% could probably
> be compared unfavorably with the additional electricity
> cost of just putting another PC online 24-7 to handle
> the cameras.
>
> In round approximate numbers: .18/KwHr.... 120 watts for a
> second 24-7 PC...
> ((120 * 24) / 1000) * .18 = approx fifty cents a day...
> 365 days.... $180 per year...

That Q8400 can be overclocked to 400 x 8 = 3.2 GHz with a decent
cpu cooler and willing RAM. That'd probably give you your 20%.
Otherwise, maybe replace the least efficient camera?

I had a Q9550 overclocked to 3.4 GHz which I handed-down to my son
in favor of a new Z68 + 2600K system. I notice zero difference in my
media encoding and occasional DVD shrinking, but the new system is
much more power efficient.