Intel onderzoekt waarom games crashen op 13e en 14e generatie Core i9-processors

Intel gaat onderzoeken waarom sommige games crashen op desktopcomputers met Core i9-processors van de dertiende en de veertiende generatie. Het probleem lijkt zich vooral voor te doen bij een aantal games die gemaakt zijn met Unreal Engine.

"Intel is op de hoogte van problemen die zich voordoen bij het uitvoeren van bepaalde taken op de 13e en 14e generatie Core-processors voor desktop-pc's en is deze aan het analyseren met grote partners", zei een woordvoerder van het bedrijf tegen ZDNet Korea. De oorzaak van het probleem is op dit moment nog niet bekend.

Gebruikers met de processors in kwestie ervaren al enkele maanden verschillende problemen. Sommige gebruikers krijgen tijdens het spelen een foutmelding dat er niet genoeg geheugen is. Bij anderen sluit de game zich vanzelf af. Het probleem doet zich voor bij games als Tekken 8, Fortnite en Hogwarts Legacy. Al die games zijn ontwikkeld met Unreal Engine.

Epic Games heeft aan gebruikers laten weten wat ze kunnen doen als het probleem zich voordoet, totdat Intel met een oplossing komt. Het bedrijf stelt voor om de biosinstelling SVID Behavior te veranderen in Intel Fail Safe. Dat werkt volgens de ontwikkelaar op moederborden van ASUS, Gigabyte en MSI.

Reacties (87)

[Webber]

Interessant.

Ten eerste blij dat dit opgemerkt wordt door ontwikkelaars en als nieuws geplaatst op tweakers (anders had ik het nooit gezien). Zelf heb ik ook last van deze issues met een i7-14700K.

Ten eerste moest ik mijn Corsair Vengeance CMK64GX5M2X6800C32 omlaag halen van 6800MT/s naar 6600MT/s omdat anders de videokaart gegevens in het geheugen verkeerd plaatste (schrijven en daarna lezen gaf verschillende waardes). Hierna hielden BSODs volledig op.

Nog verder omlaag naar 6000MT/s of 6200MT/s gaf mij echter geen "nog stabielere" resultaten. Wel vallen games in UE met enige regelmaat uit. Vaak met een memory access violation, exact hetzelfde als de error die eerder in BSODs voor kwamen. Dit gebeurt zowel op de lagere geheugensnelheden als op de hoogst genoemde stabiele snelheid van 6600MT/s.

Gelukkig starten veel van die games tegenwoordig wel weer lekker snel op! En kan je bij moderne games vaak rejoinen, wat de frustratie sterk vermindert.

[Reactie gewijzigd door Webber op 22 juli 2024 13:17]

[GeertBoer]

Voor de i7-14700K recommend intel ook maar 5600MT/s https://www.intel.com/con...0-ghz/specifications.html

Een memory access violation is naar mijn idee de meest generieke error die je kan krijgen, dus het kan ook zijn dat het op een volledig andere manier veroorzaakt wordt dan door te hoge memory clocks.

[youridv1]

Dat klopt. Intel recommend altijd vrij conservatieve kloksnelheden en alles boven 5600MT/s is ook overclocking. Het is echter al jaren normaal om hoger te draaien en welke kits icm met jouw cpu op welk moederbord stabiel zouden moeten zijn, kun je daarom ook vinden op de QVL op de support pagina van je moederbord.

Wees je er van bewust dat alle benchmarks die je op internet ziet worden gedaan met veel hogere geheugenclocks dan 5600. Vaak 6400+

[Reactie gewijzigd door youridv1 op 22 juli 2024 13:17]

[FateTrap]

Op de ondersteuning pagina's van de CPU's van Intel staat ook niet aangegeven dat bvb de Intel Alder Lake 12600KF RAM boven 6000 MHz ondersteunt.

Ik heb zelf een 12600KF gekoppeld met RAM @ 6200 MHz en dit draait heel vlot op al de volgende besturingssystemen:

mageia, PCLinuxOS, FreeBSD, Alpine Linux, ROSA Fresh Desktop, Gentoo, OpenMandriva, Clear Linux, EndeavourOS, OpenBSD, ALT Linux, openSUSE, Void Linux, GhostBSD, Artix Linux, ChimeraOS

Ik heb ook al gelezen dat windows 10/11 minder goed is in het (stabiel) ondersteunen van hoge RAM frequenties boven 6000 MHz.

[Webber]

Zeker mee eens. Toch dacht ik dat mijn real world ervaring wat toevoeging kon geven voor andere mensen met dergelijke processoren.

Dat het geheugen niet goed wordt weggeschreven op de GPU (in case 1) doet mij ook vermoeden dat het een chipset issue zou kunnen zijn, gerelateerd aan de genoemde CPUs (wellicht ook voor case 2).

[CrazyBernie]

Had ook problemen bij overclocken met een 14900K bij alles boven de 6400MT regelmatig BSOD in visual studio.

Bij Burnin testen werkte alles prima op 6800MT. Maar bij praktijk gebruik dus niet.

Echter terugschakelen naar 6400MT wel al maanden rock solid.

[FateTrap]

Ik heb ook al gelezen dat windows 10/11 minder goed is in het (stabiel) ondersteunen van hoge RAM frequenties boven 6000 MHz.

Het zou wellicht interessant zijn als je 6800MT eens test op de volgende besturingssystemen:

mageia, PCLinuxOS, FreeBSD, Alpine Linux, ROSA Fresh Desktop, Gentoo, OpenMandriva, Clear Linux, EndeavourOS, OpenBSD, ALT Linux, openSUSE, Void Linux, GhostBSD, Artix Linux, ChimeraOS

Ik vermoed dat je in de praktijk geen problemen gaat zien.

[CrazyBernie]

Had ik dit jaar geen tijd voor.

Vorig jaar wel met Linux getest en de 13900k was het resultaat dat Linux veel eerder omviel bij memory en cpu overclocks dan Windows 11. Waar Windows dan in elk geval de burn in overleefde haalde Linux dat gewoon niet .

[GeertBoer]

Een driver bug lijkt me logischer

[youridv1]

Wel vallen games in UE met enige regelmaat uit. Vaak met een memory access violation, exact hetzelfde als de error die eerder in BSODs voor kwamen.

Een memory access violation is zelden het resultaat van een hardware stabiliteit of kloksnelheid probleem.

Memory access violation betekent dat je proces geheugen aan probeert te spreken wat niet voor dat process toegankelijk zou moeten zijn. Je hebt dat geheugen niet van windows gehad (of welke memory manager dan ook), dus krijg je geen toegang, dus crasht je programma. Over het algemeen is het een ordinaire programmeerfout.

Kan zijn dat je driver een access violation geeft als gevolg van dit hardware probleem, maar dat is wel zeldzaam.

Wat ik me kan bedenken is dat er een asset niet geladen wordt door geheugen instabiliteit en dat de programmeur is vergeten om die situatie af te handelen, waardoor hij probeert de ongeladen asset te accessen. Dan krijg je een access violation.

In het beste geval hoor je een missende asset of een crash naar main menu te krijgen. Een access violation betekent dat iemand ergens een return code of nullpointer check is vergeten.

Edit; Leuk, een "irrelevant" moderatie score voor het inhoudelijk uitleggen van een term die gebruikt wordt.

[Reactie gewijzigd door youridv1 op 22 juli 2024 13:17]

[MSalters]

Wat ik me kan bedenken is dat er een asset niet geladen wordt door geheugen instabiliteit

Niet hoe het werkt

en dat de programmeur is vergeten om die situatie af te handelen

Dat handel je niet af. Probleem van de overclocker.

[youridv1]

Dat handel je niet af. Probleem van de overclocker.

Dit is enorme onzin. Je kijkt altijd naar de returnvalue en je doet een nullpointer check als je een asset of een resource inlaadt.
Hardware problemen zijn niet de enige oorzaak van een asset of resource load fail en je checkt daar altijd op als je geen rommel software schrijft. @Alfa1970 verwoordt het heel goed.
Niet controleren of het geheugen de juiste data bevat is iets voor 1e jaars CS studentjes.
Jij omschrijft software schrijven met alleen happy flow. Dat is iets voor regelrechte amateurs.

Niet hoe het werkt

Dan heb je geen serieuze software development ervaring als je dit denkt. Praat gewoon niet als je geen verstand van zaken hebt.

Bizar dat je een positieve moderatiescore krijgt voor een bericht met een recordhoeveelheid misinformatie per woord.

[Reactie gewijzigd door youridv1 op 22 juli 2024 13:17]

[bwerg]

Een null pointer wegens geheugeninstabiliteit is juist flauwekul. Of je geheugen werkt betrouwbaar, of niet, en in dat laatste geval kan een programmeur helemaal niets meer.

Andere oorzaken van null pointers zijn helemaal niet relevant bij dit artikel. Sterker nog, dit hele artikel gaat niet over null pointers.

[Reactie gewijzigd door bwerg op 22 juli 2024 13:17]

[youridv1]

een access violation heeft een hoofdoorzaak: niet voor jou gealloceerd geheugen accessen. Een mooi voorbeeld daarvan is de nullpointer, maar het hoeft niet. Was gewoon een basaal voorbeeld van het soort sanity checks dat je in dit geval doet.

Een null pointer wegens geheugeninstabiliteit is juist flauwekul.

Neehoor, kan prima dat daardoor je resource load faalt en de library die je gebruikt dan geheugenadres null returnt.

Geen nullpointer of andere return code of errorcode check bij windows doen na het laden van een externe resource is wel echt een rookie mistake.

[Reactie gewijzigd door youridv1 op 22 juli 2024 13:17]

[bwerg]

Neehoor, kan prima dat daardoor je resource load faalt en de library die je gebruikt dan geheugenadres null returnt

Ja, dat kan prima. Hij kan ook corrupt geheugen teruggeven, wat je als programmeur nooit gaat ontdekken. Of je programmastack kan corrupt raken, waar je als programmeur niet eens iets mee kan. Effectief doet je programma niet meer dat wat je geprogrammeerd hebt, en je weet niet wanneer of hoe.

Mooi verhaal over hoe nullpointers en access violations kunnen ontstaan, maar met instabiel geheugen kunnen er tienduizend verschillende dingen misgaan. Inclusief je error check of error recovery zelf. Je daar als programmeur mee bezig houden is als een autofabrikant die zich bezig gaat houden met het scenario van een meteorietinslag.

Je hele verhaal over "rookie mistakes" gaat alleen op voor gangbare en voorspelbare i/o-fouten als ontbrekende bestanden, netwerkfouten en bugs in je programma of in libraries. Dat is bij de fouten waar dit artikel over gaat gewoon niet relevant.

Instabiel geheugen betekent crashende software, daar gaat geen programmeur iets tegen doen. Meer dan een algemene catch-all op OS-niveau, zonder garanties, zit er niet in.

[Reactie gewijzigd door bwerg op 22 juli 2024 13:17]

[Alfa1970]

Euh, nou, nee, als je als programmeur vergeet om je return te checken op een nullpointer ben je onverantwoordelijk bezig, en mag je naar mijn mening de titel programmeur niet eens dragen.
Dan krijg je van mij de titel 'hobby prutser'.

[bwerg]

Op nullpointers checken vanwege geheugeninstabiliteit? Dit is absolute flauwekul. Als je geheugen instabiel is dan is het totaal niet te voorspellen wat er fout gaat. Je kan dan helemaal niets meer aannemen, elke waarde kan corrupt zijn. Inclusief alles wat helemaal niet expliciet door de programmeur wordt beheerd maar door de compiler zelf, of door libraries.

Instabiel geheugen betekent onvoorspelbaar gedrag. Met heel veel geluk verandert er een bitje in de textures met "slechts" glitches als gevolg, maar in het algemeen krijg je gewoon crashes. Daar doet een programmeur niks tegen.

[Reactie gewijzigd door bwerg op 22 juli 2024 13:17]

[Alfa1970]

Nee, nullpointers returns moet je _altijd_ checken.
Want dan kun je netjes de zaken afhandelen, ongeacht de oorzaak.

Dat je als programmeur de oorzaak niet altijd kan beheersen, wil niet zeggen dat je er maar met je pet naar kan gooien.

En inderdaad, je kan niks aannemen bij een instabiel systeem, dus _altijd_ checken is het directief.

En zelfs dan kan het crashen, maar dan ben je er in ieder geval zeker van dat het niet aan de software ligt, of, in ieder geval niet aan "jouw" software.

[bwerg]

Wat is de relevantie van algemene programmeerregels bij dit artikel?

MSalters reageert op de opmerking dat de programmeur vergeten is het scenario van instabiel geheugen af te handelen, en niets meer dan dat. Die opmerking inderdaad gewoon onzin. Of er verder programmeerfouten zijn gemaakt bij het inladen van resources gaat ook gewoon geen verschil maken, je programma gaat crashen, dus ik zie niet in wat je punt over null pointer checks nou toevoegt.

[Alfa1970]

Ik reageer op het feit dat hij beweert dat de onkunde van de programmeur het probleem moet zijn van degene die hij als verdachte aanwijst voor het onstabiel maken van het systeem.
En jij die dat lijkt te onderschrijven.

Ongeacht de oorzaak van de onstabiliteit moet de programmeur er gewoon zorg voor dragen dat zijn software geen memory access violation veroorzaakt, en dat kan prima ongeacht of een systeem stabiel is of niet.

[Hatseflats]

Zo mooi. Ik moet er altijd wel om lachen, dit soort mensen. Om 20:58 reageren op jouw stukje en om 7:48 brabbelen en terugkrabbelen als hij er niet meer uit komt en de relevantie ter discussie stellen.

Het vermoeden rijst dat we hier met een nieuw soort programmeur te maken hebben.

[bwerg]

"Terugkrabbelen"? Het artikel gaat over het falen van memory (controllers), MSalters geeft aan dat je daar als programmeur niks mee te maken hebt (klopt als een bus), Alfa1970 blijft hameren dat een programmeur altijd null pointers moet checken, wat echt niks met de oorzaak en het probleem van het artikel te maken heeft, noch met de reactie van MSalters, en dan is het lachen dat ik de relevantie ter discussie stel?

Juist ja. Jullie snappen het helemaal. Gewoon null checks en doen en dan draait jullie software helemaal top op systemen met instabiel geheugen. We hebben inderdaad met een heel nieuw soort programmeur te maken.

[Reactie gewijzigd door bwerg op 22 juli 2024 13:17]

[bwerg]

Ik reageer op het feit dat hij beweert dat de onkunde van de programmeur het probleem moet zijn van degene die hij als verdachte aanwijst voor het onstabiel maken van het systeem.

Deze conclusie die je uit zijn reactie trekt snap ik totaal niet.

Hij zegt: geheugeninstabiliteit veroorzaakt niet het "niet laden van assets" en de programmeur handelt scenario's met instabiel geheugen niet af. Klopt allebei als een bus. Meer zegt 'ie niet. Meer onderschrijf ik ook niet.

Hoe je op onkundige programmeurs uitkomt is me een compleet raadsel.

[Reactie gewijzigd door bwerg op 22 juli 2024 13:17]

[Hatseflats]

The gift that keeps on giving.

[MSalters]

Welke API heeft een "returns nullptr on memory corruption"? Noem er eens een?

Je checkt nullpointers waar dat gedocumenteerd is. De rest is voodoo programming.

[Alfa1970]

Sigh, really, programming 101:
Controleer de waardes van de argumenten als jouw functie wordt aangeroepen.
Als je zelf een functie aanroept, controleer dan de waarde van de output van die functie.
It's that simple.
Ongeacht wat gedocumenteerd is, want in héél veel software is de documentatie (te) oud of gewoon domweg verkeerd, en je kan ook niet vertrouwen op de comments in de code want ook heel vaak zijn die out of whack met de werkelijkheid.

[Robinblitz]

Ik heb zelf een i9-13900k met 6400 MT/s CL32, dit kwam gepaard met veel BSOD's als ik aan het gamen was die terug te herleiden was naar de memory. Ook ik heb dit naar beneden moeten brengen naar 6200 MT/s CL34 voordat deze crashes ophielden.

Dit was overigens niet alleen met Unreal Engine games (Gebeurde ook bij Escape From Tarkov, Unity)

[computerjunky]

Je kan ook proberen het voltage met 0.02v te verhogen dat wil nog wel eens helpen bij intel. Sommige borden malen er echt een zooitje van. Zo ook een mail bord waar ik een systeem mee gebouwd had. Totaal onstabiel bij bepaalde loads tot ik geheugen voltage verhoogde.

[Reactie gewijzigd door computerjunky op 22 juli 2024 13:17]

[mr_evil08]

Hier geen issue,s met de i7-14700K en XMP ingeschakeld met supported geheugen, verder geen overclocking.

Mogelijk speel ik te weinig Unreal engine game,s Ark Ascended en Fortnite draait in iedergeval probleemloos uren lang.

Wel een knaap van een waterkoeling aanwezig ofwel de processor wordt niet snel warm.

[Reactie gewijzigd door mr_evil08 op 22 juli 2024 13:17]

[Buck Naked]

Bij mij exact hetzelfde. Heb een 13900kf met een Corsair 7200MHz ram setje moest deze terugzetten naar 7000MHz om het systeem stabiel te krijgen. Daarvoor vastloper na vastloper en benchmark errors. Dacht eerst weken dat het aan mijn RTX4090 lag.

Denk dat Intel hun chips veel te ver pushen om competitief te kunnen blijven. Snap echt niet waarom ze niet tijdelijk overstappen op TSMC of Samsung voor een lager productieproces totdat ze eindelijk zelf bij zijn.

[Webber]

Ik dacht eerst ook dat het aan mijn grafische kaart lag. Totdat ik een nauwkeurige omschrijving van het probleem kreeg door middel van een trial versie van BurnInTest. Die gaf keurig aan waar het probleem lag.

[Probook8979]

Wat gaf djt applicatie aan?

[computerjunky]

Heb je geprobeerd handmatig het geheugen voltage iets te verhogen? Met een rig die ik gebouwd heb voor iemand was 0.02v genoeg om het stabiel te krijgen op xmp. Sommige borden zijn gewoon niet optimaal zo lijkt het.

[rickyy]

Ik kan me herrineren dat ik dit issue over menory violation ook een tijdje heb gehad met mijn i5 11400f, 32gb ddr4 en rx3060. Ik kwam erachter dat DLSS uitzetten dit voor mij oploste. Nu een paar maanden later kan ik het weer zonder problemen aanzetten.

Misschien even in de hoek van framegen kijken.

[WiXX]

Heb net een i7 van de 13de generatie besteld. Geld dit ook voor deze processoren of is het alleen de i9?

Edit: In dit bericht wordt er alleen gesproken over de i9, maar op X gaat het ook over i7's

[Reactie gewijzigd door WiXX op 22 juli 2024 13:17]

[rain2reign]

Volgens Tomshardware betreft het ook de Core i7-13700K, maar of het andere Core i7 processoren betreft, zoals de Core i7-14700K, is voor mij nog niet duidelijk voor zover ik gelezen hebt.

[Webber]

Dit geldt ook voor de i7-14700K. Zie mijn andere bericht voor gedeeltelijke maar niet sluitende workaround.

[Webber]

Gaat ook over de i7's weet ik uit ervaring.

[Countess]

SVID heeft te maken met het dynamic veranderen van het spanning(volt) van de CPU. De I9's staan daarin strakker afgesteld als de i7's en zullen waarschijnlijk minder foutmarge hebben op dat gebied, zeker als ze op hun maximum turbo frequentie draaien.
Er is een redelijk kans dat het deels een kwestie zal zijn van gelukt, en dat als je de silicon lottery hebt verloren dat je met een i7 er ook last van zou kunnen hebben.

[Reactie gewijzigd door Countess op 22 juli 2024 13:17]

[Xfade]

Heb al sinds het begin een 13700k met 6400mhz geheugen. Nog nooit een crash gezien. CPU ook met 0.1v undervolt.

[Toonen1988]

Ik heb de afgelopen maanden meerdere keren "out of memory" en "EXCEPTION_ACCESS_VIOLATION(0XC0000005)" crashes gehad in diverse games en engine's.

Sinds ik Intel Extreme Tuning Utility gebruik en mijn performance ratio core van 57x naar 54x heb gezet, draaien games stabieler.

Ik heb de I9 14900kf.

[Reactie gewijzigd door Toonen1988 op 22 juli 2024 13:17]

[CriticalHit_NL]

Ik heb de afgelopen maanden meerdere keren "out of memory" en "EXCEPTION_ACCESS_VIOLATION(0XC0000005)" crashes gehad in diverse games en engine's.

Die 0xc0000005 code is vaak gerelateerd aan geheugenproblemen, heb je al eens een mem-test gedaan om er zeker van te zijn dat deze geen fouten genereren?
En anders maar eens proberen een lagere geheugensnelheid in te stellen en/of XMP uit te schakelen.

Hoop dat je ook, indien het 2 modules zijn, deze in de geprefereerde slots hebt gedaan, lees wel vaker dat de secundaire slots van wat mindere kwaliteit lijken te zijn, maar dat kan ook zijn omdat de primaire gebruikte slots op het 'einde' van het circuit zitten om terug naar de CPU te gaan i.p.v. dat het geïnstalleerde geheugen ook nog eens eerst door een leeg slot heen moet, wat dus voor meer ruis kan zorgen op het signaal, en met een ruisig signaal kan de CPU weinig dan fouten smijten.

Tenminste, dit is wat ik her en der lees en begreep hoe dit zat.

[Toonen1988]

Lagere snelheid heb ik ook al geprobeerd, ben ondertussen al van 6000mhz naar 3800mhz gegaan zonder enige vooruitgang.

Nu sinds ik de performance core ratio van 57x naar 54x ben gegaan, heb ik geen enkel probleem meer gehad. Sterker nog, ik heb zelfs een gevoel dat games zelfs beter lopen.

Maargoed, ik ga volgende maand een nieuwe behuizing, moederbord, koeling en voeding kopen. Wil nog een betere koeling en moederbord hebben, dan kan ik ook naar mijn geheugen kijken.

[CriticalHit_NL]

Vraag me af of de cache van de CPU ook zoiets teweeg kan brengen, het is immers ook een soort-van geheugen. Maar gelukkig heb je een oplossing gevonden.

[Ohiobob]

Ook veel crashes gehad, in verschillende games.
Sinds het uitschakelen van de kern isolatie stack beveiliging geen crashes meer. ( Geloof dat deze functie op deze cpu's alleen actief zijn )

[Reactie gewijzigd door Ohiobob op 22 juli 2024 13:17]

[CriticalHit_NL]

Apart, kernisolatie staat hier standaard uit op Windows 10 22H2.
Heb ook wel Hogwarts en andere UE-titels gespeeld maar nooit geen crashes.

[PainkillA]

dat mensen nog intel kopen op dit moment. Verbruiken ongekende hoeveelheid stroom voor gelijkwaardige prestaties met amd waarbij ze ook nog eens duurder zijn.

[CriticalHit_NL]

Vaak zijn de CPU's af-fabriek met te hoge voltages ingesteld om zich potentieel in te dekken voor minder gebinde CPUs die dan wel crashen op lagere voltages, maar veelal is het prima mogelijk een undervolt te doen, lagere hitte te bewerkstelligen en zo throttling de kop in te drukken dus meer performance over te houden dan als je door hitte throttling zou krijgen.

Als je enkel games speelt is zo'n X3D type Ryzen natuurlijk wel tof, alleen als je veel RAM wilt heeft AM5 vaak nog wel wat meer problemen met DDR5 op grotere capaciteiten stabiel te krijgen, even afgezien van het lange memory-trainingsproces na elke verandering van de instellingen.

Maar de 7950X t.a.v. de recente twee i9's is echt situatie-afhankelijk waar ze in uitblinken, ieder heeft zijn sterkere punten, de 7950X3D versie is dan weet wat minder gezien dat geknoei met de CCDs waarvan er maar eentje de extra cache krijgt voor de game-prestaties, niet echt een lekker compromis.

Ik zou me trouwens eerlijkgezegd wel wat irriteren aan de Ryzen heatspreader, de koelpasta kan er lekker tussendoor glibberen als je niet uitkijkt.

Waar recent overigens je nog getallen van +340W zag als totaal verbruik in de recente best-buy-guide van processoren is dat vaak makkelijk met enkele tientallen te verlagen zonder op prestaties in te boeten.

Overigens liggen de uitvoering: AMD Ryzen 9 7950X Boxed en uitvoering: Intel Core i9-13900K Boxed niet mijlenver uit elkaar in dit geval, een 7800X3D kan weer niet zo goed dezelfde zware workloads doen die deze CPUs wel kunnen, allemaal afwegingen.

[Zorian]

Ik heb zelf de i9 13900k maar ben niet bekend met deze problemen (gelukkig). De genoemde spellen heb ik ook gespeeld, maar geen crashes of andere vage dingen gehad die worden genoemd in het artikel. Ben benieuwd waar het probleem exact door veroorzaakt wordt en of het met een simpele bios update verholpen kan worden.

[Matthieu]

Ik heb tijdens de lancering van call of duty modern warfare 3 hier een filmpje over gemaakt.

Het heeft te maken met
Ram boost mogelijkheden.

Zet je ram op de juiste frequentie
Xmp lekker aanzetten.
Overige ram tweaks uit laten.

De meeste laatste bios updates fixen dit automatisch.

Tweaks op de cpu vanuit de kernel zou kunnen, maar ik heb daar met de 14600kf geen last van.

[Reactie gewijzigd door Matthieu op 22 juli 2024 13:17]

[CriticalHit_NL]

Ik heb hier geen last van, pas als ik de undervolt nog een stuk omlaag ga gooien dan gaan inderdaad te onpas applicaties crashen of blauwe schermen getoond worden.
Veelal makkelijk te triggeren via applicaties als Cinebench R23.

Maar onlangs nog een 30 minuten duurtest gedaan, 290W maximaal verbruik, 1 core tikte maximaal 90°C aan en dus nergens throttle.
Volledig stabiel en dus geen crashes.

Enige probleem dat ik nog wel eens heb dat sommige applicaties als paint.net niet willen starten, of battlenet sporadish.
Dan is het proces gewoon vastgelopen, wellicht kunnen ze niet goed omgaan met de P/E cores en de omvang van de hoeveelheid cores.

Anderzijds zijn er ook games die maximaal bijvoorbeeld 16 cores aankunnen, en met meer geen raad weten en dan gewoon niet starten.
Daar is uiteraard wel een workaround voor, maar dat kan je de CPU ook niet de schuld van geven.

Inmiddels anderhalfjaar tevreden gebruiker.

Setup:

• i9 13900K stock @ -0.06v Global SVID undervolt
• Asus ROG Maximus Z790 Extreme (bios 0219 begin September 2022)
• 4x32GB DDR5-5600 Corsair Dominator Platinum RGB CL40 @ 5400Mhz XMP ingeschakeld.
• EVGA GTX1080Ti FTW3 11GB
• Corsair AX1200i
• Corsair H170i met 6x Noctua NF-A14 3000RPM fans.

En de SP rating van de CPU is maar '97' wat erg middelmatig is als Silicon Prediction (kwaliteit van de CPU)

[Reactie gewijzigd door CriticalHit_NL op 22 juli 2024 13:17]

[mr_evil08]

De P/E core,s nooit problemen gehad behalve een game gaat stutteren omdat een process van de game op een E-core draaide, dan druk ik op scroll lock tijdens gamen waarbij de E-core,s parked worden en is het stutteren direct over.

Ik gebruik Windows 11.
Ik ben nog nooit game,s tegengekomen die niet overweg kunnen met 24 threads, wel eens dat ze op de verkeerde threads/core,s draaien maar dat kost alleen performance en zorgt niet voor een crash.

Hier een i7 14700K.

[Reactie gewijzigd door mr_evil08 op 22 juli 2024 13:17]

[CriticalHit_NL]

De scroll-lock methode werkt hier niet, moet je volgens mij software voor actief hebben?
Windows 10 22H2 hier overigens.

Spellen die ik ondervonden heb die er last van hebben:

• Catherine Classic
• Far Cry 2
• Far Cry 3

Far Cry 3 lijkt het enkel te werken door de cores echt via de bios uit te zetten, want door de Ubisoft DRM werken de andere workarounds niet.

Dit heb ik in de review ook hier besproken:
https://tweakers.net/prod...13900k-boxed.html#part_46

Stutteren door E-cores ook geen last van, sterker nog, World of Warcraft Retail spelen bijvoorbeeld op de E-cores only levert vrij vergelijkbare prestaties op eigenlijk tegen lagere hitte en stroomverbruik.

[mr_evil08]

De scroll-lock methode wordt hier vanuit de bios aangestuurd(moet je wel aanzetten), geen software voor nodig, vanuit monitoring in Windows zie ik netjes dat de e-core,s parked worden bij indrukken van de toets.

De game,s die ik speel leunen meer op single core performance dan is het belangrijk dat het wel over de P core,s gaan.

[Reactie gewijzigd door mr_evil08 op 22 juli 2024 13:17]

[CriticalHit_NL]

De scroll-lock methode wordt hier vanuit de bios aangestuurd(moet je wel aanzetten), geen software voor nodig, vanuit monitoring in Windows zie ik netjes dat de e-core,s parked worden bij indrukken van de toets.

De game,s die ik speel leunen meer op single core performance dan is het belangrijk dat het wel over de P core,s gaan.

Je hebt gelijk, kwam in het in een oud bios screenshot tegen, maar het staat uit:
https://i.imgur.com/uMWxkYv.png

Wellicht omdat ik toen dacht, dat heb ik niet nodig, misschien maar eens mee experimenteren.

Doorgaans vind ik het wel prettiger de E-cores gewoon verder aan te laten, qua performance is het soms een gain en soms een verlies als je enkel op de game focused, maar door de bank genomen valt het wel mee, zoals hier ook te zien is:
https://www.techpowerup.c...nabled-vs-disabled/2.html

Zeker omdat ik persoonlijk wel veel multi-task tijdens het gamen, dan is meer wel prettig.

[mr_evil08]

Die optie kun je ad-hoc inschakelen en weer uitschakelen met de scrolllock toets, doorgaans als je pc uitzet staan de e-core,s bij het opstarten sowieso weer aan.

Ik doe het alleen als een game er problemen mee heeft en dat gebeurt nog wel eens, ik merk het bijvoorbeeld aan de frame time,s of stuttering.

Windows 11 zou het perfect moeten doen maar in praktijk niet altijd, per game verschillend wat techpowerup ook laat zien.

[Reactie gewijzigd door mr_evil08 op 22 juli 2024 13:17]

[dasiro]

is je GTX1080Ti geen bottleneck in games die er ook voor zou kunnen zorgen dat je er geen last van hebt? De rest van je setup is redelijk recent al is die hoeveelheid memory aan zo'n lage snelheid ook eerder een limiterende factor voor je CPU.

[CriticalHit_NL]

Voorheen zat hij gecombineerd met een i7 3930K @ 4.4Ghz, maar deze had wel eens situaties waar deze op zijn tenen moest gaan lopen waardoor de GPU eigenlijk minder kan dan hij zou moeten kunnen.

Nu zit hij gecombineerd met deze CPU, en heeft hij meer CPU kracht tot zijn beschikking gekregen om stabieler zijn volledige potentie te benutten, zelfs een ouder spel als GTA V heeft er profijt van want de extended-distance sliders kunnen nu gewoon maximaal staan zonder dat het een probleem vormt, hij draait dit als een zonnetje met 1440P en 1.5x framescaling (en dus in feite 4K qua zwaarte) op Very High/Ultra mix.

Zie: https://i.imgur.com/yBY6nz7.png

De videokaart is inmiddels 7 jaar oud, maar de spellen die ik ermee speel voldoet hij nog prima, zeker die 11GB VRAM heeft hem geholpen zo lang te overleven, het is in feite een RTX 4060 qua performance, maar dan met meer VRAM zonder ray-tracing/DLSS.

Een aantal benchmarks kan je hier terug vinden:
Intel Core i9-13900K Boxed review door CriticalHit_NL

Verder prefereer ik meer CPU kracht boven een dikke GPU, want zonder een dikke CPU heeft een dikke GPU vaak in games een bottleneck en kan hij zijn kracht niet kwijt.

Maar ook omdat ik meer doe dan alleen gamen, virtuele machines, inpakken van grote bestanden met WinRAR waarbij zelfs soms meer dan 100GB geheugen wordt gepakt om de compressie te verhogen, en natuurlijk video's renderen en dat soort zaken, soms draai ik zelfs twee spellen tegelijkertijd dan is die VRAM wel lekker en de CPU voelt zich nog steeds als een kind in het water.

Overigens, na de 1080Ti waren er eigenlijk ook geen aanlokkelijke aanbiedingen qua videokaarten, ze hadden vaak of minder VRAM, of weinig extra, of leveringsproblemen dan wel prijzen door crypto, terwijl ik toen ook geen noodzaak had om te upgraden.

En de RTX4090 is het geld niet waard wegens het missen van Display-Port 2.1 waardoor je niet compressie-loos hoger dan 4K 120Hz kan gebruiken, terwijl die kaart daar wel toe in staat is... Dus de RTX 5090 wordt waarschijnlijk de upgrade, GDDR7 en 32GB VRAM met een 512-bit bus wat dus ook voor hogere resoluties ten goede moet komen voor de performance door de grotere bandbreedte.

Wat betreft wat je zegt dat de oudere GPU hier niet voor zorgt, nee, die instabiliteit kan al prima gebeuren zonder dat de GPU vol belast wordt.

Dit zit hem mijn inziens echt vooral in de CPU-kant van het verhaal, en wellicht het gebruik van DDR5-geheugen wat gewoon te hoog is geklokt terwijl de memory-controller dit niet vreet.

Mijn DDR5 modules voor totaal 128GB zijn van origine wel 5600Mhz, maar dat werkt vaak enkel maar goed met 2-sticks, 4 sticks lukt het velen al niet stabiel boven 4800-5200Mhz te komen, zeker bij de huidige AM5 processoren speelt dat probleem nog erger en krijgen vaak XMP niet eens stabiel ingeschakeld. Bij AM5 hebben deze ook lange tijden voor het trainen van het geheugen, daar heb ik gelukkig dan geen last van.

En mensen kopen dan vaak memory-modules met strakkere timings dan CL40, en dan vergroot je die kans dat er problemen optreden. van 5600Mhz naar 5400Mhz was hier genoeg om in memtest geen memory-errors meer te krijgen.

In dit geval was meer geheugen ook fijner dan hoger geklokt geheugen, overigens is alles boven 5600Mhz ook officieel gezien een overclock voor het moederbord én CPU, voor dat kleine beetje ga ik niet liggen creperen met 32GB RAM, het oude i7 3930K systeem liep soms al vol met 32GB DDR3-1866 CL9 en idle kom ik niet meer onder de 9-10GB uit, vaak meer dan 16-20GB en regelmatig boven 40-50GB verbruik, die oude i7 liep al 8.5 jaar mee en deze mag het dunnetjes overdoen.

[dasiro]

ik zit zelf met een overgeërfde GTX1070 in m'n 7600X-build (voordien een i5-6600 non-K), dus ik snap perfect je keuze voor een meer CPU/MEM oriented build.

Aangezien het probleem nog in onderzoek is, zal de toekomst de oorzaak nog wel uitwijzen, maar ik vermoed dat de meeste gamers met een i9 ook wel een recentere kaart hebben, waardoor de CPU allround mss meer belast wordt ipv specifiek de memory controller. GTA V is zoals je zegt een ouder spel dat qua engine en drivers al heel wat jaren aan bugfixes achter de rug heeft, dus dat zou misschien ook geen probleem-scenario kunnen opleveren.

Qua ram gebruik weet iedereen dat er meer gebruikt wordt als er meer beschikbaar is, dus daar zou ik me geen zorgen over maken. XMP geheugen op een AMD-build heb ik mogen ondervinden dat dit inderdaad geen leuke combo is boven stock-speeds, terwijl een setje specifiek EXPO het wel stabiel deed, al was dit in de begindagen van AM5. Beiden zijn eigenlijk hoe langer hoe minder goed te vergelijken, getuige het feit dat er meer en meer merk-specifieke/geoptimaliseerde setjes uitkomen.

[Osiummaster]

Heeft dit met de big-little architectuur te maken?

[mr_evil08]

Dan had de 12th gen het ook gehad.

[VultureX]

Deze dingen zijn by default niet stabiel. Dat heeft niets met Unreal Engine te maken.
Ga maar eens flink lang code compilen, of memory / disk intensive productivity werk doen. Je krijgt allemaal onverklaarbare problemen en zelfs data corruption op een gegeven moment, echt waardeloos. Het enige wat helpt is om flink de power te limiteren, maar dan lever je ook 10% performance in.
Ik vermoed dat het uiteindelijk aan te hoge temperaturen ligt en dat wordt natuurlijk erger naarmate je pc langere periodes aanstaat.

[Reactie gewijzigd door VultureX op 22 juli 2024 13:17]