[Thread Ufficiale] CPU Zen 14/12/7nm: AMD Ryzen!

[paolo.oliva2]

Originariamente inviato da alfonsor

forse non mi sono spiegato bene; il problema di cui parlo è diffusissimo; esce fuori con compilazione parallela esasperata, ma non solo, anche in altri ambiti in cui si fa uso di parallelismo spinto

ci sono enormi testimonianze in riguardo e sono tutte riconducibili allo stesso sintomo: la cpu corrompe dati in memoria; perché questo avvenga è davvero fuori dalle capacità di un utente come la stragrande maggioranza in giro nel mondo

ieri leggevo di uno che ha problemi di corruzione sha1 in git, oggi di un altro che ha problemi con programmi inferenziali su basi di dati

e tutto questo succede con cpu diversissime, mb diversissime e memoria diversissime

è tutto un identico problema

come mai non è stato affrontato? o si sperava che un processore 8 core 16 thread fosse comperato solo dai video giocatori? che si dice che tanti core non servono molto e lo capisco ora per bene: se i giocatori non si accorgono del problema, per dire il gioco non crascia, allora i thread non servono davvero (oppure magari durante un gioco un segfault non viene manco notato, perché si perde un istante per andare in uno stato successivo? boh, non gioco quindi non so)

il fatto è che il problema esiste e pessimisticamente comincio a pensare che non ha una soluzione semplice (cioé che la soluzione sarà, ma in questo sono ottimista, ryzen 2)

certamente se avessi letto un mese fa del problema, mai avrei comperato ryzen per una macchina di sviluppo linux, per cui mi scuserete, ma lo scrivo a chiare lettere: se vi serve una macchina di sviluppo linux e siete attratti dal rapport core/prezzo alto di ryzen, lasciate perdere non è cosa al momento

lietissimo di scrivere che una soluzione è stata trovata al più presto

Ma non ho capito una cosa... stai parlando di procio in OC o a def?

Perchè se fosse nella condizione def, la stampa pro-Intel ci andrebbe a nozze a caratteri cubitali, invece nulla. A me basta ricordare di quell'errore sulla L3 MAI verificatasi nella realtà, in cui la stampa ci ha dato dentro per mesi (tra l'altro distorgendo la realtà), per cui se oggi ciò che scrivi fosse reale (in condizione def), in rete sarebbe un puttanaio... perchè trovo strano che tutti quelli che si sono comprati Ryzen giochino e basta... anzi, stando al fatto che le vendite Intel si sono letteralmente stoppate da X8 compreso in su, sarei proprio dell'idea che chi compila su Linux abbia optato per un Ryzen al posto di un 6900K/6950X.
Inoltre... Naples è sempre su Ryzen... trovo alquanto improbabile che un procio server possa avere i problemi che tu riporti...

Se parli di OC, allora la spiegazione è molto semplice. Bisogna darci un Vcore maggiore... cosa risaputa nel TH OC.

[capitan_crasy]

Originariamente inviato da alfonsor

forse non mi sono spiegato bene; il problema di cui parlo è diffusissimo; esce fuori con compilazione parallela esasperata, ma non solo, anche in altri ambiti in cui si fa uso di parallelismo spinto

ci sono enormi testimonianze in riguardo e sono tutte riconducibili allo stesso sintomo: la cpu corrompe dati in memoria; perché questo avvenga è davvero fuori dalle capacità di un utente come la stragrande maggioranza in giro nel mondo

ieri leggevo di uno che ha problemi di corruzione sha1 in git, oggi di un altro che ha problemi con programmi inferenziali su basi di dati

e tutto questo succede con cpu diversissime, mb diversissime e memoria diversissime

è tutto un identico problema

come mai non è stato affrontato? o si sperava che un processore 8 core 16 thread fosse comperato solo dai video giocatori? che si dice che tanti core non servono molto e lo capisco ora per bene: se i giocatori non si accorgono del problema, per dire il gioco non crascia, allora i thread non servono davvero (oppure magari durante un gioco un segfault non viene manco notato, perché si perde un istante per andare in uno stato successivo? boh, non gioco quindi non so)

il fatto è che il problema esiste e pessimisticamente comincio a pensare che non ha una soluzione semplice (cioé che la soluzione sarà, ma in questo sono ottimista, ryzen 2)

certamente se avessi letto un mese fa del problema, mai avrei comperato ryzen per una macchina di sviluppo linux, per cui mi scuserete, ma lo scrivo a chiare lettere: se vi serve una macchina di sviluppo linux e siete attratti dal rapport core/prezzo alto di ryzen, lasciate perdere non è cosa al momento

lietissimo di scrivere che una soluzione è stata trovata al più presto

Domanda da ignorante in materia.
Per evitare questa corruzione dei dati in memoria non potrebbe essere risolvibile utilizzando DDR4 di tipo ECC?

[SpongeJohn]

In realtà basta una ricerca veloce in rete per trovare nmila segnalazioni di questo problema. >link<

Opinione personale mia è che sia un problema software risolvibile coi prossimi kernel, più che un irreparabile bug hardware.

Edit: a naso, sembra un uso irrazionale dei core/thread che impallina la cache.

[Mister D]

Originariamente inviato da alfonsor

forse non mi sono spiegato bene; il problema di cui parlo è diffusissimo; esce fuori con compilazione parallela esasperata, ma non solo, anche in altri ambiti in cui si fa uso di parallelismo spinto

ci sono enormi testimonianze in riguardo e sono tutte riconducibili allo stesso sintomo: la cpu corrompe dati in memoria; perché questo avvenga è davvero fuori dalle capacità di un utente come la stragrande maggioranza in giro nel mondo

ieri leggevo di uno che ha problemi di corruzione sha1 in git, oggi di un altro che ha problemi con programmi inferenziali su basi di dati

e tutto questo succede con cpu diversissime, mb diversissime e memoria diversissime

è tutto un identico problema

come mai non è stato affrontato? o si sperava che un processore 8 core 16 thread fosse comperato solo dai video giocatori? che si dice che tanti core non servono molto e lo capisco ora per bene: se i giocatori non si accorgono del problema, per dire il gioco non crascia, allora i thread non servono davvero (oppure magari durante un gioco un segfault non viene manco notato, perché si perde un istante per andare in uno stato successivo? boh, non gioco quindi non so)

il fatto è che il problema esiste e pessimisticamente comincio a pensare che non ha una soluzione semplice (cioé che la soluzione sarà, ma in questo sono ottimista, ryzen 2)

certamente se avessi letto un mese fa del problema, mai avrei comperato ryzen per una macchina di sviluppo linux, per cui mi scuserete, ma lo scrivo a chiare lettere: se vi serve una macchina di sviluppo linux e siete attratti dal rapport core/prezzo alto di ryzen, lasciate perdere non è cosa al momento

lietissimo di scrivere che una soluzione è stata trovata al più presto

Scusami ma se c'è almeno un utente che ha compilato con la sua piattaforma senza problemi (che è quello che ti ha risposto- non mi ricordo se qua o in altro thread per ryzen) allora vuol dire che il problema non è un bug della cpu (come stai ipotizzando). Vuoi che phonix non se ne sarebbe accorta e non avesse scritto un articolo al riguardo?
Invece sospetto che tu e tutti quelli che incontrano il problema abbiano veramente incontrato una cpu fallata. Io, come ti hanno già detto altri, avrei fatto rma per la cpu per almeno togliermi la curiosità che non era davvero lei.

[Crysis90]

Originariamente inviato da Veradun

8c/16t 499$
8c/16t X 599$
12c/24t 699$
12c/24t X 799$
16c/32t 899$
16c/32t X 999$

Se ci azzecchi, Intel OWNED.
Però ti sei dimenticato i 10C/20T.

[flaps]

alfonsor se e' un problema speriamo esca fuori. L'informatica e' una scienza esatta; Se c'e' un problema e' ripetibile in ogni sistema a meno che il problema non sia linux stesso.

[Mparlav]

Può essere benissimo un problema del processore, come quello scoperto grazie a y-cruncher sulle istruzioni FMA3 e corretto con l'AGESA.

E' stata fatta la segnalazione ad Amd per quel problema su Linux, vediamo se possono intervenire o se il problema è di altra natura.

[Roland74Fun]

Originariamente inviato da Neverlost

ridicoli https://www.tomshw.it/test-amd-ryzen-5-1600-85964

Nonostante tutto non sono riuscì ti a parlarne male.

Non capisco la storia di tomb raider e le DX 12.
La recensione è di oggi , dicono che RyZen soffre in questo gioco, ed in nota riportano che la enix dichiara di avere una patch che potrebbe migliorare la cosa.

Ma se è quasi una settimana che è uscita e non si parla d'altro e di quanto è stato il salto di miglioramento. Boh....

[SpongeJohn]

Originariamente inviato da Roland74Fun

Nonostante tutto non sono riuscì ti a parlarne male.

Non capisco la storia di tomb raider e le DX 12.
La recensione è di oggi , dicono che RyZen soffre in questo gioco, ed in nota riportano che la enix dichiara di avere una patch che potrebbe migliorare la cosa.

Ma se è quasi una settimana che è uscita e non si parla d'altro e di quanto è stato il salto di miglioramento. Boh....

Perchè l'articolo originale è di tom's usa ed è di qualche giorno fa

[evil weasel]

Sono io quello che compila senza problemi.
Però alfonsor ha ragione, anche secondo me qualcosa che non va c'è ed il web è pieno di gente che si lamenta del problema.
La cosa non è circoscritta a 4 neckbeard che usano Gentoo, io stesso sto cominciando a pensare di essere stato fortunato ad aver beccato una CPU sana.

Tanto per farsi un'idea: https://duckduckgo.com/?q=Ryzen+segmentation+fault

[maxmix65]

Originariamente inviato da SpongeJohn

In realtà basta una ricerca veloce in rete per trovare nmila segnalazioni di questo problema. >link<

Opinione personale mia è che sia un problema software risolvibile coi prossimi kernel, più che un irreparabile bug hardware.

Edit: a naso, sembra un uso irrazionale dei core/thread che impallina la cache.

Originariamente inviato da Mparlav

Può essere benissimo un problema del processore, come quello scoperto grazie a y-cruncher sulle istruzioni FMA3 e corretto con l'AGESA.

E' stata fatta la segnalazione ad Amd per quel problema su Linux, vediamo se possono intervenire o se il problema è di altra natura.

Se non ho letto male dovrebbero aver risolto con i nuovi bios
http://forum.hwbot.org/showthread.php?t=167605&page=5

[Roland74Fun]

Originariamente inviato da SpongeJohn

Perchè l'articolo originale è di tom's usa ed è di qualche giorno fa

Ah fanno il copia ed incolla tradotto.

[SpongeJohn]

Originariamente inviato da Roland74Fun

Ah fanno il copia ed incolla tradotto.

Sono tenuti a farlo, è gran parte del loro lavoro.

[TheDarkAngel]

Originariamente inviato da evil weasel

Sono io quello che compila senza problemi.
Però alfonsor ha ragione, anche secondo me qualcosa che non va c'è ed il web è pieno di gente che si lamenta del problema.
La cosa non è circoscritta a 4 neckbeard che usano Gentoo, io stesso sto cominciando a pensare di essere stato fortunato ad aver beccato una CPU sana.

Tanto per farsi un'idea: https://duckduckgo.com/?q=Ryzen+segmentation+fault

Manca l'idea di quanti siano i compilatori "compulsivi" su ryzen, perchè già andando sulla tua piatta, che sia un problema da errata fix diminuisce molto, mi verrebbe da pensare ad un problema di tools.

[evil weasel]

Originariamente inviato da capitan_crasy

Domanda da ignorante in materia.
Per evitare questa corruzione dei dati in memoria non potrebbe essere risolvibile utilizzando DDR4 di tipo ECC?

In ogni caso sarebbe un paliativo, amesso che risolva il problema (e ho più di qualche dubbio a riguardo onestamente).

Originariamente inviato da maxmix65

Se non ho letto male dovrebbero aver risolto con i nuovi bios
http://forum.hwbot.org/showthread.php?t=167605&page=5

Il problema di cui parla alfonsor è un altro ed è ormai evidente che certe CPU sono mezze fallate.

In compenso da questa mattina riesco anche io far comparire dei segfault in dmesg, la colpa però sembra essere di un SSD che sta morendo.
Se compilo insieme gcc e mesa mettendo sotto sforzo il disco di sistema portage crasha in malomodo con il seguente errore:

make[4]: Leaving directory '/var/tmp/portage/media-libs/mesa-17.1.1/work/mesa-17.1.1-abi_x86_64.amd64/src/compiler'
make[3]: *** [Makefile:1539: all] Error 2
make[3]: Leaving directory '/var/tmp/portage/media-libs/mesa-17.1.1/work/mesa-17.1.1-abi_x86_64.amd64/src/compiler'
make[2]: *** [Makefile:851: all-recursive] Error 1
make[2]: Leaving directory '/var/tmp/portage/media-libs/mesa-17.1.1/work/mesa-17.1.1-abi_x86_64.amd64/src'
make[1]: *** [Makefile:642: all] Error 2
make[1]: Leaving directory '/var/tmp/portage/media-libs/mesa-17.1.1/work/mesa-17.1.1-abi_x86_64.amd64/src'
make: *** [Makefile:642: all-recursive] Error 1
 * ERROR: media-libs/mesa-17.1.1::gentoo failed (compile phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info '=media-libs/mesa-17.1.1::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=media-libs/mesa-17.1.1::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/media-libs/mesa-17.1.1/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/media-libs/mesa-17.1.1/temp/environment'.
 * Working directory: '/var/tmp/portage/media-libs/mesa-17.1.1/work/mesa-17.1.1-abi_x86_64.amd64'
 * S: '/var/tmp/portage/media-libs/mesa-17.1.1/work/mesa-17.1.1'

>>> Failed to emerge media-libs/mesa-17.1.1, Log file:

>>>  '/var/tmp/portage/media-libs/mesa-17.1.1/temp/build.log'

 * Messages for package media-libs/mesa-17.1.1:

 * ERROR: media-libs/mesa-17.1.1::gentoo failed (compile phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info '=media-libs/mesa-17.1.1::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=media-libs/mesa-17.1.1::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/media-libs/mesa-17.1.1/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/media-libs/mesa-17.1.1/temp/environment'.
 * Working directory: '/var/tmp/portage/media-libs/mesa-17.1.1/work/mesa-17.1.1-abi_x86_64.amd64'
 * S: '/var/tmp/portage/media-libs/mesa-17.1.1/work/mesa-17.1.1'

dmesg:

[   81.950842] ata1.00: status: { DRDY }
[   81.950843] ata1.00: failed command: WRITE FPDMA QUEUED
[   81.950846] ata1.00: cmd 61/80:f0:80:30:a2/00:00:02:00:00/40 tag 30 ncq dma 65536 out
                        res 40/00:04:80:32:a2/00:00:02:00:00/40 Emask 0x10 (ATA bus error)
[   81.950847] ata1.00: status: { DRDY }
[   81.950849] ata1: hard resetting link
[   82.411716] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
[   82.412163] ata1.00: configured for UDMA/133
[   82.412169] ahci 0000:03:00.1: port does not support device sleep
[   82.412224] ata1: EH complete
[  101.564595] sh[28382]: segfault at 556e0c84d820 ip 0000556e0c84d820 sp 00007ffeeb044110 error 15

Ogni volta che i log si riempiono di questi errori la conta dei UDMA_CRC_Error_Count aumenta.
Pensavo fosse colpa di un cavo SATA rotto, ho provato a cambiarlo, cambiare porta, staccare tutti gli altri dischi, cambiare BIOS cambiare kernel, ma l'errore persiste.
Suppongo stia morendo il disco a questo punto.
Dopo che il link SATA viene degradato a SATA 3 Gb/s posso tornare a ricompilare gcc e mesa in contemporanea senza problemi, quindi nel mio caso non è la CPU ma il disco a fare casino.

[animeserie]

Originariamente inviato da Neverlost

ridicoli https://www.tomshw.it/test-amd-ryzen-5-1600-85964

C'è una cosa che non mi è chiara: perchè tutti paragonano il 1600 agli i5.
Solo perchè c'è il numero 5 in Ryzen 5 ? o per il prezzo ?
Perchè io da quello che vedo in tutte le review, il vero competitor (per performances pure ST/MT) è l'i7-6800K, altro che i5...

[Lorenzoz]

Originariamente inviato da evil weasel

Sono io quello che compila senza problemi.
Però alfonsor ha ragione, anche secondo me qualcosa che non va c'è ed il web è pieno di gente che si lamenta del problema.
La cosa non è circoscritta a 4 neckbeard che usano Gentoo, io stesso sto cominciando a pensare di essere stato fortunato ad aver beccato una CPU sana.

Tanto per farsi un'idea: https://duckduckgo.com/?q=Ryzen+segmentation+fault

Ma pure io non ho mai beccato nessuna segmentation fault da quando uso il 1600.

Come posso riprodurlo alfonsor? Cosa ricompilo? Kernel? Firefox? Mesa?

Scritto spippolando un vetro O_o

[paolo.oliva2]

Originariamente inviato da Veradun

8c/16t 499$
8c/16t X 599$
12c/24t 699$
12c/24t X 799$
16c/32t 899$
16c/32t X 999$

Anche io sono della medesima opinione.

Nel settore desktop, la linea prezzo basso/più core è stata nettamente vincente e la deve proseguire... discorso server a parte.

AMD prima deve recuperare fette di mercato, riguadagnarsi un nome, poi, purtroppo, potrà/farà come Intel. E' troppo presto per dare fiato ad Intel...

Intanto:

CPU-Z 1.79.1 - May 2017
- Intel X299 (1.79.1).
- AMD ThreadRipper (1.79.1).
- AMD Ryzen 5 and Ryzen 3.
- Fix lockup at loading on Ryzen systems with RAID.
- New benchmark version (17.01)

Va bene che i ThreadRipper sono distribuiti come ES e quant'altro... però una versione CPU-Z pubblica per un procio che si pensa sia a settembre... a me sembra troppo in anticipo. Mi fa ben sperare in luglio disponibilità completa.

[Hadar]

Originariamente inviato da Crysis90

Se ci azzecchi, Intel OWNED.
Però ti sei dimenticato i 10C/20T.

Un altro 8/16?
Perché?
No sense poi con l'Octa Intel a 599

[M4to]

Originariamente inviato da Veradun

8c/16t 499$
8c/16t X 599$
12c/24t 699$
12c/24t X 799$
16c/32t 899$
16c/32t X 999$

il 1800x non costa 699$, forse intendevi dire il 10/20?
per me il 10/20 liscio costera 499 e 549 l'x