В тесте, моделирующем резервное копирование данных, зафиксирована скорость передачи 40 Гбит/с. Это новый отраслевой рекорд.
И в чём новизна? Какой-то рекорд не сильно впечатляющий. Например вот тут (2016 г.) всё на реально и относительно давно доступном железе скорости в разы выше:
Скажите пожалуйста, позволяет ли API плагинов интегрировать в OutWiker содержимое существующих документов в другом формате или с другой структурой? В первую очередь меня интересует дерево с данными от ScrapBook.
И позволяет ли API плагинов добавлять различные синтаксисы языка представления, например, DokuWiki или упоминавшийся reStructured?
В Linux посмотрите ветку /sys/class/dmi/id/
Но наиболее надежный product_uuid обычно -r--------. 1 root root 4096 Oct 9 13:31 /sys/class/dmi/id/product_uuid
Но имейте в виду, что хоть обычный пользователь и не будет этим заниматься, но подделать все эти ID не сильно сложно: изменив оригинальный образ BIOS и прошить его.
Серийник диска получить тоже реально. Для обычных SATA легче всего, но вот со всякими SAS, NVMe, хитрыми RAID контроллерами уже "геморройнее"...
Неужели кто то пользуется розеткой Ethernet в гостинице, когда есть Wi-Fi?
Да. Всегда вожу с собой патчкорд даже в отпуск. Другое дело, что в >90% имеющаяся в номере розетка, по-видимому, даже физически не подключается с той стороны...
Часто, видя подобные надписи, было интересно, что сподвигло автора на написание. Но авторы всегда анонимны.
Но еще более удивительно, как некоторым удается заметить слово среди окружающего "хаоса" :)
NoiseSocket больше концепция, а не законченный протокол.
Ну, для нас больше был актуален Noise в чистом виде, т.к. у нас всё сильно C++&boost::asio зависимо. Т.е. внутри приложения нечто своё, похожее на NoiceSocket, работающее к тому же через несколько параллельных TCP-коннектов...
Разумеется :) Мы сейчас TLS используем. На скоростях существенно выше 10Gbps. И тут каждое копирование память-память (что есть и в Вашем примере) стоит дорого. Хотелось бы избегать этого. Я рассматривал Noise как-то, как альтернативу TLS, но вот то ограничение и не понравилось.
Понятно, что в "80%" случаев 65К будет достаточно, но вот нам тесты дают несколько другое оптимальное значение размера мессаджа в нашем приложении — 2М. Было бы неплохо, если б в протокол добавили бы, например, в тот же хэндшейк, scale поля длины мессаджа. Меня б такой "костыль" устроил бы более чем ;-)
То, что в хэндшейк можно добавить прикладную информацию — это хорошо.
Но как это повлияет на жестко заданную в спеке длину мессаджей Noise? Как его парсер узнает, что мы хотим иметь длину более 65К?
Я понимаю, что можно внутрь Noise инкапсулировать свой прикладной протокол и резать его на любые мессаджи по-своему. Но хотелось бы как раз обойтись, т.е. сделать так, чтобы мессадж своего протокола целиком помещался внутрь мессаджа Noise.
это на самом деле легко делается, можно о размере пакета договориться во время хэндшейка
Не совсем понял, что Вы имеете в виду под "это". Изменить спеку? Изменить какую-то стороннюю (или свою) опенсорсную реализацию протокола? Или что-то уже предусмотрено на уровне хэндшейка о чем Вы вскользь упомянули и что я, по-видимому, упустил?
UPD: Хм, ничего в скриптах не менял. Но на машине с Fedora 26, где последние cmake и ninja, всё вдруг само заработало.
Ninja действительно дает выигрыш, но не сильно большой. ~20 секунд на ~4 минутах сборки всего проекта. Но у нас там CPU — узкое место (шаблонов много...).
Я только немного экспериментировал с iSCSI, поэтому о производительности такого use-case не могу глубоко рассуждать.
Но, в общем, производительность сильно зависит от конфигурации vdev.
Например, принято считать, что для ZRAID* — это производительность самого медленного в массиве HDD.
Страйп зеркал будет быстрее.
И еще скорость сильно проседает, если много операций синхронной записи. Тут либо ZIL, либо sync=disabled (если приемлемо) помогут.
Так же от параметра volsize и паттерна IO приложения зависит…
В общем, вооружившись fio и его конфигурацией, похожей на паттерн Вашего приложения, можно тюнить...
И в чём новизна? Какой-то рекорд не сильно впечатляющий. Например вот тут (2016 г.) всё на реально и относительно давно доступном железе скорости в разы выше:
Вообще при передаче данных бОльшим ограничителем не сети выступают, а, скорее, носители данных.
s/DokuWiki/MediaWiki/
Скажите пожалуйста, позволяет ли API плагинов интегрировать в OutWiker содержимое существующих документов в другом формате или с другой структурой? В первую очередь меня интересует дерево с данными от ScrapBook.
И позволяет ли API плагинов добавлять различные синтаксисы языка представления, например, DokuWiki или упоминавшийся reStructured?
Теперь Дуров может подать на Вас в суд за клевету о "враль", а Дуров — за "любитель" :)
В Linux посмотрите ветку /sys/class/dmi/id/
Но наиболее надежный product_uuid обычно
-r--------. 1 root root 4096 Oct 9 13:31 /sys/class/dmi/id/product_uuidНо имейте в виду, что хоть обычный пользователь и не будет этим заниматься, но подделать все эти ID не сильно сложно: изменив оригинальный образ BIOS и прошить его.
Серийник диска получить тоже реально. Для обычных SATA легче всего, но вот со всякими SAS, NVMe, хитрыми RAID контроллерами уже "геморройнее"...
Да. Всегда вожу с собой патчкорд даже в отпуск. Другое дело, что в >90% имеющаяся в номере розетка, по-видимому, даже физически не подключается с той стороны...
Часто, видя подобные надписи, было интересно, что сподвигло автора на написание. Но авторы всегда анонимны.
Но еще более удивительно, как некоторым удается заметить слово среди окружающего "хаоса" :)
Как же он своеобразно расставлял точки над i!
В буквальном смысле.
s/брать/быть/
Я понимаю, что жанр такой данной статьи — эпатаж с холиворностью. Но с КДПВ стоит брать аккуратнее. Многие новости за завтраком любят читать...
Ну, для нас больше был актуален Noise в чистом виде, т.к. у нас всё сильно C++&boost::asio зависимо. Т.е. внутри приложения нечто своё, похожее на NoiceSocket, работающее к тому же через несколько параллельных TCP-коннектов...
Угу, там есть много ещё другой боли.
Спасибо. Как только опять вернемся к вопросу замены-ускорения TLS у нас...
Разумеется :) Мы сейчас TLS используем. На скоростях существенно выше 10Gbps. И тут каждое копирование память-память (что есть и в Вашем примере) стоит дорого. Хотелось бы избегать этого. Я рассматривал Noise как-то, как альтернативу TLS, но вот то ограничение и не понравилось.
Понятно, что в "80%" случаев 65К будет достаточно, но вот нам тесты дают несколько другое оптимальное значение размера мессаджа в нашем приложении — 2М. Было бы неплохо, если б в протокол добавили бы, например, в тот же хэндшейк, scale поля длины мессаджа. Меня б такой "костыль" устроил бы более чем ;-)
То, что в хэндшейк можно добавить прикладную информацию — это хорошо.
Но как это повлияет на жестко заданную в спеке длину мессаджей Noise? Как его парсер узнает, что мы хотим иметь длину более 65К?
Я понимаю, что можно внутрь Noise инкапсулировать свой прикладной протокол и резать его на любые мессаджи по-своему. Но хотелось бы как раз обойтись, т.е. сделать так, чтобы мессадж своего протокола целиком помещался внутрь мессаджа Noise.
Не совсем понял, что Вы имеете в виду под "это". Изменить спеку? Изменить какую-то стороннюю (или свою) опенсорсную реализацию протокола? Или что-то уже предусмотрено на уровне хэндшейка о чем Вы вскользь упомянули и что я, по-видимому, упустил?
В целом, Noise приятный протокол. Но, увы, есть некоторые ограничения. Например:
Я понимаю доводы авторов. Но, тем не менее, для некоторых условий это ограничение слишком жестко. До неприемлемости.
Ничего удивительного. Поэтому мы — инженеры-программисты, вы — инженеры-{механики|стоители|...}.
Ну, для вас ни Fortran, ни C никто не отменял.
UPD: Хм, ничего в скриптах не менял. Но на машине с Fedora 26, где последние cmake и ninja, всё вдруг само заработало.
Ninja действительно дает выигрыш, но не сильно большой. ~20 секунд на ~4 минутах сборки всего проекта. Но у нас там CPU — узкое место (шаблонов много...).
Я только немного экспериментировал с iSCSI, поэтому о производительности такого use-case не могу глубоко рассуждать.
Но, в общем, производительность сильно зависит от конфигурации vdev.
Например, принято считать, что для ZRAID* — это производительность самого медленного в массиве HDD.
Страйп зеркал будет быстрее.
И еще скорость сильно проседает, если много операций синхронной записи. Тут либо ZIL, либо sync=disabled (если приемлемо) помогут.
Так же от параметра volsize и паттерна IO приложения зависит…
В общем, вооружившись fio и его конфигурацией, похожей на паттерн Вашего приложения, можно тюнить...