Свежие комментарии

Title	Comment
Ну и да, пишу я неоптимально, это очевидно. банальным write(	Ну и да, пишу я неоптимально, это очевидно. банальным write(fd,buf, 100010241024) Но и с этой неоптимальностью не заметить разницу в три раза - сложно.
Зачем сразу обижать то? Я отдельно меряю времена генерации	Зачем сразу обижать то? Я отдельно меряю времена генерации буфера, отдельно - записи каждого гигабайта. Ну и всю запись вместе - тоже меряю. Да, и меряю, скромно, через QueryPerformanceCounter, считаю что точность - удовлетворительная :)
вот ведь, везде обман	вот ведь, везде обман
Значимого отличия от ноликов не вижу.	Значимого отличия от ноликов не вижу.
В смысле, 0xff? Ща!	В смысле, 0xff? Ща!
а относительно быстрый псевдорандом-генератор свою лепту в с	а относительно быстрый псевдорандом-генератор свою лепту в скорость не вносит?
Гоню, у меня 520-й оказался. 60Gb. 380Mb/sec - нолики 82Mb/	Гоню, у меня 520-й оказался. 60Gb. 380Mb/sec - нолики 82Mb/sec - рандомы
а попробуйте писать единички теми же гигабайтными чанками -	а попробуйте писать единички теми же гигабайтными чанками - ведь flash в единицах после стирания - что получится?
ну так он тоже не интел. ps: камент разспамь.	ну так он тоже не интел. ps: камент разспамь.
http://www.tomshardware.com/reviews/ocz-vertex-2-25nm-ssd,28	http://www.tomshardware.com/reviews/ocz-vertex-2-25nm-ssd,2867-7.html http://www.tomshardware.com/reviews/ocz-vertex-2-25nm-ssd,2867-4.html CrystalDiskMark 3.0 x64, set to read and write random data to drive
SF-2881, тоже же жмет. Какая-то бенчмарка реально использует	SF-2881, тоже же жмет. Какая-то бенчмарка реально использует высокоэнтропийные данные? На 510-м - тоже сейчас попробую. 520-го нету в хозяйстве.
нет sdd кроме intel и 520 пророк его!	нет sdd кроме intel и 520 пророк его!
У TCP - "плохо" с window.	У TCP - "плохо" с window. Т.е. если вы живете со стандартным TCP-окном в 64k, то больше чем эти самые 64к за RTT - вы не пропустите. Но это давно вылечили через большие окна. Других принципиальных проблем я не вижу. В Win7, да, скорее всего в TCP многое поправили.
А почему не верите то, что	А почему не верите то, что мешает получить 7-8 гигабит (как на картинках выше)? Задержки у infiniband маленькие, tcp window - наоборот большое, естественных ограничений нет. - Да я верю. Просто у TCP всё не так хорошо как у infiniband, и где-то читал что для пользования infiniband нужно использовать ихнии протоколы, а не TCP. На локальном компе делал клиент-сервер на TCP протоколе в Win XP на С++ - получилось около 200 метров в секунду, при этом svchost+system грузили почти полностью одно из ядер процессора. SMB я прочитал вроде поверх TCP работает, так что по идее быстрее быть не должен чем TCP.. У меня есть три мысли: 1. в Win 7 поправили протокол TCP 2. SMB на самом деле может работать не только с TCP но и с Infibandoвскими протоколами. 3. Не умею я настраивать TCP-соединение. Вот кажется мне что второе.
А почему не верите то, что	Это SMB. Сервер - Linux, клиент - Win7. А почему не верите то, что мешает получить 7-8 гигабит (как на картинках выше)? Задержки у infiniband маленькие, tcp window - наоборот большое, естественных ограничений нет. Вот в видеокарту улетают 5-6 гигабайт/сек (40-50 Gbit/s) - и никого это не удивляет. Bandwidth памяти - 20-25 гигабайт/сек, даже без zero copy tcp есть огромный запас. Ну и надо учитывать, что это Infiniband Connected Mode, пакеты по 64килобайта (минус заголовки), т.е. чтобы получить 1 гигабайт в секунду нужно всего-то 16 тыс. пакетов в секунду. На гигабите с jumbo frames - при полной загрузке линка получается около 13 тыс пакетов в секунду - и никакой существенной нагрузки это не создает. Чексуммы считаются картой, битые пакеты (которых, впрочем, обычно нет) - тоже дропаются картой, компьютеру вообще ничего почти делать не надо. А простейших клиент-серверов - навалом. Возьмите netperf, к примеру.
Скажите, а по какому	Скажите, а по какому протоколу происходило копирование? Я просто не верю что TCP-протокол способен выжать 10 гигабит даже внутри одной локальной машины. Хотелось бы простейший клиент-сервер на каком-нибудь языке программирования C++, C# или Java
Если у тебя резалка линейная, то все же банально - минимум	Если у тебя резалка линейная, то все же банально - минимум - один ломтик - максимум - все ломтики (разрядность АЦП * размер ломтика) Отношение минимума к максимуму - и есть ДД. Другой вопрос, что шум в низах - (обычно?) больше одного ломтика т.е. минимум больше, а ДД - меньше).
всегда думал, что ДД матрицы это размер булки хлеба, а разря	всегда думал, что ДД матрицы это размер булки хлеба, а разрядность это количество ломтиков на которые мы эту булку режем. не?
У 50D шум чтения пониже.	У 50D шум чтения пониже.
Фазаны пишут про себя, что у них 12.5 стопов динамического д	Фазаны пишут про себя, что у них 12.5 стопов динамического диапазона. А чтобы их поизучать - надо иметь задник на руках, у меня его естественно нету.
Нет. Потому что это такие	Нет. Потому что это такие проблемы, которые были бы сразу видны. Если там вдруг 16-битные данные в RAW, а мы сдвигаем их на 2 и теряем два старших, самых значащих, бита, то это будет видно. Сразу.
Так как АЦП - линейные (в большинстве случаев, есть исключен	Так как АЦП - линейные (в большинстве случаев, есть исключения), а матрицы - по определению линейные, то связь есть прямая. ДД системы больше разрядности АЦП не может быть.
то есть все не правы (насчет 40D и 7D) - и DxOmark неправ, и	то есть все не правы (насчет 40D и 7D) - и DxOmark неправ, и William Claff неправ :-)
а как разрядность _АЦП_ свзязана с ДД _матрицы_? сдаётся мне	а как разрядность _АЦП_ свзязана с ДД _матрицы_? сдаётся мне что это как мягкое и тёплое
А каков обычно уровень черного? Т.е. о каком количестве стоп	А каков обычно уровень черного? Т.е. о каком количестве стопов речь? Если это вопрос "14 Ev против 16 Ev", то разницы никакой нет из-за светорассеяния. А если, скажем, 11 против 13?
подозрительные у них результаты. Canon 40D в ISO vs PDR пок	подозрительные у них результаты. Canon 40D в ISO vs PDR показывает себя как Canon 7D, а Canon 50D лучше их обоих в 1.5 раза.
А вероятность того, что это	А вероятность того, что это всего лишь проблема dcraw и его алгоритма распаковки не рассматривается?
Вот <a href="http://www.downloads.netgear.com/files/GDC/RNDU	Вот pdfка. Софт унифицирован, можно взять двухдисковую RNDP2000 за 15тр и потыкать в неё ещё дисков по usb3 - получается забавно. Собственно я так к ним и пришёл, осознав, что "совершенно необходимые" приблуды типа "управления настройками тарификации хранения информации авторизуемыми ldap пользователями" мне почему-то не очень нужны. А вот снапшоты и репликации по ssl, слежение за ups, поддержка любых дисков etc идут в комплекте бесплатно. Блин, рекламная компания какая-то получается. Дёрни представительство на тему наподержать - они дают. Я реально тащусь с этих железок.
Понятно, оно сейчас преаллоцируется, запишет 40 гигов нолико	Понятно, оно сейчас преаллоцируется, запишет 40 гигов ноликов, и полегчает. Но я давно не видел ТАКОГО на пустом месте
Собственно, вот включил сейчас uTorrent, скачать кина детям	Собственно, вот включил сейчас uTorrent, скачать кина детям и себе. Сразу несколько кинов, общим объемом гигабайт 40. И что я вижу? Disk Overloaded 100% (понятно, случайный I/O). Интернет у меня - 100Mbit из домонета + 10 от стрима. Просто жесть, чтобы такое увидеть еще позавчера, на массиве, на этом массиве должен был бы быть серьезный поток IO от чего-то (от бэкапа, к примеру).

Свежие комментарии

Pages