Противоречие не преодолевается напрямую, так как этот код не использует Walsh matrix непосредственно для кодирования данных. Если бы они использовали эту матрицу напрямую, то получили бы код Уолша аналогичный по восстанавливающей способности коду Адамара - то есть имели бы дистанцию n / 2. Но в этом методе преобразование Уолша используется не напрямую для кодирования, а только как метод ускорения вычислений. Как Вы читали идея в том, чтобы представить "классический" полином оригинального RS-кода в форме Лагранжа и затем интерполировать его (заодно работая в GF(2) вместо GF(2^m)). Задача вычисления коэффициентов и сами вычисления при интерполяции оказались похожими по своим формулам на преобразование Уолша. Поэтому оно и было использовано для ускорения счета. Но это НЕ код на матрицах Уолша непосредственно. Ускорение счета достигнуто - но его цена это 2m - 2 (62 при m = 32) вызова преобразования Уолша. IMHO умножение на современных CPU как-то побыстрее будет - даже несмотря на необходимость потом в конце делать деление по модулю. Я тут тоже в последнее время позанимался всякими замерами и думаю, что из-за наличия в современных процессорах действительно быстрых, да еще и векторных (SSE) умножителей вряд ли на больших длинах можно побить по производительности методы использующие мульпликативную группу GF(p), где p - простое число. Только на малых разрядностях и соответственно длинах кода получается ускорение от других более замысловатых методов. Но на малых длинах уже практически достигнуты пределы. Так что наибольший интерес для расширения спектра приложений и для исследований IMHO теперь представляют именно большие длины.
persicum пробовал пример - ругается, получилось вот так CRC32.exe -wt -r -n2 -ya arc\*.* crc32 -wrr15000-1500 -mu1g -pow10 -tm3 -va4 -ya данные востановления CRC32_Vol\*.* CRC32.SUM CRC32.TAB из 225 метров данных получилось 25 метров восстановления - как я понимаю 10% если сделаю ключ -wrr15000-15000 будет ли это надежнее чем 2 копии ?
dimsoft 2 копии, при условии что обе могут быть частично повреждены, это вообще не резервирование - как ты будешь определять, какую часть из какой копии брать? Для тривиального "голосования" уже 3 копии нужно ) Поэтому алгоритмы специально заточенные под обнаружение ошибок и их восстановление однозначно рулят, хотя и требуют относительно небольшого объёма избыточности Хотя если вторая копия абсолютно надёжна (чего в природе конечно не бывает), то достаточно иметь возможность обнаружения самого факта возникновения ошибок в "рабочей" копии и никакие другие данные для восстановления уже не нужны
Правильно так: CRC32.exe -wt -r arc\ crc32 -wrr15000-1500 -tm7 -va4 Отличия в следующем: -n2 - это 64бит контрольной суммы для файлов вместо обычной 32-битной. Решай сам, нужно оно тебе или нет. -ya - хорош для батников, но я ведь не зря ввел элементы диалога в свою прогу, интересно всеже посмотреть, что она собирается делать, прежде чем открывать клетку такого зверя -mu1g - сколько памяти под прогу, начиная с версии 1.82 это полтора гига, если хочешь меньше - поставь реально сколько хочешь памяти. -pow10 - евроцентовая система нарезки, она тебе нужна? Оставь как было по умолчанию 5 равных файлов -tm3 - это квадратичный Рид-Соломон 32-битный, он только лишь раза в 2 быстрее ICEECC будет. Для большого числа блоков используй -tm7 - линейный Рид-Соломон -va4 - тома кратны 4 байт, можно оставить... по умолчанию тома кратны 2048байт. Решай сам как тебе больше нравиться ключ -tm7 будет считать тоже самое за 1.5 минуты =))) В несоизмеримое число раз, особенно если файлы большие. Обычное резервное копирование держится только на принципе "один снаряд в одну воронку дважды не попадает". Если есть скажем два диска и дырки возникли в одинаковых местах, то обычная резервная копия очевидно не поможет. А в случае если записаны коды - им все равно, можешь откусить хоть пол-диска с каждой копии и все равно получишь 100% исправление. Кста, моя прога в отличие от некоторый других не ограничена 100% избыточностью. можно например -wrr10000-20000 и получить 200% избытка
Y_Mur просто при разрушении диска не удалось восстановить ни одного файла полностью - а там было 7 копий (неделя). сейчас ищу "соломку" для такого случая.
А лучше зайди в директорию "arc" и делай корректирующую инфу изнутри. Так ты будешь знать, к чему относятся файлы коррекции, имена которых у меня не меняются и жестко заданы
Вру, щас замерил и получил 50 сек =))) crc32 -wrr15000-15000 -va4 -tm7 А теперь сравни 50 секунд у меня и полчаса у ICEECC o:
создал папку arc положил туда "охраняемый" архив вне папки лежит crc32 даю команду cd arc ../crc32.exe -wt -ya ../crc32 -wrr15000-15000 -va4 -tm7 -ya папки создались очень быстро спасибо за науку - стало намного понятнее ключ -ya нужен, т.к это все из батников теневые копии использует. в документации не нашел кодов возврата - есть ? или 0 - все хорошо и все ?
persicum собрал в rar без сжатия папки CRC32_Vol\*.* CRC32.SUM CRC32.TAB в winhex выделил половину и сделал обмен байтами (разрушил) в итоге ***** Info from CheckSumFile ***** Encoding Method..............: RS32_FFT Number of Data Volumes.......: 15000 Number of Recovery Volumes...: 15000 Total Size...................: 226,740,000 Size of Volume...............: 15,116 Redundancy...................: 100% Memory Required..............: 30,232 SSE2 Support.................: Enabled MMX Support..................: Enabled Finding undamaged volumes... User Data Volumes Found......: 0 from 15000 (15000 missing) Recovery Volumes Found.......: 7500 from 15000 Recovery is NOT possible... ;( Need MORE 7500 volumes что не так ? или надо было и сами данные тоже туда ?
Ну а как она тебе может из 100 метров кода сделать 200 мешков файлов? Этож не компрессор =))) Данных совсем не нашла =(((
Может, тебе нужно не 100% избытка, а 200%? Тогда можно было бы полностью уничножить данные и половину кодов, и все вернуть...
persicum точно в rar забросил и файл и востановление => Recovery Report Generated by CRC32.EXE v1.83: Checking DataSet... Access Errors....: 1 Reading Errors...: 0 CRC Errors.......: 0 Continue with repairing? [Y/N] ***** Info from CheckSumFile ***** Encoding Method..............: RS32_FFT Number of Data Volumes.......: 15000 Number of Recovery Volumes...: 15000 Total Size...................: 226,740,000 Size of Volume...............: 15,116 Redundancy...................: 100% Memory Required..............: 30,232 SSE2 Support.................: Enabled MMX Support..................: Enabled Finding undamaged volumes... User Data Volumes Found......: 14999 from 15000 (1 missing) Recovery Volumes Found.......: 131 from 15000 (130 extra) Recovery is POSSIBLE! Size of Volume...............: 15,116 Size of Buffer...............: 15,116 (100%) Memory Required..............: 226,815,348 Decoding undamaged volumes into 1 missing volumes... Decoding has been done successfully Repairing files... arc03.06.2009.7z Repaired Total Repaired : 1 Total Corrupted: 0 отлично - можно использовать
Более интересным было бы отступить 25%, а потом прибить 100%, чтобы погибло по 50% и кодов, и данных... А так у тебя подохли почти все коды, а данные все практически живы. Ну и потом, чего мелочиться? Вместо -wrr15000-15000 можно взять -wrr50000-50000, что будет гораздо-гораздо круче, а время счета не изменnтся, эффективность для пяти копий заголовков - 93%
Наверное, лучше всего что-то типа -wrr25000-25000. Но с ростом размера архивов можно смело увеличивать.
Привет всем! Кто нибудь разбирался с кодом БЧХ? Если да, помогите разобраться, если не сложно. Перерыл кучу литературы, но так и не смог найти книги, где было бы доступно описан принцип работы данного кода, да и хороших и понятных примеров нигде не найти.
Я вот в кодах Рида-Соломона немного подразобрался, но знаю только, что это лишь частный случай БЧХ... Будем ждать, что скажут nothing и sysprg По полиномным кодам Рида-Соломона есть замечательная статья Криса Касперски - "Информация воскресшая из пепла." По матричным - руководство Артема Дробанов к проекту Recovery Star, а также демонстрационный 16-битный матричный код, который используется в QuickPAR и ICEECC (жордановы исключения) в архиве к моей проге. Но это все конечно немного не то, что Вам требуется. Я только знаю, что в общем случае БЧХ должны исправлять до половины ошибок без знания их местоположения, что называется MDS в современной литературе. Но... Я просто чайник, подождем что напишут профессионалы, а если не напишут, то больше Вам в инете точно никто не поможет.
В том то и дело, что в интернете более или мене доступной информации по данному коду почти нет, а если и есть, то по большей части, описание самого алгоритма идет лишь поверхностное
Судя по всему это Вас преподы нагрузили для курсовой или тому подобное... И Вы теперь носитесь - БЧХ-БЧХ!!! А чем они лучше любого MDS-кода, того же самого Рида-Соломона? Чем Вам Рид-и-Соломон не угодили? Скажем, 16-битный код будет исправлять ошибки кратности 65535х - мало чтоли?
