Új hozzászólás Aktív témák
-
Fiery
veterán
válasz Oliverda #248 üzenetére
A komolyabb, modern DFI lapokon van egy feszultseg szabalyzo, ami a monitorozo szoftverek jol megszokott SMBus scannelese kozben fejreallitja a gepet. Mar beszeltunk a DFI-jal ez ugyben, de csak annyit tudtak mondani, hogy az ilyen lapoknal tiltsuk le az SMBus scannelest bizonyos SMBus eszkoz cimekre.
Itt egy uj EVEREST beta verzio, amiben mar elvileg le van tiltva az SMBus scanneles a lapod (es sok mas, pl. X38 chipsetes DFI lap) eseteben.
Ird meg, hogy jol mukodik-e most mar. Koszi!
-
Fiery
veterán
válasz Oliverda #258 üzenetére
Sajnalatos ez az eset, bar kicsit furcsa, hogy masoknal nem tortent (me'g) ilyesmi. Az unnepek utan razorgunk a DFI-ra, hatha ki lehetne talalni valami megoldast arra, hogy a jovobeni LANParty lapoknal ne kelljen az alaplap azonositojat tudni ahhoz, hogy elkeruljuk az ilyen eseteket. Valamint, szerzunk egy LANParty alaplapot, aminel melyrehatobban tudjuk tesztelni ezt a jelenseget -- remelem, nalunk nem fog "megzabalni" tobb procit is az alaplap, mire kisakkozzuk a dolgot
Megjegyzem, az Intel altal gyartott lapoknal (pl. D975XBX2) is ugyanigy fejreall a fesz.szabalyzo, de ott csak annyi tortenik, hogy a CPU core feszultseg visszaall alaphelyzetre (pl. 1.35V), es igy csak a tuningolt procik fagynak le (ahol az alapfesz nem elegendo a mukodeshez).
Az is furcsa, hogy az alaplapod fesz.szabalyzo ezek szerint kepes extrem feszultseget eloallitani -- hiszen pl. ha 0.5V-2.5V tartomanyban dolgozna a fesz.szabalyzo, akkor a CPU a maximumot (2.5V) is elviselne rovid ideig, legalabbis fizikai karosodas nelkul.
[ Szerkesztve ]
-
Fiery
veterán
válasz Oliverda #485 üzenetére
Kuldj kerlek valamelyik benchmark oldalrol egy teljes screen shot-ot (emailben, uusi KUKAC freemail.hu), miutan futtattad a benchmarkot es 0-t adott eredmenynek.
Az EVEREST aktualis betajanak mappajaban ugye van EVEREST_BENCH.DLL fajl Nalad? Ha van, akkor mekkora a fajlmerete?
[ Szerkesztve ]
-
Fiery
veterán
válasz Oliverda #1238 üzenetére
Koszi, javitottuk a hibat.
A Cache & Memory Benchmark ablakon nincs annyi hely, hogy mindenfele plusz informaciot feltuntessunk. Ennyi erovel relevans lenne a HyperTransport, QPI es a North Bridge orajel is. De ha minden vackot kiirnank a panelre, akkor 800x600-as felbontasban nem ferne el a kepernyon A mai netbookos idokben pedig sajnos nem feltetelezhetjuk azt, hogy mindenki 1024x768-as vagy nagyobb felbontast hasznal.
-
Fiery
veterán
válasz Oliverda #1240 üzenetére
Az a baj tudod, hogy mindenki mas adatokat szeretne latni az EVEREST CPUID panelen es a Cache & Memory Benchmark panelen. Ezek a panelek azonban statikus grafikat hasznalnak hatternek, es igy nem lehet dinamikusan varialni, hogy milyen adatok jelenjenek meg. Arra termeszetesen lenne lehetoseg, hogy 1 db dedikalt mezo legyen mindenfele adatoknak, es azt be lehessen allitani, hogy az az a 1 db mezo mit jelenitsen meg. De ezzel a temaval egyelore nem foglalkoztunk, ugyanis elobb at akarjuk gyurni mindket panelt (es ujakat is tervezunk hamarosan), hogy tobb infot tudjunk adott feluleten megjeleniteni.
-
Balala2007
tag
válasz Oliverda #1825 üzenetére
A memoria bench ertekeket illetoen nekem ugy tunik, scientia keveri az elmeleti memsavszel fogalmat a kihasznalhatoval. Igaz, hogy mindket konfigban hasonlo memoriak vannak, kozel egyforma elvi savszellel (EVERESTben az Alaplap/Alaplap/Memoriabusz tulajdonsagai alatt nezheto meg), de hogy ezekbol mennyit tud tenylegesen kihasznalni egy egyszalas alkalmazas, az mar hw implementacio fuggo, es pont ezt mutatja meg az EVEREST. Mind a ket procin a szamara kedvezobb savszel mero rutin fut a tudtunkkal leggyorsabb verzioban. Ha felbukkanna egy gyorsabb kod K10-re (tobbszal es realtime priority nem er), akkor orommel lecserelnenk arra (bar erre eleg keves eselyt latunk, eleg sokmindent vegigprobaltunk mar).
A cache-eknel egyreszt tul lassu lenne, ha keresgelnenk mekkora meretu blokkot hasznaljunk, masreszt meg altalanossagban nem is mindig lehet szamitani arra, hogy lesz "lapos" resze az atviteli gorbenek. (ket pelda akosf-tol 1, 2) Igy mi inkabb a CPUID-bol olvassuk ki a cache meretet, es azt hasznaljuk.
Mivel non-temporal write-ot hasznalunk, ezert ritkan, de elofordulhat, hogy write gyorsabb, mint a read. (Bizonyos K7-eseknel tipikus volt anno...)
[ Szerkesztve ]
AIDA64.com
-
Fiery
veterán
válasz Oliverda #1848 üzenetére
Ez mar kezd kisse off-topic lenni, de kivancsi lennek, mikepp mérik le a CPU fogyasztasat a LostCircuitsnel. Ugyanis szamomra kisse nehez elkepzelni olyan "házi" modszert, amivel a CPU es csak a CPU fogyasztasa valoban precizen merheto. Nyilvan az Intel kepes olyan alaplapot gyartani, ami ki van erre a celra hegyezve, de azt csak hazon belul hasznaljak.
-
Fiery
veterán
válasz Oliverda #1951 üzenetére
Ha megoldhato, ellenorizd kerlek, hogy a jelenlegi rendszerbeallitasok mellett az utolso stabil verzio valoban jol mukodik-e, es valoban csak a legujabb betara all-e, amit irsz. Mi ugyanis nem valtoztattunk semmit az Overclock oldalon, ezert nem is tartom valoszinunek, hogy az tehet a fagyasrol. A legtobb esetben az ilyen problemak a gep instabilitasara vezethetoek vissza.
-
Fiery
veterán
válasz Oliverda #1961 üzenetére
Sajnos azota sem tudtuk reprodukalni a hibat a sajat AMD-s tesztgepeinken Sejtesem szerint az AMD chipsettel lehet kapcsolatos ez a bug, az OverDrive funkcio kornyeken buzlik valami, csak azt nem tudom, miert pont a GPU-s reszhez erve fagy le...
Hamarosan (amikor megjon a Phenom II X6) ujabb tesztgepeket fogunk "csatasorba allitani", azoknal remelhetoleg mar tobb szerencsenk lesz ezzel a buggal kapcsolatban.
[ Szerkesztve ]
-
pe de
csendes tag
válasz Oliverda #1986 üzenetére
Naja, mindjárt. Fekete zöld rövidrezár, aztán hadd szóljon...
Még az is furcsa, mióta megvolt a modding, a proci (E6500) órajele nem csak két érték között ugrál, hanem több érteket is használ... Lehet hogy csak paranoiás lettem, mióta vérző szívvel elvágtam a tápom kábeleit... Mennyi a normál Vcore fesz? Az órajel változásával egyenes arányban ez is változik?Hámimás.
-
Fiery
veterán
válasz Oliverda #2128 üzenetére
Nem hiszem, hogy rosszul csinaltal volna barmit is. Igyekszunk me'g tesztelni a RAID-del es AHCI-vel kapcsolatos modulokat, csak sajnos ez rettento idoigenyes, hiszen tobbfele Windows-t kell telepiteni hozza, tobbfele drivert kiprobalni, RAID, AHCI es IDE modban is, stb. stb. stb. Jovore kicsit tobb idonk es energiank lesz ezekkel a franya RAID/AHCI vezerlokkel molyolni
-
Fiery
veterán
válasz Oliverda #2230 üzenetére
Leteszteltunk egy ugyanilyen konfigot, de nekunk a HD Tune Pro legujabb verzioja (4.60) nem latja egyik vinyon sem a SMART infot. Mint ahogy az AIDA64 sem, es a HD Sentinel Pro legujabb verzioja (3.50) sem.
A mi konfiguracionk:
- Gigabyte GA-890GPA-UD3H alaplap, SB850 deli hid, RAID modba kapcsolva a BIOS Setup-ban
- 2 db Seagate 500 GB SATA2 vinyo, a port0 es port1 nevezetu SATA portokra kotve, RAID0 modba konfiguralva
- 1 db Seagate 1 TB SATA2 vinyo, port2-re kotve, standalone vinyokentAz oprendszer Win7 32-bit SP0. Az AMD RAID driver verzioja 3.2.1540.75, 2010.jun.22-ei datummal.
Ird meg kerlek, hogy a Te konfiguraciod pontosan hogyan is nez ki, kulonos tekintettel az AMD RAID driver verziora, es a SATA port kiosztasra.
Koszi a turelmedet!
-
Fiery
veterán
válasz Oliverda #2150 üzenetére
A legujabb AIDA64 betaban mar megtalalhato a VT1556 chip tamogatasa. Azonban, ez az uj chip sokkal kevesebbre kepes, mint az elodei (pl. VT1165). Csak a VRM feszultseget es a VRM homersekletet méri.
A kozeljovoben a kulonfele HD 69xx chipes kartyakon talalhato mas VRM chipek (pl. uPI es CHiL) tamogatasat is beepitjuk.
-
Fiery
veterán
válasz Oliverda #2251 üzenetére
Koszi a visszajelzest! A VRM ez esetben arra utal, hogy a VRM altal szolgaltatott feszultsegrol van szo, azaz a VRM kimeno feszultsege ez.
RAID: egyelore nem tudtunk rajonni, hogy mikepp lehetne javitani az AHCI mod kezelesen Korbekerdeztunk, de masok sem tudjak a megoldast a "barati" fejlesztok kozul
-
Fiery
veterán
válasz Oliverda #2393 üzenetére
A kovetkezo betaban javitjuk a ventilatorokat, azonban a "CPU Fan2"-t sajnos nem tudjuk mérni, ugyanis az ASRock egy eleg bena mux-os megoldast alkalmaz, amit csak a sajat programjaik (F-Stream / OC Tuner / XTU) tudjak hellyel-kozzel rendesen kezelni.
Az SB950 eseteben csak a 4 "valodi" PCI-E portot listazzuk. Ahogy lathatod is, a port magarol azt allitja, hogy x1 savos, de az aktiv szelesseg viszont x16, es a port sorszama is bizarr Ez, valamint az a problema, hogy hasznalatban levonek mutatja magat (mikozben nem latszik semmilyen csatlakoztatott PCI-E eszkoz) egy BIOS bugnak koszonheto. Nem kritikus hiba, hiszen csak a diagnosztikai progikat kavarja meg.
Az EFI/AGESA temanak utana tudunk nezni, de sokat segitene, ha tudnal submittolni egy riportot nekunk (AIDA64 / fomenu / Report / Submit Report To FinalWire), meghozza a legujabb AIDA64 betaval --> [link]
Koszi a segitseget!
[ Szerkesztve ]
Új hozzászólás Aktív témák
- EA Sports WRC '23
- Videó stream letöltése
- Azonnali informatikai kérdések órája
- Ubiquiti hálózati eszközök
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Motorola Edge 40 neo - színre és formára
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Autós kamerák
- Android alkalmazások - szoftver kibeszélő topik
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- További aktív témák...