[bitbucket]

Дабы не портить тему про 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

[nuclearcat]

Стоп. Начнем с того, что шифрование и компрессия несовместимы, в моем случае - на 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 используется и под сжатие, и можно огрести с этим кучу глюков. Я с этим сталкивался.

 

 

[bitbucket]

Стоп. Начнем с того, что шифрование и компрессия несовместимы, в моем случае - на 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