Archief - Beeld freezed soms tijdens gaming

Mja een raar probleem. Mijn beeld freezed af en toe tijdens het gaming (net alsof de pc vasthangt, met sounds loops etc..) na een paar seconden loopt het echter terug vloeiend. Ik heb dit bij NFSU2 en HL2. Details wel op het zwaarste, maar dit mag geen probleem zijn (en afgezien van die freezes heb ik geen snelheidsproblemen in die 2 spellen)

Specs
AMD A64 3200+
DFI Lanparty UT250gb (nforce 3)
1GB OCZ Platinum PC3200
Aopen 6800GT 256MB DDR
Levicom 430W

Dit zal zowat het belangrijkste zijn, laatste drivers installed ofcourse.
Ikzelf dacht aan een load-time van de HD, maar dan zou ik geen sound-loops krijgen imo

temperatures tijdens gaming:
CPU 38°C (watercooled)
GPU 50-60°C
PWM IC 50°C (wtf is dit juist?)
System (ambient of chipset?) 33°C

Thanks op voorhand

welke voeding(ook zeer belangrijk he)

uiteraard, stupid me (edited)
Maar de voltlijnen lijken me stabiel, en ik zou eerder rekenen op een ECHTE vastloper moest de voeding niet sterk genoeg zijn.

ik heb ook zo iets gelijkaardigs voor met 3DMark03. Beeld freezed ff en gaat dan weer gewoon voort. Ben momenteel nog aan uitdokteren aan wat het zou liggen.
Bios? Side Band Adressing of fastwrites?
OS? verkeerde volgorde van installatie, eerst chipsetdrivers dan vga drivers ( wat ik net omgekeerd deed )
Hebt ge al een format geprobeerd?

Is pas een fresh install dus

moeha, al problemen met uwe nieuwe pc

ik heb vroeger ook es zoiets gehad, maar khad dat ook in windows zelf en werd veroorzaakt door dat windows blijkbaar een scsi apparaat geinstalleerd had maar omdat dat er helemaal niet was bleef gans de boel soms hangen omdat em daarnaar aant zoeken was...

en een paar weken terug heb ik het ook nog eens gehad, en toen was het omdat ik een SATA bij had aangesloten waardoor de hardware volgorde van men hd's veranderde en windows ATA drivers voor een SATA gebruikte en omgekeerd :doh: (hd gecrashed de dag erop )

2 keer een gelijkaardig prob veroorzaakt door hd drivers, dus kzou daar es naar zien

SoliD zei:

Is pas een fresh install dus

Klik om te vergroten...

als u beeld freezt, probeer dan is iet te typen. check daarna of die 'text' er is bijgekomen. kem gelijkaardig probleem (ben bezig met oplossing)

Bij HL2 zou er een soundbug zijn heb ik gehoord maar meer info weet ik niet.

Mjah het probleem lag dus aan AGP Fastwrites en sideband adressing. Nietszeggende functies zonder enige performancewinst, dus afgezet, en ik had het niet meer

SoliD zei:

Mjah het probleem lag dus aan AGP Fastwrites en sideband adressing. Nietszeggende functies zonder enige performancewinst, dus afgezet, en ik had het niet meer

Klik om te vergroten...

Waar zette die af? Ik heb exact hetzelfde probleem =)

imo in bios

dat moet dan toch aan uw mobo liggen ze, DFI, tja. En dat doet wel iets hoor die fastwrite.

Zowel "Sideband addressing" als "FastWrites" hebben te makken met de communicatie tussen videokaart en de rest van het systeem (meer specifiek met het geheugen). In een AMD64-systeem (zoals het jouwe) wordt de video-poort verbonden met het systeem door een zgn. AGP-bridge (in geval van een AGP-poort of via een PCI-Express bridge in het geval van een PCI-Express systeem). Een bridge verbindt 2 communicatie-systemen en vertaalt (in dit geval) de data van het ene formaat (hier AGP) naar het andere (hier HyperTransport).

In een klassiek systeem (P4, AXP) communiceert de videopoort rechstreeks met de northbridge/memory-controller. In een AMD64-systeem moet de data dus eerst via de bridge naar de CPU; pas dan kan die aan het geheugen (omdat de memory-controller in de CPU gebakken is).

Wanneer de CPU voor een of andere reden met andere zaken bezig is (een interrupt afhandelen bijvoorbeeld), dan zal de request naar het geheugen even opgehouden worden. Vandaar dat er wat vertragingen kunnen optreden.

Waarom treden die dan alleen op met "Sideband addressing" en/of "FastWrites" aan? Omdat die rechstreekse communicatie toelaten tussen videokaart en RAM zonder tussenkomst van de CPU (of tenminste: daar gaan die vanuit). Aangezien dat bij een AMD64 niet kan, worden die calls toch nog onderbroken door de CPU. De videokaart en de drivers gaan daar echter niet vanuit en nemen ook geen speciale voorzorgen om stalls te voorkomen (wat ze zonder die features dus wel doen). Dit geldt voornamelijk voor "FastWrites". Ik denk dan ook dat "Sideband addressing" niet echt het probleem vormt in jouw geval maar wel "FastWrites".

Conclusie: op een AMD64-systeem heb je eigenlijk niets aan "FastWrites" aangezien alle requests toch naar de CPU gestuurd worden.

P.S.: Ik kan het natuurlijk fout hebben he; ik leid ook maar zaken af uit zaken die ik her en der lees

In HL2 had ik dat ook , was weg na een defrag.

SoliD zei:

Mjah het probleem lag dus aan AGP Fastwrites en sideband adressing. Nietszeggende functies zonder enige performancewinst, dus afgezet, en ik had het niet meer

Klik om te vergroten...

Ja kzei het, die twee hebben mijn GT ook altijd al doen vastlopen.

Dat van fastwrites off zetten heb je duidelijk uitgelegd. Maar ze zeggen ook dat het best is om agp op 4x te zetten ipv 8x.
Heb je daar ook zo'n uitleg voor ?

AGP zou ik alleen op 4x zetten indien ge instabiliteit hebt ofzo, anders is da niet nodig..

Dat heb ik anders nog nooit gehoord dat van die AGP 4x.

FmTx^ zei:

Dat van fastwrites off zetten heb je duidelijk uitgelegd. Maar ze zeggen ook dat het best is om agp op 4x te zetten ipv 8x.
Heb je daar ook zo'n uitleg voor ?

Klik om te vergroten...

Ik kan het proberen...

AGP8x en AGP4x werken beiden op een kloksnelheid van 66 MHz. AGP4x is quad-pumped wat betekent dat er 4 keer per kloktik data wordt verstuurd. AGP8x is 8-pumped waardoor er 8 pakketten per kloktik worden verstuurd. Het probleem hier ligt niet aan een verschil in trace-length (= de lengte van de circuits; vreschillen in lengte van verschillende parallelle banen voor eenzelfde circuit geeft timing-problemen die erger worden naarmate de kloksnelheid hoger wordt: dit omdat de parallelle signalen voor 1 pakket dan niet perfect gelijktijdig toekomen op het eindpunt) aangezien het probleem dan zowel in AGP4x mode als AGP8x mode zou optreden (beide draaien immers aan 66 MHz).

De problemen met AGP8x zijn niet nieuw: die kwamen ook voor bij de introductie van AGP4x (o.m. de beruchte problemen met Radeon 9700 kaarten). Deze problemen werden toen toegeschreven aan problemen met de moederborden enerzijds (BIOS-flash bood gewoonlijk de oplossing) en aan te strikte standaard-navolging van de kaartenbakkers anderzijds (rma of BIOS-flash van de kaart moest dat dan verhelpen).

In de standaarden wordt gespecifieerd hoe signalen worden verstuurd. Als fabrikant kan je die standaarden best ruim interpreteren en moet je rekening houden met speling op de aangegeven waarden. Als je zeer strikt de signalen verwacht die in de standaarden gespecifieerd staan, en het signaal komt wat vervormd toe, dan zal je dat signaal niet (of verkeerd) interpreteren. Resultaat is instabiliteit.

Waarom treedt dat dan meer op bij AGP8x dan bij AGP4x? Ik vermoed dat de signalen in 8-pumped systemen makkelijker met elkaar kunnen interfereren dan bij quad-pumped systemen. Dus een afwijking die verkeerd uitgelezen wordt kan dan sneller voorvallen.