Bob wrote:
> Unbuffered / Registered obviously.
>

Bad form Bla Bla Bla but just to update the list, the abit A-S78H also
supports Un-buffered ECC RAM, it doesn't have FireWire though
http://www.abit.com.tw/page/en/mothe...E=Socket%20AM2

> This is an edited repost of something I sent to debian-user list last
> month with little result, so apologies to those who, like me, are
> subscribed to both.
>
> I'm building a couple of Debian / MythTV based home media players /
> servers and want reliability + low power consumption and noise, at the
> moment I'm leaning towards
>
> CPU 45W Dual Core Athlon64
> Motherboard ASUS M3A78-EMH HDMI
> RAM 4GB DDR2 ECC RAM as fast as I can find [0]
> GPU Radeon X800, X1900, X1950 [1] or on-board [2]
> HDD (system) Toshiba MK8037GSX or some other SATA laptop drive
> HDD (Data) Western Digital 1TB Green Power
> or the Samsung ITB F1
> and some DVB-C card
>
> I'll probably go for ATI/AMD graphics because
> A: I want to reward AMD for the recent opening up of their GPU specks
> B: no other GPU matches the on-board one on the 780G chipset in terms of
> performance for power consumption, at a rough guess with the on-board
> GPU, a 45W CPU and a Laptop HardDrive or net boot I should be able to
> get the whole systems power to 30 or 40 W idle and maybe 70W under load,
> if I can do that then it can be passively cooled with no fans and
> potentially no moving parts at all.
>
> The ASUS AM2+ boards are the only ones I can find with the traces / BIOS
> support for ECC RAM but this one doesn't have FireWire on-board which
> I'd like, can anyone suggest another mATX system with USB2, SATA2, ATA,
> FireWire, Digital sound IO and ECC RAM support that would meet my
> requirements? [3]
>
> Does anyone know weather an Athlon X2 4850e (2500MHz) or Athlon X2
> BE-2400 (2300MHz) (both 45W ) is going to be capable of decoding H.264
> 1080p in Blu-ray quality if the only assistance it gets is with scaling
> via XV which already works for GPUs <= R400 in the Radion diver [5] but
> I don't think does yet in RadeonHD? [6]
>
> How about when we get IDCT (Inverse Discrete Cosine Transform) and MC
> (Motion Compensation) video acceleration in RadeonHD?
>
> Thanks for any .
>
>
> [0] ECC for prolonged uptime and reliability without having to go for
> full Opteron with Registered ECC RAM, the fastest ECC sticks I can find
> are DDR2-800, I can't find any 1066s and would like to for some headroom
>
> [1] I haven't decided which GPU to go for, I'll have to do more research
> into how well R500 and R600 GPU are handling video playback at the
> moment, I have a feeling that for simplicity I may have to get an R400
> GPU as an interim measure and then when RadeonHD matures a bit I'll
> switch to either the On-Board or an R500 based discreet card [4]
>
> [2] for the first time in my life I'm considering on-board graphics (the
> 780G chipset).
>
> [3] not necessarily AMD but preferably
>
> [4] Because the R600 Unified Video Decoder (UVD) has integrated DRM
> we'll probably never get access to it, in which case any
> hardware-assisted video decoding the Linux world sees will be in the
> same form as the R500 stuff, (pixel or vertex shader) I'm unsure if
> this will mean that R500s will ultimately be "better" than R600s but I
> suspect they'll be the same, either way for Home Theater PCs I'd really
> like someone to start putting Mobility Radeon GPUs on PCIe cards.
> http://www.phoronix.com/scan.php?pag...item=955&num=1
>
> [5] and maybe R500 too as Dave Arlied has been running the Radion driver
> on R500 hardware, but he has a powerful beard so it's probably not a
> solution I, with my puny stubble, want to rely on for my everyday video
> playback needs quite yet.
>
> [6] up to 40Mbit/s, probably not is my feeling from reading round, I
> think an X2 6000+ (3000 MHz) at 89W or 125W can *just* do it.
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/07/08 01:23, Bob wrote:
> Bob wrote:
>> Unbuffered / Registered obviously.
>>
>
> Bad form Bla Bla Bla but just to update the list, the abit A-S78H also
> supports Un-buffered ECC RAM, it doesn't have FireWire though
> http://www.abit.com.tw/page/en/mothe...E=Socket%20AM2

Add a Firewire PCI card?

- --
Ron Johnson, Jr.
Jefferson LA USA

We want... a Shrubbery!!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIIaXQS9HxQb37XmcRAnIeAJ9+WwZpU1uZyBGQJsfQ0P HRooWz0gCgs4fw
s218r5qGCfoDdGZeocKXmvI=
=8CEz
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Roger Heflin wrote:
> Bob wrote:
>
>> Bill Williamson wrote:
>>
>>> On Wed, May 7, 2008 at 4:23 PM, Bob <spam@homeurl.co.uk
>>> <mailto:spam@homeurl.co.uk>> wrote:
>>>
>>> Bob wrote:
>>> > Unbuffered / Registered obviously.
>>> >
>>>
>>> Bad form Bla Bla Bla but just to update the list, the abit A-S78H also
>>> supports Un-buffered ECC RAM, it doesn't have FireWire though
>>> http://www.abit.com.tw/page/en/mothe...E=Socket%20AM2
>>> <http://www.abit.com.tw/page/en/motherboard/motherboard_detail.php?pMODEL_NAME=A-S78H&fMTYPE=Socket%20AM2>
>>>
>>> Why do you think that ECC vs non ECC ram will have any bearing on
>>> stability of a media computer ? If you're going ECC, why would you
>>> not also go SCSI?
>>>
>>> I don't disagree with wanting stability, but the reality is that ECC
>>> likely will not give you any.
>>>
>> ECC RAM corrects bit errors in memory which could cause a crash or other
>> problems, these errors while rare are estimated to occur once a month
>> per GB of RAM, I'm planing have 2 or 4 GBs and I'll leave the system up
>> all the time, which is why reliability and low power consumption are a must.
>>
>
> Actually the errors don't happen that often anymore, not sure exactly why, but I
> have monitored huge amounts of ram (10000+ GB for months) and the errors happen
> pretty rarely except on machines getting huge numbers of errors, in a given
> month with a machine with 32GB on it very few of the machines get any errors at
> all, the few that get errors don't usually get only 1 error.
>

That's interesting to have some real world figures, thank you.

> But, if you are monitoring ECC then this will give you a chance to know about
> the memory *BEFORE* it causes you machine to be unstable and crash randomly
> without you knowing why it is crashing. It would also speed up correcting the
> issue as you don't have to guess what the actual issue is.
>

What do you use to monitor the errors?

> It is really one of the advantages of the AMD cpus, as you can easily get ECC in
> them without buying a single socket server grade MB for a lot more money that
> you have to get with the Intel cpus.
>

This is exactly the reason I'm after an AM2+ MotherBoard that supports
it, I like these 2 boards [4] but I've had bad experiences with both
abit [0] and asus [1] in the past in both cases not actually their fault
but once bitten.. the only downside is the lack of FireWire which as Ron
on debian-users points out that can be fixed with a PCI card, the only
problem with that is these mATX are quite short on space and I'll
probably put a DVB-C card in.

>> I don't want to build a "proper" server with ECC Registered RAM and SCSI
>> because it'll cost a fair bit more for a fairly marginal improvement in
>> stability and longevity.
>>
>
> SCSI does not matter anymore, in the last 3 years the SATA/IDE disk have got a
> lot better, I think the issue is that the disk manufacturers figured out better
> platter quality control. I have experience with large samples of SCSI
> (2003-800 scsi disks) and SATA disks (2000+ IDE/SATA disks), and they both have
> similar failures rates, if you go back to large numbers of IDE/SCSI disks in the
> 2000-2004 range this was not the case and the SATA disks were utter crap were
> you could expect 10-20% failures in the first 6 months, and the SCSI/FC disks
> had very low failure rates.

[0] abit BP6 motherboard dual skt 370 celeron board, that took ECC RAM,
great home SMP board with a clear upgrade path, only intel moved some
stuff around on the P!!! and shafted them / us

[1] some ASUS Slot A board with a crappy VIA chipset, [2] I won't touch
VIA again [3] and shouldn't really hold it against ASUS but I sort of have

[2] and then ALI came along to show us all that VIA wasn't that bad
after all

[3] although if they genuinely open up their graphics drivers and the
new 64bit CPU is as OK as it's touted to be, I may well use them for low
power desktops or media players, and embedded servers if they put ECC
support in their RAM controllers

[4] the abit A-S78H & ASUS M3A78-EMH HDMI for those that missed the OPs



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Bob wrote:
> Roger Heflin wrote:
>> Bob wrote:
>>
>>> Bill Williamson wrote:
>>>
>>>> On Wed, May 7, 2008 at 4:23 PM, Bob <spam@homeurl.co.uk
>>>> <mailto:spam@homeurl.co.uk>> wrote:
>>>>
>>>> Bob wrote:
>>>> > Unbuffered / Registered obviously.
>>>> >
>>>>
>>>> Bad form Bla Bla Bla but just to update the list, the abit A-S78H also
>>>> supports Un-buffered ECC RAM, it doesn't have FireWire though
>>>> http://www.abit.com.tw/page/en/mothe...E=Socket%20AM2
>>>> <http://www.abit.com.tw/page/en/motherboard/motherboard_detail.php?pMODEL_NAME=A-S78H&fMTYPE=Socket%20AM2>
>>>>
>>>> Why do you think that ECC vs non ECC ram will have any bearing on
>>>> stability of a media computer ? If you're going ECC, why would you
>>>> not also go SCSI?
>>>>
>>>> I don't disagree with wanting stability, but the reality is that ECC
>>>> likely will not give you any.
>>>>
>>> ECC RAM corrects bit errors in memory which could cause a crash or other
>>> problems, these errors while rare are estimated to occur once a month
>>> per GB of RAM, I'm planing have 2 or 4 GBs and I'll leave the system up
>>> all the time, which is why reliability and low power consumption are a must.
>>>
>> Actually the errors don't happen that often anymore, not sure exactly why, but I
>> have monitored huge amounts of ram (10000+ GB for months) and the errors happen
>> pretty rarely except on machines getting huge numbers of errors, in a given
>> month with a machine with 32GB on it very few of the machines get any errors at
>> all, the few that get errors don't usually get only 1 error.
>>
>
> That's interesting to have some real world figures, thank you.
>
>> But, if you are monitoring ECC then this will give you a chance to know about
>> the memory *BEFORE* it causes you machine to be unstable and crash randomly
>> without you knowing why it is crashing. It would also speed up correcting the
>> issue as you don't have to guess what the actual issue is.
>>
>
> What do you use to monitor the errors?

On AMD boards a program called mcelog (you will have to put it in cron) will
work-most soft MCE errors are ECC errors either in the CPU or in memory, also
something in the kernel (may require an extra module in some distribtions)
called edac will also work. The edac thing will also work on *SELECT* intel
boards, mostly on the intel side only the higher end (dual socket server boards)
are supported, on AMD because the ECC is in the CPU itself it is pretty much
supported everywhere if the MB will take ECC ram.

>
>> It is really one of the advantages of the AMD cpus, as you can easily get ECC in
>> them without buying a single socket server grade MB for a lot more money that
>> you have to get with the Intel cpus.
>>
>
> This is exactly the reason I'm after an AM2+ MotherBoard that supports
> it, I like these 2 boards [4] but I've had bad experiences with both
> abit [0] and asus [1] in the past in both cases not actually their fault
> but once bitten.. the only downside is the lack of FireWire which as Ron
> on debian-users points out that can be fixed with a PCI card, the only
> problem with that is these mATX are quite short on space and I'll
> probably put a DVB-C card in.

In the order of the vendors, Supermicro's quality is on average better than any
of the other MB only vendors.

>
>>> I don't want to build a "proper" server with ECC Registered RAM and SCSI
>>> because it'll cost a fair bit more for a fairly marginal improvement in
>>> stability and longevity.
>>>
>> SCSI does not matter anymore, in the last 3 years the SATA/IDE disk have got a
>> lot better, I think the issue is that the disk manufacturers figured out better
>> platter quality control. I have experience with large samples of SCSI
>> (2003-800 scsi disks) and SATA disks (2000+ IDE/SATA disks), and they both have
>> similar failures rates, if you go back to large numbers of IDE/SCSI disks in the
>> 2000-2004 range this was not the case and the SATA disks were utter crap were
>> you could expect 10-20% failures in the first 6 months, and the SCSI/FC disks
>> had very low failure rates.
>
> [0] abit BP6 motherboard dual skt 370 celeron board, that took ECC RAM,
> great home SMP board with a clear upgrade path, only intel moved some
> stuff around on the P!!! and shafted them / us
>
> [1] some ASUS Slot A board with a crappy VIA chipset, [2] I won't touch
> VIA again [3] and shouldn't really hold it against ASUS but I sort of have

I have a via chipset, and I have used other VIA MB's, and I would probably avoid
VIA if possible, but if they are the only ones with the required features I
would use them.

Roger


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Roger Heflin wrote:
> Bob wrote:
>
>> Roger Heflin wrote:
>>
>>> Bob wrote:
>>>
>>>> Bill Williamson wrote:
>>>>
>>>>> Bob <spam@homeurl.co.uk wrote:
>>>>> Bob wrote:
>>>>> > Unbuffered / Registered obviously.
>>>>> >
>>>>>
>>>>> Bad form Bla Bla Bla but just to update the list, the abit A-S78H also
>>>>> supports Un-buffered ECC RAM, it doesn't have FireWire though
>>>>> http://www.abit.com.tw/page/en/mothe...E=Socket%20AM2
>>>>> <http://www.abit.com.tw/page/en/motherboard/motherboard_detail.php?pMODEL_NAME=A-S78H&fMTYPE=Socket%20AM2>
>>>>>
>>>>> Why do you think that ECC vs non ECC ram will have any bearing on
>>>>> stability of a media computer ? If you're going ECC, why would you
>>>>> not also go SCSI?
>>>>>
>>>>> I don't disagree with wanting stability, but the reality is that ECC
>>>>> likely will not give you any.
>>>>>
>>>>>
>>>> ECC RAM corrects bit errors in memory which could cause a crash or other
>>>> problems, these errors while rare are estimated to occur once a month
>>>> per GB of RAM, I'm planing have 2 or 4 GBs and I'll leave the system up
>>>> all the time, which is why reliability and low power consumption are a must.
>>>>
>>>>
>>> Actually the errors don't happen that often anymore, not sure exactly why, but I
>>> have monitored huge amounts of ram (10000+ GB for months) and the errors happen
>>> pretty rarely except on machines getting huge numbers of errors, in a given
>>> month with a machine with 32GB on it very few of the machines get any errors at
>>> all, the few that get errors don't usually get only 1 error.
>>>
>>>
>> That's interesting to have some real world figures, thank you.
>>
>>
>>> But, if you are monitoring ECC then this will give you a chance to know about
>>> the memory *BEFORE* it causes you machine to be unstable and crash randomly
>>> without you knowing why it is crashing. It would also speed up correcting the
>>> issue as you don't have to guess what the actual issue is.
>>>
>>>
>> What do you use to monitor the errors?
>>
>
> On AMD boards a program called mcelog (you will have to put it in cron) will
> work-most soft MCE errors are ECC errors either in the CPU or in memory, also
> something in the kernel (may require an extra module in some distribtions)
> called edac will also work. The edac thing will also work on *SELECT* intel
> boards, mostly on the intel side only the higher end (dual socket server boards)
> are supported, on AMD because the ECC is in the CPU itself it is pretty much
> supported everywhere if the MB will take ECC ram.
>

But those are quite rare on consumer side of things, when I get these
boards setup I'll look into mcelog vs edac, it looks like edac is in
lenny but not etch.
http://packages.debian.org/edac-utils

>>> It is really one of the advantages of the AMD cpus, as you can easily get ECC in
>>> them without buying a single socket server grade MB for a lot more money that
>>> you have to get with the Intel cpus.
>>>
>>>
>> This is exactly the reason I'm after an AM2+ MotherBoard that supports
>> it, I like these 2 boards [4] but I've had bad experiences with both
>> abit [0] and asus [1] in the past in both cases not actually their fault
>> but once bitten.. the only downside is the lack of FireWire which as Ron
>> on debian-users points out that can be fixed with a PCI card, the only
>> problem with that is these mATX are quite short on space and I'll
>> probably put a DVB-C card in.
>>
>
> In the order of the vendors, Supermicro's quality is on average better than any
> of the other MB only vendors.
>

Intel only though.

>>>> I don't want to build a "proper" server with ECC Registered RAM and SCSI
>>>> because it'll cost a fair bit more for a fairly marginal improvement in
>>>> stability and longevity.
>>>>
>>>>
>>> SCSI does not matter anymore, in the last 3 years the SATA/IDE disk have got a
>>> lot better, I think the issue is that the disk manufacturers figured out better
>>> platter quality control. I have experience with large samples of SCSI
>>> (2003-800 scsi disks) and SATA disks (2000+ IDE/SATA disks), and they both have
>>> similar failures rates, if you go back to large numbers of IDE/SCSI disks in the
>>> 2000-2004 range this was not the case and the SATA disks were utter crap were
>>> you could expect 10-20% failures in the first 6 months, and the SCSI/FC disks
>>> had very low failure rates.
>>>
>> [0] abit BP6 motherboard dual skt 370 celeron board, that took ECC RAM,
>> great home SMP board with a clear upgrade path, only intel moved some
>> stuff around on the P!!! and shafted them / us
>>
>> [1] some ASUS Slot A board with a crappy VIA chipset, [2] I won't touch
>> VIA again [3] and shouldn't really hold it against ASUS but I sort of have
>>
>
> I have a via chipset, and I have used other VIA MB's, and I would probably avoid
> VIA if possible, but if they are the only ones with the required features I
> would use them.
>

I hear you, one thing that saddened me was ULi being swallowed by
nVidia, they were coming out with some pretty innovative stuff, Oh well,
it can join 3dfx, S3 graphics and lodes of others on the wasted
potential and shattered dreams pile.

I'd actually like to get a system with one of the Loongson / Godson 3
chips when they come out, assuming they're available in a more capable
all round package than the Godson2 stuff was.



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Bob wrote:
> Roger Heflin wrote:
>> Bob wrote:
>>
>>> Roger Heflin wrote:
>>>
>>>> Bob wrote:
>>>>
>>>>> Bill Williamson wrote:
>>>>>
>>>>>> Bob <spam@homeurl.co.uk wrote:
>>>>>> Bob wrote:
>>>>>> > Unbuffered / Registered obviously.
>>>>>> >
>>>>>>
>>>>>> Bad form Bla Bla Bla but just to update the list, the abit A-S78H also
>>>>>> supports Un-buffered ECC RAM, it doesn't have FireWire though
>>>>>> http://www.abit.com.tw/page/en/mothe...E=Socket%20AM2
>>>>>> <http://www.abit.com.tw/page/en/motherboard/motherboard_detail.php?pMODEL_NAME=A-S78H&fMTYPE=Socket%20AM2>
>>>>>>
>>>>>> Why do you think that ECC vs non ECC ram will have any bearing on
>>>>>> stability of a media computer ? If you're going ECC, why would you
>>>>>> not also go SCSI?
>>>>>>
>>>>>> I don't disagree with wanting stability, but the reality is that ECC
>>>>>> likely will not give you any.
>>>>>>
>>>>>>
>>>>> ECC RAM corrects bit errors in memory which could cause a crash or other
>>>>> problems, these errors while rare are estimated to occur once a month
>>>>> per GB of RAM, I'm planing have 2 or 4 GBs and I'll leave the system up
>>>>> all the time, which is why reliability and low power consumption are a must.
>>>>>
>>>>>
>>>> Actually the errors don't happen that often anymore, not sure exactly why, but I
>>>> have monitored huge amounts of ram (10000+ GB for months) and the errors happen
>>>> pretty rarely except on machines getting huge numbers of errors, in a given
>>>> month with a machine with 32GB on it very few of the machines get any errors at
>>>> all, the few that get errors don't usually get only 1 error.
>>>>
>>>>
>>> That's interesting to have some real world figures, thank you.
>>>
>>>
>>>> But, if you are monitoring ECC then this will give you a chance to know about
>>>> the memory *BEFORE* it causes you machine to be unstable and crash randomly
>>>> without you knowing why it is crashing. It would also speed up correcting the
>>>> issue as you don't have to guess what the actual issue is.
>>>>
>>>>
>>> What do you use to monitor the errors?
>>>
>> On AMD boards a program called mcelog (you will have to put it in cron) will
>> work-most soft MCE errors are ECC errors either in the CPU or in memory, also
>> something in the kernel (may require an extra module in some distribtions)
>> called edac will also work. The edac thing will also work on *SELECT* intel
>> boards, mostly on the intel side only the higher end (dual socket server boards)
>> are supported, on AMD because the ECC is in the CPU itself it is pretty much
>> supported everywhere if the MB will take ECC ram.
>>
>
> But those are quite rare on consumer side of things, when I get these
> boards setup I'll look into mcelog vs edac, it looks like edac is in
> lenny but not etch.
> http://packages.debian.org/edac-utils
>
>>>> It is really one of the advantages of the AMD cpus, as you can easily get ECC in
>>>> them without buying a single socket server grade MB for a lot more money that
>>>> you have to get with the Intel cpus.
>>>>
>>>>
>>> This is exactly the reason I'm after an AM2+ MotherBoard that supports
>>> it, I like these 2 boards [4] but I've had bad experiences with both
>>> abit [0] and asus [1] in the past in both cases not actually their fault
>>> but once bitten.. the only downside is the lack of FireWire which as Ron
>>> on debian-users points out that can be fixed with a PCI card, the only
>>> problem with that is these mATX are quite short on space and I'll
>>> probably put a DVB-C card in.
>>>
>> In the order of the vendors, Supermicro's quality is on average better than any
>> of the other MB only vendors.
>>
>
> Intel only though.

I forgot that since I have used a number of Supermicro AMD server boards, Intel
only unless you are a VAR. They do have AMD boards for VAR's, just not for
consumers, and the lowest board is a low-end server board.

See: http://www.supermicro.com/aplus/

The closest they have use an Opteron 1000 and costs $260, it does have 6 sata
ports, 2 gbit lans, and some higher end pcie ports (x16,x8,x4), but no DVI or
HDMI even on the more expensive MB with video on it.


>
>
> I hear you, one thing that saddened me was ULi being swallowed by
> nVidia, they were coming out with some pretty innovative stuff, Oh well,
> it can join 3dfx, S3 graphics and lodes of others on the wasted
> potential and shattered dreams pile.
>
> I'd actually like to get a system with one of the Loongson / Godson 3
> chips when they come out, assuming they're available in a more capable
> all round package than the Godson2 stuff was.


Not sure I would touch a via again, I just figured out that my machine (with a
via chipset) became unstable when I started using both of the via sata ports, it
had been previously stable without them, using the via ports made the raid about
2x faster but prone to crashing the machine, and causing a number of other bad
behaviors.

Roger


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org