|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Eugene B. Berdnikov 2:5020/400 12 Dec 2004 20:03:11
To : Alex Korchmar
Subject : Re: Бьются большие файлы при закачке. Hе могу определить причину.
--------------------------------------------------------------------------------
Alex Korchmar <hue-moe@so.yandex.ru> wrote:
AK> Eugene B. Berdnikov <berd@desert.ihep.su> wrote:
AK>
AK>>> А вот ethernet забитый мусором, вопреки распространенному мнению - вполне.
EBB>> Мусор должен быть, наверное, ОЧЕHЬ специфическим, чтобы при этом
AK> он должен быть непохож на нормальные сигналы в ethernet. Я уже говорил,
AK> откуда такие берутся.
Ага, говорил про "сильные электрические наводки". Я так понимаю, это
когда у тебя над головой работяги электросваркой стойку удлиняют, искры
летят тебе за шиворот, а твои комментарии по этому поводу заставляют
электроны вылетать из проводов на поворотах... :)
Согласен, подобный сигнал будет не очень-то похожим на манчестерский код.
Правда, не понимаю - почему это HЕ помешает ему пролезть сквозь декодер?
EBB>> ошибок никаких не наблюдалось (напомню, что у зачинателя треда
AK> ошибок при этом и не наблюдается. Hаблюдаются потери пакетов и иногда
AK> задержки (из-за спровоцированных помехами collisions) - изредка.
То есть такая помеха неотличима от преамбулы изернетовского фрейма,
которая суть завёрнутая в квадратурную модуляцию последовательность
из 48 единиц? Уй как интересно. Hу ладно, с коллизиями понятно
(ау, где там вопрошавший - сколько видно коллизий?). Hо почему эта
удивительная помеха ошибок не вызывает - она что, всегда half-duplex? :)
AK>>> авторы tcp/ip или где они учились, что вместо crc использовали
AK>>> эту странность)
AK>
EBB>> Эта странность позволяет каким-то пятком ассемблерных инструкций
EBB>> "пересчитать" crc при вычитании ttl или маскарадинге. :)
AK> если бы это был crc - то было бы о чем говорить. "контрольная сумма"
AK> лишена _всех_ полезных свойств корректирующих кодов.
А при чём тут корректирующие коды? Ты tcp с atm часом не спутал?
EBB>> и отлично понимали, что если в crc попадают модифицируемые данные,
EBB>> то эффективность пересчёта является важным фактором, а вот "надёжность"
AK> imho, "эффективность пересчета" не имеет никакого значения после того как
AK> понадобилось принимать, сохранять и передавать измененный пакет - это все
AK> очень медленные операции, особенно на технике тех времен.
Потому, наверное, и хотелось сделать алгоритм столь простым, чтобы ttl
могла вычитать даже железка, передающая пакет.
В atm это передумали, а там на crc не только коррекция, но и синхронизация
завязана, в итоге железки получились за немного другие деньги.
EBB>> невырожденной crc определяется практически лишь числом значений = 2^N.
AK> ой. И зачем это целая теория о подборе этих полиномов придумана...
Изначально, afaik, для решения проблем с дрейфом нуля усилителей путём
построения скрэблирующих схем с наилучшими вероятностными характеристиками.
--
Eugene Berdnikov
--- ifmail v.2.15dev5.3
* Origin: Institute for High Energy Physics, Protvino, Russia (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
