AMD Zen / Ryzen 1-2-3XXX serie tråden

[Theo343]

 

[G]

10 hours ago, Theo343 said:

 

Uten å ha sett video først, så tipper jeg at det må være Asrock, da det er de som helst har drevet med mini-PC for AMD tidligere, og at jeg har sett et nyhetsdrypp nylig om at det er Asrock som kommer til å være tidlig ute med mini-PC for Zen2. Synd det ikke er særlig mange konkurrenter som har kastet seg på dette tidligere. Også synd at de ikke slapp dette høst/vinter 2019, fordi da hadde nok en slik en funnet veien inn som kjøkken-PC for hyggelig surfing av oppskrifter, dagbok, musikkmaskin og masse andre artige ting hos meg.

Edit:

Virker som at Asrock ikke skinner som produsent i video. Har ikke fullført å se den enda. Men Asrock kan jo være produsenten i bunn selv om varen bærer det indigogo-produsent navnet Minisforum.

Edit2:

7-ish noen minutter uti, så avsløres at dette ikke var en Zen2, men en Zen+  (skufffende)

Endret 24. august 2020 av G

[G]

15 hours ago, Svein M said:

Hadde ikke brydd meg om hva dette programmet viser. Det eneste en trenger er å vite at det er Samsung B-die.

Ser der står XMP 1603 MHz og 14-14-14-35-49 /1.35V, men også her må du stole mer på det som står på pakken eller spesifikasjoner enn det du leser ut.

Skjønner fortsatt ikke G.Skill sin fordel av å kode inn begrepet prototype knyttet mot en RAM-brikke. Mener noen at dette er en feiltolkning også?

[G]

14 hours ago, Theo343 said:

 

nice

[Svein M]

G skrev (1 time siden):

Skjønner fortsatt ikke G.Skill sin fordel av å kode inn begrepet prototype knyttet mot en RAM-brikke. Mener noen at dette er en feiltolkning også?

Du ser at der er mange felter som ikke kan stemme der, de er ikke like mellom de forskjellige brikkene. Det er programmet som leser feil eller har feil forståelse av hva de forskjellige data det leser inneholder (det er kanskje ikke en standard, jeg vet ikke). Det eneste en trenger er om det er Samsung B-die eller noe annet. For det må en legge inn i Ryzen calculator for å finne foreslåtte timing verdier.

Endret 24. august 2020 av Svein M

[Cowboystrekk]

Thaiphoon burner leser ofte rett, men bommer innimellom. Bruk det som en indikasjon, ikke en fasit

[G]

22 minutes ago, Svein M said:

Du ser at der er mange felter som ikke kan stemme der, de er ikke like mellom de forskjellige brikkene. Det er programmet som leser feil eller har feil forståelse av hva de forskjellige data det leser inneholder (det er kanskje ikke en standard). Det eneste en trenger er om det er Samsung B-die eller noe annet. For det må en legge inn i Ryzen calculator for å finne foreslåtte timing verdier.

Kom over en interessant diskusjon om Asus og RGB minne:

https://www.gskill.us/forum/forum/product-discussion/ddr4/trident-z-rgb/13195-aura-g-skill-software-corrupts-spd-s

Quote

G.SKILL TECH

We are aware of the issue and of course working on a solution. It is not solely Trident Z RGB software or ASUS Aura software that causes it so there are many other factors involved that we are looking into. Rest assured our goal is always to make sure the product is as good as it can be, and most importantly, the product is working flawlessly in your system. We read every post so we appreciate your feedback and patience as we resolve problems as soon as possible.

Quote

BillB

I believe the problem is that ASUS AURA and AI Suite access the SMB Bus without using the proper interlocks to avoid bus access conflicts. ASUS AURA and AI Suite have been causing conflicts with Corsair Link, HWINFO, CPUZ, SIV, and other sensor monitoring utilities for years. These programs all use the proper interlock mutexes but ASUS does not as their program developers seem to assume that they are the only ones accessing the SMB Bus. Considering their target is HEDT Enthusiasts who are using these types of programs while overclocking, it is a pretty stupid thing for them to assume. The fix is easily made but to date, the solution has fallen on deaf ears. Now that LED RAM is all the rage, and G.Skill is using the SMB Buss for LED control data, non-inerlocked SMB Buss access is now causing random SPD data corruption and bricking brand new RAM modules.

G.Skill needs to get ASUS to get with the program and modify their software to use the proper interlock mutexes like HWINFO, CPUZ,Corsair Link, and SIV do. With all these reports of LED color control data corrupting SPD data, hopefully ASUS will finally fix their poorly coded software. Corsair finally fixed Link but only after years of the developer of SIV waving the problem (and the solution) in their faces. He has also offered to assist ASUS in correcting their programs so that they access the SMB Bus with the proper interlocks. It will be interesting to see how this unfolds. Until they step up and fix it, I personally will not run any ASUS software that accesses sensor information. I was thinking about buying a G.Skill Trident-Z LED kit but decided to wait and see if they would have problems due to SMB Bus contention. Glad I waited but I feel sorry for those that bought the marketing hype and took the plunge early.

So come on G.Skill. I am guessing you guys are aware of the root problem by now, so why don't you give ASUS a call and strongly suggest they clean up their poorly written software. After all, ASUS is not the one dealing with RMAs on brand new, expensive, bricked RAM sticks.

Quote

facehook

Hi! First of all, check out SPD CRC with Thaiphoon Burner. It must be OK.

or

If it is corrupted you will see "CRC: Error" what means that some of SPD bytes within the first 256 byte array are corrupted and need to be restored. G.SKILL doesn't mess with programming Serial Number and Manufacturing Date, its SPD is very common. So if you didn't back up the original SPD you can use similar SPD for TridentZ, Ripjaws, FlareX series. Make sure the source SPD has identical number of Ranks and DRAM density as your module.

Quote

ckc

this happened to me. one of my sticks of F4-3200C14-8GTZR has lost its xmp profile, which was visible before. i had an asrock x370 taichi, used the g.skill software on that, and at some point i noticed that the xmp information had disappeared from cpu-z and despite reinstalling windows, the g.skill software wouldn't run. now i have a crosshair vi and i can't use the xmp profile in the bios because one of the sticks doesn't have that information (wasn't a problem on the crosshair). i also have to use the asus aura software to control the leds, so there's no guarantee it won't happen again.

the cl14 replaced cl16 rgb trident z that went bad and failed, produced a bunch of bsods and errors in memtest. and i'm now wondering if the rgb software was also responsible for that.

this is expensive ram. i don't particularly care for the rgb, but that's all we get here now. and if you have ryzen 7 and want samsung b-die, it's the only ram that guarantees b-die without knowing the version number.

not overly pleased my nz$360 ram now has corrupted spd and the only way to fix it is either rma (which doesn't mean it won't happen again) or buy another program (with a really restrictive licence) and write new spd information?

more information on what's gone wrong and how to avoid it happening again would be really useful. because although i've used g.skill exclusively for years, that can change instantly. and seeing as it looks like i'm going to have to rma this ram, it could change pretty much as soon as i find the right version of corsair ram.

Quote

Have had this issue impact all 4 DIMMs on an Asus Crosshair VI Hero. It's gotten so bad that one of the DIMMs won't boot at all on x370 motherboards, but will boot on Intel chipsets still. RMA request went entirely unanswered so *shrug*.

Looks like the SPD write protection on the Intel PCH protects the really critical data on Z170 and up boards. I have no confirmation, but it appears that x370 boards don't have that and thus using the software on them can render your system unable to boot entirely.

Quote

AUStheWOLF

I also fell victim to the Aura software. It worked perfect for the lighting control, but corrupted my SPD and also caused random crashes during gaming. Another issue peeked its head, where the DRAM limited itself to 7.93GB Available/16GB. Not good!! I have read success stories from similar users who chose to restore their SPD profiles with Thaiphoon Burner software, but I didn't try to do this before sending in my RMA for replacement. The software does have a built in library, to restore your DRAM proifles, so in the event I run into additional problems, I will likely purchase the software to attempt the repair myself.

Sadly I am processing an RMA on the DRAM modules, to have a replacement sent of the same product. I sent the package last Friday and it looks like they will be arriving this Thursday. Pending a quick RMA and expedited shipping, this puts me at middle of next week. This is not a fun process, and I would have much rather "rolled the dice" on some software to restore the DRAM firmware. I feel G.Skill should release a restoration software or patch to perform the same function the Thaiphoon software is performing. It is unfortunate, because this is NOT an isolated few cases. This is actually a widespread problem, and a ton of G.Skill memory is being damaged due to (official release) software for synchronize lighting. Also, I have not downloaded any other lighting control software that would have caused conflict.

I did contact ASUS and G.Skill via phone to try and troubleshoot anything before filling the RMA, neither tech support line was helpful to my issues... I could tell the girl at ASUS didn't know anything I was talking about, then transferred me from hardware consultants department to complete computer systems. G.Skill said there was nothing that can be done at the moment, other than sending the DRAM to them to look at. This particular DRAM is the only type of DRAM that has given others success with the Ryzen platform, therefore I do not intend on changing anything. I cannot even attribute this problem directly to ASUS, as others have posted here with similar issues on the different motherboards and even with G.Skill in-house software. Maybe there will be future hardware revisions, but at the moment I can only blame the Aura software. My DRAM functioned perfectly out the box, and I was able to achieve a 3600MHz speed with the 1107 BIOS, recommended voltage, recommended timings. I have searched this forum, overclock.net, and ASUS ROG forum. I am upset being out these two weeks while my RMA is being processed, but I would rather address this issue while I am within my 30-day return period.

Quote

facehook

You are not right! When he turns on his computer BIOS can't calculate the module capacity on the base of SPD parameters like Number of Ranks, DRAM Density, Data Width, etc since SPD data are corrupted. That is why BIOS ignores such modules and lowers the total system memory capacity.

However, folks from G.SKILL R&D are really crazy with their idea to control LED lightning via SPD Write commands  It's a very dangerous idea! The only purpose of SPD EEPROM is to store SPD data! What the hell did they use SPD EEPROM to control LED? Neither solution will solve the SPD corruption issue, because of the concept itself to use SPD Write commands!

Mitt hovedkort er Asus også.. Stopper siteringen der. Er på mange sider. Se lenke selv for dybdelesning:

https://www.gskill.us/forum/forum/product-discussion/ddr4/trident-z-rgb/13195-aura-g-skill-software-corrupts-spd-s

 

  

1 minute ago, Cowboystrekk said:

Thaiphoon burner leser ofte rett, men bommer innimellom. Bruk det som en indikasjon, ikke en fasit

Kan jeg ha dumpet borti årsaken til hvorfor det oppleves på min PC også?

Endret 24. august 2020 av G

[TheKims]

G skrev (3 timer siden):

7-ish noen minutter uti, så avsløres at dette ikke var en Zen2, men en Zen+  (skufffende)

Trodde jeg aldri skulle si det men Intel er bedre på navngiving av sine mobile CPUer. 4000 serien mobile som kommer snart er egentlig bare 3000 serien desktop, så man kan bli lettere forvirret av navngivingen til AMD. 

[Svein M]

G skrev (1 time siden):

I believe the problem is that ASUS AURA and AI Suite access the SMB Bus without using the proper interlocks to avoid bus access conflicts. ASUS AURA and AI Suite have been causing conflicts with Corsair Link, HWINFO, CPUZ, SIV, and other sensor monitoring utilities for years. These programs all use the proper interlock mutexes but ASUS does not as their program developers seem to assume that they are the only ones accessing the SMB Bus.

 

G skrev (1 time siden):

However, folks from G.SKILL R&D are really crazy with their idea to control LED lightning via SPD Write commands  It's a very dangerous idea! The only purpose of SPD EEPROM is to store SPD data! What the hell did they use SPD EEPROM to control LED? Neither solution will solve the SPD corruption issue, because of the concept itself to use SPD Write commands!

Høres ikke bra ut dette. Er det slik at oppsetts ting i minnebrikkene blir overskrevet og at dermed at minnebrikkene blir ødelagt, eller vil de fortsatt virke, eller kan en skrive inn igjen det som skal være der skal tro. Jeg har ikke satt meg inn i dette, så fortår det ikke fullt ut.

Ville i hvertfall avinstallert slik software.

Endret 24. august 2020 av Svein M

[G]

2 hours ago, TheKims said:

Trodde jeg aldri skulle si det men Intel er bedre på navngiving av sine mobile CPUer. 4000 serien mobile som kommer snart er egentlig bare 3000 serien desktop, så man kan bli lettere forvirret av navngivingen til AMD. 

Er enig med deg. Har vel blitt nevnt før. Men er kanskje aktuellt nå igjen når produktene ser ut å komme til overflaten?

Alle disse navnene ser ut å være Zen2 https://wccftech.com/amd-ryzen-2020-2022-cpu-apu-roadmap-leak-zen-2-3-4-families-unveiled/

• AMD EPYC Rome (2nd Gen EPYC)
• AMD Ryzen 3000 'Matisse'
• AMD Ryzen 3000XT 'Mattise Refresh'
• AMD Ryzen 4000 'Renoir'
• AMD Ryzen 5000 'Van Gogh'

En skal altså over på kodenavn Vermeer, Warhol (ble litt usikker på artikkelen rundt disse to) og Raphael for å finne generasjonsfornyelse på linje med Mainstream Desktop produktporteføljelinjen til AMD.

I og med, stemmer ikke overens med tabellen høyere opp i artikkelen, da Warhol kalles Ryzen 5000 Series der:

Spoiler

The full list of Zen 3 CPU and APU families include:

• AMD EPYC Milan (3rd Gen EPYC)
• AMD Ryzen 4000 'Vermeer'
• AMD Ryzen 5000 'Warhol'
• AMD Ryzen 5000 'Cezanne'
• AMD Ryzen 6000 'Rembrandt'

 

Ja! Så ganske fucked up 

Endret 24. august 2020 av G

[G]

45 minutes ago, Svein M said:

 

Høres ikke bra ut dette. Er det slik at oppsetts ting i minnebrikkene blir overskrevet og at dermed at minnebrikkene blir ødelagt, eller vil de fortsatt virke, eller kan en skrive inn igjen det som skal være der skal tro. Jeg har ikke satt meg inn i dette, så fortår det ikke fullt ut.

Ville i hvertfall avinstallert slik software.

Hehe, ja. Først må en jo være klar over hva som tres ned over hodet ditt. Samt, når man har feil produkt som er ment å skulle samarbeide med RAM-brikkens RGB, som er bundlet med produktet. Noe av programvare følger vel også BIOS (en uting?), mens annen programvare må etterinnstalleres manuellt.

Opplever f.eks. gjentatte forsøk med en plagsom lydprogramvare som krever omstart ut av det blå, er om starten som er mest plagsom da, ikke like plagsomt at den ikke finner ut at den allerede er innstallert 20 ganger tidligere, men fortsetter å be om å innstallere seg. "Sonic Radar eller noe sånn".

Kan vedde på at mange er sugne på å styre sin RGB når de først har kjøpt slik en RAM, og da innstallerer man jo i uvitenhet noe sånn, dersom dette er sannheter fra et G.Skill-forum da.

Endret 24. august 2020 av G

[G]

Quote

AMD Ryzen 4000G Renoir APUs Selling Like Hot Cakes in Japanese Retail Market, Entire Inventory Sold Out Within First Few Hours of Availability

https://wccftech.com/amd-ryzen-4000g-renoir-apus-sell-like-hot-cakes-in-japanese-retail-market/

[N o r e n g]

TheKims skrev (5 timer siden):

Trodde jeg aldri skulle si det men Intel er bedre på navngiving av sine mobile CPUer. 4000 serien mobile som kommer snart er egentlig bare 3000 serien desktop, så man kan bli lettere forvirret av navngivingen til AMD. 

Hva er forskjellen mellom i7-1065G7 og i7-10710U da? AMD har spredt Zen 2 ut over 3000 og 4000, Intel har spredt Skylake ut over 6000, 7000, 8000, 9000, og delvis 10000

[TheKims]

N o r e n g skrev (12 minutter siden):

Hva er forskjellen mellom i7-1065G7 og i7-10710U da? AMD har spredt Zen 2 ut over 3000 og 4000, Intel har spredt Skylake ut over 6000, 7000, 8000, 9000, og delvis 10000

Den første har bedre grafikk og høyere TDP? Nei jaggu ikke lett å si uten å ty til google ?

[The_Viper]

Nizzen skrev (På 16.8.2020 den 15.50):

G.skill 3600c15

 

https://www.prisjakt.no/product.php?p=3754103

Kortvarig glede disse minnebrikkene. Fikk ikke prøvd å overklokke heller. Holder seg gående i ca 5-10min før pcen bare fryser. Takk og lov at jeg ikke solgte det andre paret jeg kjøpte først. Kjørte på stock og.

[N o r e n g]

The_Viper skrev (10 minutter siden):

Kortvarig glede disse minnebrikkene. Fikk ikke prøvd å overklokke heller. Holder seg gående i ca 5-10min før pcen bare fryser. Takk og lov at jeg ikke solgte det andre paret jeg kjøpte først. Kjørte på stock og.

Hvilken prosessor har du?

[The_Viper]

N o r e n g skrev (12 minutter siden):

Hvilken prosessor har du?

3600X

[-=HellBound=-]

1usmus  kommer med en  ClockTuner for Ryzen  -> https://www.guru3d.com/news-story/clocktuner-for-ryzen-(ctr-by-1usmus).html

[N o r e n g]

The_Viper skrev (30 minutter siden):

3600X

Den bør ikke ha problemer med 3600 C15, og det er ikke FCLK for det gir en instant reboot. Satte du brikkene i rett spor?

[The_Viper]

N o r e n g skrev (Akkurat nå):

Den bør ikke ha problemer med 3600 C15, og det er ikke FCLK for det gir en instant reboot. Satte du brikkene i rett spor?

Har brukt brikkene noen dager. Brikkene stod i A2 og B2. Kjørt stock de dagene. Clear CMOS funket ikke, starter opp men fryser etter en stund.