Skocz do zawartości

Joozeff

Użytkownik
 Pokaż profil  Zobacz aktywność

  • Postów

    38

  • Dołączył

  • Ostatnia wizyta

 Typ zawartości 

Treść opublikowana przez Joozeff

  1. Joozeff
    Odebrałem dziś przesyłkę z Holandii, G.Skill wymienił ten RAM na nowe sztuki. Wysłałem do nich maila z pytaniem, co stwierdzili, bo ciekawi mnie ta sytuacja. Poza tym potrzebuję jakiegoś konkretu, żeby zażądać od sprzedawcy zwrotu kosztów za wysyłkę do G.Skill, bo jednak "u nas działa" nie spowodowało, że w Holandii też
  2. Joozeff
    Pojawiła się przerobiona wersja FSR 4.1.1b dla RDNA2. Przeróbka polega na tym, że usunięto z niej ograniczenie limitujące INT8 do RDNA3.
  3. Joozeff
    Ciekawe. Szkoda, że nie użyto popularnych ustawień GPU, w miejsce stock.
  4. Joozeff
    Jest, niestety. Mechanizm działa tak, że GPU nabiera energii, żeby zrobić boost (wynikający z ustawień zegara i napięcia), następnie uderza w limit mocy, gwałtowanie zbija taktowanie aby zmniejszyć budżet energetyczny (krzywa f -> V), pobór spada i GPU ponownie próbuje zrobić boost, bo widzi możliwość. Kłopot - power limit działa reaktywnie, nie proaktywnie. Efektem będzie spadek fps w 1% Low. Sprawdź sam, RTSS liczy coś takiego. Owszem, masz rację, że zmniejszanie napięcia będzie powodować wskakiwanie GPU na wyższe takty, ale na to sensowne rozwiązanie jest tylko jedno - ustawić suwakiem max taktowanie. Ale pozwolić GPU samemu dobierać boost (i energię) do nastaw napięcia i częstotliwości. [dodane] Jest w Adrenalin robienie profilów dostrajania dla wybranej gry. Można zrobić kilka z różnym taktowaniem, a potem ustawić. Z tego, co pamiętam, w momencie uruchamiania gry Adrenalin ładuje dany profil, a po wyjściu z gry wraca do domyślnego.
  5. Joozeff
    GPU ma krzywą zależności f -> V, którą się posługuje dynamicznie. Jeśli zmniejszasz taktowanie (albo dzieje się to w efekcie dobicia GPU do Power Limitu), to GPU zaczyna używać niższego napięcia. Moc jest proporcjonalna do kwadratu napięcia, więc ma to duże znaczenie, bo barierą dla GPU jest moc (i max napięcie, które jest możliwe). Dlatego pomimo niższego taktowania efektywność może być wyższa, bo GPU częściej idzie w wyższy boost. Gdzieś tam w nastawach będzie złoty środek, dla danego egzemplarza, tak w przybliżeniu. Najlepiej znaleźć minimalne stabilne napięcie przy jakimś założonym taktowaniu. A potem podnosić pomału w górę napięcie (6-7mV to jest taki krok dla RDNA), równocześnie podnosząc taktowanie o ~25MHz. W pewnym momencie przyrosty taktowania będą się zmniejszać (sprawność energetyczna bedzie maleć). No i dla każdego takiego punktu warto mierzyć 2-3 rzeczy fps. Power Limit dopiero na koniec, ustawić blisko tego, co GPU pobiera w testach, żeby trzymało się tego napięcia/taktowania.
  6. Joozeff
    Wiesz, tutaj od razu widzę możliwość, że stock też może opierać się na Power Limit (tym domyślnym) i tak pewnie będzie, jeśli nie ma jakiegoś innego limitu (typu górny limit FPS w grze). Testy syntetyczne stale obciążają GPU w ten sam sposób. W grach - obciążenie zależy od sceny. Popatrz na to tak: sceny mniej złożone (nazwijmy je "nie-syntetyczne") - masz niższe napięcie, co oznacza, że GPU z tej samej energii może pójść w boost wyżej, o ile nadal zostaje w ramach PL. W tym będzie plus. W scenach bardziej złożonych (tych bliższych "syntetycznym") GPU oprze się o PL, ale ... z niższym napięciem, więc może być trochę gorzej niż stock, który pozwala na wyższy PL, ale podaje wyższe napięcie, a P (moc) ~ V2 (kwadrat napięcia). Więc kwestia gry, ile procent klatek jest tych mniej a ile bardziej złożonych. FPS jest średnią. Dlatego owszem, lepiej testować na syntetykach, bo w grach realnych zwykle jest lepiej, jeśli w syntetykach różnica jest niewielka. Jakbyś chciał realnie sprawdzić możliwości, to dotykanie PL powinno być ostatnią rzeczą. Pierwsza rzecz, to zmniejszenie napięcia. Druga, połączona - ograniczenie taktowania tak, żeby GPU było efektywnie jak najbliżej ustawionej wartości. Szukanie sweet spotu. Wiem, że to polecałem, ale ... z mojego doświadczenia, trzeba każdorazowo odpalać grę od zera. Bo każde kolejne odpalenie gry - daje gorszy rezultat. Ja chyba powtarzałem benchmark 5x (na jednym odpaleniu gry), a potem robiłem średnią z wyników. Bo różnice są znaczne.
  7. Joozeff
    Ciekawe to i myślę, że możliwe. Te -80mV na rdzeń w stosunku do bazy 1.1V, gdzie moc jest proporcjonalna do kwadratu napięcia, może oszczędzić z 15% mocy, więc połowa z tych -30% nic nie zmienia. Za to te drugie 15% - tu może być ciekawie, bo dobicie GPU do PL powoduje throttling, zrzucenie zegarów, niższe zegary to niższe napięcie, a niższe napięcie to niższa moc. Czyli obniżenie taktowania, ale nie wprost. To taka hipoteza. Ciekawi mnie co by było, gdybyś zupełnie nie dotykał PL, ale oprócz napięcia -80mV obniżył trochę taktowanie. Bo tak jak pisałem, ustawione taktowanie to cel dla GPU, wcale nie musi być osiągalne. Ustawienie niższego celu może dać lepszy efekt - stabilny boost zamiast rwanego. Ogólnie dotykasz sedna istnienia takiego sweet spotu dla danego egzemplarza. I to jest dużo lepsze niż fabryczne nastawy, które mają działać dla każdego egzemplarza, bez uwzględniania jego sprawności energetycznej.
  8. Joozeff
    Jestem ciekawy jak wygląda porównanie 1% Low w obu przypadkach.
  9. Joozeff
    Prawda. Dla RDNA2 działał MPT, tam można było ustawiając Vmax ograniczyć tylko top krzywej, nie ruszając środka. To sporo poprawiało stabilność, bo to, co jest w Adrenalin tak jak opisałeś - działa jak offset dla całego zakresu. Przesunięcie może zdestabilizować środek, kiedy górny zakres jest ok. Można to było częściowo obejść ustawiając w Adrenalin wysokie taktowanie minimalne, ale w RDNA4 taka nastawa zniknęła. To prościej chyba kupić po prostu słabsze GPU z rodziny z niższym poborem mocy
  10. Joozeff
    Tak, pisałem o tym wczesniej. Radeony są skonstruowane tak, że prędkość CU zależy od rodzaju obciążenia numerycznego CU (nie ma dedykowanych rdzeni jak u "zielonych"). Ale to co ustawiasz jako częstotliwość, to nie jest wartość dyskretna, ale zależność częstotliwości od napięcia w całym spektrum pracy. Nie ma większego sensu patrzeć na to jaka jest aktualna częstotliwość, ale na utylizację i efektywność. W Radeonach częstotliwość stale pływa, bo wynika z rodzaju obciążenia. Porównywanie tego z odmienną architekturą "zielonych" nie ma sensu, to po prostu inaczej działa. Powtórzę - jakaś analogia jest z Ryzenami, tam też nie ma konkretnej częstotliwości, CPU boostuje do takiej wartości, do jakiej może przy aktualnym obciążeniu i warunkach pracy. Dlatego usztywnienie tego Power Limitem dla mnie to coś, co psuje ten mechanizm. Nie będzie to optymalne energetycznie. Moim zdaniem lepszym pomysłem z Radeonami jest zmiana napięcia i taktowania, bo to wymusi zmianę krzywej, która kontroluje pracę w całym zakresie obciążeń. GPU nie będzie boostował tylko po to, żeby PL to gasił. Nic więcej nie dodam. Zgadzam się z Twoimi obserwacjami, ale mechanizm ukryty pod spodem działa inaczej, niż to opisujesz. Co więcej, zależność między napięciem a taktowaniem też wymaga czasu i testów, bo tam też występuje throttling - zbyt niskie napięcie ogranicza boost, więc trzeba szukać tego najlepszego dla danego egzemplarza ustawienia i to różnicując rodzaj obciążenia. Może tak, żeby coś wyjaśnić: taktowanie w Radkach to nie jest ustawienie, że GPU ma z takim taktowaniem pracować 100%. To jest ustawienie górnej granicy, której GPU w swoim boost ma nie przekraczać. Z tego będą wynikać parametry pracy. A one będą zależeć od rodzaju obciążenia numerycznego, nie zawsze maksymalny boost jest możliwy. Bardziej konkretnym ustawieniem jest napięcie, chociaż ono pośrednio zależy od aktualnego taktowania. I to też trzeba rozumieć, jako napięcie maksymalne, a nie napięcie stałe.
  11. Joozeff
    W mojej ocenie to jest na odwrót: obniżyć taktowanie czyli głównie boost, po to, żeby zdjąć napięcie. W efekcie obu - obniży się pobór mocy. Po ustabilizowaniu napięcia można próbować zwiększać boost ponownie (taktowanie) ale z pomiarem efektywności (jakimś sensownym obciążeniem - np testem Cyberpunk 2077, albo coś z 3D Mark). Czyli zakładany pobór mocy (ile chcemy ściągnąć) jest tym pierwszym krokiem. Zgadzam się że "smok" 300W w budzie, to nie jest to co powinno. Lepiej jak to jest zdecydowanie bliżej 200W. Limit mocy - spoko, być może plus z tego największy, że to "szybka ścieżka". Ale to zrzuca takty. GPU posługuje się krzywą zależności częstotliwości od napięcia. Lepiej zmniejszając napięcie przesunąć tą całą zależności i niech to sobie działa. A Limit mocy to coś, co mówi "nie" w ramach tej zależności. Nie wiem, czy to dobre, żeby GPU albo CPU pracowało na throttlingu. Mam wrażenie (może mylne), że to będzie jak taka czkawka, energia idzie na boost, żeby za moment kaganiec ją zgasił. I tak w kółko. Może mało widziałem, ale nie kojarzę "Radka", który by miał celowo duszenie boosta Limitem mocy. W Ryzenach - zasada też jest taka, żeby EDC/TDC nie dusiło boosta.
  12. Joozeff
    Trochę nie ten temat, ale może się przyda: CoreCycler. Można ustawić auto i apka sama modyfikuje wartości CO w trakcie testów, czyli zadajesz na stracie -30 na wszystkich i zostawiasz do testów. Jak wyskoczy niestabilność (błędny wynik matematyczny) apka obniży (doda) krok do CO i puści test na dany rdzeń ponownie. Szkoda, że brak czegoś podobnego dla Radeonów i trzeba testować stabilność zmniejszania napięcia ręcznie. Poza tym mam podobne do Twojego podejście co do GPU/CPU: zrobić UV, potem w jego ramach uzyskać możliwe OC, ale z naciskiem na stabilność i sens (efekt per wat) i zostawić. Jak się trafi dobry egzemplarz, to można sporo zyskać. Super Dodam, że taktowanie - chodzi o to, że chwilowy boost to takie szarpanie się GPU w górę i dół, które przede wszystkim pobiera moc. Po ustabilizowaniu napięcia lepiej zmniejszyć takty patrząc na efektywność. Szukać takiego sweet spotu, w którym osiągi są zbliżone, a boost nie pływa. Fajna zabawa, jak ktoś lubi w tym grzebać, bo to testy i testy
  13. Joozeff
    Nie rozumiemy się, chyba. Samo ustawienie suwaka zegara wyżej nie znaczy, że boost tak pójdzie. Ograniczeniem jest napięcie, to z niego wynika co się da. Dlatego warto mierzyć np efektywne taktowanie w HWiNFO. Czyli jak często GPU dobija do tego ustawionego taktowania. UV na danym egzemplarzu polega na tym, żeby obniżyć to napięcie i nie stracić efektywnego boosta. Tak jak napisałem wczesniej, podobny mechanizm do Curve Optimizer dla Ryzena, w którym dany procek (egzemplarz) może więcej. Kluczowe jest to napięcie i egzemplarz. Domyślnie - każdy egzemplarz GPU ma ustawione te same wartości. Power Limit to duszenie GPU, które być może używa zbyt dużego napięcia w stosunku do tego, co dany egzemplarz rzeczywiście potrzebuje. Co więcej, jak tak myślę, to dochodzenie GPU do Power Limit będzie powodowało, że GPU będzie zrzucał zegary, żeby zmniejszyć moc, za chwilę przyspieszał i tak w kółko. Nie jestem pewien efektywności czegoś takiego.
  14. Joozeff
    No tak, tak ma być, co w tym dziwnego? Radeon idzie w stronę Ryzena (nieprzypadkowo), to rodzaj obciążenia numerycznego decyduje o poborze mocy i wartości boost. Właśnie dlatego korkowanie tego Power Limitem wydaje mi się takim sobie pomysłem. Quake 2 RTX to inne obciążenie numeryczne niż Haven Benchmark. Podejrzewam że RT obciąża Compute Unit (CU) najbardziej (część o nazwie Ray Accelerator, pewnie AI Accelerator), co w grach RT nie pracuje, więc pobiera mniej mocy. Taktowanie (a dokładnie boost) też zależy od rodzaju obciążenia. Realnie najlepszym ogranicznikiem (metodą na UV) jest zmniejszanie napięcia, bo będzie się skalować z każdym rodzajem obciążenia. Dobrze jest myśleć o Radeonie trochę jak o Ryzenie Sens w Ryzenie ma chyba tylko CO, czyli ~zmniejszanie napięcia (per rdzeń). Reszta się sama dostosowuje (pobór mocy, boost -> taktowanie). Z Radeonem jest podobnie. Taktowanie i moc nie powinno być ograniczeniem - jeśli dana sztuka potrafi więcej -> niech tak pracuje.
  15. Joozeff
    Tak powinno być. Power Limit jest kagańcem, nie pompowaniem mocy w GPU. Jeśli GPU potrzebuje więcej mocy do aktualnych operacji i tego nie dostanie (bo dotyka Power Limitu), to zrzuca boost, czyli spada wydajność. Przyznam, że mam kłopot z tą ideą, żeby robić UV przez zmniejszanie Power Limit. Bo to mi wygląda że te mniej złożone operacje, które wymagają mniej mocy, będą wykonywać się szybciej, a te bardziej złożone - będą trafiać na Power Limit i throttling. Zastanawiam się, czy nie lepszy efekt da zmniejszenie zegara rdzenia i napięcia.
  16. Joozeff
    OK, tak, w takim przypadku lepiej nie testować. Ja podmieniłem biblioteki w HD2, widać tam jest mniej restrykcyjny Game Guard. Same stery chyba nie wystarczą, pewnie będzie wersja tej biblioteki, czyli gra będzie musiała to zaimplementować oficjalnie.
  17. Joozeff
    @Lameismyname Ja mam innym RAM w kompie. Mam swoje stare kostki 2x 8GB. Z OC, pozaciskane timingi (dobre Hynixy CJR SR). Nie robiły problemów, nic podobnego. Ten sam CPU, płyta. Nie chcę pracować na tej wątpliwej pamięci, bo pomimo że zakres adresowy, w którym dzieją się te przekłamania nie jest duży, a przekłamanie na 2 bitach tylko (i to jest stale powtarzalne), to czasem mam jakiś crash, który wcześniej zwalałem na grę/GPU i że "czasem tak jest". A i ten zakres adresów i stale 2 konkretne przekłamane bity (z 32) jak dla mnie wygląda na jakąś konkretną kość w module, albo kości, ścieżki - cokolwiek. Czemu to potrafi działać sprawnie - za cholerę. Teraz zacząłem się zastanawiać,co by było, gdybym zwiększył napięcie, bo u mnie to max 1.38V. Może coś by się odetkało? [dodane] Nic się nie odetkało, wstawiłem te RAMy po całym dniu w pudełku, 1.4V nic nie poprawiło. Liczyłem jeszcze na to, że może to leżenie w pudełku czymś zaskoczy, jakby tak nagle zaczęło działać. Ale nie. Widać magia dzieje się w serwisie sprzedawcy. Samo opakowanie nie jest magiczne
  18. Joozeff
    Czysty profil XMP też generuje błędy. A z drugiej strony ciasne OC potrafi pracować stabilnie przez kilka dni. Jak wsadzę do innego kompa, to ile ma to tam pracować, żeby rezultat był wiarygodny - tydzień? Miesiąc? To jest rozważanie hipotetyczne, wskazuję, w czym jest problem. Dostałem w poniedziałek zwrot tych RAMów, wsadziłem do kompa i od razu przywróciłem w BIOS ciasne timingi, które miałem ustawione poprzednim razem. I od razu na to puściłem testy TM5, kilka godzin. Zero błędów. Potem na tych ciasnych timingach komp pracował do dziś, codziennie po włączeniu zapuszczałem na 10 minut MemTest86. Bez błędów. Dziś się sypnęło - błąd pierwszy po 30 sekundach, potem lawina pozostałych. Wywaliłem te ciasne timingi, załadowałem czyste XMP. Bez zmian. Wyjąłem sprawny moduł, zostawiłem ten który generował błędy w przeszłości solo. Błędy. Zmieniłem slot. Błędy. Wyjąłem moduł z błędami, wstawiłem drugi, sprawny. Przeszło cały cykl MemTest86 bez błędu. Powtarzam tą procedurę już po raz 3ci, za każdym razem jest to samo, ten sam rodzaj błędów, zakresy adresowe. I też do jakiegoś momentu moduł jest sprawny, a po jakimś okresie traci tą sprawność. Scenariusz serwisu jest taki, że wstawiają kości i sprawdzają, nie wiem, nawet kilka h. U mnie to też chodzi poprawnie przez 3 dni.
  19. Joozeff
    Doceniam, ale nie w tym kłopot. Problem w tym, że ja to wysyłam do sprzedawcy, z pełnym opisem, załącznikami, a oni testują u siebie i to działa (nie zakładam złej woli). Potem odsyłają do mnie i u mnie działa przez 3 dni (dokładnie tak się 2x wydarzyło, gdzie dziś jest 4-ty dzień tego 2-go razu). Dlatego jest jakiś ogólny problem z rodzajem usterki, mnie ciekawi nie "czy" moduł jest zwalony, bo jest (na zasadzie prostego różnicowania między tym, który działa poprawnie, a tym, który generuje powtarzalne błędy, kiedy już zacznie). Mnie ciekawi co takiego tam się dzieje fizycznie, co by wyjaśniało te zachowania. Powiedziałbym, że może gromadzenie się jakiegoś ładunku, który nie spływa, ale nie znam się dobrze na sposobie działania RAMów. Tak czy siak, to feler, tak nie powinno się dziać, na co wskazaniem jest poprawnie działający moduł. No i inna para RAMów 2x 8GB, też Hynix CJR, które działają bez problemów. Czyli mam 4 moduły, ta sama platforma, 1 moduł daje te przekłamania, niezależnie od gniazda, taktowania. A wszystkie 4 katowane na stabilność godziny w TM5. Brałbym to, co się rysuje.
  20. Joozeff
    Właśnie tego nie wiem. Nie mam takiej ścieżki. No chyba że 3 dni po serwisie, bo tak było 2x Jak już świrują, to zawsze jeden moduł, niezależnie od gniazda. Te same 2 bity (pierwsze testy w lutym robiłem, mam raporty z MemTest86) i podobny zakres adresowy. Drugi moduł wszystko przechodzi bez błędu - więc ... raczej to nic innego. Różne sloty, zmieniałem BIOS, taktowanie, przecierałem styki. To świrowanie nie ustępuje, to nie jest coś cyklicznego. Jak już się zacznie, to jest. Za pierwszym razem walczyłem z tym prawie tydzień, nie mogąc rozpoznać źródła niestabilności (zakładałem, że może Ryzen coś).
  21. Joozeff
    Konsument ma wybór w oparciu o niezgodność towaru z umową, tak mi się mocno wydaje (czy zwrot kasy, czy wymiana). Myślę nad wersją z zimnym lutem. Nie jestem pewien, bo ja dziś jak i poprzednio po odesłaniu od sprzedawcy, miałem błędy na zimnym kompie, ale ... nie od razu. Nie pierwszego dnia. A pierwszego katowanie pamięci. Zarówno teraz jak i poprzednio były 3 dni bez błędu, codziennie na starcie MemTest86, zanim Windows odpali.
  22. Joozeff
    Właśnie dziś problem powrócił. Komp na zimno, już standardowo odpalanie zaczynam od szybkiego MemTest86 z USB. No i powtórka z rozrywki: 3733MHz błędy, potem XMP 3600MHz błędy. Jeden moduł sprawny, drugi te same przekłamania na dwóch bitach, w stałym co wcześniej zakresie adresowym. W międzyczasie wyłączam kompa, przekładam moduły w różne sloty, nic nie pomaga. A wczoraj działało. Zaczynam pomału dopuszczać magię Jestem ciekawy, co robią w serwisie sprzedawcy, że to potem jakiś czas u mnie działa. Jeszcze wczoraj puszczałem na tych RAMach TM5 1usmus, tak z dobre 40 minut, bez żadnego problemu. A dziś MemTest86 z 60 błędów, i to tak nie dobił nawet do 50%. Niby fizyka. Tak, myślę, że G.Skill to będzie właściwy krok dalszy, a jeśli tam wymienią, no to poproszę sprzedawcę o zwrot kosztów wysyłki
  23. Joozeff
    Dzięki za podpowiedź. Póki co zwiększyłem strumień powietrza w obudowie w zależności od HotSpot GPU - mam takie sprytne zależności w FanControl. Crashy od tego momentu nie było. Napięcie Vdimm 1.37V, ale próbowałem 1.36V i to też nic nie zmieniło w testach. AiO mam od Be Quiet! Bardziej myślę o jakimś hipotetycznym rozwiązaniu, bo oddawanie ciepła przez GPU do środka obudowy to raczej standard, chłodzenie wodne GPU, to już większa zabawa i wydatek. Może wystarczyłby jakiś większy radiator na RAMy? Luźniejsze nastawy to w mojej ocenie takie poddawanie się trochę Ta opisana sytuacja była na Hynixach CJR SR od Kingston'a. Aktualnie mam w kompie Hynixy CJR DR od G.Skill - tutaj testów nie robiłem.
  24. Joozeff
    Taka historia. Na początku zeszłego roku, jeszcze przed podwyżką, kupiłem DDR4 G.Skill 2x16GB. Wstawiłem do kompa (bez testowania), ustawiłem taktowanie 3733MHz i ... zapomniałem o nich. Na początku tego roku, po wymianie GPU i zabawach w jego tune'owanie, stwierdziłem, że pozacieśniam trochę timingi RAMu. Wziąłem TM5 1usmus i ... co ustawię, przejdzie 3 cykle, to zmienię coś innego, wywala błędy, cofam tą ostatnią zmianę - błędy nadal. Próbowałem to stabilizować przez 2 dni, cudowałem z napięciami, sprawdziłem ponownie CO w Ryzenie - bez sukcesu. Na koniec mnie olśniło, wrzuciłem MemTest86. Jeden moduł dawał przekłamania na dwóch bitach, w jakimś stałym zakresie adresowym. Sprawdzałem różne sloty solo, profil XMP, czysty JEDEC - bez różnicy. Drugi moduł spoko. Spakowałem RAMy, odesłałem do sprzedawcy, powołując się na niezgodność towaru z umową. Po tygodniu odrzucenie, "u nas działa". Przyszła paczka, wrzuciłem na półkę, bo były inne rzeczy na tapecie. Paczka poleżała kilka miesięcy do lipca. Wtedy przyszedł czas. Otworzyłem, pamięci do kompa, MemTest86 - wszystko działa. Ustawiłem 3733MHz i zacząłem katować TM5 1usmus i anta777 - stabilne jak skała i powtarzalne. Pozacieśniałem timingi, to było wiele godzin testów, przez kilka dni, kiedy miałem czas, coś zacieśniałem i potem TM5. Na 4ty dzień, zaczęły się znowu problemy: coś zacieśniłem, błąd, cofnąłem do stabilnego - nadal błąd. Nauczony doświadczeniem znowu MemTest86 - przekłamania na 2 liniach bitowych jak na początku roku (tych samych), podobny zakres adresowy. Ponownie testowanie każdego modułu osobno, różne sloty, XMP, JEDEC - cały czas przekłamania. Spakowałem paczkę, opisałem wszystko co się dało, jakąś przypadkowość, wskazałem analogie co do konkretnego modułu i przekłamań zgodnych z tymi z początku roku, dołączyłem raporty z MemTest86, wysłałem ponownie do sprzedawcy. Po tygodniu powtórka: decyzja o odrzuceniu, "u nas działa". Dziś odebrałem paczkę. Wstawiam do kompa - ano działa. Ustawiam 3733MHz z tymi ciasnymi timingami które wypracowałem wcześniej - działa. MemTest86 przechodzi. Nie mam pomysłu o co chodzi. Ktoś, coś?
  25. Joozeff
    Wcześniej była metafora.
×
×
  • Dodaj nową pozycję...