когда client_bandwidth > server_bandwidth вообще никак не должна тестироваться? ;)
Вы, наверное, хотели написать clientthrottlespeed > server_bandwidth? :)
В любом случае, что вы ожидаете увидеть при этом?
то еще и не такие фокусы могут происходить.
Мне кажется, что вы меня уже поняли. Я говорил исключительно об исходной постановке задачи, т.е. о юнит-тестировании реализации тротлинга в каком-то вашем HTTP-клиенте…
Предлагаю экзотические фокусы, нагрузочное тестирование и т.д. оставить за рамками обсуждения. Да и обсуждение, КМК, уже выродилось. Предлагаю на этом и закончить.
Потому, что единственным необходимым условием для корректной реализации является условие client_throttle_speed < server_bandwidth.
И это мы еще не рассматриваем случаи, когда тротлинг на клиенте может на длительном интервале времени давать 80KiB/sec, но это будет за счет того, что 10 секунд он будет вообще ничего не читать, а потом за секунду выкачает 880KiB.
Зачем рассматривать заведомо абсурдную постановку?
Bandwidth принято мерять в *bps, вот и корректный тротлинг должен давать плавный график с разрешением близким к секунде, а не измеряться за "неделю".
min(128,80), min(256,256), min(512,1024) разумеется, дадут 80, 256, 512.
Только вот 2 последних случая никакого отношения к тротлингу на клиенте иметь не будут.
Я не против того, что вы сделали и описали. Самому приходилось добавлять тротлинг для передачи и получения данных. Вполне понятная и востребованная "фича".
Я "придираюсь" исключительно к формулировке исходной задачи, что мол, для тестирования реализации тротлинга в клиенте вам понадобился сервер с аналогичной функциональностью. Для меня же очевидно, что для тестов, т.е. min(client_speed, server_speed) достаточно, чтобы client_speed < server_speed.
Условно, если server_speed==inf, то всё Ok ;) Отсюда и вывод, что то, что вы сделали может быть и полезно где-то ещё, но в рамках поставленной задачи бесполезно.
Мне затруднительно ответить на этот вопрос, не зная вашего тестового окружения.
Но, очевидно, можно было бы использовать тот же сервер, в который вы добавили тротлинг, который можно было бы не добавлять.
Мониторинг скорости клиента как раз таки есть.
Прекрасно, этим можно было б и ограничиться, не трогая сервер.
Да к чему угодно, что способно выдать больше, чем вам нужно в тесте.
А далее достаточно снять скорость с соединений вашего клиента.
Я понимаю, что может существовать требование поддержки тротлинга к серверу.
Но в рамках поставленной задачи такая поддержка на сервере не нужна.
Нужен мониторинг в том или ином виде.
Мне потребовался HTTP-сервер, который бы отдавал трафик с какой-то заданной скоростью, например, 512KiB/sec. Тогда бы я мог видеть, действительно ли приложение выдерживает скорость 200KiB/sec или же оно срывается на более высокие скорости.
Хм, а если ваше приложение "сорвется" до 400KBps, значит ли это, что тест пройден или провален?
Я к тому, что если вам нужна имплементация тротлинга в клиенте, то зачем тут еще и сервер с тротлингом. КМК достаточно мониторинга соединений клиента, чтобы оценить качество реализации тротлинга в нем.
Ясно. У меня есть дома 1 счетчик на M-Bus, который стоит в очень неудобном месте.
И есть идея-фикс:) Хочу с него данные передавать по воздуху. И если с последним проблем нет, то вот физически считать с M-Bus — временный затык.
Из готового "дешевого" нашел только https://ru.aliexpress.com/item/USB-MBUS-M-BUS-10/32854222405.html
Но мне USB на выходе избыточен, а вот обычный UART на 3-5V для микроконтроллера — нет таких готовых конвертеров :(
Ладно бы, если бы эти функции содержали какое-то know how или реализацию чего-то хоть немного сложного, а не банальное сохранение состояния FPU в согласованном для ядра состоянии. А так это огораживание и просто мелкая палка в колеса.
Они б ещё запретили стороннему коду работать на более чем одном ядре CPU для полного "счастья".
При этом одним из аргументов было "мы не хотим себе дополнительных трудозатрат для не GPL кода". Ага, вот эти 8 символов "лишних" — огромные затраты :)
У меня рабочий комп на "древнем" Intel Z77 с AMI BIOS.
Чтобы загружаться с Samsung 960 PRO пришлось добавить в BIOS NVMe драйвер (есть тулзы, делающие сей процесс тривиальным), а сам M2 девайс поставить в переходник и воткнуть в PCIe. Возможно, такой же трюк применим и к вашей м.п.
По моей логике выходит, что в статье для поддержки TRIM в Linux предложена безальтернативно только ext4. Это и только это утверждение я оспариваю в своем исходном посте.
Заниматься софистикой с вами нет ни малейшего желания.
Поддержкой TRIM занимается не файловая система, а ОС
От них обеих зависит, т.е. от ОС и драйверов ФС.
Какая файловая система используется — абсолютно фиолетово.
Если вы под ФС подразумеваете только структурированные данные на носителе, а драйвера ФС считаете частью ОС, то с такой оговоркой я готов согласиться. Но зачастую под ФС понимают совокупность, включая драйвера.
Вы, наверное, хотели написать clientthrottlespeed > server_bandwidth? :)
В любом случае, что вы ожидаете увидеть при этом?
Мне кажется, что вы меня уже поняли. Я говорил исключительно об исходной постановке задачи, т.е. о юнит-тестировании реализации тротлинга в каком-то вашем HTTP-клиенте…
Предлагаю экзотические фокусы, нагрузочное тестирование и т.д. оставить за рамками обсуждения. Да и обсуждение, КМК, уже выродилось. Предлагаю на этом и закончить.
Потому, что единственным необходимым условием для корректной реализации является условие client_throttle_speed < server_bandwidth.
Зачем рассматривать заведомо абсурдную постановку?
Bandwidth принято мерять в *bps, вот и корректный тротлинг должен давать плавный график с разрешением близким к секунде, а не измеряться за "неделю".
min(128,80), min(256,256), min(512,1024) разумеется, дадут 80, 256, 512.
Только вот 2 последних случая никакого отношения к тротлингу на клиенте иметь не будут.
Я не против того, что вы сделали и описали. Самому приходилось добавлять тротлинг для передачи и получения данных. Вполне понятная и востребованная "фича".
Я "придираюсь" исключительно к формулировке исходной задачи, что мол, для тестирования реализации тротлинга в клиенте вам понадобился сервер с аналогичной функциональностью. Для меня же очевидно, что для тестов, т.е. min(client_speed, server_speed) достаточно, чтобы client_speed < server_speed.
Условно, если server_speed==inf, то всё Ok ;) Отсюда и вывод, что то, что вы сделали может быть и полезно где-то ещё, но в рамках поставленной задачи бесполезно.
Мне затруднительно ответить на этот вопрос, не зная вашего тестового окружения.
Но, очевидно, можно было бы использовать тот же сервер, в который вы добавили тротлинг, который можно было бы не добавлять.
Прекрасно, этим можно было б и ограничиться, не трогая сервер.
Немного промазал с ответом:( См. https://habr.com/ru/post/462349/#comment_20473777
Да к чему угодно, что способно выдать больше, чем вам нужно в тесте.
А далее достаточно снять скорость с соединений вашего клиента.
Я понимаю, что может существовать требование поддержки тротлинга к серверу.
Но в рамках поставленной задачи такая поддержка на сервере не нужна.
Нужен мониторинг в том или ином виде.
Хм, а если ваше приложение "сорвется" до 400KBps, значит ли это, что тест пройден или провален?
Я к тому, что если вам нужна имплементация тротлинга в клиенте, то зачем тут еще и сервер с тротлингом. КМК достаточно мониторинга соединений клиента, чтобы оценить качество реализации тротлинга в нем.
Посмотрел на поддержку S3 в Moto.
Очень сыро.
SHARKY 774 — мне такой вот попался. Но хоть без радио, а с проводным M-Bus.
Хм, еще недавно ничего не находил, а вот только что глянул, что-то похожее на то, что мне надо нарисовалось: https://ru.aliexpress.com/item/100pcs-lot-Free-shipping-SMD-resettable-fuse-SMD1210P100TF-30-1210-1A-1000MA-30V/32806628015.html
Только большинство мало-мальски хороших счетчиков тепла, как назло, используют именно его.
Ясно. У меня есть дома 1 счетчик на M-Bus, который стоит в очень неудобном месте.
И есть идея-фикс:) Хочу с него данные передавать по воздуху. И если с последним проблем нет, то вот физически считать с M-Bus — временный затык.
Из готового "дешевого" нашел только https://ru.aliexpress.com/item/USB-MBUS-M-BUS-10/32854222405.html
Но мне USB на выходе избыточен, а вот обычный UART на 3-5V для микроконтроллера — нет таких готовых конвертеров :(
Что-то типа этого?
https://github.com/rscada/libmbus/blob/master/hardware/MBus_USB.pdf
Или совсем оригинальное? Ваши наработки не open source?
Смотрел на готовые решения, но ценник!
Мне для хобби, но я, увы, совсем не электронщик :(
Это ещё мягко сказано. Вот такое вот — это просто мелкое вредительство.
Ладно бы, если бы эти функции содержали какое-то know how или реализацию чего-то хоть немного сложного, а не банальное сохранение состояния FPU в согласованном для ядра состоянии. А так это огораживание и просто мелкая палка в колеса.
Они б ещё запретили стороннему коду работать на более чем одном ядре CPU для полного "счастья".
При этом одним из аргументов было "мы не хотим себе дополнительных трудозатрат для не GPL кода". Ага, вот эти 8 символов "лишних" — огромные затраты :)
А почему про M-Bus ни слова?
забыл
В Linux с {любимым|нелюбимым} systemd есть готовый юнит для офлайнового TRIM.
Достаточно выполнить
и будет делаться раз в неделю (по умолчанию).
Если хочется, например, ежедневно, то
и закопипастить что-то типа:
У меня рабочий комп на "древнем" Intel Z77 с AMI BIOS.
Чтобы загружаться с Samsung 960 PRO пришлось добавить в BIOS NVMe драйвер (есть тулзы, делающие сей процесс тривиальным), а сам M2 девайс поставить в переходник и воткнуть в PCIe. Возможно, такой же трюк применим и к вашей м.п.
По моей логике выходит, что в статье для поддержки TRIM в Linux предложена безальтернативно только ext4. Это и только это утверждение я оспариваю в своем исходном посте.
Заниматься софистикой с вами нет ни малейшего желания.
От них обеих зависит, т.е. от ОС и драйверов ФС.
Если вы под ФС подразумеваете только структурированные данные на носителе, а драйвера ФС считаете частью ОС, то с такой оговоркой я готов согласиться. Но зачастую под ФС понимают совокупность, включая драйвера.