Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Na necie znalazłem ciekawy parametr dotyczący zewnętrznych nośników usb. Chodzi o [b]/sys/block/sdb/device/max_sectors[/b] . Domyślnie ma on 240. W sumie to nie wiedziałem czy to dużo czy mało więc postanowiłem sprawdzić wartości 60, 240, 2048 i 32678 . Po ustawieniu ich, przy pomocy dd zapisałem sobie plik 1G na tym przykładowym pendrive przy pomocy tego poniższego polecenia:
$ time sh -c "dd if=/dev/zero of=/media/morfik/sdb1-usb-Kingston_DT_101_/01 bs=1M count=1024 && sync"
Poniżej zaś są czas i transfer jaki udało się osiągnąć, odpowiednio dla 60, 240, 2048 i 32678:
5.1 MB/s 0.00s user 2.51s system 1% cpu 3:32.19 total 8.4 MB/s 0.00s user 2.38s system 1% cpu 2:11.17 total 10.2 MB/s 0.00s user 2.49s system 2% cpu 1:48.32 total 9.6 MB/s 0.00s user 2.34s system 2% cpu 1:54.42 total
Przy tych 2048 sektorach zapis jest około 10M/s. Standardowo ten pendrive ma około 8M, tak jak to widać w drugiej linijce. Zatem wzrost wydajności o 25%? xD Wyższe wartości nie ma już zbytnio znaczenia, przynajmniej w przypadku tego pendrive.
Moglibyście przeprowadzić u siebie podobny experyment i oszacować % wzrostu wydajności o ile w ogóle będzie coś na plus?
Offline
Próbuj go montować z opcją sync, wtedy zapis jest dosyć równy i chyba chodzi szybciej.
Jednak w przypadku udisk2 będziesz musiał go montować przez udeva.
Tu masz przykład:
https://forum.dug.net.pl/viewtopic.php?pid=293671#p293671
Z resztą chyba znasz lepsiejsze :D
Ostatnio edytowany przez Jacekalex (2015-12-02 17:54:23)
Offline
60 - skopiowane 1073741824 bajty (1,1 GB), 282,772 s, 3,8 MB/s 240 - skopiowane 1073741824 bajty (1,1 GB), 141,762 s, 7,6 MB/s 2048 - skopiowane 1073741824 bajty (1,1 GB), 123,551 s, 8,7 MB/s 4096 - skopiowane 1073741824 bajty (1,1 GB), 122,304 s, 8,8 MB/s 8192 - skopiowane 1073741824 bajty (1,1 GB), 121,969 s, 8,8 MB/s 16384 - skopiowane 1073741824 bajty (1,1 GB), 122,112 s, 8,8 MB/s 32678 - skopiowane 1073741824 bajty (1,1 GB), 122,277 s, 8,8 MB/s 240 - skopiowane 1073741824 bajty (1,1 GB), 134,26 s, 8,0 MB/s 240 - skopiowane 1073741824 bajty (1,1 GB), 136,244 s, 7,9 MB/s
Na końcu dwa razy powtórzyłem przy 240 - jak widać pędrak (właściwie - karta w czytniku) się nieco rozgrzał...
Jak widać nie ma tu mowy o spektakularnych 25% (+/- "nędzne" 10%).
Offline
Odpowiednio dla 60, 240, 2048 i 32678.
logan@toshiba:/mnt/1$ time sh -c "dd if=/dev/zero of=./01 bs=1M count=1024 && sync" 1024+0 przeczytanych recordów 1024+0 zapisanych recordów skopiowane 1073741824 bajty (1,1 GB), 7,22978 s, 149 MB/s real 1m39.998s user 0m0.000s sys 0m1.256s logan@toshiba:/mnt/1$ time sh -c "dd if=/dev/zero of=./02 bs=1M count=1024 && sync" 1024+0 przeczytanych recordów 1024+0 zapisanych recordów skopiowane 1073741824 bajty (1,1 GB), 18,4323 s, 58,3 MB/s real 1m42.057s user 0m0.000s sys 0m1.296s logan@toshiba:/mnt/1$ time sh -c "dd if=/dev/zero of=./03 bs=1M count=1024 && sync" 1024+0 przeczytanych recordów 1024+0 zapisanych recordów skopiowane 1073741824 bajty (1,1 GB), 23,3442 s, 46,0 MB/s real 1m42.317s user 0m0.000s sys 0m1.312s logan@toshiba:/mnt/1$ time sh -c "dd if=/dev/zero of=./04 bs=1M count=1024 && sync" 1024+0 przeczytanych recordów 1024+0 zapisanych recordów skopiowane 1073741824 bajty (1,1 GB), 24,6953 s, 43,5 MB/s real 1m41.023s user 0m0.008s sys 0m1.292s
Offline
Jak widać nie ma tu mowy o spektakularnych 25% (+/- "nędzne" 10%).[/quote]
Tak doczytałem sobie i to generalnie zależeć ma od konkretnego urządzenia. Także % nie zawsze będzie taki sam ale powinno być lepiej.
@Jacekalex, u mnie opcja sync = kompletna degradacja transferu, który zwykle wynosi parę KiB/s xD Z reguły transfer jest mniej więcej taki jaki widać, tj. po zakończeniu kopiowania, sync praktycznie przechodzi od razu i dioda na penie przestaje migać.
@Pavlo950, raczej na odwrót powinno być chyba? xD Poza tym, skoro masz usb3, to czy tam domyślnie była wartość 240 czy coś więcej?
Offline
@Jacekalex, u mnie opcja sync = kompletna degradacja transferu, który zwykle wynosi parę KiB/s xD Z reguły transfer jest mniej więcej taki jaki widać, tj. po zakończeniu kopiowania, sync praktycznie przechodzi od razu i dioda na penie przestaje migać.[/quote]
U mnie na sync chodzi normalnie, bez sync transfer wygląda, jak żeby piły, zaczyna szybko, a potem zjeżdża do niemal zera.
PS
Pendrak - stary Kingston.
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
No to sobie skonfiguruj dirty pages, żeby system nie buforował w pamięci wszystkich danych kopiowanych na pena.
# sysctl -a | grep dirty vm.dirty_background_bytes = 0 vm.dirty_background_ratio = 3 vm.dirty_bytes = 0 vm.dirty_expire_centisecs = 400 vm.dirty_ratio = 5 vm.dirty_writeback_centisecs = 1000 vm.dirtytime_expire_seconds = 43200
W skrócie przeznacza 3% ramu dla pojedynczego procesu (5% dla wszystkich) pod te dirty pages. Po 4s te strony pamięci są oznaczane jako stare i w interwale 10s zapisywane na nośnik, chyba, że szybciej napływają do pamięci i przekroczą limit, wtedy z automatu zostaną zapisane. Nie mam pojęcia co to jest vm.dirtytime_expire_second, na necie nic nie ma na jego temat xD Trzeba tylko pamiętać, że im bardziej się przytnie te wartości tym gorszy transfer będzie przy zapisie.
Ostatnio edytowany przez morfik (2015-12-02 19:31:03)
Offline
Nie będę się tu rozpisywał, odsyłam jedynie do konstrukcji typu "multibit per cell" i zwracam uwagę że to nie jest SLC.
Może wyjść rozbieżność nawet 50% zgodnie z notami katalogowymi części układów. Następnie popatrz w jakich porcjach wysyłasz dane z dd. Rozrzut powodowany na warstwie sprzętu potęguje rozjechanie buforów i ich wielkości. Oraz sposób pracy samych programów od strony kodu maszynowego w takich wyjątkach.
Chyba o tym że w łańcuchu jest jeszcze chipset i kontroler nie muszę wspominać i tutaj też jest kolejkowanie, a drugi posiada dodatkowo swój bufor.
Offline
[quote=morfik]@Pavlo950, raczej na odwrót powinno być chyba? xD Poza tym, skoro masz usb3, to czy tam domyślnie była wartość 240 czy coś więcej?[/quote]
No jak na odwrót? Jest 240, ale u mnie jest coś skopane, że chce kopiować zbyt szybko. Poza tym. Dla mnie różnicy wielkiej nie ma - przynajmniej u mnie. Co Ty masz narobione u siebie, to nie wiem. Nie znam się, ale widzę że to już jest druga sytuacja, że u mnie przed i po jest tak samo, a u Ciebie niby coś się poprawia. Może to wina systemd? XD
Ostatnio edytowany przez Pavlo950 (2015-12-02 20:19:40)
Offline
W sumie fakt, zasugerowałem się tym transferem z dd. xD Powinniście sobie skonfigurować te dirty pages. Wtedy nie będzie takiej sytuacji gdzie system kończy kopiować, a i tak jeszcze dane się zapisują na nośnik przez parę minut. xD
U mnie jest poprawa i to widać wyraźnie przy zmianie wartości. To nie tylko jeden przypadek. Generalnie ja to sobie testowałem tak by wyeliminować jakąś przypadkowość ale zawsze przy zmianie z tej domyślnej na większą dostaje 2M/s gratis. xD Wątpię by to było za sprawą systemd, może taki pendrive albo coś innego.
@qluk, to jak ten test miałby wyglądać by dać miarodajne wyniki?
Ostatnio edytowany przez morfik (2015-12-02 20:49:45)
Offline
2421
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:28:14)
Offline
Z tego wykresu wychodzi, że zależność jest i im większa wartość tym szybciej, przynajmniej do określonego momentu, także nie jestem odosobnionym przypadkiem. Teraz pytanie jaka jest optymalna wartość i czy da się ją jakoś wyliczyć bez strzelania na ślepo. xD W [url=http://www.linux-usb.org/FAQ.html]FAQ o USB[/url] piszą, że ta wartość ma być wielokrotnością 8 lub 16, odpowiednio dla 32bit i 64bit systemów. Więc, te 60 to trochę nietrafione. xD Pisza, też że nie ma górnego limitu ani nie ma co jechać więcej niż 2048.
Czym zrobić taki grafik?
Offline
2422
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:28:15)
Offline
Time (s) | Query |
---|---|
0.00012 | SET CHARSET latin2 |
0.00004 | SET NAMES latin2 |
0.00095 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.142.131.51' WHERE u.id=1 |
0.00086 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.142.131.51', 1732866498) |
0.00048 | SELECT * FROM punbb_online WHERE logged<1732866198 |
0.00082 | DELETE FROM punbb_online WHERE ident='198.235.24.56' |
0.00250 | SELECT topic_id FROM punbb_posts WHERE id=293897 |
0.00497 | SELECT id FROM punbb_posts WHERE topic_id=27958 ORDER BY posted |
0.00033 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=27958 AND t.moved_to IS NULL |
0.00087 | SELECT search_for, replace_with FROM punbb_censoring |
0.00060 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=27958 ORDER BY p.id LIMIT 0,25 |
0.00476 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=27958 |
Total query time: 0.0173 s |