2243
Microsoft Flight Simulator 2020
-
nibron #1963 hmm, nem is olyan sok. de neked alapvetően nem az a bajod. microlag problémát sokfélét ismerünk msfs, p3d, és fsx-nél is. de a te problémád elég furmányos, és be kell látnom nem láttam még ilyet. azért a szétfragmentált majdnem teli hdd egyszerűbb probléma, csakúgy mint a rosszul beállított teljesítményprofil. ezek a legsűrűbbek. és csak ezek után jönnek az erősen alulméretezett videókártyák, memóriák, stb-k.
van hdd a gépedben. iktasd már ki, hogy csak ssd legyen. egyáltalán ne legyen sata kábel az alaplapba dugva. -
#1962
"millió konfigon jól működik. gondolom feltúrtad már a netet. találtál vkit akinek szintén így működik? " Nem is kevés embernek! Erre, hogy "msfs micro stutters" a google 12.900 találatot hoz fel... -
#1961
Köszönöm, meg fogom nézni! -
nibron #1960 "feszültség emelésével nő az áramerősség, így a disszipáció is"
ez így igaz (ohm törvénye). de mi van akkor ha a teljesítmény adott? mint ebben az esetben is. arról van szó, hogy pl. 300w-hoz kell tápot előállítani. ez az oka, hogy legújabban már a proci bügyögteti a tápot. régebben, ill. az i7-esek ill az alatt, úgy történik a dolog, hogy amikor teljesítményt kell emelni, akkor az árammal együtt a feszültség is nő, és együtt érik el a kívánt teljesítményt. ezt látod amikor monitorozod a dolgokat. És mindez csak azért van, mert még így is bődületes áramok folynak. 150-200a már a ponthegesztésben is komoly teljesítmény. a gnd-hez már legalább 70mm2-es csatlakozás kell. Ez már majdnem 10mm átmérőjú tömör vezeték.
azért ha lenne a hőmegfutás elleni védelemről egy kapcsolásod, vagy valami képlet ami alapján lehetne kapcsolást csinálni megköszönném. Nem lehet egyszerű, mert ezek eleve laborban kísérletezett értékek egy adott technológiára és anyagra. Ezért aztán akár alkatrész típusonként más és más értékek (táblázatok) lehetnek. Írásod alapján igen erős bennem az a feltételezés, hogy azt sem tudod mi az a hőmegfutás. Ami érthető, mert 40 éve nem tanították egyik elektrotechnikai suliban sem. az elektronikai műszerészek sem tanulták, és az egyetemen sem. 84-ben kezdtem a bme-n, mi sem. Egyszerű oka van, hogy miért nem. Nem igazán létezett még a jelenség. A hőmegfutás nem azonos a félvezető leolvadással ill. az oda vezető úttal. Ez csak valahol a 90 évek hozadéka, mert akkor születtek meg az első chipek ahol ez problémaként jelentkezhet. Most sem nagyon tanítják, nincs elszámoltatás, csak megemlítik. A diófáknál, tranyóknál, fet-eknél, tirisztor, triak-oknál a mai napig sem használjuk.
Csak hőmérsékletet tudunk mérni. Lehetséges hőmérsékletet nem tudunk csak nagyjából számítani, az meg szart sem ér. Ezért aztán kinézünk egy hőmérsékletet amíg biztonságos az üzem. Addig oké, azt meghaladva nem oké. Ennyi. A hőmérsékleten kívül nincs benne semmi más tényező. A chipben valahová beraknak egy félvetezős termisztort hozzá egy a/d konvertert és csá. A túláramvédelem megint csak nagyon egyszerűen készül. Az öreg jól bevált söntöt használják. Már csak azért is mert nem kell külön alkatrészt rakni a rajzolatra. Maga a vezeték a sönt. Egy darab szakasz, műveleti erősítő, utána egy trigger és kész is.
De szívesen veszem az újításokat, ezért tényleg szívesen nézném meg a hőmegfutás elleni általános védelmet ami még a túláramtól is megvédi az áramkört. Feltéve hogy működik és nem tartalmaz a jelenlegi megoldásoknál több alkatrészt. Érdekes lehet egy, csak elméleti problémának a gyakorlati megvalósítása:). Bár gyanítom, hogy a jelenleg használt megoldások sokkal egyszerűbbek, ezért nem találsz erről semmi gyakorlati megvalósítást (pl. kapcs.rajzot).
"a legutóbbi SU -ig rendben volt minden" - értelek, de eddig csak te vagy aki panaszkodik ez miatt (akikről tudok). a kedvedért írtam pár msfs "kollégának" körlevelet, akik válaszoltak senkinél sincs ilyen. akkor most ezzel az infóval mit kezdjek? nálam pl. úgy sem akadozik, hogy egy rakás cucc nincs frissítve. de ez alapján, akkor csináld azt, hogy gép reinstall. msfs-t újratelepítve meg kell, hogy szűnjön a csak nálad létező probléma azzal, hogy a szoftver teljesen újra van telepítve. de hát ezt már megtetted, ugye? így kizárható. maga a szoftver nem lehet rossz, mert millió konfigon jól működik. gondolom feltúrtad már a netet. találtál vkit akinek szintén így működik? -
bunny #1959 Én megnézném a helyedben ezt az amúgy DCS-hez ajánlott módosítást.
https://forum.dcs.world/topic/335866-disabling-core-parking-in-windows-fixed-my-stuttering-in-menu-and-game
-
#1958
"a cpu és/vagy gpu kifogyott az feldolgozandó adatokból, és várnak, hogy bejöjjön egy újabb csomag. "
Ezzel egyetértek, csak azt nem értem, honnan jön az újabb csomag????? Mivel sem a NET, sem az SSD folyamata nem jelez semmilyen olvasást a szünet alatt/után! https://kepkuldes.com/image/DVahng Másrészt - mint írtam - a legutóbbi SU -ig rendben volt minden, csak azóta sz@rakodik ugyanazokkal a beállításokkal.
Utoljára szerkesztette: Vizipok56, 2023.11.04. 20:02:10 -
#1957
1. "Ráadásul hibát keresel egy olyan rendszerben, amit össze-vissza állítgattál." Mint már többször is leírtam, teszteltem olyan állapotban is a deszkát, amikor CSAK az MSFS volt a frissiben felrakott win alá telepítve. Dadogott.
2. "Na most, ha a nálad otthon rádugnék egy 1MW-os fogyasztót a 1,5mm2-es vezetékedre, az kábé 1 ezred mp alatt párologna el" - Kivéve, ha a vezetéket - kellően rövid reakcióidejű - hőmegfutás elleni védelemmel látjuk el - mint az a processzoroknál szokásos...
3. "Többnyire a core feszültségét is azért kell emelni, hogy az áram csökkenjen valamelyest, és a túláramtól ne égjenek el a bevezétesek ill. a felület ne párologjon el." Ez érdekes... Sekélyes villamosmérnöki ismeretemmel eddig úgy tudtam, hogy a feszültség emelésével nő az áramerősség, így a disszipáció is... (Igaz, a diplomám több mint 40 éves, azóta sokat változott a világ! :-)
Köszönöm a segítséged, további szép napot!
Utoljára szerkesztette: Vizipok56, 2023.11.04. 19:45:17 -
nibron #1956 "A hőmegfutás elleni védelem egyben a megengedett disszipáció túllépése elleni védelmet is jelenti!"
Ezt gondold át mert így leírva egy marhaság.
Egy intel procinál 10W-on is el tudom érni, hogy megszólaljon a hővédelem (ezt már megtettem), és elvileg 500W-nál is, hogy nem. Maradjunk annyiban, hogy a hővédelem az csupán a hőre vonatkozik, teljesítménytől függetlenül. És az a feladata, hogy a hőmegfutásból eredő olvadást elkerülje. Rohadtul nem érdekli, hogy azt túlhúzás miatt vagy olvasztó kemence (ezt már tapasztaltam) melletti használatból fakad. Ezt legjobban az nVidia-nál látni. A külső (package) hőmérséklet eléri a beállított értéket (~105C???), és újraindul a gép vagy leállítja a processt, kinél hogyan (nekem újraindul).
Amikor pedig teljesítménnyel ill. a hozzá tartozó disszipációval számolunk, akkor ott irreleváns adat lenne a hő. Mire használnánk? Nem arra vagyunk kíváncsiak, hogy mennyi hő keletkezik, hanem arra, hogy a befektetett energiát hogyan tudjuk hasznosítani, meg mire. Még akkor sem ha éppen fűtőberendezést tervezünk (akkor már tudjuk, hogy mekkora teljesítményű kell). A hővel vagy hőelvezetéssel a legvégén kell csak foglalkoznunk, és akkor is csak annyira, hogy a hőt ki tudjuk vezetni. Pl. az erősítőnél van-e megfelelő felület a meghajtókon, hogy le lehessen hűteni (de ez már inkább alkatrészgyártási probléma). A csipeknél is ez van (lásd tápáramkörök). Kivezetik a hőt aztán csinálj vele amit akarsz. Az már egy másik tudomány.
Szóval a két dolog nem igazán tartozik össze. Az egyik elektrotechnika, a másik fizika és anyagismeret. -
nibron #1955 Úgy tudom te is foglalkozol elektromos dolgokkal. Akkor tudnod kell, hogy egy vezetőn nem tudunk átengedni végtelen mennyiségű áramot. Így működik az olvadó biztosíték. Na most, ha a nálad otthon rádugnék egy 1MW-os fogyasztót a 1,5mm2-es vezetékedre, az kábé 1 ezred mp alatt párologna el (itt most ne számoljunk a biztosítással). Anno megmértem, hogy az 3x1,5 MT kábelnek az érsodratából ha kicsípek egy szálat, az mekkora biztosítéknak felel meg. 2,4A-nál olvadt meg (természetesen ez függ az ötvözettől). Tehát ha egy 6A-os biztosítékot szeretnék megpatkolni, akkor 2 vagy 3 szálat kell használnom.
Gondolom innen már nem is nagyon kell magyaráznom, hogy a chipeknél miért fontos a túláramvédelem. A procidnak van 1700 lába, ebből mondjuk van 50-60 ami core-nak biztosítja a feszültséget. Van másfajta tápláb is a procin, pl. az I/O teljesen le van választva, ráadásul nem is azzal a fesszel ketyeg mint a core (adatlapon megnézheted). Azután mivel a táplálás kétpólusú így a GND-nek is kell jó sok lábacska. Az 1700-ból jó sokat elvisznek a táplábak. Alapvetően két oka van amiért ilyen sok kell. Magán a chip felületén nem lehet akkora keresztmetszetet kialakítani, ami elvinne 100A-nál több áramot, másrészt rohadt nagy zaja lenne a chipnek, és sok felületet foglalna a tápvezetékek huzalozása. Ezért lokális betáplálást használnak. Tehát a core felülete több helyen kap betáplálást, így a keresztmetszet elfogadható, és a zaj is kisebb a jóval rövidebb vezetékezés miatt. Na+ jóval több felület marad ahová tranyókat lehet tenni.
Többnyire a core feszültségét is azért kell emelni, hogy az áram csökkenjen valamelyest, és a túláramtól ne égjenek el a bevezétesek ill. a felület ne párologjon el. A chipek élettartama is attól függ, hogy az áram milyen intenzitással párologtatja a felületet. Ha egy chipre túlfeszültséget adsz (mondjuk 5V helyett 10V-ot), akkor is az áramtól megy tönkre a chip, nem a feszültségtől. Ott már akkora lesz az átfolyó áram ami elégeti a bevezetéseket vagy magát a felületet. Amikor a felület hirtelen elpárolog, akkor "robban" szét a chip (a szememből kellett is kiszedni már műgyanta darabkákat). A legkisebb rétegleképezési technológiánál sincs 30V alatt nincs átütés, tehát alatta csak az áramtól mehet tönkre egy chip. Ha 200V-ot adsz neki, akkor ott már átütés keletkezik a felületen, ilyenkor már nincs jelentősége az áramnak.
Érdekességként kiszámolhatod, hogy a processzorodnak amikor teljesen ki van terhelve, mekkora vezető keresztmetszet szükséges, ahhoz a teljesítményhez. Meg fogsz lepődni, főleg akkor ha a kezedbe veszel egy olyan keresztmetszetű vezetéket. Azután gondolkodj el rajta, hogy a picsába tudták azt beleszuszakolni abba a pici tokba.xD A GND-nek meg ugye még vastagabb kell, és az is bele van szuszakolva. -
nibron #1954 nem kell az xtu. az alaplapod bios-a tudja, hogy mit kell csinálni. a proci mondja meg a biosnak, hogy miből mennyi kell neki. Majdnem ugyanaz a lapunk van, és a bios-unk egyforma (feltéve, hogy frissítetted). Az i9 miatt frissíteni kell. Kicsit elméláztam, hogy a 13900-ashoz miért nem Z-790-et használsz, de tudom, hogy a 690 is elviszi a 13-as generációt is. Viszont olyat még sosem csináltam. Ha ilyet kell összeraknom 790-est használok. Namost a 13900-ashoz eddig az összes 790-es lapot frissíteni kellett (nemtom miért van az, hogy 1 családban az i9 mindig kiesik a lappal szállított bios-okból). Ezért kicsit szkeptikus vagyok a 690 vs. 13900 irányában. De ha a lapodhoz adtak ki kifejezetten 13.generációs i9-es frissítést, akkor mindennek jónak kell lennie. az i9 szorosan együttműködik az alaplappal, nem úgy mint az i7-esek (intel honlapján van erre összehasonlítás doksi). Ezért az összes i9-es amikor megjelenik, biost kell frissíteni.
Az xtu jó az i7-hez, bár az utóbbi időben leszoktam róla, mert a bios-ok alapból tudják a gyári tuningot. Sajátot meg már ezeken az eszközökön jobb ha nem csinálunk.
Nem ezeket a teszteket mondtam. Ráadásul hibát keresel egy olyan rendszerben, amit össze-vissza állítgattál. Mondtam már, hogy az ilyen hibákat "eredeti gépen" lehet megkeresni. Mivel csak az MSFS miatt van ez a gép még könnyen meg is teheted. Írtad hogy csak az alapdrivereket használod. Erre most írod az XTU-t. Hát nem igazán értem a "hibakeresési" koncepciódat, ezzel nem tudok mit kezdeni. Ráadásul egy olyan gépről beszélünk amit bazi nehéz jól beállítani.
Ha szervízbe viszed, az első dolog, hogy alapba állítanak mindent, és úgy próbálják. Tehát az összes szarságot vakard le, amit nem a windows és az msfs telepített fel (a külső tesztalkalmazások maradhatnak, akár háttérben futva is). Bios frissítése és alapba állítása. Az msfs-nél szintén. HIGH graf.beállítás, és semmit nem piszkálsz el.
Az nVidia legfrissebb driverét tedd fel (nekem az van jól működik), semmi kiegészítőt sem teszel alá (külső fps számlálót sem).
A windows energiaséma is legyen a windows alapértelmezett. Windows játék beállításoknál szintén (ezen később lehet változtatni (nálam ki-be-ki van)). Mivel elég gyors ssd-d van (nekem is) ezért a telepítés mehet a C:-re, de csak az alap (nekem steam-es van). A Community-nek külön drive-ra kell kerülnie, és erre a drive-ra kerülhet a cache-is. A teszthez olyan területet kell keresni ahol nagyobb reptér van (eddf vagy omdb-t szoktam használni) lehetőleg a városon belül. Pl. egll azért nem jó, mert messze van a reptér londontól, így város és a reptér "összeakadhat" a betöltéseknél.
Ha van HD Sentinel-ed, rá kellene nézni a drive-okra, hogy nem írt valami hibát. A SMART-ban olyan értéket kell keresni, ahol nagyobb értékű szám van, és hibára utal (pl. akárminek a hibajavítása). Nem néztem utána az ssd-knek így nemtom, hogy m2-es vagy sata-s, de ha sata-s akkor ezeknél a gyors driveoknál sok kábel nem felel meg. Ezt is meg lehet nézni a sentinel-ben.
A múltkorában volt nálam egy gép. Régebbi alaplapja volt, 10.generációs proc. Az volt a baj, hogy mind a kettő M2-es foglalatban volt modul. És azért volt baj, mert a bios-ban engedélyezve volt a SATA, és az alapból kiosztotta mind a 6 helyet (a lap ennyit kezelt). Viszont az M2-es modulok ezekre voltak kötve. Meg kellett keresnem, hogy az m2-esek mely sata portokat használják (manual) és azokat a portokat le kellett tiltani. Az már más kérdés, hogy az egyik hdd pont össze volt kötve a második m2-essel. Végeredményben az én hibám volt, mert anno én raktam össze a gépet, és már akkor le kellett volna tiltani. A hdd-t már a tulaj tette be.
Azért csak a háttértárra (vagy környezetére) tenném a zsetont, mert akárhogy gondolom végig, csak az jön ki, hogy nincs a memóriában aminek ott kellene lennie és ezért áll meg (mondjuk a CPU arra vár, hogy a DMA befejezze az adatok szállítását). A CPU és a GPU sem áll meg ha van feladata. Szoftvergond nem lehet, mert akkor az mindenkinél jelentkezne. Memóriagond sem lehet, mert az egészen másként jelentkezik. És az sem lehet, hogy valami leáll, mert kizárt dolog, hogy folytatni tudná. Márpedig a hiba elmúlik mintha mi sem történt volna. Tehát csak az lehet, hogy a cpu és/vagy gpu kifogyott az feldolgozandó adatokból, és várnak, hogy bejöjjön egy újabb csomag. -
#1953
A "beégetett korlát" számomra azt jelent, hogy nem lehetséges átlépni - de mint tesztek sokasága bizonyítja, átléphető... Úgyhogy maradjunk annyiban: az intel által alap léghűtés mellett javallott érték.
Utoljára szerkesztette: Vizipok56, 2023.11.04. 12:39:35 -
#1952
A hőmegfutás elleni védelem egyben a megengedett disszipáció túllépése elleni védelmet is jelenti! Ha egy chip 1000W-ot disszipál, miközben 20 fokos marad, úgy kit érdekel? Úgyhogy nem igazán tudom értelmezni, hogy "a 250W a 12900K beégetett korlátja, 13900-ast nemtom (ezért 250W-al számolok), meg kell nézni az adatlapon. a chip kivezetéseit védeni kell, mert ha 1 elég, akkor megy a többi is." - Ha 250W fogyasztás alatt - a jó hűtésnek köszönhetően - a chip hőmérséklete mondjuk 70 fok, akkor mitől is égne el bármely kivezetése is??? -
nibron #1951 a 250W a 12900K beégetett korlátja, 13900-ast nemtom (ezért 250W-al számolok), meg kell nézni az adatlapon. a chip kivezetéseit védeni kell, mert ha 1 elég, akkor megy a többi is. A hőmegfutás elleni védelem teljesen más. -
#1950
"Ez a prociba égetett érték, amit semmiképpen sem léphet át a processzor, mert ilyenkor már pattannak el a lábak." Szerintem ez sem photoshop... https://kepkuldes.com/image/Da5Xli Úgyhogy a 250W-os limitet szerintem felejtsük el - eléggé valószínűtlen, hogy 250W-nál 10 us alatt működésbe lép a gyári védelem és utána 300W fölé engedi húzni! :-) Max. azt tudom elképzelni, hogy 100 egynéhány fok fölé nem engedi kifűteni - az viszont, hogy ehhez hány watt kell, a hűtéstől függ! Egy normális Artic 420-as vízhűtés szerintem bőven 300W fölé engedi a TDP-t (Persze ha a BIOS-ban is be van állítva) - egy jobb hűtéssel pedig a 400W-ot is el tudom képzelni!
Utoljára szerkesztette: Vizipok56, 2023.11.03. 17:02:04 -
#1949
Aida tesztek:
https://kepkuldes.com/image/Daahg0
https://kepkuldes.com/image/DaaZbL
Így első ránézésre eléggé stabilnak tűnik a CPU... Az SSD linear olvasási sebessége az elején és a végén lehetne (sokkal) jobb is, de szerintem az MSFS alá ennek is elégnek kell lennie. -
#1948
"Ez a prociba égetett érték, amit semmiképpen sem léphet át a processzor, mert ilyenkor már pattannak el a lábak." Nem tudom, hogy lehet egy prociba égetett értéket felülírni, de akkor itt (300W felett) már komoly lábpattanások lehettek! :-))) https://i.imgur.com/yuHa0cj.png -
#1947
Természetesen nem kézzel emeltem - az Intel XTU-val állítottam be. Ez nem fixre állítja (amit valóban nem lehet), hanem a limiteket módosítja. Most a Core Voltage Offsetet -0.015V-ra állítottam és az E magokat kikapcsoltam, így a TPD 195W lett, 100%-os terhelésnél, tehát az áramkorlát biztosan nem játszik, valamint a 250W-ot sem éri el még μs-okra sem, mivel ez nem okozna ~2 mp-es "lefagyást"
Köszönöm a tippet: A több teszt egyidejű futtatásának utána nézek, mivel és hogyan lehetne kivitelezni.
Utoljára szerkesztette: Vizipok56, 2023.11.03. 14:02:42 -
nibron #1946 Ha átkapcsolok DX12-re, a betöltéskor (amikor a végére ér a csík) szó nélkül kilép. eseménynaplót még nem néztem. lhbp körzetében próbáltam, lehet odébb kellene menni, hátha a hiba lokális. No+ egy pár külső addont frissíteni. Pl. lehetett a GSX is, mert az elég régi, mindig elódázom a frissítést.
ha 5.6-ra kézzel emelted, az i9-nél az nem működik. auto-n kell hagyni, mert a processzornak kell szabályoznia az órajelet és a feszültséget is. Ezeknél a típusoknál nem lehet fix értéket beállítani. Sokat szórakoztam vele én is, aztán elolvastam az adatlapját.
Elérte az a 250W-ot csak nem vetted észre, az adatlapon 10us a védelmi reakció. Ez a prociba égetett érték, amit semmiképpen sem léphet át a processzor, mert ilyenkor már pattannak el a lábak.
Meg kellene tanulnod, hogy egyszerre csak egy dolgon változtass. Ha össze-vissza állítgatsz mindent azzal csak a szart kavarod végtelen ciklusban. Úgyhogy vissza mindent, és csak a DX11-et állítsd be.
Az számomra teljesen érthetetlen, hogy a géped "csak úgy gondol" egyet, és "megáll". Ugye a grafikonok alapján ezt bizonygatod. Ez nem fordulhat elő. Illetve ha a szoftver hajlamos lenne erre, az az összes többi gépen jelentkezne.
De ha mégis ez van, akkor ideje hardverproblémát keresni. Valaki valamivel nem passzol. Olyan mód nem lehet a gépen, hogy 1-2 sec.re leáll minden mikor van feladat bőven. Meg kell nézni mással is, ami szintén erőforrásigényes.
Egyébként az m2-es ssd-k szoktak olyat művelni 50 fok felett, hogy nagyon lelassulnak, illetve a válaszadásba külön várakozó ciklusokat iktatnak be. Mert szegények azt hiszik, hogy a használat miatt szökött fel a hőmérséklet, pedig csak a videókártya fújja rájuk a kb. 70fokot. De az nem így jelentkezik. Viszont látom, hogy ez nálad nem játszik. Corsair ssd-t talán még nem használtam, de elég igényes cég, memóriát rendszeresen veszek tőlük, imádom mert problémamentes.
Kellene keresni egy olyan tesztalkalmazást amiben lehet egyszerre több elemet tesztelni. Most így elsőre az AIDA ugrik be. Olyan teszt kellene amiben a vga a cpu stresszteszten van, és mellette szintén tesztel olvastatni az ssd-ket. Esetleg veszel egy jó nagy becsomagolt fájlt és ki-be csomagolod, miközben a vga stressztesztben van. Ez megjáratja a procit, memóriát, háttértárat és a videót is.
Gondolkodtam még kontakthibán, de ehhez hasonlót szerintem még nem láttam. Annak általában fagyás a vége. -
#1945
Nos, gyorsan kipróbáltam DX11 alatt - egyben az órajel szorzót is felemeltem 56x-ra. (A proci 5.6 GHz-es) https://kepkuldes.com/image/DarDUL Az eredmény egy ~2 mp-es kifagyás lett. Ami érdekes, hogy most egyértelműen látszódik, hogy ez alatt az idő alatt nemcsak a GPU, de a CPU használata is igen erősen lecsökkent!!! (A diszk nem tehet róla :-))) Halvány elképzelésem sincs, mi miatt helyezi magát önkényesen takaréklángra... A CPU a 250W közelében sem járt és az áramkorlát sem léphetett működésbe.
Utoljára szerkesztette: Vizipok56, 2023.11.03. 07:04:16 -
#1944
OK, köszönöm, kipróbálom majd DX11 alatt is. A háttértárra pedig nem várakozik, nézd meg ezt: https://kepkuldes.com/image/DVahng - látszik, hogy sem a GPU botlás alatt, sem utána nincs (intenzív) diszk használat. Ha várakozna, akkor utána - mikor hozzájut az adatokhoz - megugrana az olvasási sebesség! -
nibron #1943 Nagyon rosszul látom, de mi az a piros a tetején?
DX12-őt kapcsoltad be? Csak azért kérdezem, mert az nem működik teljesen. Már millió hibán vagyok túl ami őt illeti. Állítsd vissza DX11-re és úgy próbáld. Megnézem majd nálam DX12-el.
Az a gép a gyári a320-as?
Szóval nem a GPU okozza az akadást. Látszik, hogy nincs feladata. És az nem lehet. Tehát valami nem nyomja oda neki az adatot, meg a feladatot időben. Ilyen pl. a várakozás a háttértárra. -
nibron #1942 pont az, hogy nem túlméretezett (az msfs-nél eleve nincs túlméretezés). Azt próbálom elmagyarázni, hogy egy 13700-as proci sokkal optimálisabb lenne, mert azt meg lehet hajtani (a szimnek meg az kell). Az i9-et meg nem.
Tehát az, hogy a gépet direkt msfs-hez csináltad, elqtad a procit, mert 700-ast kellett volna betenni. És az még olcsóbb is.
Nekem csak azért van i9 mert nem a játék a preferrált működés. A visual studio, sql szerverrel, meg a többi szarság amit használok, inkább az alacsonyabb sebességű, de sokmagot szeret összességében. A visual studionál ha xaml-t szerkesztek ami már kábé 3000 sornál tart, ott szemmel észre lehet venni a 700 és a 900 között a különbséget. Elektronikus tervezőnek az Altium-ot használom, ami szintén jobb a 900-ason. Játékra az i7 sokkal ideálisabb. -
#1941
Tudom, hogy kissé túlméretezett, de úgy voltam vele, hogy a tesztgépemben (amin a photogrammetriás tájakat készítem) I7-13700KF van, akkor ebben legyen I9...:-) - rosszabbnak biztosan nem rosszabb! :-) (Gondolom lehetne játszani a feszültségekkel és áramlimitekkel (Z-690-es alaplapom van), de nem akarok.) -
#1940
Igen, egyértelműen a GPU kihasználatlanság okozza a dadogást - viszont ezen láthatod, hogy sem a diszkre, sem a NET-re nem kell várnia: https://kepkuldes.com/image/DVahng -
#1939
Megnéztem developer módban - laikusként nem igazán látok különbséget a kiírt értékekben akkor, amikor éppen "dadog" egyet : https://kepkuldes.com/image/DaTxKc és akkor, amikor simán fut: https://kepkuldes.com/image/DaTDtl A gyakoriság erősen változó - van úgy, hogy 2-3 percig "sima" és van, hogy percenként 4-5x is megakad.
-
nibron #1938 Írtad, hogy kifejezetten az MSFS miatt van ez a gép. Látom, hogy 13900KF proci van benne. Hát ez nem optimális a flightsim-hez. Túl sokat fogyaszt, sosem tudod kihajtani arra a frekire amire eladták, mert megszólal az áramkorlát. Látszik is, hogy 5.06GHz a freki, holott ez a proci 5,8-as? (nem néztem meg, erre emléxem, de lehet, hogy 6GHz-es). Nekem 12900KS van, max. 5.3GHz-re tudok felmenni (5.5 a gyári érték), szintén áramkorlát miatt (250W). De nekem munkához van. Az MSFS-hez inkább 13700-as kellene, a leggyorsabb frekivel. De a bajod nem ettől van, csak megemlítettem, a 13900-assal is remekül kell futnia. -
nibron #1937 Kívülállóként elég nehéz értelmezni mit kellene a grafikonokon nézni. De a jobb felső sarokban lévőn van egy hosszabb letörés a gpu kihasználtságban. Azt? Mert ha igen, akkor az máris látható, hogy nem a gpu a ludas. Vár valakire. Jó lenne látni vele együtt mondjuk a háttértárolvasást. Vagy a cpu ugrik ki ezzel ellentétben? Kereséshez a rosszabb beállítást kellene használni, mert így jobban követhető, mint amikor csak tüskeszerűen jelentkezik. -
nibron #1936 próbáld megnézni, hogy mi a baj a beépített kutykuruttyal. Developer módban bekapcsolod, és ott látnod kell, hogy amikor megakad, mivel van problémája. Egyébként milyen sűrű a megakadás? -
nibron #1935 anno én is "véletlenül" indítottam el, és semmi bajom vele. Rossz dvd-t tettem a meghajtóba. A laptop meg már úgy jött. Szeretem, könnyű vele dolgozni. Bár a 10-essel sem volt semmi baj. Magának a windows-nak nagyon jót tett, hogy a 7-est olyan szépen lepucolták és stabilizálták. Hálából ki is rúgták a projectvezetőt. -
#1934
Hát sajnos a tegnapi és a mai tesztek nem hoztak semmilyen javulást. A cache méretével variáltam 32 és 256 GB között - az alábbi eredménnyel:
https://kepkuldes.com/image/DVaWLu
Ezen pedig látható, hogy a dropok alatt sem CPU, sem DISK, sem NET túlterhelődés nem volt: https://kepkuldes.com/image/DVahng
A NET kikapcsolása után (Online functionality OFF) inkább rosszabb, semmint jobb lett :-( (Itt már jó egy másodperces lefagyások is előfordultak...)
https://kepkuldes.com/image/DVdSwH
Feladom.
Utoljára szerkesztette: Vizipok56, 2023.11.01. 13:10:32 -
#1933
Valahogy így ja. Le lehetett volna állítani de mindegy, hamár ennyit dolgozott vele akkor frissítsen, legfeljebb visszarakom a régit. Eddig semmi probléma, kb ugyanúgy fut minden, a tálcát nem lehet áthelyezni oldalra de már megoldottam. Letesztelem majd még a vr cuccokat kicsit jobban de eddig no problemo. FS is szépen fut. -
RaKmaTakaTa #1932 "véletlenül elindítottam..."
:-))
-
#1931
Köszi, akkor egyelőre marad.
Más téma, véletlenül elindítottam a win11 installt és most várom h végezzen. Kiváncsi leszek mi lesz elqrva.
Utoljára szerkesztette: PhantomAss, 2023.10.31. 08:12:23 -
#1930
Ma és holnap lészen az nagy tesztelések ideje!!! :-) -
nibron #1929 ha nem kapcsol le, akkor nem. de ezek szerint a libegést is elég jól viseli a géped, különben panaszkodnál. tönkremenni nem fog mert a védelem előbb aktiválódik. a terheléstől legalábbis. rossz alkatrész miatt az új is tönkremehet, de az más téma. -
#1928
És ez hosszabb távon nem fog problémát okozni hogy a táp a csúcs közelében jár?
Nem fogja tönkretenni idő előtt a gput vagy egyéb alkatrészt? -
nibron #1927 ezek szerint digi 1gbps optikád van. nekem is, de nekem 900 alá sosem megy a letöltés és a ping mindig 1ms (utóbbi mióta digi van). elvileg neked sem szabadna. véletlenül nem 2 routered van otthon?. de ettől függetlenül jónak kell lennie. mint írtam mobilnettel is jól elmegy. -
nibron #1926 azért egy pillanatra gondolj bele, hogy egyszerre hány ojjektum látható a képernyőn. majd forogj körbe. szerinted reális elvárni, hogy cache nélkül ott legyen ennyi cucc, egy olyan kapcsolattal amivel eleve a megbízhatatlanságával tervezünk? Mert a hálózati forgalom programozásakor a legtöbb problémát pont a megbízhatatlanság miatt kell megoldanunk, meg amúgy mindenféle kis trükköcskét bevetni a minimalizálás végett. Szóval kapcsold csak be, nem kell 256GB, mivel írtam, hogy 128GB felett semmit sem javít. A cache méretnek viszont olyan értéket kell választanunk, mellyel még éppen jó. Ha több azzal csak a cache találati arányát rontod. Tehát amennyiben kísérletezni szeretnél inkább a kevesebb értéket kell próbálni. 64GB vagy 48, 32 aszerint, hogy mikor lesz stabil. És ha megvan ez az érték ne emeld, mert azzal már csak elcseszed. Ezért van pl. az ARM processzoroknál is max. 64kB cache, az is bontva adatra és kódra, mert efelett nagyon megromlik a találati hatásfok.
Nekem a 128GB vált be, és mivel ez nem gépfüggő hanem a szoftver működik így (tehát nálad és nálam ugyanaz fut), ennek az értéknek kell jónak lennie nálad is. Sőt mindenkinél.
A többit bunny egész jól leírta. A nagyobb cache törléséhez több energia kell ha adattal írod felül és mondjuk nem kézzel törlöd. Ha ide-oda ugrálsz akkor keletkezhetnek szakadások mely két részre bontható. Az egyik ami még nincs betöltve, ezért a feldolgozó még fogja, a másik a cache területek felülírása. De ennek a legrosszabb esetben is 1 percen belül meg kell szűnnie (tételezzük fel, hogy nincs textúra hiba, mert ez már egy másik történet). Ha folyamatosan repülsz, olyankor a területek előtöltéssel kerülnek beolvasásra ezáltal jól elnyújtva azt az időt ami a megjelenítésig kell. Viszont ekkor lehet olyan, hogy nagyon nagy és bonyolult hierarchiájú adatméretű csomagok (tipikusan egy nagyon részletes reptér), egyszerre szeretne betöltődni (főleg ha gyors a repcsi), ilyenkor egy pillanatra megakadhat 1szer (rengeteg DMA kérés, megszakítás és átvitel születik). Ezt el kell fogadnunk nem tudunk vele mit csinálni.
Van egy apró trükk a területek kezelésének beállításához: mondjuk 3000ft magasságon elindítasz pl. egy b737-et robottal. A sebesség a lehető legnagyobb legyen (330kts környéke), ahol még nem tiltakozik. Majd állítsd át a time rate-et 2x és/vagy 4x-es módba. Így szemrevételezheted hogyan teljesít a szim. Ha nem jó, állítasz a dolgokon. Először a cache-t kell belőni, ekkor a grafikát ki kell venni a képből. ezt úgy szoktam, hogy a graf.beállítások mennek high-ba plusz az árnyékok mediumra. Ha belőtted a cache-t, utána lehet hangolni a grafikát. Ha valakinek a high a max. amit a gép bír akkor mediumra állítani (körülbelül 1-el lejjebb mint a normál beállítás). Ultráról pl. Low-ra állítani nem szabad, mert az megtéveszt, úgy nem lehet jól beállítani. A beállítások elkezdése előtt az időjárást statikusra kell állítani, mert az nagyon el tudja vinni. Nekem kábé az 5/8-ad felhőzet szokott jó lenni, clear-ben vagy overcast-al szintén nem jó. -
bunny #1925 Én nem hiszek a cache kikapcsolásban, ha belegondolsz mire való, pont a hálózai dadogás miatti laggolás megszüntetésére van kitalálva. Azt el tudom képzelni, hogy ha folyamatosan nagy sebességgel nagy területet jársz be vagy ugrálsz mondjuk Új-Zélandról a piramishoz és kifut a cache akkor rádadog amikor feltölti, de normál repülési körülmények között szerintem marhaság, hogy kapcsolj ki egy hálózati fájlok gyorsítót mert attól jobb lesz. A méretnövelés is akkor érdekes, ha nagy területeket jársz be egy repülésen, de azt meg értelemszerűen magasan szokás megtenni ahol megint nem kéne, hogy látszódjon a töltés.
Én inkább azt mondom, hogy törölj cache-t, menj egy kört kvázi beindítva a terület letöltést és utána ha a környéken maradsz ami a cache-en már ott van tuti jobb eredmény lesz, mintha a netről húzná folyamatosan a textúrákat stb mert ki van kapcsolva. De ez csak egy vélemény.
Hasonló példa erre a DCS-ben a shaderek, minden frissítéskor törlöm, aztán minden térképet elindítok egyszer, hogy generálja le amit kell, addig persze lassú, fel se veszem a VR-t, aztán ha már végzett a szüttyögéssel már gyors az indulás meg a működés.
Utoljára szerkesztette: bunny, 2023.10.30. 08:02:34 -
#1924
A NET-em általában ilyesmi, mint ma reggel is: https://digi.speedtestcustom.com/result/9b077030-76dd-11ee-a4dc-65fba3c583f3 - tehát szerintem megfelelő, de azért ma mindenképpen kipróbálom a kikapcsolt NET opciót. Viszont a amit a gyorsítótárról írsz, az érdekes. A legtöbb helyen kifejezetten ajánlják az OFF -ra állítását (pl. itt: https://forums.flightsimulator.com/t/i-dont-use-rolling-cache-anymore/578386/104 kifejezetten azt mondják, hogy pont ez okoz(hat) dadogást ("Always off for me. It actually improves textures loading time, but that’s almost unnoticeable. When it’s on, stuttering in external view is quite annoying."), így én ezt kikapcsoltam, de meg fogom nézni milyen mondjuk 256GByte-tal) A hálózati feszültség hibájában már kevésbé hiszek, pl 5 perc furmark alatt sem a GPU fogyasztásában, sem az órajelében minimális változás nem következett be, úgyhogy annak a vizsgálatára majd csak akkor kerítek sort, ha a fentiek nem hoznak javulást.
Utoljára szerkesztette: Vizipok56, 2023.10.30. 05:50:25