Re: Отдача больших файло в

[MZ <zuborg@xxxxxxxxxxxxxxxxxxx>]

Shvayakov Alexander wrote:
> MZ wrote:
> > Отсутствие положительного опыта использования SATA устройств у Вас 
> > лично ещё не означает что SATA отстой. На самом деле при одинаковой 
> > механике и настройках довольно проблематично добиться условий чтобы 
> > скорость различалась хотя бы в два раза (при том что скорость cdrom 
> > меньше на порядки чем sata/scsi дисков).
> SATA , как интерфейс, не отстой, просто для него свое место. Скорость 
> линейного чтения у SATA может быть заметно выше, но увы...
> Скорость линейного чтения и способность осблуживать множество 
> интенсивных потоков фрагментированных данных - это разные параметры. И 
> основная разница не в механике диска, а в свойствах контроллеров.
Да, scsi-винт может принять на обслуживаение несколько запросов 
одновременно, но выполнять их придется поочередно - по другому механика 
не позволит. sata-винты с ncq делают в точности то же самое, только 
длина очереди там ограничена 32-мя запросами, а не 32к.
> Вы не задумывались почему sata контроллер стоит 3$, а приличный SCSI - 
> 150-2000$ ?
1. маркетинг
2. востребованные рынком и в силу этого популярные решения имеют меньшую 
себестоимость
> Поинтересуйтесь ценами на диски, и спросите в любом сервисе какой у них 
> процент отказов по SATA и SCSI дискам.
Летят диски все, без исключения. И процент надежности у scsi-дисков 
далеко не на порядок лучше чем у sata (а для некоторых моделей и вовсе 
хуже). Так что без raid1 не обойтись в любом случае, если нужна 
отказоустойчивость.
> Раз уж мы с Вами не имеем точной информации о конструкции дисков, то 
> предлагаю предположить на основании разницы в цене и надежности, что 
> разница в механике и прочих технических мелочах все же есть. Объяснить 
> все это только  понятиями желтая-белая-черная сборка  не получится.  Все 
> это железо делают одни и те же японские роботы что в китае, что в 
> мексике или венгрии.
Раз уж не имеем, то давайте не фантазировать а опираться на проверенные 
данные. Заявление "scsi - рулез, а sata - отстой" я считаю голословным и 
не опирающимся на реальные факты. Разница между scsi и sata, безусловно, 
присутствует, но не позволяет выкинуть на помойку или клеймить "отстоем" 
одну из этих технологий.
> > Больше еффекта от аппаратного кеша контроллера ? Каким, позвольте 
> > поинтересоваться, образом ?
> Существенная разница в том, что аппаратный кэш работает на уровне 
> объектов головка-дорожка-сектор, а кэш операционной системы на уровне 
> файлов.
Верно, как и то, что оба кеша работают на уровне блоков данных. Только 
аппаратные кеш дороже, а софтовым ОС может гибко управлять - кешировать 
в зависимости от статистики использования, освобождать области с уже 
ненужными или неизмененными данными..
>  >> Сколько мегабайт кеша контроллера еквивалентно одному гигабайту RAM ?
> Размер объектов подлежащих кэшированию и алгоритмы работы с ними очень 
> разные. Сопоставьте размер сектора диска и размер кина на вашем  диске, 
> которое вы хотите кэшировать.
> вычислите эквивалент.
Размер сектора - 512байт, размер кина - 1400М - какой отсюда вычисляется 
  еквивалент ?
> Однако  все сложнее гораздо. Важен процент попадания в кэш, а он будет 
> низким и почти всегда. Какова вероятность того, что в один момент 
> несколько клиентов тянут один и тот же файл?
Какое это имеет отношение к вопросу SCSI vs SATA и аппаратный vs RAM кеш?

> > Даже в домашних сетях dvd не раздают на 100м интерфейсах, а уж для 
> > коммерческого проекта думаю предусмотрено минимум одна 1Г сетевуха.
> Если это сетвуха за 4$, то не ожидайте от нее чудес. Серверные сетевые 
> карты  предназначенные  для обслуживания интесивных потоков имеют ряд 
> особых свойств и стоят заметных денюжков. Не забудьте посмеятся над 
> людьми которые их покупают, они же глупые... :)
> По умолчанию, без средств управления трафиком, при раздаче трафика 
> используются очереди пакетов типа fifo. Это работает по принципу "первым 
> пришел, первым ушел" (First In, First Out).  Потому один клиент может 
> захватить канал и  пока он не закончит тянуть свой файл, все остальные 
> ждут. Есть множество  оговорок  благодаря которым  канал все же немного  
> распределяется - учитывается значение поля пакета TOS (Type of Service), 
> в канале есть приоритеные полосы и т.д.
> Однако общий эффект грустный. Эти  заморочки особенно заметны  при 
> работе с интернет. При работе с относительно мелкими файлами кажется все 
> нормально распределяется, а в случае если кто зацепил тянуть видео с 
> рапиды, все нервно курят и ждут пока он докачает свою порнуху.
Не путайте перегруз офисного интернет линка пакетами от рапиды, которые 
не имеют выбора кроме как быть пущеными в канал или дропнутыми, с 
отдачей контента на сервере - ОС дает всем соединениям одинаковый 
приоритет (я рассматриваю соединения к веб-серверу) и по мере увеличения 
уровня потерь пакетов и задержек поддверждений уменьшает sending rate, 
поддерживая загрузку канала на высоком уровне и уменьшая необходимость 
перепосылать пакеты в случае их потери.