информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Где водятся OGRыSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Ядро Linux избавляется от российских... 
 20 лет Ubuntu 
 Tailscale окончательно забанила... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / hardware
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Для меня гибернация это не скорость загрузки системы, а... 21.02.13 21:03  Число просмотров: 4610
Автор: kstati <Евгений Борисов> Статус: Elderman
Отредактировано 22.02.13 02:04  Количество правок: 3
<"чистая" ссылка>
> Простое восстановление этих 32 гигабайт будет по скорости
> сопоставимо с честной нулевой загрузкой системы.
>
> У меня на системном 128 свободно около 40 гигабайт, но
> часть помоек все-таки унес на второй диск где через
> настройки, где через directory junction. А на ssd оставлено
> то, что часто запускается и редко меняется.
Для меня гибернация это не скорость загрузки системы, а скорость восстановления рабочего пространства. Если пользуюсь — то всегда открыта прерванная работа — потыкал CTRL+S по открытым программам, увёл в спячку. Вернулся к компьютеру — после загрузки всё на прежних местах.
В том числе и из-за необходимости менять стиль прерывания работы задумывался над применимостью SSD ко мне в данное время.
Можно, конечно, перестраиваться. Да и не часто использую гибернацию, но всё ж — хочу, что бы после апгрейда работа была лучше, а не искать компромиссы.
<hardware>
Задумал переехать системой на SSD - посоветуйте или отговорите, плз. 20.02.13 14:01  
Автор: Fighter <Vladimir> Статус: Elderman
<"чистая" ссылка>
Аналогично задумывался. Глянул на цену — жаба задушила. Кинул две баракуды на raid-0 и нормально. Читаю под 180, пишу под сотню. Не SDD, конечно, но тоже не плохо при заметно меньшей цене за гигабайт. 20.02.13 20:54  
Автор: kstati <Евгений Борисов> Статус: Elderman
<"чистая" ссылка>
Тут надо смотреть на характер нагрузки. У ССД на 2 порядка... 19.04.13 14:01  
Автор: leon_pro Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Тут надо смотреть на характер нагрузки. У ССД на 2 порядка меньше время доступа. Если преобладает произвольное чтение/запись, то ссд тут будет гораздо уместнее. И работа с большим количеством мелких файлов гораздо быстрее на ссд, чем на рейде. А для работы с фото/видео выигрыш не так заметен.
У меня стоят 2 штуки - попроще для ОСей, пошустрее для работы, плюс традиционные винты под данные, не критичные к скорости.

P.S. дефрагментацию отключить, ибо это лишний износ ссд. Впрочем, следует погуглить "ssd best practices"
Ну, 30-50 баксов разницы по нынешним временам... 21.02.13 16:03  
Автор: Fighter <Vladimir> Статус: Elderman
<"чистая" ссылка>
Это не так много за бОльшую скорость и меньшее количество дисков и проводов (один ССД ровно в 2 раза меньше чем 2 ХДД в райде) ). Плюс меньше тепла. А объем для системного диска не особо важен, 120 Гб мне хватает за глаза.
Как раз в объеме и вопрос. У меня без хлама на системном... 21.02.13 20:35  
Автор: kstati <Евгений Борисов> Статус: Elderman
Отредактировано 21.02.13 20:44  Количество правок: 4
<"чистая" ссылка>
> Это не так много за бОльшую скорость и меньшее количество
> дисков и проводов (один ССД ровно в 2 раза меньше чем 2 ХДД
> в райде) ). Плюс меньше тепла. А объем для системного диска
> не особо важен, 120 Гб мне хватает за глаза.
Как раз в объеме и вопрос. У меня без хлама на системном диске забито чуть меньше сотни гигов нужными мне полезностями и служебным софтом. Один только hiberfile по объему озушки — 32 гига. Редко, но бывает, пользуюсь гибернацией. Пройдёт полгода — могу и вылезти за 120. А 240 уже кусаются. И уж цена ни как не на $50 разница.
Баракуды 1,5Tb $80-$90 штука, SSD-корсары и плексторы на которые целился были от $120-150 за 128Gb.

Скорость, конечно, хорошо. Но к объему быстро привыкаешь.
Разумеется, к следующему апгрейду (через годик-полтора) уже воткну SSD
C последним готов поспорить) Давным давно отучил себя и... 21.02.13 22:08  
Автор: Fighter <Vladimir> Статус: Elderman
Отредактировано 21.02.13 22:17  Количество правок: 1
<"чистая" ссылка>
> > Это не так много за бОльшую скорость и меньшее
> количество
> > дисков и проводов (один ССД ровно в 2 раза меньше чем
> 2 ХДД
> > в райде) ). Плюс меньше тепла. А объем для системного
> диска
> > не особо важен, 120 Гб мне хватает за глаза.
> Как раз в объеме и вопрос. У меня без хлама на системном
> диске забито чуть меньше сотни гигов нужными мне
> полезностями и служебным софтом. Один только hiberfile по
> объему озушки — 32 гига. Редко, но бывает, пользуюсь
> гибернацией. Пройдёт полгода — могу и вылезти за 120. А 240
> уже кусаются. И уж цена ни как не на $50 разница.
> Баракуды 1,5Tb $80-$90 штука, SSD-корсары и плексторы на
> которые целился были от $120-150 за 128Gb.
>
> Скорость, конечно, хорошо. Но к объему быстро привыкаешь.
C последним готов поспорить) Давным давно отучил себя и всех, кто находится на расстоянии вытянутой ноги, от использования системного диска в качестве файлопомойки. А уж если разнести систему и файл подкачки... нулевой райд такого объема при 32 Гб ОЗУ тебе 100% не потребуется. Вот и получается 80-90 баксов под мусор и 120 баксов под ССД - как раз выигрыш по всем параметрам за 30-50 баксов.
> Разумеется, к следующему апгрейду (через годик-полтора) уже
> воткну SSD
Разумеется. Для «помойки» выделено отдельное место. Если у... 23.02.13 00:47  
Автор: kstati <Евгений Борисов> Статус: Elderman
Отредактировано 23.02.13 01:27  Количество правок: 3
<"чистая" ссылка>
> C последним готов поспорить) Давным давно отучил себя и
> всех, кто находится на расстоянии вытянутой ноги, от
> использования системного диска в качестве файлопомойки.
Разумеется. Для «помойки» выделено отдельное место. Если у тебя на столько мало хлама, что ты можешь себе представить помойку на системном диске с занятым пространством около сотни гигов, то похоже, ты не знаешь, что такое помойка.
И уж если тебя смущают проекты на пару сотен гигов, то ты не знаешь что такое работа с большими объемами данных.
Это к слову о помойке на системе. С моими объемами ни она, ни рабочий поток в сотню не укладываются. Даже в три не влезут.

> А уж если разнести систему и файл подкачки...
Смеёшься? Какой на фиг своп при нормальном количестве озу?

> нулевой райд
> такого объема при 32 Гб ОЗУ тебе 100% не потребуется.
Абсолютно нелогичное высказывание.
ОЗУ — первичный носитель. HDD/SDD/RAID — вторичный. Как ни крути объем первого от объема второго не зависит. Опять же, похоже, что тебе не приходится крутиться с объемами данных на десятки-сотни гигов.

> Вот и
> получается 80-90 баксов под мусор и 120 баксов под ССД -
> как раз выигрыш по всем параметрам за 30-50 баксов.
SSD — получается выигрыш по одному параметру — скорости загрузки системы и первого открытия программ. При чём не всегда очевидный.
Когда скорость запуска программ ничтожна по сравнению со скоростью доступа к данным разница не заметна. Тем более, если не забывать о файловом кэше в озу.
Заметными по времени остаются лишь первые запуски программ и, разумеется, самой оси.

В поточной работе помойкой является абсолютно всё. И система, и текущая работа. Работа, по-скольку не подчищается от хлама до последнего этапа, а система, по скольку её восстановление из образа занимает считанные минуты — беречь смысла нет.

И выгода однозначна — временное хранилище, превышающее потребности примерно в два раза и система на массиве со скоростью доступа всего-то в два-три раза ниже SSD.
При этом всегда на внешнем винте висит образ системного диска, а выполненные работы еженедельно подчищаются от хлама и скидываются в архив на файловый сервер.

Если тебе не требуется прогонять за неделю этак террабайт, то это вовсе не значит, что такой потребности нет не у кого.

В общем, нулёвка более плавно «размазывает» выгоду от ускорения между данными и системой в отличие от резкого ускорения работы системы при нулевом ускорении доступа к данным.

Так что однозначной выгоды при таких объёмах озу и данных SSD не даёт — софт грузится «долго» лишь в первый запуск, во-второй — сто-пятый открывается «моментально» из кэша. А данные как грузились бы медленно всегда, так и продолжили бы. Очевидная разница лишь в убирании «первого» этапа.
Ниасилил - многабукаф 23.02.13 03:45  
Автор: Fighter <Vladimir> Статус: Elderman
Отредактировано 23.02.13 04:31  Количество правок: 2
<"чистая" ссылка>
Но главный посыл понял - я не видел настоящих файлопомоек, а значит я лох. 100% с тобой согласен, не спец я по помойкам)) Меня от них плющит и колбасит. Но как лох лоху скажу, что если ты не используешь своп, то ты никогда не работал со 100-200-300 Гб проектами. Во всяком случае под виндой, с 2-3-мя тяжелыми приложениями постоянно гребущими эти 100-200-300 гиг в разном направлении, иначе бы ты давно просто повесился. Разве что из твоих 300 гиг - 299 это действительно мусор.

Теперь самое главное. Я не просил тебя комментировать МОЙ стиль и условия РАБОТЫ, а просто объяснил тебе в предыдущем посте, что у некоторых все совсем по другому и пытаться навязать свою абсолютную истину минимум глупо, она у всех своя. ИРЛ, вчера поставил себе 520-й интел (Плексторов не оказалось в наличии, а ждать понедельника было влом) на 120 Гб и все мои ожидания и потребности были полностью удовлетворены. А что там происходит у тебя и какое количество мусора ты создаешь - мне абсолютно перпендикулярно, за 20 с лишним лет в ИТ я всякое повидал и выработал определенные правила, которые позволяют почти никогда не напрягаться по поводу комфортной работы и проблем на ровном месте лично мне. Одно из них - не создавать райды без необходимости. Другое - всегда иметь файл подкачки в винде т.к. стиль 98% программеров и сама винда гарантируют его использование, а так же проблемы при его отсутствии, в тех же 98% случаев. Поэтому я всегда 1 раз задаю нужный размер и расположение вручную и забываю о нем навсегда на данной конкретной машине.
То плиз, посоветуйте или отговорите, то стебешься. Ещё и тупишь. Ты уж определись 23.02.13 10:56  
Автор: kstati <Евгений Борисов> Статус: Elderman
Отредактировано 23.02.13 11:13  Количество правок: 7
<"чистая" ссылка>
> Но главный посыл понял - я не видел настоящих файлопомоек,
> а значит я лох. 100% с тобой согласен, не спец я по
> помойкам)) Меня от них плющит и колбасит. Но как лох лоху
> скажу, что если ты не используешь своп, то ты никогда не
> работал со 100-200-300 Гб проектами. Во всяком случае под
> виндой, с 2-3-мя тяжелыми приложениями постоянно гребущими
> эти 100-200-300 гиг в разном направлении, иначе бы ты
> давно просто повесился. Разве что из твоих 300 гиг - 299
> это действительно мусор.
Своп является костылём позволяющим увеличить общий доступный объем VM. При этом своп минимум на порядок медленнее RAM. Если ты в работе постоянно свопишься, то нафаига тебе SSD вообще? Первоначально производительность зависит от рамы, как первичного носителя. Стабильно не хватает её — добавь, а не свопься.
Ну и в общем. Удивишься, но одно целое на полсотни гигов на много требовательнее к ресурсам, чем сотня «деталек» по полгига, либо тыщёнка по полсотни метров. И весь проект в озу размещать требуется в крайне редких случаях. При том, что на вторичном носителе, как ни крути занятый объём один и тот же.

> Теперь самое главное. Я не просил тебя
> комментировать МОЙ стиль и условия РАБОТЫ, а просто
> объяснил тебе в предыдущем посте, что у некоторых все
> совсем по другому и пытаться навязать свою абсолютную
> истину минимум глупо, она у всех своя.
То плиз, посоветуйте или отговорите, то стебешься. Ещё и тупишь.
Ты уж определись.

Самое главное ты таки подметил — навязывать абсолютную истину глупо. В разных условиях «она своя»
Ты не поверишь. При любом объёме ОЗУ создай своп - он будет использоваться. 17.04.13 05:09  
Автор: AlexD <Alexander> Статус: Member
<"чистая" ссылка>
Нафига козе боян, а в нормальной конфигурации тормоз-своп? 17.04.13 10:02  
Автор: kstati <Евгений Борисов> Статус: Elderman
<"чистая" ссылка>
Поищи на хабре, там лох с ником амирул популярно и аргументированно объяснил почему. 17.04.13 19:45  
Автор: Fighter <Vladimir> Статус: Elderman
<"чистая" ссылка>
Тупишь ты, причем не по-детски. Советы твои закончились тогда, когда ты начал мне рассказывать, что я полный лох в мусорках. 23.02.13 13:54  
Автор: Fighter <Vladimir> Статус: Elderman
Отредактировано 23.02.13 14:10  Количество правок: 1
<"чистая" ссылка>
> > Но главный посыл понял - я не видел настоящих
> файлопомоек,
> > а значит я лох. 100% с тобой согласен, не спец я по
> > помойкам)) Меня от них плющит и колбасит. Но как лох
> лоху
> > скажу, что если ты не используешь своп, то ты никогда
> не
> > работал со 100-200-300 Гб проектами. Во всяком случае
> под
> > виндой, с 2-3-мя тяжелыми приложениями постоянно
> гребущими
> > эти 100-200-300 гиг в разном направлении, иначе бы ты
> > давно просто повесился. Разве что из твоих 300 гиг -
> 299
> > это действительно мусор.
> Своп является костылём позволяющим увеличить общий
> доступный объем VM. При этом своп минимум на порядок
> медленнее RAM. Если ты в работе постоянно свопишься, то
> нафаига тебе SSD вообще? Первоначально производительность
> зависит от рамы, как первичного носителя. Стабильно не
> хватает её — добавь, а не свопься.
> Ну и в общем. Удивишься, но одно целое на полсотни гигов на
> много требовательнее к ресурсам, чем сотня «деталек» по
> полгига, либо тыщёнка по полсотни метров. И весь проект в
> озу размещать требуется в крайне редких случаях. При том,
> что на вторичном носителе, как ни крути занятый объём один
> и тот же.
>
> > Теперь самое главное. Я не просил
> тебя
> > комментировать МОЙ стиль и условия РАБОТЫ, а просто
> > объяснил тебе в предыдущем посте, что у некоторых все
> > совсем по другому и пытаться навязать свою абсолютную
> > истину минимум глупо, она у всех своя.
> То плиз, посоветуйте или отговорите, то стебешься. Ещё и
> тупишь.
> Ты уж определись.
>
> Самое главное ты таки подметил — навязывать абсолютную
> истину глупо. В разных условиях «она своя»
Умница, если бы ты еще и молчать вовремя научился... Но это походу из области фантастики.(
Надо же. Зато у тебя выходит как раз детская тупость и весёлые наезды. Кто про мусорки-то и вытянутыми ногами с высока запел? 23.02.13 14:43  
Автор: kstati <Евгений Борисов> Статус: Elderman
<"чистая" ссылка>
гибернация при ssd, конечно, противопоказана 21.02.13 20:50  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Простое восстановление этих 32 гигабайт будет по скорости сопоставимо с честной нулевой загрузкой системы.

У меня на системном 128 свободно около 40 гигабайт, но часть помоек все-таки унес на второй диск где через настройки, где через directory junction. А на ssd оставлено то, что часто запускается и редко меняется.
Для меня гибернация это не скорость загрузки системы, а... 21.02.13 21:03  
Автор: kstati <Евгений Борисов> Статус: Elderman
Отредактировано 22.02.13 02:04  Количество правок: 3
<"чистая" ссылка>
> Простое восстановление этих 32 гигабайт будет по скорости
> сопоставимо с честной нулевой загрузкой системы.
>
> У меня на системном 128 свободно около 40 гигабайт, но
> часть помоек все-таки унес на второй диск где через
> настройки, где через directory junction. А на ssd оставлено
> то, что часто запускается и редко меняется.
Для меня гибернация это не скорость загрузки системы, а скорость восстановления рабочего пространства. Если пользуюсь — то всегда открыта прерванная работа — потыкал CTRL+S по открытым программам, увёл в спячку. Вернулся к компьютеру — после загрузки всё на прежних местах.
В том числе и из-за необходимости менять стиль прерывания работы задумывался над применимостью SSD ко мне в данное время.
Можно, конечно, перестраиваться. Да и не часто использую гибернацию, но всё ж — хочу, что бы после апгрейда работа была лучше, а не искать компромиссы.
sleep + ups - примерно тот же эффект 21.02.13 21:12  
Автор: dl <Dmitry Leonov>
Отредактировано 21.02.13 21:13  Количество правок: 1
<"чистая" ссылка>
Когда объем памяти становится сопоставимым с объемом диска, действительно начинает жаба душить.
Я вообще батник использую) Еще со времен NC. Нажал и, пока ходишь или думаешь, уже все на месте. 23.02.13 04:30  
Автор: Fighter <Vladimir> Статус: Elderman
<"чистая" ссылка>
Во многих случаях он подходит. В моём же я не совсем точно... 23.02.13 11:27  
Автор: kstati <Евгений Борисов> Статус: Elderman
Отредактировано 23.02.13 11:34  Количество правок: 2
<"чистая" ссылка>
Во многих случаях он подходит. В моём же я не совсем точно подобрал фразу «всё на месте». Правильнее — всё продолжает работать с остановленного места.

Нередко, хоть и не часто надо перегнать, например, несколько сотен имаг метров по 200-300 через нужный конкретной типографии профиль. Например, несжатые RAW-ы 16bt привести к тифам 8bit используя одинаковую поправку на растискивание.
Вручную — свихнуться можно от однотипных действий. Решение — скриптинг. Писать учёт проделанной работы ломает. На много проще считать всю задачу атомарной. Как результат при прерывании работы до её завершения теряется текущая «позиция» работы. Да, конечно, допилить можно и сохранять состояние. Но зачем, нарушать правило «работает что-то — не лезь» без острой необходимости? )

Второй случай, с которым не справится батник — конкретное позиционирование внутри документа. Опять же, решения создать можно, но зачем?

Могу, конечно, ошибаться, но батники в большинстве случаев позволяют тупо открыть необходимый софт, а не восстановить его состояние. Если не прав — просвяти, пожалуйста.
100%, я рассказал про свой случай. 23.02.13 14:09  
Автор: Fighter <Vladimir> Статус: Elderman
<"чистая" ссылка>
Большинство современных средств разработки при запуске открывают все нужные файлы в нужном месте, а если что-то и не открывает, то пара кликов меня спасает. Плюс многолетняя привычка: некоторые рутинные операции стали уже ритуалом начала работы)
1  |  2 >>  »  




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach