Trwa konkurs "Ogól naczelnego", w którym codziennie możecie wygrać najnowsze maszynki systemowe Hydro Connect 5 marki Wilkinson Sword.

Więcej informacji
Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Krótki test Kingston HyperX Fury USB 3.0 64GB pod różnymi systemami plików na Windowsie i Ubuntu

Dziś będzie krótkie porównanie jak sprawuje się pendrive Kingston HyperX Fury USB 3.0 64GB pod zarówno różnymi systemami operacyjnymi, jak i różnymi systemami plików. Do zrobienia tego krótkiego porównania skłoniły mnie pewne rozbieżności w wydajności podczas użytkowania go pod tymi dwoma systemami. Zacznijmy może od warunków testu.

  • Komputer: Lenovo G710
  • HDD: WDC WD10JPCX 1000GB
  • USB: Intel USB 3.0 (Core i3 na pokładzie), w Ubuntu przedstawia się jako Linux Foundation 3.0 Root Hub
  • Plikiem testowym był plik wideo o rozmiarze 1,7GB
  • Zacznijmy może od ogólnego benchmarku tej pamięci przeprowadzonego w HD Tune i CrystalDiskMark:

    Na początek najbardziej podstawowy system plików - NTFS. Używam go w większości pamięci masowych ze względu na powszechność - odczyta go w zasadzie każdy system i każde urządzenie obsługujące USB. W tym wariancie dane były kopiowane z partycji NTFS na Kingstona zarówno pod Windows 7 jak i Ubuntu.

    Jak widać jest spora różnica w wydajności - kopiowanie pliku w Ubuntu zajęło 70% więcej czasu niż na Windows. Żeby wyeliminować wpływ oprogramowania na Windows test przeprowadzałem zarówno na standardowym Explorerze jak i Total Commanderze, na Ubuntu natomiast w standardowym Nemo i Dolphinie.

    Skoro Ubuntu zgłasza że pendrive jest spięty po USB 3.0, a jest zbyt wolny, to pomyślałem, że wina może leżeć w obsłudze NTFS przez Ubuntu. Ktoś może z resztą powiedzieć: NTFS to nie jest system plików dla Linuxa, zrób sobie normalne systemy plików.

    Sprawdziłem więc dwie kombinacje i porównałem z pierwszym testem NTFS -> NTFS. Wyniki są dla mnie mocno zastanawiające - moja hipoteza była taka, że kopiowanie będzie przebiegało najsprawniej, podczas gdy będzie przeprowadzane z partycji ext4 na pendrive sformatowany w systemie ext4. Spójrzcie więc:

    Stan faktyczny jest dokładnie odwrotny - pod Ubuntu najszybciej przebiegało kopiowanie z NTFS do NTFS, a i tak było 70% wolniejsze niż pod Windows 7. Nie jestem niestety w stanie dojść przyczyny tych - swoją drogą ogromnych - rozbieżności w wydajności. Niemniej jednak pamięci z tej serii polecam ponieważ oferują nawet więcej niż mówi specyfikacja - producent podaje że prędkość zapisu wynosi 30MB/s. Prędkości podczas zapisywania dużych plików jednak oscylują wokół 40-60MB/s, a posiadając dysk SSD można te wartości w zasadzie podwoić.

     

windows linux sprzęt

Komentarze

0 nowych
  #1 13.02.2017 21:07

To na pewno wina M$ ;-p

dragonn   11 #2 13.02.2017 21:21

Różnica w tym wynika z tego że sterownik na Linuksie działa poprzez FUSE - czyli w przestrzeni użytkownika a nie jako sterownik jądra. A dlaczego nie porównałes exFAT?

pocolog   12 #3 13.02.2017 21:23

Za mały plik - mógł się w całości zmieścić w buforze zapisu. Powyłączałeś te funkcjonalności przed testem?
Mogło być tak że Windows pokazał zakończenie kopiowania, ale później 5 minut odmontowywał pendrive opróżniając bufor zapisu.

  #4 13.02.2017 21:50

Szukasz swojej Misty? ;)

Mk13   16 #5 13.02.2017 22:20

@dragonn: dlatego sądziłem że sterownik jądra jednak będzie szybszy, a jest wręcz przeciwnie. na exFAT na windowsie czasy są takie same w porównaniu do NTFS
@pocolog: od razu po kopiowaniu można odmontować pendrive i na jednym i na drugim systemie, nie ma tak, że niby skończył się kopiować, ale plik jeszcze nie jest w całości

generalnie im większy plik tym większa padaka wydajnościowa w ubuntu

Autor edytował komentarz w dniu: 13.02.2017 22:21
pocolog   12 #6 13.02.2017 22:30

@Mk13: To dziwne, nie robiłem dokładnych pomiarów, ale u mnie nie widać takich różnic.

  #7 13.02.2017 23:09

http://www.x-kom.pl/p/205716-pendrive-pamiec-usb-kingston-64gb-hyperx-fury-usb-3...

W linku podają, że prędkość zapisu tego pendrive'a wynosi 30MB/s, więc wynik uzyskany pod Windowsem jest raczej błędny, a na Ubuntu zgadza się ze specyfikacją.

Domker   7 #8 14.02.2017 12:35

Co ciekawe szybkość kopiowania na pendrive USB często zależy od ilości RAM :P
Trzeba ustawić poprawnie tak zwane "dirty bytes" dla większej ilości RAM są ustawione domyślnie zbyt duże wartości i wyniki będą znacznie gorsze niż na komputerach z mniejszą ilością RAM. Trzeba ustawić je ręcznie :)

/proc/sys/vm/dirty_bytes
/proc/sys/vm/dirty_background_bytes

https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dir.../
https://www.kernel.org/doc/Documentation/sysctl/vm.txt

edmun   13 #9 14.02.2017 12:48

Ciekawy wpis i ciekawe komentarze. Czyżby z tego wynikało, że żeby mieć dobre czasy przenoszenia danych, to Linuxa należy tweakować bo domyślnie out-of-the-box będzie miał lepsze rezultaty na "obcym" systemie plików niż na własnym? Trochę to nielogiczne czyż nie?

grapeli23   5 #10 14.02.2017 13:21

@edmun: Czasy wyłącznie zależą od tego KTO wykonuje "benchmark".

Choć dobrze byłoby aby wykonujący ów test był świadomy:
echo 3 > /proc/sys/vm/drop_caches
konieczności wykonania sync, eject.
Dobrze jest wiedzieć z jakimi opcjami był zakładany system plików. Jakie będzie przeznaczenie tego nośnika, jakie było ratio inodów. Czy będzie tam składowanych 10 plików 4GB, czy 5 milionów 1024 bajtowych.
Z jakimi opcjami był montowowany system plików, itd.

No i lepiej czasy mierzyć dość dokładnie. Nie kopiując w Nautiliusie z budzikiem w ręku jako stoperem.

  #11 14.02.2017 13:43

Uhuhu... Linuksiarze tłumaczą słabe wyniki proponując edycje w konsoli. User friendly system :D

pocolog   12 #12 14.02.2017 13:48

@apostolisthefirst: A to konsola nie jest user friendly? Ona nie jest jedynie idiot friendly B)

grapeli23   5 #13 14.02.2017 14:24

@apostolisthefirst: Nastał taki czas. Jest generalnie "padaka wydajnościowa w ubuntu". Proponuję zainstalować go natywnie na ntfs, w kontenerze loop. Zwie się to WUBI, będzie duży skok wydajnościowy :)

Obecnie jest duże zapotrzebowanie na "niesprawdzanie" się linuksa. W Monachium już 7 raz "rozważają i planują" revert, choć teraz przesunęli termin na 2020 rok.
Wiele rzeczy się niesprawdza ostatnio. Chrome, Google Search, Android.
Niedługo nadejdzie czas premier windowsowych nowości i ta nadaktywność sztabu propagandowego nie dziwi zbytnio.

Mk13   16 #14 14.02.2017 14:44

@grapeli23: Akurat to że w ogóle piszę o linuksie jest następstwem tego że Windows się nie sprawdza ostatnio.

Pudel89   10 #15 14.02.2017 18:47

@Mk13 Testowałem zrzucanie 18GB pliku na Kubuntu, Ubuntu i Windows zarówno 7 jak i 10. Czasy? Te 70% o których autor napisał to było mało :)
Wina leży też w implementacji USB 3.0. Może i trzeba tweakować pewne opcje ale okazuje się, że sterowniki mogą być wadliwe. Mam chispet Intela, Q77, CPU i7-3770, i SSD Samsunga 850 Evo 500GB. Tu nie ma się co zaciąć a jednak dostaje pendrive świra.

Autor edytował komentarz w dniu: 14.02.2017 18:47
pocolog   12 #16 14.02.2017 19:00

@Mk13: " Niemniej jednak pamięci z tej serii polecam ponieważ oferują nawet więcej niż mówi specyfikacja - producent podaje że prędkość zapisu wynosi 30MB/s. Prędkości podczas zapisywania dużych plików jednak oscylują wokół 40-60MB/s, a posiadając dysk SSD można te wartości w zasadzie podwoić."

Usuń to zdanie bo tak jak pisałem nie wziąłeś pod uwagę wielkości buforu zapisu - nie wyłączyłeś go. Przy tak małym pliku test jest niewiarygodny. Poza tym żaden producent nie zaniży wartości swojego produktu, wszyscy zawyżają ze względów marketingowych - to kolejny dowód, że taki test można o kand d... :P

grapeli23   5 #17 14.02.2017 19:10

@Mk13: Ale żeby aż tak, że na podstawie trzech trywialnych "pomiarów" od razu wysuwać jakieś zbyt daleko idące wnioski i informować o tym cały świat.

Szczerze mówiąc nie podałeś kompletnie żadnych istotnych informacji. Całość została w sferze domysłów, przypuszczeń i zgadywanek. Mi to jedynie jeszcze przychodzi taki tip&trick.
https://wiki.archlinux.org/index.php/Improving_performance#USB_storage_devices
Sytuacji w której kernel linuksowy gorzej obsługuje sprzęt (Lenovo) od win7 wykluczyć nie mogę, ale żeby kopiowanie pod nim via ext4->ext4 było znacząco niższe od tego z ntfs jest bardzo mocno podejrzane.

Autor edytował komentarz w dniu: 14.02.2017 20:44
Mk13   16 #18 14.02.2017 23:58

@pocolog: plik 7,3GB, w Windowsie 158 sekund, czyli średnia prędkość 46MB/s. bez buforowania zapisu, tak jak we wszystkich testach. strasznie chcesz podważyć ten wynik i zarzucasz mi nierzetelność sam pisząc bzdury (nie wyłączyłeś buforowania, pendrive za szybki - z tego drugiego to już śmiechłem)

ixiński   2 #19 15.02.2017 09:39

I ja również jestem zdziwiony tak dużymi różnicami, kiedyś sam robiłem porównanie win7 i manjaro przy starszej generacji USB i wyniki były zbliżone praktycznie bez żadnej różnicy, ale skoro są aż takie to może autor pokusił by się o więcej testów? Zwłaszcza że win 7 ma swój wiek, a Ubuntu pewnie świeże?
@Domker: Skoro dystrybucje można chwalić że wszystko działa ootb to dlaczego do testów miałby cokolwiek zmieniać?
Może dla porównania linux - linux będzie ok. A potem dla pewności win7 - win 10 żeby mieć obraz sytuacji :)

PanKetchup   3 #20 15.02.2017 20:44

Lepszy ram disk do szybkosci operacji a do przenoszenia plikow usb 3.0 urzadzenie i port wystarcza praktycznie malo co zauwazam roznice

nintyfan   11 #21 16.02.2017 14:06

Może warto skorzystać z systemów plików pendrive friendly, jak BTRFS czy jakiś system Samsunga.

grapeli23   5 #22 16.02.2017 15:08

@nintyfan: Nie do końca. SSD a SD to zupełnie inne technologie zapisu. Generalnie karty SD są optymalizowane pod FAT i exFAT. NTFS, ext4 to systemy plików z journalem (księgowaniem). Oczywiście w przypadku ext4 możesz sobie go wyłączyć. Domyślny czas transakcji (commit) wynosi 5s. Albo podłączasz ten system plików z innym commit time (mount -t ext4 -o commit=120,...) albo z niego zupełnie rezygnujesz (bo nadmierne wydłużanie commit traci zupełnie sens). Księgowanie zasadniczo w niczym nie pomoże kartom ani nie zapobiegnie prezed ich "kolapsem". Jedynie zaszkodzi, bo generuje bardzo dużą ilość dodatkowych zapisów. Karty SD to po dyskietkach chyba najmniej trwały nośnik w historii (wiem, wiem są takie lepsiejsze, 10-20x droższe od zwykłego chłamu). Jeśli mamy stabilny system, jeśli mamy podtrzymywanie bateryjne, żadna nam tragedia nie grozi. Na kartach SD stosujemy najprostsze z możliwych systemy plików ext2 lub ext3,4 bez journalu i fat.

Wiele rzeczy w linuksowym systemie podlega tuningowi i ustawieniom w zależności od przeznaczenia, sposobu użytkowania i potrzeb (jeśli nie wiemy co robimy, to lepiej takich wartości nie zmieniać i nie ruszać!!!). Niezwykle istotna jest ta wartość:
cat /proc/sys/vm/dirty_expire_centisecs
i troszkę mniej ta
cat /proc/sys/vm/dirty_ratio
Na szybkość działania ext4 duży wpływ ma ilość inodów. Raz że nadmierna ich ilość w stosunku do potrzeb będzie tylko dodatkowym hamulcem, dwa te zupełnie niepotrzebne inody zabierają cenne miejsce. Ratio inodów ustala się raz przy zakładaniu systemu plików, nie można go zmienić po. Jest ustalone w /etc/mke2fs.conf lub mkfs.ext4 -T {small,big,huge,largefile...}. Zastosowanie kart SD zasadniczo nie różni się przeciętnie od "dużych" dyskietek. Trzyma się na nich stosunkowo mało plików.

Autor edytował komentarz w dniu: 16.02.2017 15:50
nintyfan   11 #23 16.02.2017 15:54

@grapeli23: Czy ja pisałem o NTFS, Fat czy Ext? Ja pisałem o BTRFS i F2FS.

grapeli23   5 #24 16.02.2017 17:07

@nintyfan: Ty pisałeś aby eksperymentować z btrfs i f2fs na SD. Odradzam. Zaproponuję im UDF (im system prostszy, a mającuy ciut więcej do zaoferowania od fat-ów tym lepiej dla sd).
Zachęcam do używania ich (f2fs, btrfs) na wszelkich innych nośnikach. Szczególnie SSD w przypadku f2fs, a btrfs na dowolnym innym (linuks jest stworzony do każdych eksperymentów).
Moje wynurzenia po za pierwszym zdaniem nie odnosiły się do twojej wypowiedzi. Nie oddzieliłem tego wyraźnie.

Ext4 no niezwykle uniwersalny system plików na każdy nośnik (SD bez journalu). Wyjątkowo stabilny. W przypadku testów Fuzzy Lop btrfs wytrzymuje 5s, f2fs - 10s a ext4 2h (to jest istna przepaść w stabilności).
http://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20f...
Wyjątkowo efektywny i szybki (mało który mu dorówna pod tym względem, biorąc poprawkę że jest pozbawiony COW).
Idealny dla mało doświadczonych użytkowników.
Z pierwszorzędnym wsparciem ze strony developerów kernela.

Autor edytował komentarz w dniu: 16.02.2017 18:41
Mk13   16 #25 16.02.2017 19:37

@nintyfan: Na nic mi pendrive, który odczyta tylko mój komputer.

  #26 16.02.2017 19:54

@Mk13: Mało i które urządzenia obsłużą Ntfs. To system plików obłożony dużą ilością zastrzeżonych do dziś patentów.
Algorytmy wear-leveling kart SD są optymalizowane wyłącznie pod FAT-y. Przeformatowanie kart czy to pod ntfs, czy też inny sytem plików może znacząco skrócić ich trwałość.

Mk13   16 #27 16.02.2017 20:12

@Anonim (niezalogowany): Chyba tylko MacBook nie obsługuje dobrze NTFS ;> nie spotkałem jeszcze urządzenia obsługującego pamięć masową USB nieobsługującego NTFS.

wojtex   10 #28 19.02.2017 17:11

Raczej znany problem. U mnie out-of-the-boxowe Kubuntu podczas kopiowania plików z/na pendrive USB 2.0 praktycznie uniemożliwiało korzystanie z systemu. Zmiana parametrów dirty_* pomogła.

~MacG   5 #29 19.02.2017 23:43

@Mk13: Przeczytałem twoje prędkości, zajrzałem na stronę producenta i już wiem że ten "test" jest wart tyle co zeszłoroczny śnieg.

  #30 20.02.2017 09:21

to jest pewien stary tweak w windows, kiedyś tego w windows nie było i wszyscy producenci płyt dawali takie dodatkowe turbo usb oprogramowanie 2010 rok

Później to się pojawiło jako standard w windzie 8
Ostatnio zainstalowałem przycięty windows 10 z winclub i tam Mr.T widać to wywalił bo wyniki spadły bardzo ba były znacznie gorsze jak na mint18 z kelnerem standard od netexa czy jak mu tam.




USB 3.0 has become the standard high-performance data transfer technology for PCs, however, there is still room for improvement! New USB 3.0 Boost is an exclusive ASUS innovation that goes beyond original USB 3.0 speeds, delivering the latest UAS Protocol (UASP) on ASUS motherboards, and giving consumers up to 170 % faster data transfer performance as well as an accelerated Turbo Mode that supports all USB devices with the traditional BOT (Bulk Only Transfer) protocol.


UASP Mode: dedicated to new UASP devices for max performance with the latest specifications.

Turbo Mode: accelerates USB BOT devices, increasing their transfer speeds.

Normal Mode: guarantees complete compatibility with all USB devices.
http://event.asus.com/mb/2010/The_Best_USB3_Experience/The_UASP_For_USB3.0.htm

Mk13   16 #31 17.04.2017 23:12

@Domker @@wojtexmacie jakieś sprawdzone wartości tych parametrów? trochę grzebałem tam i faktycznie zmniejszenie tych parametrów poprawia szybkość transferu danych między zewnętrznym nośnikiem a dyskiem (szczególnie na SSD), ale może są jakieś "cudowne" wartości które już ktoś wypróbował. mam 4GB RAM

Autor edytował komentarz w dniu: 17.04.2017 23:13
Domker   7 #32 18.04.2017 12:40

@Mk13: dla 4GB zwykle zostawiam domyślne, bo różnice nie są aż tak duże. Przy 8GB, 16GB + już warto się pofatygować o zmianę tych parametrów.
Uniwersalnych wartości raczej nie ma.
Na danym kernelu, dysku, RAM może dana wartość przynosić odmienne efekty.
Tutaj kwestia pomiarów i prób, aż wycelujesz najbardziej optymalną wartość. Zwykle 5 - 7 prób wystarczy, żeby znaleźć najlepszą wartość.
Teoretycznie im więcej "dirty bytes" tym bardziej dane są buforowane zanim zostaną faktycznie zapisane na pendrive. U mnie zbyt duże wartość powodowały, że system informował, że kopiowanie zakończone, podczas gdy dalej ono trwało, bo dane z bufora nie zdążyły się zapisać.

Bierzesz skrajnie większą wartość dirty_bytes /dirty_background:
echo wartość | tee /proc/sys/vm/dirty_bytes
echo wartość | tee /proc/sys/vm/dirty_background_bytes
//opróżniasz pagecache dentries i inodes
echo 3 > /proc/sys/vm/drop_caches
//wgrywasz plik testowy na pendrive, flaga fdatasync spowoduje, że zostanie //zmierzony czas fizycznego zapisu na nośniku
time dd if=/dev/zero of=/ścieżka_do_pendrive/test.file bs=1M count=1000 conv=fdatasync

To samo robisz dla skrajnie małej, średniej i pomiędzy skrajnie małą i średnią, pomiędzy średnią i skrajnie dużą.
W sumie masz 5 pomiarów, każdy zapisuje plik wielkości 1GB.
Wybierasz wartości, które dają najlepszy czas zapisu.
Możesz też w internecie wyszukać informacje na temat dobrych wartości, ale u mnie się one nie sprawdziły.
Tutaj masz też bardzo fajnie opisane, co w trawie piszczy:
https://dug.net.pl/tekst/282/ram__cache_i_dirty_pages/

Tutaj info o danych parametrach:
https://www.kernel.org/doc/Documentation/sysctl/vm.txt

Autor edytował komentarz w dniu: 18.04.2017 12:47

Gratulacje!

znalezione maszynki:

Twój czas:

Ogól Naczelnego!
Znalazłeś(aś) 10 maszynek Wilkinson Sword
oraz ogoliłaś naszego naczelnego!
Przejdź do rankingu
Podpowiedź: Przyciśnij lewy przycisk myszki i poruszaj nią, aby ogolić brodę.