Я делаю некоторую передачу данных от dsPIC к ПК, и я делаю 8-битный CRC для каждого блока 512 байтов, чтобы убедиться, что нет ошибок. При включенном коде CRC я получаю около 33 КБ / с, без него - 67 КБ / с.

Какие есть альтернативные алгоритмы обнаружения ошибок, чтобы проверить, что будет быстрее?

Хотя могут быть более быстрые варианты, чем CRC, если вы их используете, вы, вероятно, в конечном итоге пожертвуете некоторой степенью возможности обнаружения ошибок. В зависимости от ваших требований к обнаружению ошибок, альтернативой может быть использование кода CRC, оптимизированного для вашего приложения.

Сравнение CRC с другими вариантами приведено в превосходном ответе Мартина Томпсона .

Одним из способов помочь с этим является pycrc - инструмент (написанный на python ¹ ), который может генерировать исходный код на C для десятков комбинаций модели и алгоритма crc . Это позволяет оптимизировать скорость и размер для вашего собственного приложения, выбирая и сравнивая различные комбинации. ^{1: требуется Python 2.6 или более поздняя версия.}

Она поддерживает crc-8 модель , но и поддерживает crc-5, crc-16и crc-32среди других. Что касается алгоритмов , он поддерживает bit-by-bit, bit-by-bit-fastи table-driven.

Например (загрузка архива):

$ wget --quiet http://sourceforge.net/projects/pycrc/files/pycrc/pycrc-0.8/pycrc-0.8.tar.gz/download
$ tar -xf pycrc-0.8.tar.gz
$ cd pycrc-0.8
$ ./pycrc.py --model=crc-8 --algorithm=bit-by-bit      --generate c -o crc8-byb.c
$ ./pycrc.py --model=crc-8 --algorithm=bit-by-bit-fast --generate c -o crc8-bybf.c
$ ./pycrc.py --model=crc-8 --algorithm=table-driven    --generate c -o crc8-table.c
$ ./pycrc.py --model=crc-16 --algorithm=table-driven   --generate c -o crc16-table.c
$ wc *.c
   72   256  1790 crc8-byb.c
   54   190  1392 crc8-bybf.c
   66   433  2966 crc8-table.c
  101   515  4094 crc16-table.c
  293  1394 10242 total

Вы можете даже делать такие вещи, как указание, используя двойной поиск (с 16-байтовой таблицей поиска), а не однобайтовый поиск с 256-байтовой таблицей поиска.

Например (клонирование репозитория git):

$ git clone http://github.com/tpircher/pycrc.git
$ cd pycrc
$ git branch
* master
$ git describe
v0.8-3-g7a041cd
$ ./pycrc.py --model=crc-8 --algorithm=table-driven --table-idx-width=4 --generate c -o crc8-table4.c
$ wc crc8-table4.c
  53  211 1562 crc8-table4.c

Учитывая ограничения памяти и скорости, эта опция может быть лучшим компромиссом между скоростью и размером кода. Единственный способ быть уверенным в том, чтобы проверить это, хотя.

Pycrc репозиторий на GitHub , как его отслеживания проблем , но он также может быть загружена с сайта SourceForge .

Простая однобитовая четность (в основном, XOR данных поверх себя снова и снова) - это почти так быстро, как только можно. Вы теряете много ошибок при проверке CRC.

В псевдокоде:

char checksum = 0;
for each (char c in buffer)
{
    checksum ^= c;
    SendToPC(c);
}
SendToPc(checksum);

Действительно хорошая статья, сравнивающая производительность различных контрольных сумм и CRC во встроенном контексте:

Эффективность контрольных сумм для встраиваемых сетей

Некоторые цитаты из выводов (на основе их исследований вероятностей необнаруженных ошибок):

Когда доминируют пакетные ошибки

XOR, добавление двух дополнений и контрольные суммы CRC обеспечивают лучшую производительность обнаружения ошибок, чем добавление дополнения, контрольные суммы Fletcher и Adler.

В других приложениях

«хороший» полином CRC, по возможности, должен использоваться для целей обнаружения ошибок

Если стоимость вычислений очень ограничена

(как в вашем случае) используйте (в порядке эффективности):

• Контрольная сумма Флетчера
• дополнение к дополнению
• дополнение к двум дополнениям

Другие цитаты:

Контрольная сумма Флетчера имеет более низкую вычислительную стоимость, чем контрольная сумма Адлера, и, вопреки распространенному мнению, также более эффективна в большинстве ситуаций.

а также

Как правило, нет оснований продолжать обычную практику использования контрольной суммы XOR в новых разработках, поскольку она имеет те же вычислительные затраты на программное обеспечение, что и контрольная сумма на основе сложения, но эффективна при обнаружении ошибок только наполовину.

Контрольная сумма Адлера должна быть достаточной для проверки искажений при передаче. Он используется библиотекой сжатия Zlib и принят стандартом мобильной графики 3D Java для быстрой, но эффективной проверки целостности данных.

Со страницы википедии :

Контрольная сумма Adler-32 получается путем вычисления двух 16-битных контрольных сумм A и B и объединения их битов в 32-битное целое число. A - сумма всех байтов в строке плюс один, а B - сумма отдельных значений A для каждого шага.

В начале прогона Adler-32 A инициализируется равным 1, B - 0. Суммы делаются по модулю 65521 (наибольшее простое число меньше 2 ^ 16 или 65536). Байты хранятся в сетевом порядке (с прямым порядком байтов), B занимает два старших байта.

Функция может быть выражена как

 A = 1 + D1 + D2 + ... + Dn (mod 65521)
 B = (1 + D1) + (1 + D1 + D2) + ... + (1 + D1 + D2 + ... + Dn) (mod 65521)
   = n×D1 + (n-1)×D2 + (n-2)×D3 + ... + Dn + n (mod 65521)

 Adler-32(D) = B × 65536 + A

где D - строка байтов, для которой должна быть рассчитана контрольная сумма, а n - длина D.

Я не знаю ничего, что было бы столь же эффективно при обнаружении ошибок, как CRC и быстрее - если бы оно было, люди использовали бы его вместо этого.

Вы можете попробовать простую контрольную сумму, но вероятность обнаружения ошибок гораздо ниже.

Ну, сама логика контрольной суммы хороша, и люди могут помочь с более быстрыми алгоритмами.

Если вы хотите повысить скорость работы вашего компонента, вам может потребоваться изменить общую технику, чтобы отделить компонент передачи от компонента проверки.

Если у вас есть эти два независимых элемента (в разных потоках), вы можете получить полную скорость передачи и пересылать только ошибочные пакеты.

Алгоритм будет выглядеть примерно так:

• Сервер распадается на пакеты известных размеров (скажем, порции по 1 КБ). Ставит их в очередь «быть отправленным».
• Каждый пакет отправляется с 16 или 32-битным идентификатором и его контрольной суммой.
• Клиент получает каждый пакет и помещает его в очередь для обработки.
• В отдельном потоке клиент получает пакет за раз, выполняет проверку.
  • В случае успеха он добавляет его к окончательному набору пакетов (в порядке идентификации)
  • При сбое он сообщает о сбойном ID обратно на сервер, который ставит в очередь этот пакет для повторной отправки.
• После того как вы получили и проверили пакеты и у вас есть идентификаторы в правильной последовательности (начиная с 1), вы можете начать записывать их на диск (или делать то, что требуется).

Это позволит вам передавать с максимально возможной скоростью, а если вы играете с размером пакета, вы можете определить оптимальную частоту отказов VS, а также скорость проверки / повторной отправки.

Контрольные суммы традиционные

(уменьшить # '+ поток)

XOR, как указано выше, будет также работать

(уменьшить # 'поток XOR)

Немного более сложной (более медленной) схемой является стандартная проверка четности для последовательных соединений.

На этом уровне вы торгуете правильно для скорости. Они иногда терпят неудачу.

На следующем, более сложном уровне вы можете использовать некоторые вещи типа crc / hash.

Другой дизайн должен был бы увеличить размер блока, используемого для потока.

У вас должна быть оценка фактической частоты ошибок, чтобы настроить ваш алгоритм выбора и параметры для размера блока.