Re: [TOTALLY OFFTOPIC] Re: [?] Why should Distros be called as i386 for a 32-bit PC, and as amd64 for a 64-bit PC, when Intel Core PCs are also 64bit systems

2021-03-15 Thread Dan Ritter
Andrei POPESCU wrote: 
> On Lu, 15 mar 21, 17:21:39, Dan Ritter wrote:
> > 
> > At last report: normal desktop Ryzens (nothing with a G suffix
> > unless it also has a PRO marking) 
> 
> Do you have a reliable source for the lack of ECC support in G suffix 
> processors?
> 
> And why would it work for PRO processors instead?
> 
> I think it's unlikely AMD has 2 different cores for PRO and non-PRO, 
> it's more likely it either works for both or neither.


https://www.asrock.com/mb/AMD/X570%20Taichi/index.asp#Specification

I'm going to omit a bunch of details:

AMD Ryzen series CPUs (Vermeer) support ...  ECC & non-ECC, un-buffered memory*
- AMD Ryzen series CPUs (Matisse) support ... ECC & non-ECC, un-buffered memory*
- AMD Ryzen series APUs (Renoir) support ... ECC & non-ECC, un-buffered memory*
- AMD Ryzen series CPUs (Pinnacle Ridge) support ... ECC & non-ECC, un-buffered 
memory*
- AMD Ryzen series CPUs (Picasso) support non-ECC, un-buffered memory*

* For Ryzen Series CPUs (Picasso), ECC is only supported with * PRO CPUs.


The first APUs are the Raven Ridge, 2200G and 2400G, which
aren't even supported on the current motherboards

The next are Picassos, 3200G and 3400G, there's an explicit
statement that only the PRO versions support ECC.

The current ones are Renoir, 4000 series, and I haven't got a
reliable source that they are ECC only on the PRO -- but I
strongly suspect it.

It's not the cores that differ between the PROs and non- -- it's
the I/O chiplet.

-dsr-



Re: [TOTALLY OFFTOPIC] Re: [?] Why should Distros be called as i386 for a 32-bit PC, and as amd64 for a 64-bit PC, when Intel Core PCs are also 64bit systems

2021-03-15 Thread Andrei POPESCU
On Lu, 15 mar 21, 17:21:39, Dan Ritter wrote:
> 
> At last report: normal desktop Ryzens (nothing with a G suffix
> unless it also has a PRO marking) 

Do you have a reliable source for the lack of ECC support in G suffix 
processors?

And why would it work for PRO processors instead?

I think it's unlikely AMD has 2 different cores for PRO and non-PRO, 
it's more likely it either works for both or neither.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Re: [TOTALLY OFFTOPIC] Re: [?] Why should Distros be called as i386 for a 32-bit PC, and as amd64 for a 64-bit PC, when Intel Core PCs are also 64bit systems

2021-03-15 Thread Dan Ritter
Anssi Saari wrote: 
> Dan Ritter  writes:
> 
> As for the ECC support in Ryzen CPUs, as I understand it it's a bit of a
> mess. Sure the CPUs support it but if it's not validated by motherboard
> manufacturers, how do you know it actually works reliably?

... by trying it out and reporting the results to others, and
reading their results and reporting your confirmation.

This isn't a thing that the motherboard manufacturer can put in
by accident.

Anyway. If you need ECC support, you buy an EPYC server and get
registered ECC support. If you would like to have ECC as a feature, you
get a Ryzen board that's reported to work, and you get
unbuffered ECC for one-bit correction and two-bit reporting.

Then you overclock it to generate RAM errors, and it shows up in
your system log. Then you bring it back down to normal speed.

At last report: normal desktop Ryzens (nothing with a G suffix
unless it also has a PRO marking) on any ASrock, most ASUS, and
some Gigabyte motherboards will support this. To the best of my
current knowledge, no MSI motherboards.

-dsr-



Re: [TOTALLY OFFTOPIC] Re: [?] Why should Distros be called as i386 for a 32-bit PC, and as amd64 for a 64-bit PC, when Intel Core PCs are also 64bit systems

2021-03-15 Thread Anssi Saari
Dan Ritter  writes:

> Intel knew that their argument was bull: they owned the market
> and needed ways of subdividing their CPUs to fit every price
> point. Turning off ECC support was one of those ways.

> That strategy started with the 80486, when they brought out a
> cheap version called the 80486SX which lacked a floating point
> unit. The SX has the floating point unit, it was just turned
> off.

Initially, yes. A panic move when AMD brought out their 40 MHz 386. It
worked, got popular and later on the 486SX was manufactured separately
with a smaller die and no floating point.

As for the ECC support in Ryzen CPUs, as I understand it it's a bit of a
mess. Sure the CPUs support it but if it's not validated by motherboard
manufacturers, how do you know it actually works reliably?



Re: [TOTALLY OFFTOPIC] Re: [?] Why should Distros be called as i386 for a 32-bit PC, and as amd64 for a 64-bit PC, when Intel Core PCs are also 64bit systems

2021-03-15 Thread Dan Ritter
Sven Hartge wrote: 
> Stefan Monnier  wrote:
> 
> > From a purely technical perspective, it's hard to understand how Intel
> > managed to pour so much energy into such an obviously bad idea.  The
> > only explanations seem all to be linked to market strategies.
> 
> This history repeats for Intel on several fronts:
> 
> Or the discussion about ECC for desktop devices. Intel argues "not
> needed", which is, if you follow the Rowhammer issues, not true. AMD
> just does it and it works.

Intel knew that their argument was bull: they owned the market
and needed ways of subdividing their CPUs to fit every price
point. Turning off ECC support was one of those ways.

That strategy started with the 80486, when they brought out a
cheap version called the 80486SX which lacked a floating point
unit. The SX has the floating point unit, it was just turned
off. Worse: purchasing the 80487 math coprocessor to enable
floating point support... the 487 was a full 486, that turned
off the original.

> Then there was FB-DIMM back in the 2008s. Nice idea, just, again, too
> expensive and disconnected from the market in the end.

Intel wanted more pricing points. 

> I personally am really glad that AMD got their stuff together again and
> with their ZenX-Architectures showed Intel how it is done.
> 
> What AMD now needs is a hit in the low, lower and ultra-low power
> segment.

They've got the low and lower parts now: 35W and 15W 4000-series
APUs, from the Renoir design. Stefan and I were just talking
about how you can't buy one with a normal motherboard right now
because they are entirely allocated to systems integrators. AMD
is selling 100% of production.

They don't have any 7W or lower parts, but those things aren't
very interesting compared to ARM64 architecture, where Qualcomm
and Apple and any number of smaller shops are doing great things
in the tablet and phone space.

-dsr-



Re: [TOTALLY OFFTOPIC] Re: [?] Why should Distros be called as i386 for a 32-bit PC, and as amd64 for a 64-bit PC, when Intel Core PCs are also 64bit systems

2021-03-15 Thread Sven Hartge
Stefan Monnier  wrote:

> From a purely technical perspective, it's hard to understand how Intel
> managed to pour so much energy into such an obviously bad idea.  The
> only explanations seem all to be linked to market strategies.

This history repeats for Intel on several fronts:

Look at the Netburst Pentium 4 desaster, which as scrapped as soon as
the Israel division showed their improved concept based on the P3, which
ran laps around the P4 while at the same time using far less power and
had a bigger yield.

Or the discussion about ECC for desktop devices. Intel argues "not
needed", which is, if you follow the Rowhammer issues, not true. AMD
just does it and it works.

Then there was FB-DIMM back in the 2008s. Nice idea, just, again, too
expensive and disconnected from the market in the end.

And all in all the rather slow improvments on the CPU fronts, the
piecemeal 5% increases sold as "big achievements" every year, while at
the same time all improvements turned out to be major security problems.

I personally am really glad that AMD got their stuff together again and
with their ZenX-Architectures showed Intel how it is done.

What AMD now needs is a hit in the low, lower and ultra-low power
segment.

Grüße,
S°

-- 
Sigmentation fault. Core dumped.