Jump to content

µTorrent µTP


kokaracha

Recommended Posts

  • Отговори 67
  • Created
  • Последен отговор

Top Posters In This Topic

  • kokaracha

    18

  • Mile

    12

  • byte

    9

  • NetworkPro

    8

  • Администратор

Имах предвид на самите пппое концентратори или на бордера правиш филтъра.

Use since

OpenBSD 3.x

FreeBSD 4.x

Centos 5.x Debian 3.x Ubuntu 7.x

Аз съм фен на OpenWRT.

 

Горчивината от лошото качество остава дълго след като е преминало удоволствието от ниската цена.

_____________________________

___|____|____|____|____|____|__

_|____|____|____|____|____|____

___|____|_ Удряй _|____|____|__

_|____|___ главата ___|____|____

___|____|_ си тук!! |____|____|__

_|____|____|____|____|____|____

___|____|____|____|____|____|__

Адрес на коментара
Сподели в други сайтове

  • Администратор

Навред

а при теб колко пакета в сек. засичаш на този протокол ?

~150pps на всеки 100mbps в момента, след 16ч скачат.

Use since

OpenBSD 3.x

FreeBSD 4.x

Centos 5.x Debian 3.x Ubuntu 7.x

Аз съм фен на OpenWRT.

 

Горчивината от лошото качество остава дълго след като е преминало удоволствието от ниската цена.

_____________________________

___|____|____|____|____|____|__

_|____|____|____|____|____|____

___|____|_ Удряй _|____|____|__

_|____|___ главата ___|____|____

___|____|_ си тук!! |____|____|__

_|____|____|____|____|____|____

___|____|____|____|____|____|__

Адрес на коментара
Сподели в други сайтове

Графиките вървят към изваждане на пари... Пак ^^

Quad 9550, Broadcom 5721 .... 928 клиента в момента на него, 178 vlan, 500mbps трафик, 100к pps горе-доло, шейп

post-32-130900726042_thumb.jpg

Адрес на коментара
Сподели в други сайтове

  • Администратор

Графиките вървят към изваждане на пари... Пак ^^

Quad 9550, Broadcom 5721 .... 928 клиента в момента на него, 178 vlan, 500mbps трафик, 100к pps горе-доло, шейп

Раздели  си входящия и изходящия на 2 отделни макар и по слаби машини.

Use since

OpenBSD 3.x

FreeBSD 4.x

Centos 5.x Debian 3.x Ubuntu 7.x

Аз съм фен на OpenWRT.

 

Горчивината от лошото качество остава дълго след като е преминало удоволствието от ниската цена.

_____________________________

___|____|____|____|____|____|__

_|____|____|____|____|____|____

___|____|_ Удряй _|____|____|__

_|____|___ главата ___|____|____

___|____|_ си тук!! |____|____|__

_|____|____|____|____|____|____

___|____|____|____|____|____|__

Адрес на коментара
Сподели в други сайтове

Пашата обича смелите и дебелите ^^

Отдавна ми беше мерак за Supermicro x7sbi-ln4 за директна съпоставка с броадкомите и сега ще ги проверя.

Засега не ми се реже нищо все още въпреки, че е явно наложително вечер. Гледам руснаците и направо от l2 са почнали да го режат. Това не е ли по-разумния избор?

Личния ми тест мина много странно. Ако тегля от бг и пинга към пиърите е нормален пакетите са с нормална големина. Ако затегля от майната си и пинга е високичък започвам да трупам пакети 150-200 байта на кило. Стават и много и яхвам класическата "y = ex" и нема оправия. Тогава се сещам, че всичко се поправя... с пари :)

Адрес на коментара
Сподели в други сайтове

Чисто теоретично, ако се ползва napi/polling едва ли натоварването на µTP ще е голямо, т.к. няма да се извиква прекъсване при получаване на нов фрейм както е стандартно,

а ще минава kernel thread през определен интервал и взема съдържанието на RX buffera

Адрес на коментара
Сподели в други сайтове

А чисто практически pps дига ли се не го интересува ни мси, ни напи .. нищо. Затова и руснаците блокират още от d-linkovete дето са им любими по някаква причина negotion-a на uTP, което кара клиента да мине на tcp. Са кой е крив, кой прав само времето ще покаже. Всеки се бори по свой начин. Един познат преди години имаше култовия лаф "софтуерните недоразумения обикновено най-добре се решават с хардуерни излишъци".

Адрес на коментара
Сподели в други сайтове

Миле да вземем да ти направим един раздел: Лафове

страшен си ...

между другото защо моита кошница не разпредля по равно товара между различните цпу-та

cpuf.png

[pre]Linux mecho 2.6.28.10-imq-layer7-ipset #1 SMP Thu Nov 12 07:56:26 EET 2009 i686 GNU/Linux

          CPU0      CPU1      CPU2      CPU3

  0:        45          0          0          0  IO-APIC-edge      timer

  1:      1505          0          0          0  IO-APIC-edge      i8042

  8:          2          0          0          0  IO-APIC-edge      rtc0

  9:          0          0          0          0  IO-APIC-fasteoi  acpi

10:          0          0          0          0  IO-APIC-fasteoi  ohci_hcd:usb1

12:        114          0          0          0  IO-APIC-edge      i8042

14:        95          0          0          0  IO-APIC-edge      ide0

15:          0          0          0          0  IO-APIC-edge      ide1

29: 1730037855          0          0          0  IO-APIC-fasteoi  eth1

30: 2074818721          0          0          0  IO-APIC-fasteoi  eth0

31:  32329747          0          0          0  IO-APIC-fasteoi  cciss0

NMI:          0          0          0          0  Non-maskable interrupts

LOC: 3733184696  694463985  406275702  610731679  Local timer interrupts

RES:  15815851  24682526  19369132  21360732  Rescheduling interrupts

CAL:        425        735        757        798  Function call interrupts

TLB:    2931650    3014142    2863353    3792436  TLB shootdowns

TRM:          0          0          0          0  Thermal event interrupts

SPU:          0          0          0          0  Spurious interrupts

ERR:          0

MIS:          0

[/pre]

и имали смисъл да ровя smp_affinity та мрежовия трафик да се разпределя по равно между cpu-ta или само ще сбозясам машинката.

Адрес на коментара
Сподели в други сайтове

irqbalance.org възможно е вече да го вграждат като опция на кърнъла. Актуализирай кърнъла, може проблема да е решен по някакъв начин.

edit: мисля че по-бързо и стабилно решение ще е да си наместиш наистина affinity-то - IRQ-то на eth0 -> на cpu2 и IRQ-то на eth1 -> на cpu3 ... http://www.alexonlinux.com/smp-affinity-and-proper-interrupt-handling-in-linux

-

Адрес на коментара
Сподели в други сайтове

  • Администратор

Чисто теоретично, ако се ползва napi/polling едва ли натоварването на µTP ще е голямо, т.к. няма да се извиква прекъсване при получаване на нов фрейм както е стандартно,

а ще минава kernel thread през определен интервал и взема съдържанието на RX buffera

Така е наистина,polling-а сваля натоварването и прекъсванията но пък внася задръжки,което при много пакети пак не е добре.

Use since

OpenBSD 3.x

FreeBSD 4.x

Centos 5.x Debian 3.x Ubuntu 7.x

Аз съм фен на OpenWRT.

 

Горчивината от лошото качество остава дълго след като е преминало удоволствието от ниската цена.

_____________________________

___|____|____|____|____|____|__

_|____|____|____|____|____|____

___|____|_ Удряй _|____|____|__

_|____|___ главата ___|____|____

___|____|_ си тук!! |____|____|__

_|____|____|____|____|____|____

___|____|____|____|____|____|__

Адрес на коментара
Сподели в други сайтове

Относно CPU-тата най-добре сложи 'ff' на affinity-то, че да си ходи на ядрата (стига да е един процесор).

NAPI верно сваля натоварването на процесора, но пък латенцията отива в космоса

Адрес на коментара
Сподели в други сайтове

Създайте нов акаунт или се впишете, за да коментирате

За да коментирате, трябва да имате регистрация

Създайте акаунт

Присъединете се към нашата общност. Регистрацията става бързо!

Регистрация на нов акаунт

Вход

Имате акаунт? Впишете се оттук.

Вписване
  • Потребители разглеждащи страницата   0 потребители

    • No registered users viewing this page.

×
×
  • Създай нов...

Important Information

By using this site, you agree to our Terms of Use.