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

Які існують альтернативні алгоритми виявлення помилок, щоб перевірити, що було б швидше?

Незважаючи на те, що варіанти CRC можуть бути більш швидкими, ніж 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 .

Простий однобітний паритет (в основному XORing даних над собою знову і знову) проходить так само швидко, як можна отримати. Ви все-таки втрачаєте багато перевірки помилок CRC.

У псевдокоді:

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

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

Ефективність контрольних сум для вбудованих мереж

Деякі цитати висновків (засновані на їх дослідженнях невиявлених ймовірностей помилок):

Коли домінуючі помилки домінують

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

В інших додатках

"Добрий" поліном CRC, коли це можливо, слід використовувати для виявлення помилок

Якщо вартість обчислень дуже обмежена

(як у вашому випадку) використовуйте (в порядку ефективності):

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

Інші цитати:

Контрольна сума Fletcher має менші обчислювальні витрати, ніж контрольна сума Адлера, і, всупереч поширеній думці, також більш ефективна у більшості ситуацій.

і

Як правило, немає причин продовжувати поширену практику використання контрольної суми XOR у нових конструкціях, оскільки вона має таку ж обчислювальну вартість програмного забезпечення, як контрольна сума на основі додатків, але лише приблизно вдвічі ефективніша при виявленні помилок.

Контрольна сума Адлера повинна бути достатньою для перевірки спотворень передачі. Він використовується бібліотекою стиснення Zlib і був прийнятий стандартом графічної графіки Java 3D для забезпечення швидкої, але ефективної перевірки цілісності даних.

На сторінці вікіпедії :

Контрольна сума 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, і швидше - якби вони були, люди замість цього використовували б.

Ви можете спробувати просту контрольну суму, але це набагато менше шансів виявити помилки.

Добре, що логіка контрольної суми хороша, і люди можуть допомогти у більш швидких алгоритмах.

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

Якщо вони є двома незалежними елементами (у різних потоках), ви можете отримати повну швидкість передачі та надсилати лише невдалі пакети.

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

• Сервер розпадається на відомі розміри пакетів (скажімо, 1K шматки). Ставить їх у чергу "надіслати".
• Кожен пакет надсилається з 16 або 32 бітовим ідентифікатором І його контрольною сумою.
• Клієнт отримує кожен пакет і ставить його в чергу для обробки.
• На окремій потоці клієнт приймає пакет одночасно, робить перевірку.
  • Після успіху він додає його до остаточної колекції пакетів (у порядку ідентифікації)
  • У разі відмови він повідомляє про невдалий ідентифікатор назад на сервер, який подає чергу до цього пакета, щоб повторно відмовитися.
• Після отримання та перевірки пакетів та отримання ідентифікаторів у правильній послідовності (починаючи з 1) ви можете почати записувати їх на диск (або робити все, що потрібно).

Це дозволить вам передавати з максимально можливою швидкістю, і якщо ви граєте з розміром вашого пакету, ви можете розробити коефіцієнт відмови оптимію VS для перевірки / повторної передачі.

Капсули традиційні

(зменшити # '+ потік)

XOR, як зазначено вище, також буде працювати

(зменшити # 'потік XOR)

Трохи більш детальною (повільнішою) схемою є стандартна перевірка парності для послідовних з'єднань.

На цьому рівні ви торгуєте правильністю швидкості. Вони періодично виходять з ладу.

На наступному, найскладнішому рівні, ви можете використовувати деякі матеріали типу crc / hash.

Іншою конструкцією було б збільшення розміру блоку, який використовується для потоку.

Ви повинні мати оцінку фактичної частоти помилок, щоб настроїти вибір алгоритму та параметри для розміру блоку.