Jump to content

IgaX

Forum Members
  • Posts

    950
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by IgaX

  1. 17 часов назад, vasek00 сказал:

    c youtube например валит поток QUIC (Quick UDP Internet Connections)

    вроде же еще только экспериментально .. да и в browser://net-internals / chrome://net-internals по-умолчанию вырублено.

    так-то DASH в основном по HTTP/2 на современных, а UDP пока смысл если ток стримит в лайве.

    там в конфиге еще вроде downstream был на мосту, хотя вряд ли там где-то мультикаст образуется и воздух убивает, но для профилактики м.б. .. м.б. питания для шины не хватает под нагрузкой - м.б. БП другой попробовать.

  2. 18 минут назад, Dhampir113 сказал:

    а вот эта сработала

    
    interface WifiMaster0 channel width 20

    да ну, зачем себя ограничивать в 20МГц если никто и никому не мешает.

    20 минут назад, Dhampir113 сказал:

    если сделать 

    
    interface WifiMaster0 no channel width

    то сбрасывается по умолчанию вообще

    - вот, то что надо - чтобы никаких channel width в конфиге.

    .. и до кучи, "чтобы было", например:

    interface WifiMaster0 rekey-interval 3600

    хуже не будет.

  3. interface WifiMaster0
        country-code RU
        compatibility BGN
        channel width 40-below
        up
    !

    -> 

        channel width 40-below

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

    возможно(!) потому что в нормальном мире при расширении полосы "вниз" не дадут установить "основной" канал меньше 5 .. т.е. 40МГц идут как 5+1 .. и то это не оптимально - желательно не менее 7+3 при расширении "вниз" - если не нужно место из-за соседей выбирать.

    show interface WifiMaster0 channels

    -> тут как бы все возможно (не, м.б. если оно автоматом грамотно на 20МГц сбавляет, то ок).

    в общем, попробуйте для начала поставить принудительно 7-й канал и принудительно вырубить автосканирование (которое вроде по-умолчанию д.б. отключено):

    interface WifiMaster0 no channel width 40-below
    interface WifiMaster0 no channel auto-rescan
    interface WifiMaster0 channel 7

    если получится, то надо принудительно что-то принудить =)

  4. 47 минут назад, Le ecureuil сказал:

    Потому делать на статику запрос с if-modified-since и if-none-match раз в минуту при серфинге по страницам и получать 304 вполне себе неплохое решение.

    Вот, если не касаться картинок при первом открытии/рефреше страницы (это у меня бзик, что все должно быть без углов, поэтому извините если что), то основная проблема, на мой взгляд, в max-age=60 для всех *.js .. да даже не проблема, а мелкое неудобство, которое может приводить к лишним вопросам пользователя.

    Вот, например, хожу я между tools.diag.js?c=25s3u и tools.components.js?c=25s3u и пока действует max-age - все берется из дискового кэша с 200 OK, т.е. Date, ETag, Expires, Last-Modified - все это не учитывается и не трогается, но /ci всегда выдает свежие конструкции.

    И вот мы обновляем прошивку, например, быстро. Все завелось и взлетело, /ci стал выдавать свежие конструкции, а нужный *.js все еще под воздействием max-age и если пользователь в этот период зарефрешит, то все равно продолжит хватать ошибки в правом нижнем, если конструкции от /ci для текущих *.js непонятны.

    В общем, есть предложение для *.js сделать моментальное устаревание и проверку валидацией по If-None-Match и If-Modified-Since со стороны браузера при помощи нужного заголовка в ответе Nginx:

    Cache-Control: must-revalidate, max-age=0

    Браузер будет проверять по ETag и Last-Modified, которые обязательно поменяются, если изменится запрашиваемый ресурс в целом или при перепрошивке (дата вроде совпадает с той, когда прошивал). Где не изменилось - все будет 304 Not Modified.

    После прошивки при ребуте digest замерзнет и браузер, по идее, при загрузке/обновлении индекса провалидирует и обновит one.js на автомате вместе с остальным.

    Другой старый добрый способ - это таймштамп, например, прошивки в url, например, вместо Ваших 25s3u по всем запросам. Но это там, где надо от лишних 304 избавиться и завысить max-age по максимуму оставляя возможность на обновление ресурсов (бандлами через верхний индекс) или чтобы кривые кэширующие прокси пройти или некоторым старым браузерам пургена дать .. ну т.е. .. универсальное средство.

    Меня просто TTFB беспокоит, плавает даже на ресурсах при том, что роутер ничем особо не занят и нагрузки от клиентов нет .. не критично конечно но все же .. в общем, непонятно - Nginx или что поглубже.


  5. 8 минут назад, Le ecureuil сказал:

    Какие именно команды выполняются из этого скрина не видно, потому судить рано - может этот запрос выводит список всех интерфейсов и все настройки? Тогда и 100 мс это мало.

    Да вот в том-то и дело, что ничего особенного /ci не делает - иначе бы и воплей с моей стороны не было бы.

    <packet ref="/">
    <request id="1" ref="ndm

    /ndm[update:debug_led]">
      <command name="show system debug">
      </command>
    </request>
    </packet>
    
    и все дела в Response:
    
    <packet>
        <response id="1">
            <debug>
                <state>off</state>
                <alarm>off</alarm>
            </debug>
        </response>
    </packet>

     

  6. 3 минуты назад, Le ecureuil сказал:

    Ну подумать-то можно хоть немного, зачем это сделано.

    Для удобства разрабов это сделано. Релиз не проверял, но там такая догадка и не прокатит.

    4 минуты назад, Le ecureuil сказал:

    А если при перепрошивке устройства поменялись статические файлы

    ETag не сойдется и Last-Modified. И пользователь все же чаще ходит по интерфейсу, чем перепрошивает роутер.

    В общем, со мной в этом плане бесполезно.

  7. честно еще несколько раз решрефил для чистоты эксперимента .. и мое "любимое" время ожидания от .. localhost?

    Скрытый текст

    guiscr2.thumb.png.024ddeacabc2cbceaa4b0f40abef6edb.png

    и:

    Скрытый текст

    guiscr3.thumb.png.ffb40ba75b1d1bd22810a31c728ecdc9.png

     

    34 минуты назад, Le ecureuil сказал:

    И что в этой картине не так?

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

  8. .. пробегаемся по "кэшу" и что, в основном, видим?

    Cache-Control: max-age=60

    Т.е. устаревает через 60 сек (статика .. 60 сек, не, ну, Карл!). При этом имеет приоритет перед Expires, который выставляется .. а тоже в одну минуту (но просто не работает, м.б. для legacy). Про доп.опции Cache-Control, которые могли бы в т.ч. помочь "забыть" пользователю "обновлять" "кэш" браузера каждый раз после прошивки для, например, one.js, и сделать его, пользователя, жизнь комфортной, - про это просто не говорю.

    Не, есть грамотный момент, не спорю: для /ci выставляется (чтобы сразу устаревало):

    Cache-Control: max-age=0

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

    more temp:nginx/nginx.conf

    И возьмем примеры по настройке кэшей в Nginx, скажем, здесь .. в поисках конструкций:

    server {
    #...
    location ~* \.(gif|ico|jpe?g|png)(\?[0-9]+)?$ {
    expires     1w;
    }
    location ~* \.(css|js)$ {
    expires     1d;
    }
    #...
    }

    и

    server {
    #...
    location ~* \.(?:ico|css|js|gif|jpe?g|png)$ {
    add_header Cache-Control "max-age=88000,  public";
    }
    #...
    }

    и вот он наш Expiresтуда же и заодно):

    location ^~ /favicon.ico {
    			return 404;
    			add_header Ndm-Sysmode router;
    			expires 1m;
    
    .. и вот:
    
    location ~* ^(?!(\/storage\/|storage:\/)).*\.(gif|jpg|png|css|js|ico)$ {
    			include /etc/nginx/mime.types;
    			default_type application/octet-stream;
    			root /usr/share/htdocs;
    			add_header Ndm-Sysmode router;
    			expires 1m;
                
    итд.

    .. добавить заголовки для Cache-Control .. а .. зачем, Nginx видимо сам добавит на основе expires, не царское это дело.

    И справочно (мало ли):
    https://habrahabr.ru/post/204464/
    http://xmlhack.ru/texts/06/doing-http-caching-right/doing-http-caching-right.html

    ***
    Как там было .. "почувствуйте нашу любоff" =)

  9. Например, после рефреша #web.tc общая картина выглядит так:

    Скрытый текст

    guiscr1.thumb.png.52e6f95da490188fd57085be12dada23.png

    Эмм .. ну вы понимаете, да? как $#&%@@^*@%*#%*^%#^ и вообще для локального(!) веб-сервера.

    1) HTTP/1.1 304 Not Modified .. как бы соединение все равно есть, байтики идут, digest юзается;
    2) И скок их тут лишних на простом рефреше где-то в #web.tc? .. на вскидку как бы как мин. 13.

    Самое забавное, что memory cache то используется (а если делать через encode и data: - то, угу, всегда).

    Дальше лучше ..

  10. мм .. а еще в браузере можно настроить список/порядок предпочитаемых языков, о чем он потом весело сообщает каждый раз серверу:

    GET / HTTP/1.1
    Host: 192.168.2.1
    Connection: keep-alive
    Cache-Control: max-age=0
    Authorization: ...
    ...
    Upgrade-Insecure-Requests: 1
    Save-Data: on
    User-Agent: ...
    ...
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
    DNT: 1
    Accept-Encoding: gzip, deflate, sdch
    Accept-Language: ru,en;q=0.8
    Cookie: sysmode=router; _authorized=...

    и как бы обычно после этого:

    Accept-Language: ru,en;

    - сервер и так знает в каком порядке и чем кормить.

    .. но опять размышляете на тему системного(!) инпута (тайп-эф) .. для стилизации и локализации которого уже все давно придумано в т.ч. через pure JS.

    .. и не видите, например, всего айсберга .. а скок ему .. годы? .. а давайте посмотрим.

  11. 24 минуты назад, Padavan сказал:

    В сухом остатке - если вас не смущает более низкая скорость в Ookla SpeedTest на прием (если провайдер юзает шейпинг), то можно включать tx-burst смело

    Нет, не особо. Просто если алгоритм подсчета более-менее универсальный, то может аукнутся в других сценариях. Я ж не придираюсь, так, по делу.

    М.б. все же где-то есть неучтенное место при переходе в провод.

    По идее, сниф эфира и с провода на выходе аплинка может помочь. Как вариант на комплексный, м.б. и Вам интересно будет.

  12. крутилки вообще вещь хорошая .. согласно DataSheet на MT7612E можно все выкрутить так, чтобы даже на уровне чувствительности только высшие скорости остались .. победить Receive Adjacent Channel Rejection =)  .. (или хотя бы попробовать забороть) .. а остальные дальние вне thresholds как такие ля-ля ни о чем, слабые помехи.

    эх, такое шикарное железо .. ну вы поняли =)

  13. Формально, чтобы OFDM не сваливался в более простую модуляцию, нам надо держать noise меньше -82 dBm .. если noise на WifiStation адекватен в плане показаний, то vga-clamp крутим пока не будет баланса между скоростью/дальностью и noise-ом, чтобы модуляция не проваливалась .. т.е. как одна из педалек поиска золотой середины в плане стабильности линка (а там их еще много =)) при наличии "помехи".

    Есть другая полезная вещь, но как она используется - под вопросом. Это - Energy Detection Clear Channel Assessment (EDCCA) - не путать с EDCA (Enhanced Distributed Coordination Access). То что это есть в конфиге, в принципе, означает поддержку гибридного HCF (Hybrid Coordination Function), что в свою очередь, видимо, может подразумевать до кучи поддержку PCF (Point Coordination Function) и HCCA (HCF Controlled Channel Access), но это под большим вопросом .. поэтому формально и предположительно доступ к каналу регулируется либо через универсальный и древний DCF (Distributed Coordination Function), что добавляет веса в необходимости педалек вырезающих саму возможность Legacy, либо через более современный HCF (и да, для QoS нам бы педальки к EDCA в т.ч. помимо базовых WMM :)).

    Но вернемся к EDCCA - в идеальном мире этот механизм в т.ч. определяет - свободен канал или кто-то передает (тут еще тот курсовик как мин.) и в т.ч. дает зеленый свет на передачу .. все это работает в рамках Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) позволяя избегать коллизий и связанных ретрансмитов. С выключенным EDCCA мы, видимо, полагаемся только на базовый CCA (а что там помимо noise?) и Virtual Carrier Sense (ох уж эти NAV и что их вызывает) .. и как бы с одной стороны с позиции физ.линка у нас зеленый свет чаще (мы ведь всплески энергии не проверяем с выключенным EDCCA) и пашет оркестратор на базе, например, NAV (и тут такой CTS-to-self в воздухе и подбит канал на время действия), но шанс на колижн и лобовое выше (хорошо, что хоть клиенты по идее точно CCA замеряют перед своей отправкой).

    В общем, если не разбирать все, то первое знакомое:

    EDCCA_AP_RSSI_TH=-80

    - если я правильно понимаю, то: а) такую силу сигнала считаем, что канал занят (что логично для порога сваливания OFDM в районе -82 dBm); б) по идее, на этой первой линии в т.ч. отсекаются клиенты, у которых RSSI меньше этого порога (помимо другой похожей настройки/подстройки .. что тоже логично, т.к. ну этих глухих и дальних, только время эфира занимают при передаче на низких скоростях итп. итд. .. если, конечно, нет офигенной направленной с крутой PA и LNA, чтобы достучаться, усилить и услышать).

    А теперь к шуму. Если шум (который я вижу у себя, например), вдруг, посчитается EDCCA как передача, то пока генератор шума не будет подавлен, формально, по EDCCA канал будет занят (что как бы и объясняет возможную пропажу маяков - AP просто не будет их выпускать в воздух, т.к. не будет разрешения со стороны CSMA/CA).

    Поэтому вопросы:

    1) Когда мы сможем покрутить все сами в т.ч. по EDCCA? .. я бы, например, ~ EDCCA_AP_RSSI_TH=-70 попробовал со своим шумом на 2.4.
    2) Когда мы сможем вырубить по питанию генератор шума, например, USB3?

    В 23.05.2017 в 15:55, Padavan сказал:

    когда в эфире присутствует сильная специфическая помеха, которая приводит к исчезновению AP в эфире (пропадают маячки)

    Мысленный эксперимент показывает, что в плане пропажи своих маяков это имеет смысл, только с включенным EDCCA .. который если фабрично для RU - уже пока ни от чего не зависит, а не для RU (а .. Казахстан тоже цэ Европа? Нам бы список, чтобы знать кому что говорить). Может, лучше педальки? У меня почти все ответы есть. :)

  14. 5 часов назад, Roman_Petrov сказал:

    @IgaX так вы не особо сторонник TX burst? Раньше же он был включен по умолчанию и вроде как ничего все было? 

    Я сторонник, чтобы все возможные детали раскрыть, чтобы вновь прибывшие духи поменьше головой об стенку бились =)

    Опять же, если активных потребителей на единицу времени немного и все устраивает, то почему бы и не "за" для конечного пользователя, если это делает его довольным (но это все равно не отвечает на вопрос: почему на разных процах оно ведет себя по-разному). Просто всему есть цена и если, вдруг, под Rx-нагрузкой от AP Вы услышите - какого Ля со скайпом происходит на другом клиенте, - то эта настройка как один из кандидатов.

  15. Ну прям все так безапелляционно. =)

    Наверное, все же стоит предположить, что tx-burst не призывает ускорение за счет темной магии, а, скорее всего, питается за счет времени других потенциальных клиентов .. т.е., например, врубает вариацию RTS/CTS для монополизации канала, задирает счетчик в NAV, оставляя другим более длительные затяжки по CW и переходит на SIFS-интервал (а зачем AP PIFS в рамках burst) .. поскольку по времени этот интервал меньше того же VO AIFS1 в рамках WMM QoS .. то ощущение скорости выше .. но, вероятно, в рамках произведения burst со стороны AP до канала не достучаться и все буферизуется. А скок там burst .. наверное, в рамках Win-окна .. м.б. 64К и после него маааленькая такая возможность вклиниться со своим пакетиком и там AP снова отжигает своим burst пока патроны не закончатся. Как-то так, скорее всего.

    Итого:

    1) Tx-burst хорошо если активных клиентов мало .. скажем, больше одного ненасытного и по идее начнут чувствоваться лаги в определенных сценариях .. про QoS .. там видео на ТВ и одновременное что-то, наверное, виновник будет примерно ясен;
    2) А если залпы burst отжигают те же 64К для своих PHY по времени ровно как часы, а TCP (а у нас с ним точно все хоккей?) не поставляет равномерно топливо в эту трубу, то стоит ли винить speedtest? .. по идее, нам нужна та тема с ядром повыше и дисциплиной не pfifo ;)

    Мы так скоро и до разбора VO, VI, BE и BK дойдем :)

  16. 5 часов назад, ydzhus сказал:

    + по локальной сети в маршрут. Ноутбук SSD Windows 8.1 + подключенный WAN

    было бы очень интересно еще посмотреть при Вашей схеме, когда ноут с W8.1 будет подключен к WAN по проводу (если роутер в 192.168.1.1, то ноут с W8.1, например, на статику 192.168.0.1 через настройки подключения в W -> св-ва -> TCP/IPv4 .. и роутер: ручная настройка IPoE: шлюз на 192.168.0.1, ip на 192.168.0.2) .. шара на W8.1 вроде будет видна (если что - напрямую по ip) .. интересует в Ваших сценариях изменения при прокачке через WAN в сторону клиента с BCM94352HMB (и в обратную сторону тоже).

    p.s. и с разными комбинациями ppe (если не затруднит).
    p.p.s. и с разными комбинациями wmm / tx-burst

    спасибо.

  17. 6 часов назад, gaaronk сказал:

    Как его потом скормить драйверу - вот вопрос

    Драйвер, по идее, подцепит настройки из .dat при инициализации.

    Пока в мыслях либо через:

    show drivers

    - и там же в CLI выгрузить нужный и загрузить, но аргументы непонятны (какие и нужны ли).

    Либо эмулировать нажатие кнопки вкл./выкл wifi - WifiToggle .. она вроде глушит движок и запускает не трогая .dat и остальное (догадка).

  18. 46 минут назад, gaaronk сказал:

    И как все это богатство конфигурировать?

    хороший вопрос. я в этих системах как свинья в апельсинах :).

    nginx вроде под root-ом крутится .. если залить .dat в storage и переписать в temp: поверх, то с правами неувязок, наверное, не должно быть .. для 5 ГГц набор крутилок в RT2860APi.dat.

    если правильно понял намек, то м.б. помогут environmental variables как возможный подход через ssh .. но не знаю, получится ли добраться от root-a ssh .. я просто не понимаю, user space изолирован как-то жестко в своей песочнице или все же может все:

    env

     

  19. 3 часа назад, gaaronk сказал:

    2,4 не использую. броадкаста мультикаста нет =)
    Ваши рекомендации по настройке?

    Имхо, вылизывая N в 2.4 - мы его подготовим идеальным и для 5 ГГц

    Скрытый текст

    Не то, чтобы гарантированно разгонит до максимума N (да и вообще взлетит) .. но я бы обязательно обратил внимание на эти настройки:

    Скрытый текст
    
    
    # The word of "Default" must not be removed
    Default
    BssidNum=4
    FastStartup=0
    CountryRegion=0
    CountryCode=US
    SSID1=bla-bla1
    SSID2=bla-bla-guest
    SSID3=
    SSID4=
    WirelessMode=6;6;6;6	
    Channel=11
    TxRate=0			# Это пока непонятный зверь - в манускрипте не описан
    BasicRate=3840			# Я бы оставил только выше 24 Mbps, но можно и BasicRate=4032 для бОльшей совместимости
    BeaconPeriod=100
    DtimPeriod=1
    TxPower=50
    DisableOLBC=1			# Overlapping Legacy BSS - защитный механизм на B/G AP - вырубаем нафих
    BGProtection=2			# Аналогично, главный претендент на убийство линков до 13 Mbps в чистом N, жесткий OFF
    TxAntennaSel=0			# В манускрипте идет как TxAntenna .. можно попробовать поставить 2 в принудительно 2T2R
    RxAntennaSel=0			# В манускрипте идет как RxAntenna .. можно попробовать поставить 2 в принудительно 2T2R
    TxPreamble=0			# Long/Short Preamble .. я бы пока не крутил
    RTSThreshold=2347		# RTS/CTS - крутим в определенных случаях на дистанциях, но стараемся не трогать никогда
    FragThreshold=2346		# Если соседей слишком много и пакеты портятся на физ.уровне в большом кол-ве - лечим фрагментацией
    TxBurst=0			# Если QoS с WMM, то лучше пробовать без него, хотя фз, требует тестов во второй волне подстроек
    PktAggregate=0			# Говорят, что Ralink2Ralink only и для B/G, но я бы врубил во 2-ю волну, т.к. я бы назвал TurboRate проприетарным
    TurboRate=0
    WmmCapable=1;1;0;0 
    APSDCapable=1;1;0;0		# WMM Power Save - если есть перекос на Rx/Tx - пробуем нулить (помним Intel interoperability issue)
    EdcaIdx=0;0;0;0
    APEdca0=1;3,7,1,1;4,4,3,2;10,10,4,3;0,0,94,47;0,0,0,0
    APAifsn=3;7;1;1
    APCwmin=4;4;3;2
    APCwmax=6;10;4;3
    APTxop=0;0;94;47
    APACM=0;0;0;0
    BSSAifsn=3;7;2;2
    BSSCwmin=4;4;3;2
    BSSCwmax=10;10;4;3
    BSSTxop=0;0;94;47
    BSSACM=0;0;0;0
    AckPolicy=0;0;0;0		# Ack policy на интерфейсах для QoS WMM - попробовал бы включить при профилировании перформанса
    NoForwarding=0;0;0;0
    NoForwardingBTNBSSID=1
    HideSSID=0;0;1;1
    ShortSlot=1
    AutoChannelSelect=0
    AutoChannelSkipList=
    ACSCheckTime=0
    IEEE8021X=0
    CSPeriod=10
    WirelessEvent=1
    PreAuth=0
    AuthMode=WPA2PSK;WPA2PSK;OPEN;OPEN
    EncrypType=AES;AES;NONE;NONE
    RekeyInterval=86400;86400;86400;86400
    RekeyMethod=TIME;TIME;TIME;TIME
    PMKCachePeriod=10
    WPAPSK1=-=secret=-
    WPAPSK2=-=secret=-
    WPAPSK3=
    WPAPSK4=
    DefaultKeyID=1;1;1;1
    Key1Type=0;0;0;0
    Key1Str1=0000000000
    Key1Str2=0000000000
    Key1Str3=0000000000
    Key1Str4=0000000000
    Key2Type=0;0;0;0
    Key2Str1=0000000000
    Key2Str2=0000000000
    Key2Str3=0000000000
    Key2Str4=0000000000
    Key3Type=0;0;0;0
    Key3Str1=0000000000
    Key3Str2=0000000000
    Key3Str3=0000000000
    Key3Str4=0000000000
    Key4Type=0;0;0;0
    Key4Str1=0000000000
    Key4Str2=0000000000
    Key4Str3=0000000000
    Key4Str4=0000000000
    HSCounter=0
    AccessPolicy0=0
    AccessPolicy1=0
    AccessPolicy2=0
    AccessPolicy3=0
    AccessControlList0=
    AccessControlList1=
    AccessControlList2=
    AccessControlList3=
    ApCliEnable=0
    ApCliWirelessMode=9
    ApCliSsid=
    ApCliBssid=
    ApCliWPAPSK=
    ApCliAuthMode=OPEN
    ApCliEncrypType=NONE
    ApCliDefaultKeyID=1
    ApCliKey1Type=0
    ApCliKey1Str=0000000000
    ApCliKey2Type=0
    ApCliKey2Str=0000000000
    ApCliKey3Type=0
    ApCliKey3Str=0000000000
    ApCliKey4Type=0
    ApCliKey4Str=0000000000
    WscManufacturer=ZyXEL
    WscModelName=Keenetic
    WscDeviceName=Keenetic Giga III
    WscVendorPinCode=32140781
    WdsEnable=0
    EAPifname=
    PreAuthifname=
    HT_HTC=1			# Собственно, прелесть 802.11n, надо включать
    HT_RDG=1			# Аналогично, надо пробовать
    HT_EXTCHA=0			# Расширенный 40 МГц вниз/вверх
    HT_LinkAdapt=1			# Круиз контроль 802.11n - пробуем
    HT_OpMode=1			# Зачем нам mixed и legacy, слишком всего лишнего (в другом посте выше)
    HT_MpduDensity=5		# Если в лоб, то я бы вообще 0 поставил, а так профилируем в сторону уменьшения интервала MPDU в A-MPDU
    HT_BW=1				# Поддержка наших 40 МГц
    HT_PROTECT=0			# Добавляем, по-умолчанию в 1, пробуем вырубить защитный механизм(?) сосуществования с Legacy (L-SIG TXOP Protection?)
    HT_TxStream=2			# Добавляем, у нас ведь 2 Spatial Streams, м.б. будет полезно STBC, зачем отдавать это драйверу :) но требует тестов
    HT_RxStream=2			# Добавляем, у нас ведь 2 Spatial Streams, м.б. будет полезно STBC, зачем отдавать это драйверу :) но требует тестов
    HT_BADecline=0			# Добавляем, по-умолчанию 0, но для тестов пробуем 1 при профилировании .. хотя по смыслу 0 - норм
    HT_AutoBA=1			# По идее по-умолчанию 1 - норм
    HT_AMSDU=1			# Однозначно надо пробовать эту аггрегацию если нормально работает с основным A-MPDU
    HT_BAWinSize=64			# Если работает как надо и соседи не зверствуют, то норм, а так пробовать уменьшать при диких ретрансмитах
    HT_GI=1				# SGI включен "из коробки", но из-за моментов выше, имхо, работает через раз .. а при поправках выше м.б. взлетит как надо
    HT_STBC=1			# Nice, хоть где-то согласен
    HT_MCS=32;32;32;32		# Я бы поставил принудельно высший MCS и 40 МГц онли через =32, а так вышка =15 с поддержкой 20 МГц
    HT_MIMOPSMode=3			# Добавляем, SM Power Save .. по-умолчанию 3 .. в манускрипте вроде ошибка с описанием - я бы попробовал с 0 или 1 в любом случае
    Ext_LNA=1			# Добавляем, у нас ведь eLNA, неизвестно, что по-умолчанию - поэтому пробуем
    Ext_PA=1			# Добавляем, у нас ведь ePA, неизвестно, что по-умолчанию - поэтому пробуем
    EnhanceMultiClient=0		# Добавляем, по-умолчанию 0, но выставляем в 1 при множестве N-клиентов, м.б. улучшит перформанс
    BGMultiClient=0			# Добавляем, по-умолчанию 0, цементируем, проверяем, чтобы так и оставалось
    EDCCAEnable=0			# В манускрипте по-умолчанию так и было .. так что неизвестно - включалось ли (у меня этой строчки нет, так что предполагаю дефолт как в общих случаях)
    TX_RETRY_NUM=3			# Добавляем, по-умолчанию вроде(?) 0 .. по идее кол-во попыток "мягкого" ретрансмита прежде чем у драйвера появится идея сбросить скорость .. в общем, надо пробовать
    RTS_RETRY_NUM=3			# Добавляем, аналогично, но надеемся, что RTS/CTS вообще не возникает в воздухе без необходимости
    EDCCA_AP_STA_TH=1
    EDCCA_AP_AP_TH=1
    EDCCA_AP_RSSI_TH=-80
    EDCCA_ED_TH=90
    EDCCA_FALSE_CCA_TH=180
    EDCCA_BLOCK_CHECK_TH=2
    IgmpSnEnable=1
    E2pAccessMode=2
    EfuseBufferMode=0
    SKUenable=0
    BandSteering=0
    PMFMFPC=0;0;0;0
    PMFMFPR=0;0;0;0
    PMFSHA256=0;0;0;0
    ApCliPMFMFPC=0
    ApCliPMFMFPR=0
    ApCliPMFSHA256=0
    VgaClamp=0

    через iwpriv set есть еще кое-какие вкусности .. непонятно, отразятся ли в .dat если ставить их как-то, чтобы в файле настройки хранить .. и пробовать подцеплять через ту же кнопку включения радио =)

    я за удобства, не понимаю почему мы без них. да и манускрипт старый, а новый не дают прикрываясь NDA .. нет чтобы давно весь список дать в настройки system и крутите как хотите с подсказками =)
    это как Sony с 4К по DLNA, годы идут, уже кивают про конкурентов с поддержкой из коробки, а самураям до фени, Сони ведь, с флешки можно? - значит, вам хватит - а за DLNA + 4К в следующем телике заплатите =)

     

  20. 22 минуты назад, AndreBA сказал:

    Скорее всего коэффициент усиления.

    Смущает "clamp" .. как бы не оказалось, что приглушения :)

    @gaaronk немного опыта: :)

    Скрытый текст
    5 часов назад, gaaronk сказал:

    compatibility N

    - с этим надо аккуратнее .. если клиент принимает весь набор предлагаемых настроек (по крайней мере, на моей fw), то легко убивает линки до 13/22 mbps (я даже, скорее всего, знаю почему, но упорно "это не те дроиды, которых вы ищите") .. м.б. конечно уже выправили .. если не сложно - при текущих настройках - какой у Вас вывод (без паролей):

    
    more temp:RT2860AP.dat

     .. а так, конечно, хотелось бы выбраться из нашего mixed:

    Скрытый текст

    cwap-ppdu-05.png

    HT-Mixed PPDU
    - Preamble contain the non-HT short & long training symbol that can be decoded by legacy 802.11a (clause 17) or 802.11g (clause 19)
    - Rest of the HT-mixed preamble & header cannot be decoded by legacy clients.
    - Tranmission can occur both 20MHz & 40MHz.
    - When 40MHz channel is used all broadcast traffic must be sent on legacy 20MHz (for legacy clients)

     

    5 часов назад, gaaronk сказал:

    preamble-short

    имхо, не для N и лишний повод для дров .. в общем, вместо OFDM больше шансов на сваливание в BPSK и QPSK (особенно заметно, когда сваливается в 13/26 mbps на 20 МГц и 27/54 на 40 МГц) .. поэтому в т.ч. ратую за GI строго 400 ns (0.4μs вместо в т.ч. 0.8μs) и вырубание Legacy в т.ч. через Basic Rates (на OFDM PLCP не повлияет, все будет норм) .. итд. итп.:

    Скрытый текст

    cwap-ppdu-04.png

    cwap-ppdu-02.png

    cwap-ppdu-03.png

    cwap-ppdu-06.png

     

    6 часов назад, gaaronk сказал:

    tx-burst

    - это в теории может конфликтовать с WMM на интерфейсе AP.

    6 часов назад, gaaronk сказал:

    rekey-interval 86400

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

     

  21. Т.е. формально на стабильном канальном 802.11ac 867 mbps с учетом беспроводной эффективности mac стремимся к .. 867*0.65*0.89/8 = ~62.7 MB/s .. ком. Tuxera вроде в kernel (который вроде еще предоставляет разраб, чтобы все было вылизано со стороны Tuxera по части Tuxera по совместимости и перформансу .. если я все правильно понял) и сама Tuxera грит, что они шикарны как слеза младенца, врут? =)

  22. Просто если взять PHY гигабитного линка, применить MAC CoP для провода на уровне средних ~94% и дополнительно наложить SMB CoP на уровне тех же средних ~89% .. то если нет bottleneck-ов будем в обе стороны на скорости ~104.6 MB/s.

    Смотрим бенчмарки:

    Скрытый текст

    g8.png
    g9.png

    ..  как бы 2.4/5 - фиолетово, думаешь: smb1, wifi, cpu, drivers, interrupts, latency, buffers итд.

    Потом вспоминаешь, что Tuxera .. смотришь коммерческий:
    http://www.tuxera.com/products/tuxera-ntfs-embedded/

    и http://www.tuxera.com/products/tuxera-smb/

    Чекаешь форум, 7 лет назад:

    Скрытый текст

    If we want to purchase your commercial solution, How many write thruput may it can reach?
    Our platform: MIPS 400MHz, 64KB Cache, 64MB RAM, USB 2.0 interface; Linux 2.6.21

    Write performance can be over 100 MB/s using eSATA or USB 3.0 with the commercial Tuxera NTFS. Performance is limited to maximum about 30 MB/s with the USB 2.0 protocol due to the USB 2.0 protocol design. If you want more speed then you need eSATA or USB 3.0.

    Т.е. по соточке сходимся .. но встречал репорты, что на USB2 под 40 выжимали и норм.

    И как-то все совсем запутывается.

  23. 14 часа назад, ydzhus сказал:

    Возможно, вся проблема в USB

    а какие скорости вообще удавалось выжимать на Кинетиках? .. просто лимиты на USB2 под 480 Mbps, а на USB3 под 5 Gbps .. до пределов двойки кто-нибудь доходил, чтобы на троечку пересаживаться?

×
×
  • Create New...