Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MythTV: build or RPM?



David Kramer wrote:
> I don't know how I can be overestimating the cost.  Several hundred
> watts 24/7 is a lot of electricity. 

According to:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2889&p=2

which lists power consumption for a variety of modern systems, I'd 
expect an older Athlon XP system to be not much worse, so around 150 W 
while idle.

According to:
http://www.nstaronline.com/residential/account_services/rates_tariffs/basic_service.asp
http://www.nationalgridus.com/masselectric/home/rates/4_default.asp

current electric rates are about $0.12 KW/h.

0.150 KW * 24 h * $0.12 = $0.43/day or about $12 every 4 weeks. Not 
trivial, but it also may not be too expensive, depending on the time and 
effort required for the alternatives.


> I have a PVR-350, so the transcoding/compression/whatever is happening
> on the card, and not taking CPU power.

I was aware of that (you've mentioned it before). You may still want to 
do transcoding, as the PVR cards produce MPEG2, which is substantially 
less space efficient than MPEG4. This transcoding can be done 
non-real-time at a low priority, but will still chew up some CPU that 
may or may not be available on a multi-use machine.


> My CPU (an Athlon XP 2400+)...
> Please correct me if that won't be good enough.

I'm using an XP 2600+, which seems to be able to keep up with recording 
two PVR streams, feeding video to a front-end, and background 
transcoding. You should be fine for recoding a single stream with no 
simultaneous playback.


> Most of the time I'll transfer them to my laptop and watch them there...

That probably does simplify the requirements if you won't be feeding 
video to a front-end in real-time.


> (I would use X10 not WOL, but that's me)

(I put off buying any X10 equipment for many years. Sadly, when I did, 
it lived up to the poor reputation. I still use X10 for a few limited 
things, but it continues to be unreliable. Given it's design, it isn't 
surprising. Experiences can vary greatly depending on local sources of 
interference and the nature of the wiring in the building, so if it 
works for you, consider yourself lucky.)


> ...how is some low-energy box going to cut it?  Fast CPU and fast
> drives mean bigger power draw.  That's just physics.

True, if you simply crank up the clock frequency without changing any of 
the other variables. But as transistors get smaller, they also get more 
power efficient. Take a look at the power consumption tests here:

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2889&p=3

which examines how AMD's latest 65nm parts compare to Intel's 65nm parts 
and AMD's older 90nm parts. (That page shows power consumption while 
encoding video.)

There are other tricks the manufacturers use to reduce power, like 
reducing the core voltage, as illustrated by the Athlon 64 X2 3800+ EE 
SFF shown in those charts. More on it here:

http://www.behardware.com/news/8295/energy-efficient-a64-x2-power-consumption.html

It's still using the older 90 nm process, but has the lowest power 
consumption of the parts in that AnandTech comparison (it's also the 
slowest of the bunch, but as seen in the second article it uses less 
than half the power of the regular 64 X2 3800+).

Currently you get the best performance per watt from Intel's Core 2 Duo 
chips.

Even for a primary desktop system, where performance is important and 
electricity usage is less important, I'd personally lean towards the 
lower power options, as more power consumption means more heat, which 
makes it more challenging to cool quietly.


> The only meaningful advantage of compiling it myself that I can think of
> is that it would be optimized for my CPU.

For your intended usage, I can't see that being much of an advantage. 
This is going to be primarily a factor for transcoding, and if it really 
mattered, you could hand compile the encoder (ffmpeg, mencoder, etc.). 
But chances are it either has built-in support for the AMD, or a package 
is already available.


> I'm really just too busy these days to have the time to worry about
> getting it working, I just want it working.

Then packages are definitely the way to go, providing there aren't any 
specific problems with the RPMs you'll be using. A search on the MythTV 
mailing list should quickly answer that question.

  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org