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

Закон парных случаев -- у меня вот на руках файл с расширением JPG и JIFI но SOF 0xc3 -- какой-то loseless. И его даже djpeg из libjpeg не берёт. Чем бы расшифровать? Википедия как-то молчит, и гугл скорее тоже.

Если мы действительно вспомним условие Лютера-Айвса (которому, впрочем, камера не соответствует), то выяснится что слепота в синем не обязательна

я так понимаю, что целевым объектом была мира.
то, что подсовывают конвертору в сегменте 6-9, уже не мира, а муар "отображателя", причём "отображателя" совершенно нефизичной природы. Соотв. результаты интерполятора в этом сегменте уже из разряда "наблюдение за наблюдающим" - "очень тонкое извращение", но никак не инструментальный результат. :-)

Хе-хе. Собрал самую свежую фрю 8, с фиксами на if_em. Рзрешил net_isr:

net.isr.direct=0
net.isr.direct_force=0

Радикально увеличил все очереди.

Стало лучше -- полностью насыщенный линк при 60% одного ядра. iperf Показывает 980 мегабит вместо 850 раньше.

Включил поллинг на em0 -- загрузка процессора 5-7% на тех же скоростях! ХАХА. Вот и хвалёный intel PRO/1000

С другой стороны, у меня он чипсетный, а во фре в драйвере кода для ich8lan столько же сколько для всех остальных вариантов вместе взятых, так что может это и говно и надо купить PRO/1000 PT Desktop, единственный доступный у нас PCIe x1 адаптер от интела.

Не факт, что усилитель и АЦП - это одна микросхема.

Более разрядный АЦП - это больше данных, сам АЦП дороже и все такое. При том, что реальный диапазон используемых значений меньше, чем разрядность АЦП, в D3 вот даже есть два режима, 12 бит и 14.

ZFS/RAIDZ на 1.6-1.8 гигагерцовом горшке - конкретно упирался.

А UFS у меня давно нету уже.

103 минуты за 15 дней... nfsd (отдаёт те же файлы торренто-качалке по NFS) -- 115 минут, прерывания -- 135 минут :)
Но я-то боюсь того, что он под нагрузкой именно упирается в процессор.

Похоже, что read raw творит последние чудеса -- без него было 60-65, теперь 95-110. И, да, на Win7 таки даже спец-плагин FAR'а копирует ужасно. А на XP был лучше эксплорера... Забавно.

QOS был выключен всегда, всё через свитч HP ProCurve. На сервер интел-гигабит, на клиенте -- Atheros. Ещё интересно, что же так iperf тупит-то?!

Но, мать моя, безо всякого ZFS на сервере при этом kernel (По top -S) + smbd жрут полное ядро E4500... ЧЕМ!? Не прерывания, не сетёвка, не диск, не raid5 (он жрёт скромные 2%)! Именно процесс "kernel" 60-65% и smbd ещё 35-40% :) Пора апгредйить камень? Или E4500 разогнать... Но я не умею Core2 гнать :(

Я тут перелез на Windows7 и наблюдаю ту же картину что была когда-то с XP -- iperf без опций -w показывает всего 120Mbit (на гигабите!), с -w 128k показывает хорошие 800Mbit, а вот с Samba Копируется 25MiB/s (Т.е. не 120 мегабит, но никак и не 800). И iperf показывает на винде по-умолчанию окна в 8KiB. Да, jumbo разрешены (7KiB, больше мой адаптер на винде не умеет)!
Ты вот в этом месте ничего не делал? Это только мне так не везёт? Или реестр опять править надо?

Прайс.ру и по 1600 нашел.
И вообще память в мире стремительно дешевеет. Что не может не радовать.

Software/hardware raid5/6 на SATA дисках - это еще тот пипец. Про software Alex написал. А по поводу hardware, даже с хорошим контроллером.
Обычно диски SATA покупают десктопных серий (к примеру Сигейты серии AS). А у них время задержек не регламентировано. И если винт по какой-то причине задумался, то контроллер просто переведет его в offline.
Нужно брать серверные диски SATA (у Сигейта серия NS/ES), а они стоят сильно дороже.
Поэтому для дома проще реид не делать, а просто втыкать очередной диск и подключать к точке монтирования/отдельную букву.
Как правило современные диски не сдыхают сразу так, чтобы ничего совсем нельзя было считать (случаи с заливанием или падением не считаем).

А бекапы делать куда-нибудь на USB диск, если это реально нужно.

В смысле "можно"?

У CR2 - нельзя, как я понимаю. Там просто поток данных переменной битности, а индексов для хождения "в середину" (в начало слайса 3) - нету.

У DNG - при том же способе компрессии, другая организация данных.

Хаффман там ниже.

Обсуждаемый код - это распихивание строки, уже раскодированной из Хаффмана.

Скажем, в DNG, где внизу тот же хаффман может быть, выше сделано по уму - или сплошным куском все или Tiles с известными координатами (и известными длинами, каждый тайл можно отдельно распаковывать).

А в CR2 - вот такой вот ужаснах.

Тут проблема в том, что порядок поступления пикселов - он по слайсам (слева направа, внутри слайса - сверху вниз), причем желания делать отдельный битмэп на всю картинку (Src в вашей нотации) - никакого нет, это еще мегабайт 40 (для 20Mpix), хочется ограничиться буфером на строку (а в дальнейшем - прямо in-place раскодировать, все-таки копирование жрет прилично).

А ваш код - предполагает обход в порядке пикселов destination.

Решение, которое я спер в RawSpeed заключается в том, что для каждой строки слайса мы рассчитываем смещение в destination, а дальше просто линейно идем.
Тоже не бог весть что, так как если компонентов в JPEG больше одного, то буфере будет несколько строк слайса, но достаточно эффективно, чтобы на время забыть: из 330мс стало 80. А, скажем, чтение по-байтам с пропуском маркеров - 250мс и теперь надо оптимизировать его.