Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Сб ноя 18, 2017 5:53 am

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 282 сообщения ]  На страницу Пред. 115 16 17 18 19 След.
Автор Сообщение
 Заголовок сообщения: Re: NTFS
СообщениеДобавлено: Пн янв 09, 2017 12:25 am 
Не в сети

Зарегистрирован: Вс окт 30, 2011 6:43 pm
Сообщения: 1080
Pathoswithin писал(а):
Если сделать работу с файлами в отдельном потоке, не будет зависать.
Будет. Отдельный поток будет зависать. Если я во fNav увеличу размер буфера, то также будет зависать. Поэтому кусочки небольшие, чтобы пользователь не запаниковал :)

Pathoswithin писал(а):
Ну ты ж на флешку копируешь. И то есть разница...
Во-первых, разница небольшая. Во-вторых, это всё ценой зависания KFM. Пользователь может подумать "зависло".
Так ты проверил идентичность скопированного файла? Ты похоже копируешь на тот же самый диск, в справке TC для таких случаев рекомендуют 10240 k. А я копирую на другой диск.


Вернуться к началу
 Заголовок сообщения: Re: NTFS
СообщениеДобавлено: Пн янв 09, 2017 1:26 am 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

Зарегистрирован: Чт мар 26, 2015 5:16 pm
Сообщения: 1194
Может лучше сделать, чтобы пользователь не заматерился от того, как медленно ползёт шкала? Проверь скорость копирования на жёстком диске под виндой. Можно менять размер операции в зависимости от типа устройства. Я тебе дал ссылку, где описана проблема механических вертелок с блинами, со старым драйвером они всегда вот так ползали, а теперь с одной операцией на 400 МБ справляются за 5 секунд.


Вернуться к началу
 Заголовок сообщения: Re: NTFS
СообщениеДобавлено: Вт янв 10, 2017 4:22 pm 
Не в сети

Зарегистрирован: Вс окт 30, 2011 6:43 pm
Сообщения: 1080
Pathoswithin писал(а):
с одной операцией на 400 МБ справляются за 5 секунд
Не 5 секунд, а примерно 1 минута. И не 400 Mb, а, как видно на скриншоте, 241 Mb viewtopic.php?f=31&t=659&start=225#p68027

Если говорить про viewtopic.php?f=31&t=659&start=225#p68028
то получается, что для KFM потребовалось 256 Mb(четверть ОЗУ), в то время как для fNav только 256 Kb. При этом KFM справился менее чем на 15% быстрее, запросив для этого в 1024(!!!) раз больше памяти. Также, KFM зависал на время копирования.

Pathoswithin писал(а):
Проверь скорость копирования на жёстком диске под виндой.
Сделал некоторые замеры ради интереса.
Копировался тот же самый файл 1,36 ГБ (1 465 528 320 байт), находящийся на HD FAT32.
При копировании на USB флешку NTFS через explorer это заняло примерно 3,5 минуты.
При копировании через TotalCommander на USB флешку NTFS в режиме "use big file copy mode" буфер 64 K — чуть более 4 минут.
При копировании с помощью fNav из-под KlbrInWin на тот же самый диск(но на другой раздел NTFS ) — примерно 1,5 минуты.
При копировании с помощью KFM из-под KlbrInWin на тот же самый диск(но на другой раздел NTFS ) — 01:20.

Лично для меня это мало что прояснило. Попробую ещё разные варианты размера буфера во fNav на реальной системе. Возможно, будет смысл увеличить его в пределах 2..8 Mb(я в то же время не хочу, чтобы пользователь замечал подвисание во время копирования).

Pathoswithin писал(а):
Если сделать работу с файлами в отдельном потоке, не будет зависать.
А вот если добавить не один, а два дополнительных потока, то, возможно, смысл есть. Один поток непосредственно копирует и сам он вполне может подвисать(это не будет заметно, он окна не имеет), второй поток имеет окно и отображает прогресс, его окно всегда будет реагировать на действия пользователя. Общаться они также могут с помощью IPC. Просто нужно больше потоков.


Вернуться к началу
 Заголовок сообщения: Re: NTFS
СообщениеДобавлено: Вт янв 10, 2017 5:49 pm 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

Зарегистрирован: Чт мар 26, 2015 5:16 pm
Сообщения: 1194
Ну что тебе не понятно? Диск крутится и продолжает крутится после окончания операции. Когда работа с непрерывными данными прерывается, нужно ждать почти полный оборот диска, чтоб вернутся к нужному месту и продолжить. Скорость в итоге зависит от того, насколько существенны эти задержки по сравнению с операциями. Прошивка диска бывает достаточно умной, чтобы избежать этих задержек, но оптимальный размер операции - 16 МБ.
С ФС всё ещё хуже: каждое увеличение файла это куча мелких операций в разных местах диска, тут надо ещё и головками двигать. Умный виндовый кэш способен это компенсировать почти полностью, а у нас чем больше размер операций, тем меньше лишних (а ещё, ниже вероятность фрагментации файла).

А оперативная память для того и есть, чтоб её использовать.


Вернуться к началу
 Заголовок сообщения: Re: NTFS
СообщениеДобавлено: Ср янв 11, 2017 1:34 am 
Не в сети

Зарегистрирован: Вс окт 30, 2011 6:43 pm
Сообщения: 1080
Pathoswithin писал(а):
А оперативная память для того и есть, чтоб её использовать.
Использовать надо рационально. Если не видно разницы, то зачем тратить больше? А то получается копеечная выгода в быстродействии в обмен на более чем 1000-кратные затраты памяти.

Я в прошлый раз ошибся
0CodErr писал(а):
для KFM потребовалось 256 Mb(четверть ОЗУ), в то время как для fNav только 256 Kb. При этом KFM справился менее чем на 15% быстрее, запросив для этого в 1024(!!!) раз больше памяти.
На самом деле четверть ОЗУ это 512 Mb. Следовательно, KFM запросил не в 1024, а в целых 2048 раз больше памяти.

Я решил сделать некоторые замеры в зависимости от размера буфера.
Создал для этого несколько версий fNav: fNav(128Mb).kex, fNav(16Mb).kex, fNav(1Gb).kex, fNav(1Mb).kex, fNav(256Kb).kex, fNav(256Mb).kex, fNav(2Mb).kex, fNav(32Mb).kex, fNav(4Mb).kex, fNav(512Mb).kex, fNav(64Mb).kex, fNav(8Mb).kex
Копировался файл размером 1,36 ГБ (1 465 528 320 байт) с HD FAT32 на USB NTFS.
Размер RAM = 2 Gb.
К сожалению, при размере буфера 1 Gb удалось скопировать только 1,00 ГБ (1 073 741 824 байт).
Малозаметные зависания появляются уже при размере буфера 1 Mb.
Получилась такая табличка:
Спойлер: Показать
Вложение:
0.png
0.png [ 11 КБ | 632 просмотра ]


Вернуться к началу
 Заголовок сообщения: Re: NTFS
СообщениеДобавлено: Ср янв 11, 2017 2:25 am 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

Зарегистрирован: Чт мар 26, 2015 5:16 pm
Сообщения: 1194
Вот зачем ты копируешь на флешку? Мы и так знаем, что они медленно работают. Тестируй жёсткий диск. Можешь читать на рамдиск, писать с рамдиска, а самые яркие результаты будут при копировании в пределах диска.


Вернуться к началу
 Заголовок сообщения: Re: NTFS
СообщениеДобавлено: Ср янв 11, 2017 2:41 am 
Не в сети

Зарегистрирован: Вс окт 30, 2011 6:43 pm
Сообщения: 1080
Pathoswithin писал(а):
Вот зачем ты копируешь на флешку?
Чтобы раздел не запороть. А то мало ли... Но вообще хорошо было бы, если кто-то сравнил бы скорость копирования HD -> HD при различных размерах буфера.
Pathoswithin писал(а):
Мы и так знаем, что они медленно работают.
А зачем ты скорость сравниваешь? Ты соотношение сравнивай.

Яркий результат пока вот
0CodErr писал(а):
К сожалению, при размере буфера 1 Gb удалось скопировать только 1,00 ГБ (1 073 741 824 байт).
Но неизвестно, это ошибка записи на NTFS или ошибка чтения с FAT32(64Kb кластер). По идее EOF должен при чтении приходить. Но вон там viewtopic.php?f=31&t=659&start=225#p68015 было копирование NTFS -> NTFS, и тоже скопировалось меньше.

Одно ясно — даже после стольких лет разработки в KolibriOS с дисковой подсистемой ещё очень много проблем. И для серьёзных вещей она не годится.


Вернуться к началу
 Заголовок сообщения: Re: NTFS
СообщениеДобавлено: Ср янв 11, 2017 6:09 am 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

Зарегистрирован: Чт мар 26, 2015 5:16 pm
Сообщения: 1194
Ну у меня как-то Netsurf читал папку с FAT32 и умудрился превратить её в фарш. Уж не знаю, как такое получилось, но shit happens даже при чтении. А скорость копирования я уже сравнил - разница в несколько раз, что не удивительно. Можешь чтение на рамдиск проверить, там тоже какая-то разница будет. А у флешек разница совсем скромная - они ж не механические.

Если EOF, значит при чтении.

Спасибо, Кэп. В течении всех этих лет её разрабатывало не более одного человека за раз.


Вернуться к началу
 Заголовок сообщения: Re: NTFS
СообщениеДобавлено: Ср янв 11, 2017 3:29 pm 
Не в сети

Зарегистрирован: Вс окт 30, 2011 6:43 pm
Сообщения: 1080
Pathoswithin писал(а):
Ну у меня как-то Netsurf читал папку с FAT32 и умудрился превратить её в фарш.
Ну если только папку, то, подумал я, рискну тогда. Но, к сожалению, "Not supported for this file system". Папка не сжатая, не шифрованная. Chkdsk ошибок не нашёл. Просто что-то не поддерживается.

Похоже придётся отложить это до лучших времён. Предлагаю попробовать пофиксить EXT. Может хотя бы там заработает.

Pathoswithin писал(а):
А скорость копирования я уже сравнил - разница в несколько раз, что не удивительно. Можешь чтение на рамдиск проверить, там тоже какая-то разница будет.
На рамдиске же FAT, а хотелось проверить запись NTFS. И для рамдиска тоже нужно память выделять, тогда для буфера копирования останется мало(всего RAM 2 Gb). C FAT32 на FAT32 тоже проблема, там у меня размер кластера 64 Kb, а это сейчас в KolibriOS глючит.
И, кстати, вон там viewtopic.php?f=31&t=659&p=68039#p68032 из-под KlbrInWin разница не в разы, а точно так же примерно 15%.

Может есть ещё желающие протестировать?

И всё-таки не понятно, какой лучше размер буфера для копирования? Ведь уже при 1 Mb начинаются еле заметные подвисания(а дальше больше). Думаю, что увеличить его во fNav с 256 Kb всё равно надо. Может пока для тестирования несколько версий выложить стоит?


Вернуться к началу
 Заголовок сообщения: Re: NTFS
СообщениеДобавлено: Ср янв 11, 2017 6:26 pm 
Не в сети

Зарегистрирован: Вт апр 12, 2011 11:19 pm
Сообщения: 1077
Тестить надо только на реальном железе? И какие конкретно условия теста?

_________________
я лишь учусь


Вернуться к началу
 Заголовок сообщения: Re: NTFS
СообщениеДобавлено: Пт янв 13, 2017 3:06 pm 
Не в сети

Зарегистрирован: Вс окт 30, 2011 6:43 pm
Сообщения: 1080
Pathoswithin писал(а):
Ну у меня как-то Netsurf читал папку с FAT32 и умудрился превратить её в фарш. Уж не знаю, как такое получилось, но shit happens даже при чтении.
А там, наверное, происходит ещё установка LastAccessDate, то есть, запись тоже присутствует при чтении.
Цитата:
Но, к сожалению, "Not supported for this file system".
Даже не создаётся файл. Это скорее всего из-за ограничения 32000(если не ошибаюсь). У меня на разделе файлов явно гораздо больше. С чем связано ограничение, кстати?

punk_joker писал(а):
Тестить надо только на реальном железе?
Ну по идее да. Я вот хотел запись NTFS проверить, но кроме как на флешку никакой другой возможности у меня нет.


Вернуться к началу
 Заголовок сообщения: Re: NTFS
СообщениеДобавлено: Пт янв 13, 2017 8:05 pm 
Не в сети

Зарегистрирован: Вт апр 12, 2011 11:19 pm
Сообщения: 1077
Готов потестить на реальном железе. Если надо, могу и fNav с разными буферами протестить.

_________________
я лишь учусь


Вернуться к началу
 Заголовок сообщения: Re: NTFS
СообщениеДобавлено: Сб янв 14, 2017 4:19 pm 
Не в сети

Зарегистрирован: Вс окт 30, 2011 6:43 pm
Сообщения: 1080
Для увеличения полноты картины вон того viewtopic.php?f=31&t=659&p=68039#p68032
Цитата:
При копировании с помощью fNav из-под KlbrInWin на тот же самый диск(но на другой раздел NTFS ) — примерно 1,5 минуты.
При копировании с помощью KFM из-под KlbrInWin на тот же самый диск(но на другой раздел NTFS ) — 01:20.
решил проверить также в TotalCommander на тот же самый диск в режиме "use big file copy mode" буфер 10240 Kb. Результат — 01:07. И никаких "в разы" тут и близко нет.

Pathoswithin писал(а):
теперь с одной операцией на 400 МБ справляются за 5 секунд.
То есть, это получается 80 Mb\s.

Я потому и спросил
0CodErr писал(а):
Pathoswithin, а у тебя может там AHCI?
Или ещё что-то...

У меня ATA100. Вон там http://www.realworldtech.com/ata100/ пишут
Цитата:
The main thing to remember is that the ATA/100 (100MB/s) speed ONLY applies to buffer to host transfers. That is, when the operating system can’t find the data needed in its own cache, and it is not in the controller’s cache, but doesn’t need to be retrieved from the actual disk itself (the platters). A small amount of data is cached in the disk’s buffer, and that is the ONLY data that will be transferred at ATA/100 speed. Any data retrieved from the actual platters cannot be done so at that high rate of speed – period. The chances that the system will be able to find what it needs in the disk buffer (unless your request are very small and fits the cache scheme) are slim to none, mostly due to its small size. So, your limiting factor is the actual data transfer from the platters to the buffer – which is well under the ATA/100 speed, under ATA/66 speeds, and not much better than ATA/33.

А на второй странице есть таблица http://www.realworldtech.com/ata100/2/ и результаты там не так уж сильно отличаются от виндовых.
Вот перевод статьи http://stolica.ru/techinfo/article/2001_02/07_01.htm


Вернуться к началу
 Заголовок сообщения: Re: NTFS
СообщениеДобавлено: Сб янв 14, 2017 6:09 pm 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

Зарегистрирован: Чт мар 26, 2015 5:16 pm
Сообщения: 1194
У меня там SATA в режиме IDE, но скорость диска определяется его размером, а там аж 160 ГБ.

punk_joker
Надо сравнить fNav с KFM (или Eolite) на реальном диске - время копирования крупного файла, файловые системы любые (хотя запись на FAT может работать медленней), дополнительно можно проверить скорость работы с рамдиском.


Вернуться к началу
 Заголовок сообщения: Re: NTFS
СообщениеДобавлено: Сб янв 21, 2017 2:32 am 
Не в сети

Зарегистрирован: Вт апр 12, 2011 11:19 pm
Сообщения: 1077
926 mb файл, копировался на FAT32 раздел SSD диска (как оказалось, только на нем был подходящий раздел, позже проверю все таки и на жестком) с HDD в режиме AHCI (в режиме bios-диски)
KFM 0:39 мин
fNav 2:50 мин

_________________
я лишь учусь


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 282 сообщения ]  На страницу Пред. 115 16 17 18 19 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB