Нет, сам ротор, точнее «рёбра». Трещины от места, где железный стержень входит в пластик и до металлического кольца внутри ротора. Сам он не разваливается от этого, но нарушается центровка и при вращении появляется сильное биение.
Если в таком состоянии его крутить, то ещё и канавки на сфере «волнами» покрываются. От этого ещё сильнее бить начинает и так по нарастающей.
Отличная штука. Первое время ушибы на костяшках со стороны ладони образуются, а потом ничего, привыкаешь. Главное не переусерствовать, а то придётся пару дней перерыв делать — пока уровень боли терпимым станет :)
ЗЫЖ сломал свой Neon за две недели — отзывы не врут. Хочу попробовать поменять на 250Hz
Ну ручка на столе всегда есть.
Очень хорошо думается, когда просто сидишь и «в фоне» крутишь. Я ещё в школе подсел, теперь уже не могу ничего в руках не вертеть :)
Конечно на результат сравнения это никак не повлияет. Быстрые останутся быстрыми, а медленные медленными. Но всё же когда написано «Как видно из тестов скорость записи упала почти в 2 раза» без учёта генерации /dev/random падение окажется намного больше чем в 2 раза. Просто думаю важнее именно падение относительно максимальной скорости харда. А судя по
151.82 real .00 user 132.96 sys
в оценке скорости линейной записи на нешифрованный носитель она (скорость) упёрлась именно в процессор, а никак не в хард
> Если есть сомнения, то могу сделать тесты на /dev/zero и выложить. особой разницы вы не увидите.
Да нет что вы, сомнений в относительных результатах нет никаких. Тем более что дальше идут тесты bonnie
> dd if=/dev/random
не лучший вариант для оценки скорости именно _шифрования_ — генерация рандома сама по себе довольно затратная операция.
На расположение контейнеров по скорости это конечно не влияет, а вот на величины вроде «Как видно из тестов скорость записи упала почти в 2 раза» — очень даже.
Впрочем, возможно вы это сделали умышленно и мой каммент не в тему, но для меня «скорость записи» это скорость самой записи, без учёта скорости генерации данных.
Лучше купить BBK, который читает дофига форматов и не обращает внимание на DRM, чем взять «бренд» и потом мучаться с (не)поддерживаемыми форматами и снятием всевозможных защит, да ещё и за цену, в несколько раз дороже.
Это юыло бы полезно, если бы все без исключения каптчи использовали перечёркнутый ноль. Иначе понять будет ли '0' перечёркнутым в каждой конкретной реализации можно будет только увидев '0' в каптче, а он там может и не встретиться.
Ну не стоит всё-таки смешивать английское написание и наше. Если я правильно понял ГОСТ 8.417-2002 (Таблица А.1), то там вообще не вводится сокращения для «бит».
Всё может быть, но я ны нашем ТВ не вижу ни одного конкурента 2х2. Т.е если я перестану смотреть 2х2, то я вообще перестану смотреть ТВ, ну разве что «культуру» иногда, ибо это самый адекватный канал из всех что есть
Если в таком состоянии его крутить, то ещё и канавки на сфере «волнами» покрываются. От этого ещё сильнее бить начинает и так по нарастающей.
ЗЫЖ сломал свой Neon за две недели — отзывы не врут. Хочу попробовать поменять на 250Hz
Очень хорошо думается, когда просто сидишь и «в фоне» крутишь. Я ещё в школе подсел, теперь уже не могу ничего в руках не вертеть :)
151.82 real .00 user 132.96 sys
в оценке скорости линейной записи на нешифрованный носитель она (скорость) упёрлась именно в процессор, а никак не в хард
> Если есть сомнения, то могу сделать тесты на /dev/zero и выложить. особой разницы вы не увидите.
Да нет что вы, сомнений в относительных результатах нет никаких. Тем более что дальше идут тесты bonnie
не лучший вариант для оценки скорости именно _шифрования_ — генерация рандома сама по себе довольно затратная операция.
На расположение контейнеров по скорости это конечно не влияет, а вот на величины вроде «Как видно из тестов скорость записи упала почти в 2 раза» — очень даже.
Впрочем, возможно вы это сделали умышленно и мой каммент не в тему, но для меня «скорость записи» это скорость самой записи, без учёта скорости генерации данных.
Но вообще проц при достаточно быстром скролле хавается на 100%