premiero

Woda to nie miedź. Woda ma słabą przewodność cieplną, ale za to dużą pojemność - odwrotnie jest z miedzią, która szybko odbiera i dobrze "dmuchana" szybko oddaje ciepło. Dlatego regulacja prędkości wentylatorów. w LC powinna odbywać na podstawie temp płynu, a nie temp. podzespołów.

Czujnik to musisz dokupić, Ja na przykład mam czujnik od monsoon, o taki: https://www.performance-pcs.com/water-cooling/fittings-connectors/monsoon-premium-g-1-4-temperature-plug-gold-mon-tpl-go.html i musisz podłączyć go pod płytę na której jest header do mierzenia temperatury (ja mam taki w Asus ProArt X670E-CREATOR WIFI). Ale jeśli denerwują cię nagłe skok prędkości, to sprawdź prawdopodobnie temat załatwisz inaczej. W wielu płytach w BIOS-ie jest opcja w jaki sposób reagować na zmianę temperatury - skokowo o czy płynnie. W MSI to się chyba nazywa ""ramp up in X.XX sec increments" gdzie X.XX oznacza sekundy. Możesz ustawić to np na 1.5 sekundy.

Chyba większość sprzętu IT kupionego oficjalnym kanałem dystrybucji w Polsce idzie przez AB. SA. To największy hurtownik. Z tego co się orientuję, jak coś jest na gwarancji i z tego uprawnienia korzysta konsument, (nie mówię o rękojmi sklepowej), to sklep i tak przepuszcza to przez AB. Co do gwarancji udzielonej przez Gainwarda to ja rozumiem to tak, że reklamować możesz przez dowolnego zakontraktowanego pośrednika/partnera, czyli niekoniecznie w sklepie, w którym kupiłeś. Jako klient indywidualny do tej pory robiłem RMA u różnych producentów (ASUS, Seagate, Kingston, D-link, Patriot) i nikt nie kazał mi przesyłać przez pośredników. Owszem, wymagali dowodu zakupu, ale dla niektórych (gdzie była wieczysta gwarancja) wystarczył sam fakt posiadania części.

Nie napisałeś nic o zasilaczu, ale w tym budżecie jeśli liczą się tylko gry, to wywaliłbym obecną grafę na rzecz RTX2070 lub 5700XT (obie można dostać za 1699 zł), za resztę kasy rozbudował RAM, a jak sprzedasz starą grafę to zobaczysz ile Ci zostanie i wtedy ewentualnie upgrade CPU.

@Chlebu- skoro GPU nie jest obsługiwany, to ja bym się jeszcze zastanowił nad RAM-em. Wg mnie Twoja pierwotna propozycja była lepsza niż kolegi @omelette du fromage. Lepsze 3200@CL14 niż 3600@CL18.

Nie robiłem nigdy w tej aplikacji, ale zastanawia mnie, dlaczego renderujesz na CPU a nie GPU? Jeśli Twoim zamierzeniem jest skrócenie czasu renderingu, to chyba powinieneś iść w tym kierunku? Wrzucić jakiegoś RTX ze sprzętowym wsparciem RT.

Oczywiście nikt bogatemu nie zabroni płacić 70% więcej za kartę która daje 30% większą wydajność, ale właśnie tu jest rozsądek. Wiesz, ja już dawno wyrosłem z pogoni za cyferkami. 160 klatek czy 140 w grze nie ma znaczenia, a ciszy przy wymienionym setupie się nie uzyska. Przy WC potencjał do OC będzie większy zarówno CPU jak i GPU, nie wspominając o żywotności bo temperatury będą sporo niższe.

@Firedash Jeśli chodzi o rozsądne podejście, to raczej skłaniałbym się w kierunku najtańszego referenta 1080ti, ewentualnie 2080 jeśli raytraycing jest priorytetem, a za zaoszczędzoną kasę zbudowałbym custom loop, z wc na cpu i full cover na gpu.

Jeśli chcesz ciszę, to nie wyobrażam sobie tego zestawu bez WC. Patrząc na zestaw zastanawiam się, czy chodzi o to, żeby było drogo, czy rozsądnie? :)

Ech, już sam nie wiem o co bigos. Albo padłem ofiarą testu, albo nie wiem o co chodzi: Na nowym OROM-ie, dla paska 64k i klastra 64k: - spadek zapisu liniowego w porównaniu do poprzedniej wersji o 200MB/s i o ponad 90MB/s dla bloków 512k - tutaj ciekawostka, ustawienia Cache WriteBack OFF, Disk Cache ON, Opróżnianie bufora zapisu OFF. I wyszło dokładnie tak samo jak przy starym OROMIE ale dla ustawień WriteBack OFF, Disk Cache ON, Opróżnianie bufora zapisu ON. - Write Back ON, Disk Cache ON, Opróżnianie bufora zapisu OFF Zrobiłem też pomiar HD-Tachem i wynik mnie zaskoczył: Żadnych spike'ów, wykres całkiem równy. Skąd w takim razie tak słaby odczyt w CDM? Wkurzyłem się i postanowiłem przeprowadzić test na żywych plikach. Do testów użyłem łącznie 440GB danych. Okazało się że testy syntetyczne można wrzucić do kosza. Nic się nie trzymało kupy. W testach praktycznych pokazała się przewaga tego co powinno być oczywiste - czyli włączonego Write-Back Cache'a. Kopiowanie dużych plików z dysku SSD na macierz praktycznie nie spadało poniżej 200MB/s, jak tylko wyłączałem WBC, od razu prędkości spadały do wartości ~60MB/s. Jeszcze większą różnicę było widać przy kopiowaniu małych plików. Zrzuty dla ATTO (dysk zapełniony 440GB danych): WBC ON/OFF Chyba jednak wrócę do paska 128k z włączonym WBC. Sprawdzę jeszcze jak będzie się to zachowywać przy OROM-ie 13.1.0.2126 i ostatni test zrobię na Windowsowym RAID-5. Zmęczyły mnie już testy ;/ EDIT - nie zrobię testów na Windowsowym RAID-5, ponieważ Windows 7 nie obsługuje software'owego RAID-5 :(

@rafa - wszystkie testy masz w 2 poście dla każdej możliwej kombinacji paska/klastra. Dla zapisu najlepszy rozmiar wychodził 64k/64k. I zostałbym przy tym, gdyby tylko odczyt był na poziomie 128k/64k.

Wykres ze paska/klastra 128k/64k Podejrzewam że dla paska 64k/64k byłby mniej "popikowany" niż dla 32k/64k, ale nie tak równy jak dla 128k. Zrobiłem jeszcze szybki test na woluminie RAID-0: Stripe 16k: | 4k | 64k | Stripe 128k: | 4k | 4k WriteBack ON | 64k No nic, zmodyfikowałem sobie BIOS, zrobię upgrade OROM'a i zobaczę czy to coś zmienia. Robi się co raz ciekawiej, po aktualizacji OROM wyniki dla RAID-5, 128k/64 (bez tworzenia woluminu od nowa) - spadek zapisu liniowego o połowę, a także spadki przy odczycie i zapisie 512k - z włączonym WriteBack trochę lepiej ale i tak gorzej niż na OPTION_ROM_12.7.0.1936 Stworzę od nowa na nowy OROM-ie wolumin, może coś to zmieni i znowu zrobię test.

@Dijkstra - niestety, nie znalazłem żadnego upgrade firmware do tych WD-ków (przy okazji znalazłem do mojego dysku SSD). Asus dla Z87-Pro również nie ma nowszej wersji BIOS niż 2005, a tam jest OptionROM 12.7.0.1936. @radiergummi - dzięki za linka, jeśli nic nie wymyślę, będę musiał wyekstrahować z innej płyty nowszą wersję Option-ROMu i spróbować zmodyfikować BIOS. @rafa - HD-Tach przestałem używać kilka lat temu, ponieważ nie jest w mojej opini wiarygodny i często pokazuje głupoty. W Aidzie wchodzisz Tools->Disk Benchmark->Wybierasz Linear Read i dysk który ma być przetestowany. Dostajesz piękny wykres, niestety czas jego wykonania to około 400-500 minut, więc robiłem go tylko 5 minut, także nie wrzucałem wykresu, jest tylko tabela z Read Suite. Dla świętego spokoju zrobiłem test HD-Tachem - tutaj wyniki dla paska/klastra 32k/64k. Pierwszy wykres to QuickBench 8MB Zones (taaaaa chciałbym takie wyniki) , drugi Long Bench 32 MB Zones. Zrzuty z ATTO dla 32k stripe i 4k cluster/64k cluster

Dane są na innych dyskach w tej chwili. Po co mi mirror + backup? To nie dane krytyczne, przecież to byłoby zwykłe marnotrawstwo przestrzeni. Mam propozycję, aby niepotrzebnie nie przerzucać się nad wyższością jednego RAIDA na innym, skupmy się nad tą 5-ką. Założenie jest takie, że ma być RAID-5 i umarł w butach. Wątek powstał aby zoptymalizować tego RAID-5, a nie zmieniać na inną wersję :) i tego się trzymajmy.

Jak chesz zbackupować 4TB na 2TB dysku? I rozumiem chodziło ci o "0" poziom.

Optymalizacja to podstawa, a jedno nie wyklucza drugiego. Ty byś się zadowolił taką wydajnością odczytu, wiedząc że może (powinno) być lepiej? Nie oczekuję wydajności 3 dyskowego RAID'a-0, ale 3 dyskowy RAID-5 powinien przy idealnej konfiguracji mieć wydajność na poziomie 2 dyskowego RAID-0.

Aida, robi to samo co HD-Tach, zrzuty masz wyżej i tam wygląda to dużo lepiej (przy 64/64 odczyt i zapis liniowy na początku dysku oba 270MB/s). Stąd zastanawiają mnie te rozbieżności między benchmarkami. Jak już zrobię testy na pasku 32k, o ile nie okaże się wydajniejszy w CDM, zakładam z powrotem volumin 64k/64k, i wrzucę testy na ATTO.

Z tym czy "nadaje się" to się okaże, natomiast nie przeceniałbym aż tak bardzo sprzętowych raidów. Miałem kilka 5-tek w robocie na hardwareowych adaptekach, i powiem szczerze, że do pięt nie dorastały temu Intelowi, nie mówiąc że każdy z nich po około 3-4 latach wyzionął ducha, a koszt jednego był coś koło 600-700 USD. Z resztą problem stanowi wyłącznie odczyt w CrystalDiskMarku, czego akurat nie ma przy pasku 128k. Uważasz że wydajność przy 64/64 dla zapisu jest słaba? Ja nie. Może problemem u mnie są zastosowane dyski? Niestety nie mam innych 2Tb aby sprawdzić.

Sprawdziłem jak jest z tym cachem, więc tak, jednak jest możliwość wyłączenia cache dla dysków przy włączonym cache'u dla macierzy write-back/write-through/read-only. Akurat mam zainicjalizowany wolumin na pasku 128k więc zrobiłem porównanie: 1. Stripe 128k / 64 cluster - ustawienia standardowe, czyli cache dyskowy ON, cache macierzy OFF, opróżnianie bufora zapisu ON 2. Stripe 128k / 64 cluster - cache dyskowy ON, cache write-back ON, opróżnianie bufora zapisu OFF Jedyny pozytywny przypadek, gdzie WB dało wzrost wydajności dla zapisu liniowego i losowego zapisu bloków 4k. 3. Stripe 128k / 64 cluster - cache dyskowy OFF, cache write-back ON, opróżnianie bufora zapisu OFF 4a. Stripe 128k / 64 cluster - cache dyskowy ON, cache write-through ON, opróżnianie bufora zapisu OFF 4b. Stripe 128k / 64 cluster - cache dyskowy ON, cache write-through ON, opróżnianie bufora zapisu ON 4c. Stripe 128k / 64 cluster - cache dyskowy OFF, cache write-through ON, opróżnianie bufora zapisu OFF 4d. Stripe 128k / 64 cluster - cache dyskowy OFF, cache write-through ON, opróżnianie bufora zapisu ON 5a. Stripe 128k / 64 cluster - cache dyskowy ON, cache read-only ON, opróżnianie bufora zapisu OFF 5b. Stripe 128k / 64 cluster - cache dyskowy ON, cache read-only ON, opróżnianie bufora zapisu ON 5c. Stripe 128k / 64 cluster - cache dyskowy OFF, cache read only ON, opróżnianie bufora zapisu OFF 5d. Stripe 128k / 64 cluster - cache dyskowy OFF, cache read only ON, opróżnianie bufora zapisu ON Jak widać z załączonych obrazków, zgodnie z moimi przewidywaniami, wyłączenie cache dyskowego powoduje dramatyczny spadek wydajności zapisu. Testy 4c,4d 5c,5d trwały łącznie około 2 godzin. Natomiast włączenie jakiegokolwiek sposobu cache'owania przez kontroler macierzy nie zmienia prędkości odczytu, ma wpływ wyłącznie na zapis. Na chwilę obecną najlepsze warianty wydajnościowe, to 64/64 z Write-Back OFF i 128/64 z Write-Back ON. Przede mną kolejnych kilkanaście godzin inicjalizacji stripe'a 32k :) i później seria testów. Na zakończenie testów zrobię jeszcze porównanie do 3 dyskowego RAID-0.

@Klaus - Tak, każdy dysk testowałem najpierw osobno i wszystkie praktycznie wzorcowo zachowują się tak samo, więc wykluczam wadę jednego dysku. @Dijkstra - chyba przeoczyłeś drugi post ;) , jak widzisz testuję zależności rozmiar paska / rozmiar clustra NTFS i na razie najkorzystniej wychodzi 64k/64k. Jednak jest to proces długotrwały ze względu na rozmiar i czas potrzeby na inicjalizację woluminu. Co do oszczędzania energii, jest wyłączone aby wykluczyć wpływ, na włączonym zachowuje się identycznie. Sprawdzę z tym cachem co i jak i dam znać.

CPU raczej nie ma tu nic do rzeczy, nie zauważam żadnego obciążenia podczas pracy, no może 1%. A RAID0+backup to dobry gdy nie wszystko chcesz backupować, u mnie to rozwiązanie odpada.

Dzięki panowie, za porady, jednak nadal nie dają one odpowiedzi na pytanie - dlaczego odczyt jest taki wolny? Co do write-back, nie ważne czy włączony czy włączony, nie ma możliwości sterowania własnym cachem dyskowym.

Obiecane zrzuty: Na początek pojedynczy dysk, odpowiednio 0%, 42%, 88% zapełnienia. A tu benchmarki z RAID-5 3xHDD WD20EURX, odpowiednio: ROZMIAR STRIPE | ROZMIAR CLUSTRA Stripe 16k - | Inicjalizacja 4k | 4k | 8k | 16k | 32k | 64k | Stripe 32k - | Inicjalizacja 64k | 4k | 8k | 16k | 32k | 64k | 64k WriteBack ON | Stripe 64k - | Inicjalizacja 64k | 4k | 8k | 16k | 32k | 64k | Stripe 128k - | Inicjalizacja 64k | 4k | 8k | 16k | 32k | 64k | Dodatkowo wrzucam testy: RAID-5 64k stripe 64k cluster 3xHDD (0% Full) - Fully Initialized [Write Back Cache Enabled] W porównaniu do Cache'u wyłączonego widać spadek wydajności przy zapisie 512k a zapis 4k dostał 4 krotnego boosta. Reszta porównywalnie, zostawiam opcję WYŁĄCZONĄ. A tutaj zrzut z AIDY dla 64k/64k Cache Write Back wyłączony. Wygląda to lepiej niż w CrystalMarku. Zrobiłem również Linear Read i Linear Write test i tam również wyniki oscylują na początku dysku w granicach ~ 270MB/s dla odczytu/zapisu. ______________ A tutaj screeny przy wykorzystaniu funkcji Intel Smart Response (SSD Cache). Do tego celu użyłem dysku SSD Kingoston SH103S3120G 120 GB, na którym miałem system operacyjny. Ponieważ na dysku miałem około 50GB wolnego miejsca, zmniejszyłem partycję systemową o 30GB i dałem w Intel RST aby wykorzystał całe dostępne miejsce na cache dla Voluminu RAID-5. Po kliknięciu tej opcji mało nie dostałem zawału serca, bo przez chwilę myślałem, że straciłem dysk systemowy, zaczęły znikać ikonki z pulpitu i system mi się zrestartował. Na szczęście wszystko wstało jak należy, po "migracji" widać to tak: A tutaj benchmarki: RAID-5 64k stripe 64k cluster 3xHDD (0% Full) - Fully Initialized [sSD Cache 30GB Extended Mode] RAID-5 64k stripe 64k cluster 3xHDD (0% Full) - Fully Initialized [sSD Cache 30GB Max Performance Mode] Jak widać, nie ma róży bez kolców. Poza tym wyniki testów z użycie dysku SSD traktował bym raczej ostrożnie. Dla porównania wynik Read Test Suite z Aidy: No i tutaj potwierdza się moja teoria. Na razie wszystko wskazuje na najlepszą konfigurację 64k/64, dokończę sprawdzanie na innych paskach i jeśli okaże się że ta opcja jest rzeczywiście najlepsza, zacznę testy praktyczne, na zapełnionym dysku. Głównym celem będzie ustalenie czy korzystać z SSD Cache, czy nie. Obecnie inicjalizuje się wolumin na pasku 128k.

Witajcie. Mam problem z moim raidem na Platform Controller Hub (PCH). Konfiguracja: Asus Z87-Pro i7-4770K 16GB RAM RAID-5 na 3xWD20EURX Przeczytałem chyba gazylion stron na temat konfiguracji i optymalizacji RAID-5, i chociaż wszędzie piszą olać RAID5, dołożyć dysk i zrobić 10, to ja mam tylko 3 dyski i zależy mi aby mieć zabezpieczenie danych. Początkowo nieświadomie utworzyłem Volumin ze stripem 128k. W połączeniu z klastrem 4k dało to opłakane rezultaty w crystal marku - około 50 MB/s odczyt, zapis około 40 MB/s. Masakra. Oczywiście kopiowanie dużych plików śmigało nawet nawet (transfery rzędu 100 MB/s) ale daleko to było od moich oczekiwań. Natomiast kopiowanie małych plików, to już była tragedia - od 300kB/s do około 6Mb/s. Poświęciłem więc mnóstwo czasu, wyczyściłem cały wolumin i zacząłem tworzyć po kolei różne kombinacje. Do tej pory przetestowałem: 16k stripe / 4k cluster 16k stripe / 8k cluster 16k stripe / 16k cluster 16k stripe / 32k cluster 16k stripe / 64k cluster 64k stripe / 4k cluster 64k stripe / 8k cluster 64k stripe / 16k cluster 64k stripe / 32k cluster 64k stripe / 64k cluster 128k stripe / 4k cluster Idzie to jak krew z nosa, bo inicjalizowanie trwa około doby. Dla świętego spokoju przetestuję jeszcze warianty 32k i 128k Najlepsze wyniki w CrystalMarku na razie uzyskałem na konfiguracji 64k stripe / 64 cluster, ale za każdym razem zapis wychodzi szybszy niż odczyt. Wychodzi mi więc odwrotnie za każdym razem niż większości użytkowników, którzy narzekają na wolny zapis RAID-5 a szybki odczyt. Przykładowo przy konfiguracji 64stripe/64cluster sekwencyjny odczyt 150MB/s, zapis 270MB/s (dodam że włączenie w Intel RST opcji "opóźniony zapis" powoduje spowolnienie zapisu, gdzie teoretycznie powinno przyspieszyć!) Na razie nie wiem w czym jest problem. 1. Czy to problem WD-ków, bo już znalazłem w necie wątek VERY slow RAID5 on ICH10R with WDC Green series, ale tak na prawdę z niego nic nie wynika i problem dotyczy zapisu a nie odczytu i innego chipsetu. 2. A może to problem z Option ROM-em płyty głównej? Choć nie jestem pewny do końca jak to działa, bo wydaje mi się że Option ROM ma znaczenie tylko do momentu załadowania sterowników w systemie operacyjnym (mój driver to 13.​1.​0.​1058, natomiast wersja w BIOS-ie płyty głównej to zdaje się 12.7.0.1963) 3. A może CrystalMark daje [gluteus maximus]? Bo test HDD z AIDY przy liniowym odczycie pokazuje inne wartości (dużo wyższe) Co ciekawe, robiłem też testy podczas inicjalizacji woluminu, i o ile zapis rzeczywiście notuje drastyczny spadek, o tyle odczyt nie zmienia się praktycznie wcale. Jeśli nic mi się nie uda zrobić, to chyba będę musiał rozważyć opcję SSD-cache dla RAID-5, tylko nie wiem jak ona miałaby mi przyspieszyć odczyt? Jak wrócę do chaty, to wrzucę screeny z CrystalMarka dla każdej konfiguracji, może przyda się dla potomnych walczących z doborem rozmiaru paska vs klastra, bo tutaj ewidentnie widać zależności, natomiast problem ogólnego wolnego odczytu dla mnie na razie pozostaje nierozwiązany. Jeśli macie jakieś sugestie, bardzo proszę, jestem otwarty na nowe rozważania. Może ktoś z was ma u siebie RAID-5 na 3-ech dyskach i podzieliłby się wynikami z CrystalMArka? Znalazłem jeszcze jedną ciekawą informację odnośnie dopasowania pod względem podzielności: Partition offset (in kb) / stripe unit size(in kb) = integer Stripe unit size(in kb) / File allocation size(in kb) = integer. For 4K sector drives: Partition offset (in kb) / 4K = integer (this is usually meet when satisfying rule 2 above) Muszę sprawdzić jak to u mnie wychodzi. Sprawdziłem, jest ok. Partition offset wynosi 135266304 bajty = 132096 kilobajtów jest podzielne przez 128k (stripe) w całości, więc dla każdego niższego warunku (64,32,16,8,4) również będzie liczbą całkowitą. Tak na marginesie, ta reguła wcale nie potwierdza się w testach, co można zobaczyć niżej (przykład 16k stripe/64 cluster = 0,25 a daje lepsze wyniki niż 16k/16k = 1.)

Fajnie że trafiłem na ten temat, bo mam dokładnie taki sam problem. Od czasu do czasu nie rozwiązuje mi nazw, niezależnie od tego czy ustawię DNS-y na bramę, UPC, czy Tepsę, czy jakiś inne. W tym samym czasie DC++, WoT czy Winamp (Trance.fm) działają normalnie. U mnie Technishit TC7200. Jak puszczę ping po nazwie - nie działa - po IP - działa. Zauważyłem że problem zaczął się pojawiać wraz z uruchomieniem usługi UPC Wi-Free, notabene strasznie mnie tym HotSpotem zdżaźnili, zwłaszcza że jeszcze 3 dni temu nie było możiwości wyłączenia tego dla abonentów 30 Mbit/s (od 2 dni już można deaktywować), jednak wyłączenie tego nie zmieniło sytuacji.