Так я ж про деградацию скорости _чтения_, а не записи. On Thu, 18 Jan 2024 17:32:48 +0200 Alexander V Soroka wrote:

Привет !

- Где у него ошибка? - в генетике ! :-)

Для ответа на этот вопрос надо точно знать что за чипы памяти там стоят, и понимать как это железо на самом деле работает на низком уровне. :-) но сразу скажу - разнообразия мало, Самсунг и еще 1-2 производителя Флеш-памяти.

Так вот - современные флешки новые это 3D NAND технология (загуглите сами подробности) которая имеет число перезаписей всего около 1000 (одна тысяча) раз. Ну и переписывается поблочно, т.е. не ячейка памяти а весь блок. Чтобы все не сдохло сразу при работе от исчерпания ресурса, разные производители Чипов ставят разные контроллеры, которые играют в рулетку (или считают) куда надо сейчас писать, чтобы израсходовалось ресурча перезаписи каждого блока примерно по ровну.

Так вот, ты сейчас нарвался на то что "с завода" там все пусто было - потому что тесты идут самих микросхем, а после впаивания в Диск идет только функциональный тест. Ты же забил ПОЛНОСТЬЮ! весь диск сейчас, т.е. произведя записи(!) во все области памяти. Тем самым ты запустил механизм "мы начинаем считать ресурсы которые перезаписывались".

Так вот - верные значения (похожие на правду) это именно повторного теста - потому что он уже работает с перезаписью блоков и ПОИСКОМ (решением задачи поиска) новых мест для размещения данных.

Чем круче производитель Чипов (и Диска) тем сложнее и лучше(?) алгоритм поиска свободного места.

Такие вот дела...

Thursday, January 18, 2024, 12:11:52 PM, Max Tulyev maxtul@netassist.kiev.ua you wrote: MT> Доброго дня! MT> Вибачте, що питання не срача та політики, а суто технічне ;) MT> Є ряд NVMe дисків від різних виробників: Kingston, WD, якійсь MT> кітайській нонейм - взагалі всі що попадались під руку.

MT> Ставлю новенький, запускаю тест швидкості, наприклад от:

MT> hdparm -tT /dev/nvme0n1

MT> /dev/nvme0n1: MT> Timing cached reads: 27230 MB in 2.00 seconds = 13634.89 MB/sec MT> Timing buffered disk reads: 9282 MB in 3.00 seconds = 3093.66 MB/sec

MT> hdparm -tT --direct /dev/nvme0n1

MT> /dev/nvme0n1: MT> Timing O_DIRECT cached reads: 5988 MB in 2.00 seconds = 2994.86 MB/sec MT> Timing O_DIRECT disk reads: 9122 MB in 3.00 seconds = 3040.66 MB/sec

MT> Далі забиваю його випадковими числами весь (так треба):

MT> dd if=/dev/urandom of=/dev/nvme0n1 bs=1M status=progress MT> 999874887680 bytes (1.0 TB, 931 GiB) copied, 2908 s, 344 MB/s MT> dd: error writing '/dev/nvme0n1': No space left on device MT> 953870+0 records in MT> 953869+0 records out MT> 1000204886016 bytes (1.0 TB, 932 GiB) copied, 2913.95 s, 343 MB/s

MT> Потім повторюю тест:

MT> hdparm -tT /dev/nvme0n1

MT> /dev/nvme0n1: MT> Timing cached reads: 25740 MB in 2.00 seconds = 12887.79 MB/sec MT> Timing buffered disk reads: 7478 MB in 3.00 seconds = 2492.60 MB/sec

MT> hdparm -tT --direct /dev/nvme0n1

MT> /dev/nvme0n1: MT> Timing O_DIRECT cached reads: 5474 MB in 2.00 seconds = 2737.25 MB/sec MT> Timing O_DIRECT disk reads: 7700 MB in 3.00 seconds = 2566.25 MB/sec

MT> - і маю деградацію швидкості читання на рівному місці!

MT> На різних дисках вона різна, але помітна та навіть велика. MT> Найбільша була на диску WD 2Tb, з ~3000 Mbit/s до всього-навсього 190! MT> Перезавантаження системи, вимкнення системи з живлення не MT> допомагає: швидкість залишається низькою.

MT> Що це може бути та як з цим боротись? MT> _______________________________________________ MT> uanog mailing list MT> uanog@uanog.kiev.ua MT> https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Best regards, Alexander V Soroka http://www.svr.ua/ AS106-RIPE mailto:alex@euro.net.ua

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

Привет! То есть ты хочешь сказать, что "чтение" заведомо пустых секторов и реальное чтение данных с диска - обрабатывается по-разному? Ну... это уже на на@бку похоже очень... On Thu, 18 Jan 2024 18:35:20 +0200 Alexander V Soroka wrote:

Привет !

перед чтением ты записал - вот уже рандом там. Так что и при чтении будет отличаться - бо контроллер достает данные из разных мест с разной скоростью + у тебя еще кеширование самой файловой системы навреняка не отключается.

Thursday, January 18, 2024, 6:23:55 PM, Max Tulyev maxtul@netassist.kiev.ua you wrote: MT> Так я ж про деградацию скорости _чтения_, а не записи.

MT> On Thu, 18 Jan 2024 17:32:48 +0200 MT> Alexander V Soroka wrote:

...

...

Привет !

- Где у него ошибка? - в генетике ! :-)

Для ответа на этот вопрос надо точно знать что за чипы памяти там стоят, и понимать как это железо на самом деле работает на низком уровне. :-) но сразу скажу - разнообразия мало, Самсунг и еще 1-2 производителя Флеш-памяти.

Так вот - современные флешки новые это 3D NAND технология (загуглите сами подробности) которая имеет число перезаписей всего около 1000 (одна тысяча) раз. Ну и переписывается поблочно, т.е. не ячейка памяти а весь блок. Чтобы все не сдохло сразу при работе от исчерпания ресурса, разные производители Чипов ставят разные контроллеры, которые играют в рулетку (или считают) куда надо сейчас писать, чтобы израсходовалось ресурча перезаписи каждого блока примерно по ровну.

Так вот, ты сейчас нарвался на то что "с завода" там все пусто было - потому что тесты идут самих микросхем, а после впаивания в Диск идет только функциональный тест. Ты же забил ПОЛНОСТЬЮ! весь диск сейчас, т.е. произведя записи(!) во все области памяти. Тем самым ты запустил механизм "мы начинаем считать ресурсы которые перезаписывались".

Так вот - верные значения (похожие на правду) это именно повторного теста - потому что он уже работает с перезаписью блоков и ПОИСКОМ (решением задачи поиска) новых мест для размещения данных.

Чем круче производитель Чипов (и Диска) тем сложнее и лучше(?) алгоритм поиска свободного места.

Такие вот дела...

Thursday, January 18, 2024, 12:11:52 PM, Max Tulyev maxtul@netassist.kiev.ua you wrote: MT> Доброго дня! MT> Вибачте, що питання не срача та політики, а суто технічне ;) MT> Є ряд NVMe дисків від різних виробників: Kingston, WD, якійсь MT> кітайській нонейм - взагалі всі що попадались під руку.

MT> Ставлю новенький, запускаю тест швидкості, наприклад от:

MT> hdparm -tT /dev/nvme0n1

MT> /dev/nvme0n1: MT> Timing cached reads: 27230 MB in 2.00 seconds = 13634.89 MB/sec MT> Timing buffered disk reads: 9282 MB in 3.00 seconds = 3093.66 MB/sec

MT> hdparm -tT --direct /dev/nvme0n1

MT> /dev/nvme0n1: MT> Timing O_DIRECT cached reads: 5988 MB in 2.00 seconds = 2994.86 MB/sec MT> Timing O_DIRECT disk reads: 9122 MB in 3.00 seconds = 3040.66 MB/sec

MT> Далі забиваю його випадковими числами весь (так треба):

MT> dd if=/dev/urandom of=/dev/nvme0n1 bs=1M status=progress MT> 999874887680 bytes (1.0 TB, 931 GiB) copied, 2908 s, 344 MB/s MT> dd: error writing '/dev/nvme0n1': No space left on device MT> 953870+0 records in MT> 953869+0 records out MT> 1000204886016 bytes (1.0 TB, 932 GiB) copied, 2913.95 s, 343 MB/s

MT> Потім повторюю тест:

MT> hdparm -tT /dev/nvme0n1

MT> /dev/nvme0n1: MT> Timing cached reads: 25740 MB in 2.00 seconds = 12887.79 MB/sec MT> Timing buffered disk reads: 7478 MB in 3.00 seconds = 2492.60 MB/sec

MT> hdparm -tT --direct /dev/nvme0n1

MT> /dev/nvme0n1: MT> Timing O_DIRECT cached reads: 5474 MB in 2.00 seconds = 2737.25 MB/sec MT> Timing O_DIRECT disk reads: 7700 MB in 3.00 seconds = 2566.25 MB/sec

MT> - і маю деградацію швидкості читання на рівному місці!

MT> На різних дисках вона різна, але помітна та навіть велика. MT> Найбільша була на диску WD 2Tb, з ~3000 Mbit/s до всього-навсього 190! MT> Перезавантаження системи, вимкнення системи з живлення не MT> допомагає: швидкість залишається низькою.

MT> Що це може бути та як з цим боротись? MT> _______________________________________________ MT> uanog mailing list MT> uanog@uanog.kiev.ua MT> https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Best regards, Alexander V Soroka http://www.svr.ua/ AS106-RIPE mailto:alex@euro.net.ua

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Best regards, Alexander V Soroka http://www.svr.ua/ AS106-RIPE mailto:alex@euro.net.ua

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

Thu, Jan 18, 2024 at 23:57:21, maxtul wrote about "Re: [uanog] NVME strange": Странно, что я не вижу исходное письмо Сороки. А.В., вы его точно отправляли в рассылку?

То есть ты хочешь сказать, что "чтение" заведомо пустых секторов и реальное чтение данных с диска - обрабатывается по-разному? Ну... это уже на на@бку похоже очень...

Это принцип работы SSD в условиях, когда требуется запись группами, которые сильно больше размера представленного хозяину блока. Ведётся учёт реально существующих (замапленных) блоков, и если запросили чтение несуществующих (незамапленных) на сейчас, то зачем искусственно тормозить? Читать с реального флэша всё равно нельзя, ибо неоткуда. Вообще удивительно, что ты только сейчас узнаёшь это. Первым SSD, wear levelling, механизму TRIM уже твёрдо исполнилось 15 лет, а в самых ранних, полуэкспериментальных изделиях уже все 20.

...

...

...

Так вот - современные флешки новые это 3D NAND технология (загуглите сами подробности) которая имеет число перезаписей всего около 1000 (одна тысяча) раз.

В лучших таки до 10000. Но это надо хорошего изготовителя.

...

...

...

Ты же забил ПОЛНОСТЬЮ! весь диск сейчас, т.е. произведя записи(!) во все области памяти.

Кстати, что это вообще получилось, заслуга последовательной записи и кэширования в контроллере диска. При записи в случайном порядке по достижению >90% объёма диска скорость бы чудовищно упала. (Не до нуля, обычно есть резерв, кроме самых дешманских моделей. Но заметно.) PS: Прошу таки срезать всякие сигнатуры в конце. Нефиг их раздавать в столько копий. -netch-

Fri, Jan 19, 2024 at 13:25:07, alex wrote about "Re: [uanog] NVME strange":

да, именно в рассылку отправлял. 18 января, в 17 с чем-то времени.

Да, уже увидел, когда перезапустил. Там DNS как-то непонятно клинил. Вообще рассылка будет переезжать на более "собственный" сервер, по частям, так что будет анонс и несколько тестовых писем. -netch- _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

То все трім і лайно контролери :) evo plus 970 1tb hdparm -tT --direct /dev/nvme1n1; hdparm -tT --direct /dev/nvme1n1; hdparm -tT --direct /dev/nvme1n1 /dev/nvme1n1: Timing O_DIRECT cached reads: 4990 MB in 2.00 seconds = 2499.15 MB/sec Timing O_DIRECT disk reads: 7628 MB in 3.00 seconds = 2542.21 MB/sec /dev/nvme1n1: Timing O_DIRECT cached reads: 4988 MB in 2.00 seconds = 2497.78 MB/sec Timing O_DIRECT disk reads: 7620 MB in 3.00 seconds = 2539.63 MB/sec /dev/nvme1n1: Timing O_DIRECT cached reads: 5014 MB in 2.00 seconds = 2510.47 MB/sec Timing O_DIRECT disk reads: 7658 MB in 3.00 seconds = 2552.29 MB/sec пт, 19 січ. 2024 р. о 10:23 Max Tulyev пише:

Привет!

То есть ты хочешь сказать, что "чтение" заведомо пустых секторов и реальное чтение данных с диска - обрабатывается по-разному? Ну... это уже на на@бку похоже очень...

On Thu, 18 Jan 2024 18:35:20 +0200 Alexander V Soroka wrote:

...

Привет !

перед чтением ты записал - вот уже рандом там. Так что и при чтении будет отличаться - бо контроллер достает данные из разных мест с разной скоростью + у тебя еще кеширование самой файловой системы навреняка не отключается.

Thursday, January 18, 2024, 6:23:55 PM, Max Tulyev maxtul@netassist.kiev.ua you wrote: MT> Так я ж про деградацию скорости _чтения_, а не записи.

MT> On Thu, 18 Jan 2024 17:32:48 +0200 MT> Alexander V Soroka wrote:

...

...

Привет !

- Где у него ошибка? - в генетике ! :-)

Для ответа на этот вопрос надо точно знать что за чипы памяти там стоят, и понимать как это железо на самом деле работает на низком уровне. :-) но сразу скажу - разнообразия мало, Самсунг и еще 1-2 производителя Флеш-памяти.

Так вот - современные флешки новые это 3D NAND технология (загуглите сами подробности) которая имеет число перезаписей всего около 1000 (одна тысяча) раз. Ну и переписывается поблочно, т.е. не ячейка памяти а весь блок. Чтобы все не сдохло сразу при работе от исчерпания ресурса, разные производители Чипов ставят разные контроллеры, которые играют в рулетку (или считают) куда надо сейчас писать, чтобы израсходовалось ресурча перезаписи каждого блока примерно по ровну.

Так вот, ты сейчас нарвался на то что "с завода" там все пусто было - потому что тесты идут самих микросхем, а после впаивания в Диск идет только функциональный тест. Ты же забил ПОЛНОСТЬЮ! весь диск сейчас, т.е. произведя записи(!) во все области памяти. Тем самым ты запустил механизм "мы начинаем считать ресурсы которые перезаписывались".

Так вот - верные значения (похожие на правду) это именно повторного теста - потому что он уже работает с перезаписью блоков и ПОИСКОМ (решением задачи поиска) новых мест для размещения данных.

Чем круче производитель Чипов (и Диска) тем сложнее и лучше(?) алгоритм поиска свободного места.

Такие вот дела...

Thursday, January 18, 2024, 12:11:52 PM, Max Tulyev maxtul@netassist.kiev.ua you wrote: MT> Доброго дня! MT> Вибачте, що питання не срача та політики, а суто технічне ;) MT> Є ряд NVMe дисків від різних виробників: Kingston, WD, якійсь MT> кітайській нонейм - взагалі всі що попадались під руку.

MT> Ставлю новенький, запускаю тест швидкості, наприклад от:

MT> hdparm -tT /dev/nvme0n1

MT> /dev/nvme0n1: MT> Timing cached reads: 27230 MB in 2.00 seconds = 13634.89 MB/sec MT> Timing buffered disk reads: 9282 MB in 3.00 seconds = 3093.66 MB/sec

MT> hdparm -tT --direct /dev/nvme0n1

MT> /dev/nvme0n1: MT> Timing O_DIRECT cached reads: 5988 MB in 2.00 seconds = 2994.86 MB/sec MT> Timing O_DIRECT disk reads: 9122 MB in 3.00 seconds = 3040.66 MB/sec

MT> Далі забиваю його випадковими числами весь (так треба):

MT> dd if=/dev/urandom of=/dev/nvme0n1 bs=1M status=progress MT> 999874887680 bytes (1.0 TB, 931 GiB) copied, 2908 s, 344 MB/s MT> dd: error writing '/dev/nvme0n1': No space left on device MT> 953870+0 records in MT> 953869+0 records out MT> 1000204886016 bytes (1.0 TB, 932 GiB) copied, 2913.95 s, 343 MB/s

MT> Потім повторюю тест:

MT> hdparm -tT /dev/nvme0n1

MT> /dev/nvme0n1: MT> Timing cached reads: 25740 MB in 2.00 seconds = 12887.79 MB/sec MT> Timing buffered disk reads: 7478 MB in 3.00 seconds = 2492.60 MB/sec

MT> hdparm -tT --direct /dev/nvme0n1

MT> /dev/nvme0n1: MT> Timing O_DIRECT cached reads: 5474 MB in 2.00 seconds = 2737.25 MB/sec MT> Timing O_DIRECT disk reads: 7700 MB in 3.00 seconds = 2566.25 MB/sec

MT> - і маю деградацію швидкості читання на рівному місці!

MT> На різних дисках вона різна, але помітна та навіть велика. MT> Найбільша була на диску WD 2Tb, з ~3000 Mbit/s до всього-навсього 190! MT> Перезавантаження системи, вимкнення системи з живлення не MT> допомагає: швидкість залишається низькою.

MT> Що це може бути та як з цим боротись? MT> _______________________________________________ MT> uanog mailing list MT> uanog@uanog.kiev.ua MT> https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Best regards, Alexander V Soroka http://www.svr.ua/ AS106-RIPE mailto:alex@euro.net.ua

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Best regards, Alexander V Soroka http://www.svr.ua/ AS106-RIPE mailto:alex@euro.net.ua

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

---

uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

hi, Thu, Jan 18, 2024 at 11:11:52, maxtul wrote about "[uanog] NVME strange":

/dev/nvme0n1: Timing O_DIRECT cached reads: 5474 MB in 2.00 seconds = 2737.25 MB/sec Timing O_DIRECT disk reads: 7700 MB in 3.00 seconds = 2566.25 MB/sec

- і маю деградацію швидкості читання на рівному місці!

На різних дисках вона різна, але помітна та навіть велика. Найбільша була на диску WD 2Tb, з ~3000 Mbit/s до всього-навсього 190! Перезавантаження системи, вимкнення системи з живлення не допомагає: швидкість залишається низькою.

Здається, це і є реальна швидкість. А те, що ти бачиш інакше - результат роботи кеша на диску (не плутати з кешом ОС, який вимикається твоїм --direct). SSD (неважливо який інтерфейс) не можуть обійтись без цього кеша просто тому, що запис іде порціями від 128KB до 1MB, залежно від моделі. Але саме щоб ти бачив великі цифри і створюється кеш на сотню мегабайт:) (насправді ні, щоб ефективно обробляти 100500 паралельних операцій і групувати їх). -netch- _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

Привет ! да, TRIM может немного помочь в данной ситуации. Thursday, January 18, 2024, 5:24:05 PM, Mykola Ulianytskyi lystor@gmail.com you wrote: MU> Доброго дня

...

Що це може бути як з цим боротись? MU> https://en.wikipedia.org/wiki/Trim_(computing)

MU> -- MU> Best regards, MU> Mykola MU> On Thu, Jan 18, 2024 at 2:43 PM Max Tulyev MU> wrote:

...

Доброго дня!

Вибачте, що питання не срача та політики, а суто технічне ;)

Є ряд NVMe дисків від різних виробників: Kingston, WD, якійсь кітайській нонейм - взагалі всі що попадались під руку.

Ставлю новенький, запускаю тест швидкості, наприклад от:

hdparm -tT /dev/nvme0n1

/dev/nvme0n1: Timing cached reads: 27230 MB in 2.00 seconds = 13634.89 MB/sec Timing buffered disk reads: 9282 MB in 3.00 seconds = 3093.66 MB/sec

hdparm -tT --direct /dev/nvme0n1

/dev/nvme0n1: Timing O_DIRECT cached reads: 5988 MB in 2.00 seconds = 2994.86 MB/sec Timing O_DIRECT disk reads: 9122 MB in 3.00 seconds = 3040.66 MB/sec

Далі забиваю його випадковими числами весь (так треба):

dd if=/dev/urandom of=/dev/nvme0n1 bs=1M status=progress 999874887680 bytes (1.0 TB, 931 GiB) copied, 2908 s, 344 MB/s dd: error writing '/dev/nvme0n1': No space left on device 953870+0 records in 953869+0 records out 1000204886016 bytes (1.0 TB, 932 GiB) copied, 2913.95 s, 343 MB/s

Потім повторюю тест:

hdparm -tT /dev/nvme0n1

/dev/nvme0n1: Timing cached reads: 25740 MB in 2.00 seconds = 12887.79 MB/sec Timing buffered disk reads: 7478 MB in 3.00 seconds = 2492.60 MB/sec

hdparm -tT --direct /dev/nvme0n1

/dev/nvme0n1: Timing O_DIRECT cached reads: 5474 MB in 2.00 seconds = 2737.25 MB/sec Timing O_DIRECT disk reads: 7700 MB in 3.00 seconds = 2566.25 MB/sec

- і маю деградацію швидкості читання на рівному місці!

На різних дисках вона різна, але помітна та навіть велика. Найбільша була на диску WD 2Tb, з ~3000 Mbit/s до всього-навсього 190! Перезавантаження системи, вимкнення системи з живлення не допомагає: швидкість залишається низькою.

Що це може бути та як з цим боротись? _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

MU> _______________________________________________ MU> uanog mailing list MU> uanog@uanog.kiev.ua MU> https://mailman.uanog.kiev.ua/mailman/listinfo/uanog -- Best regards, Alexander V Soroka http://www.svr.ua/ AS106-RIPE mailto:alex@euro.net.ua _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog