bitbucket Опубликовано 22 июня, 2010 (изменено) · Жалоба Дабы не портить тему про RT305X ( http://forum.nag.ru/forum/index.php?showto...st&p=513867 ) откровенным оффтопиком, продолжу здесь... Я уже портировался на embedded. DIR-300 с его Atheros 175 Mhz пропихивает два мегабита, при неоптимизированном коде.2 мегабита чего ? Какой профиль трафика ? И насколько эффективно ? Кстати, DIR300revA уже давно нет, в новом revB стоит rt305x. Но при должной сноровке эффект будет значительным, все зависит от того, что вендор понимает под компрессией. Это может быть лишь какая-то дериватива или очень похожее на тот же VJ compression. К сожалению тесты никто не проводил.Я проводил. Результат - компрессия всего трафика только ухудшает результат, компрессия http трафика (80/tcp) малоэффективна. Тестировал на реальном трафике, записанном tcpdump и проигранном через tcpreplay. Вообще, математика процесса показывает, когда компрессия может быть эффективна и насколько: Vc - скорость канала (1,2,11...) Vp - скорость паковки Vu - скорость распаковки (по результирующему объему данных) l - длинна блока R1 - коэффициент паковки , для www трафика это 0.07, для общего еще хуже (0.01) R2 - коэффициент удачной паковки, т.е. когда результат меньше исходного. Для www это 0.18 (здесь применялось сжатие lzo1x_1, оно даже немного лучше того, чем жмет atheros, профиль трафика - "хомячки в час пик") итак, время на передачу будет равно: Tp=l/Vp + l*R2/Vu + (l-l*R1)/Vc без паковки это T0=l/Vc Посчитаем выигрыш в процентах: p=100-(100*Tp/T0) или p=100-(100*(1/Vp+R2/Vu+(1-R1)/Vc)/(1/Vc)) Если это перевести в тест (сжать-распустить попакетно данные из семпла трафика ~1Gb), то будут такие результаты: AMD Phenom 9750 2.4Ghz Vp=549 223 685bps Vu=35 821 129 234bps (550Мбит и 35Гбит) RB433 680MHz Vp=33 292 608bps Vu=1 606 269 096bps (33.2Мбит и 1.6Гбит) **Тут одно НО: так как памяти там мало (не 1Гб), я порезал семпл на части и кусочками скармливал девайсу (по ~40М), потом посчитал среднее. Atheros AR5414 жмет еще медленней и менее эффективно: я коэффициент сжатия проверял так: с одной стороны включал компрессию на чипе, с другой - выключал, и в monitor mode смотрел размеры приходящих пакетов. Цифры тестов сейчас найти ме ногу, к сожалению. Упаковка на atheros подразумевает вкючение какого-нибудь шифорвания, я включал самый простой wep. То, что упаковка действительно работет я проверил, загрузив канал "нулями" ( nc x.x.x.x xxx < /dev/zero ==== nc -lpxxx > /dev/null ) увидел превышение скорости радиоканала. В результате имеем такие коэффициенты: R1=0.07 R2=0.18 Ну и можно построить таблицы эффективности паковки: Если жать на PC то будет так: таблица - скорость радио в Mbit :: эффективность в %% 1 6.84 2 6.67 5.5 6.1 11 5.19 6 6.01 9 5.52 12 5.03 18 4.04 24 3.06 36 1.08 48 -0.89 54 -1.87 А вот mips на RB433: 1 4.29 2 1.57 5.5 -7.92 11 -22.85 6 -9.28 9 -17.42 12 -25.56 18 -41.84 24 -58.12 36 -90.68 48 -123.24 54 -139.52 А проседать ath5k может, т.к. чип при бОльшей нагрузке ощутимо греется. Я через месяц, как дооборудую лабу - буду замерять уровень нагрева чипа в контролируемых условиях, и возможно замерю эффективность компрессии и влияние ее на тепловыделение.Было бы интересно посмотреть на цифры. Для себя я сделал вывод: на больших скоростях трафик паковать смысла нет, будет только хуже. Тем кто гоняет "нули" паковка, конечно, поможет. Воьможно, используя другие методы компрессии плюс применение некой прокси, которая будет собирать http объекты, а потом их сжимать, можно улучшить показатели, но, чем сильнее сжатие, тем больше требуется вычислительных ресурсов. Изменено 22 июня, 2010 пользователем bitbucket Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 22 июня, 2010 · Жалоба Стоп. Начнем с того, что шифрование и компрессия несовместимы, в моем случае - на Atheros. "about compression. atheros does support compression, but i do not use it since it will not allow wpa encryption etc. which is more important than getting 30% more speed on uncompressed content only. (almost any bigger content is compressed unfortunatly)" http://www.dd-wrt.com/phpBB2/viewtopic.php...4e249efedd74951 Насколько я знаю, у него доступ к SDK. То же мне говорили Микротиковцы, и еще несколько источников. Есть вероятность что: 1)Если WEP софтовый, то компрессия будет почти бесполезна, зашифрованный траффик очень плохо сжимаем. 2)Если аппаратный, скорее всего логический блок используемый под аппаратный WEP/WPA используется и под сжатие, и можно огрести с этим кучу глюков. Я с этим сталкивался. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bitbucket Опубликовано 23 июня, 2010 (изменено) · Жалоба Стоп. Начнем с того, что шифрование и компрессия несовместимы, в моем случае - на Atheros.Ну как бы ath5k_set_decomp_mask() хочет keyidx: /* * Decompression mask registers [5212+] */ #define AR5K_DCM_ADDR 0x0400 /*Decompression mask address (index) */ Так что без включения шифрования запустить компрессию не получится. Возможно, оно скорее всего не шифрует, а подменяет алгоритм шифрования на компрессию. Не знаю, это скорее к аффтарам девайса. У меня без допиливания установки ключей (там ошибка есть в ath5k) не работала декомпрессия: в ath5k_hw_set_key_lladdr() надо поменять вычисление хеша mac адреса на: high_id = (mac[5] << 8) | mac[4]; low_id = (mac[3] << 24)| (mac[2] << 16) | (mac[1] << 8) | mac[0]; low_id >>= 1; low_id |= (high_id & 1) << 31; high_id >>= 1; high_id |=AR5K_KEYTABLE_VALID; Насколько я знаю, у него доступ к SDK. И что ? В открытых исходниках все есть. Кстати, это как раз подтверждает мысль о том, что компрессия в atheros это как еще один вариант шифрования. 2)Если аппаратный, скорее всего логический блок используемый под аппаратный WEP/WPA используется и под сжатие, и можно огрести с этим кучу глюков. Я с этим сталкивался. Скорее всего. Кстати, шифрование так же портит показатели пропускной способности канала. Можно легко посчитать насколько, исользуя формулу в первом посте. Вопрос: а так же оно в других чипсетах, например в ralink ? Изменено 23 июня, 2010 пользователем bitbucket Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...