Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Oprogramowanie / Software → CC/trunk i chyba dobre wieści
Zaloguj się lub zarejestruj by napisać odpowiedź
Deweloperzy chyba w końcu znaleźli przyczynę wąskiego gardła WAN->LAN
https://dev.openwrt.org/changeset/43587/trunk
Wieczorem potestuję i dam znać, no chyba że ktoś zrobi to wcześniej to prośba o info.
Jeśli to nie to, to cóż pozostanie pozostać przy AA 
EDIT: jest cacy
Gdzie to wystepowalo, jak sie objawialo ?? Uzywam trunka CC od miesiaca na MiniPC i transfery sa ok. Chyba ze dlatego iz mam modemy LTE podpiete
Gdzie to wystepowalo, jak sie objawialo ?? Uzywam trunka CC od miesiaca na MiniPC i transfery sa ok. Chyba ze dlatego iz mam modemy LTE podpiete
Problem dotyczy wydania BB, a ten backport nie rozwiązuje przyczyny problemu/ów tylko usprawnia/przyspiesza forwardowanie pakietów. W gruncie rzeczy... wątpię żeby przenieśli to też do BB (zupełnie inny kernel, wolą już tego nie dotykać i nie robić dodatkowych niespodzianek), a powoli szykują się już (tak można zrozumieć niektóre wypowiedzi developerów) chyba na wydanie CC (kernel 3.14), żeby ruszyć szybciej prace nad wsparciem w kernelu 3.18. No, chyba że zdecydują jednak zrobić CC na 3.18, ale wątpię.
Chyba nie, zostaną na 3.14.
Też mi się tak wydaje... i przyspieszą kolejne wydanie, będzie bez rewolucji, ale może będzie działać tak jak powinno, a nie jak BB. Martwię się tylko o jedno... Gargoyle 
Po tym jak im się BB udało niech lepiej na starym jaju siedzą.
Chyba nie, zostaną na 3.14.
Szkoda, swoją drogą słyszałem że OverlayFS znalazł się w jądrze 3.18, a w końcu od pewnego czasu to norma w openwrt.
Problem dotyczy wydania BB, a ten backport nie rozwiązuje przyczyny problemu/ów tylko usprawnia/przyspiesza forwardowanie pakietów. W gruncie rzeczy... wątpię żeby przenieśli to też do BB.
To jak z tą łatką ?
w CC problem nie występuje, tylko w BB,
skoro piszesz że do BB raczej nie wejdzie,
za to przyspiesza tylko w CC?
Łatka jest na trunk, czyli samodzielne przyłatanie jej do BB tylko przyspieszy a nie rozwiązuje problemu ?
pepe2k napisał/a:Problem dotyczy wydania BB, a ten backport nie rozwiązuje przyczyny problemu/ów tylko usprawnia/przyspiesza forwardowanie pakietów. W gruncie rzeczy... wątpię żeby przenieśli to też do BB.
To jak z tą łatką ?
w CC problem nie występuje, tylko w BB,
skoro piszesz że do BB raczej nie wejdzie,
za to przyspiesza tylko w CC?Łatka jest na trunk, czyli samodzielne przyłatanie jej do BB tylko przyspieszy a nie rozwiązuje problemu ?
Niektórym trzeba kilka razy napisać to samo, ale innymi słowami, żeby zrozumieli:
1. Łatka jest na trunka, nie na BB i na 100% nie przeniosą jej do BB (https://dev.openwrt.org/ticket/18516).
2. Problem wydajności występuje w BB, przyczyna nadal nie została wyjaśniona.
3. Łatka nie rozwiązuje problemu, dotyczy zupełnie czegoś innego. Poprawia coś, co słabo działa w BB, ale nie usuwa przyczyny.
Niektórym trzeba kilka razy napisać to samo, ale innymi słowami, żeby zrozumieli:
1. Łatka jest na trunka, nie na BB i na 100% nie przeniosą jej do BB (https://dev.openwrt.org/ticket/18516).
2. Problem wydajności występuje w BB, przyczyna nadal nie została wyjaśniona.
3. Łatka nie rozwiązuje problemu, dotyczy zupełnie czegoś innego. Poprawia coś, co słabo działa w BB, ale nie usuwa przyczyny.
Dzięki, za informacje.
Masz rację niektórym trzeba wytłumaczyć innymi słowami - często właśnie laikom.
Jednak wcale nie oznacza to że warto uszczypliwie ich traktować.
Pozdrawiam!
Czyli teraz panowie daliście mi trochę do myślenia - po raz pierwszy jak używam gargoyle pl, zastanawiam się czy przechodzić na to co tam Cezary w pocie czoła pichci - zapewne przy UPC 250/20 też będzie to odczuwalne... (?)
Ja również chętnie bym się dowiedział czym dokładnie objawia się ten problem, kiedy występuje, kogo dotyczy, a kogo nie.
Bo ja mam wgrane BB i nie widzę żadnych niepokojących objawów, wszystko śmiga co najmniej tak dobrze jak na Gargoyle, ale może o czymś nie wiem.
Ja również chętnie bym się dowiedział czym dokładnie objawia się ten problem, kiedy występuje, kogo dotyczy, a kogo nie.
Bo ja mam wgrane BB i nie widzę żadnych niepokojących objawów, wszystko śmiga co najmniej tak dobrze jak na Gargoyle, ale może o czymś nie wiem.
Tak, nie wiesz, bo pewnie masz łącze <= 200 Mbps, więc nie zauważasz różnicy.
Poczytaj sobie: https://forum.openwrt.org/viewtopic.php?id=51726
Pojawił się też backport dla BB, jak ktoś chce, to niech testuje:
https://raw.githubusercontent.com/gwlim … ache.patch
Backport działa jak najbardziej, ale już zostaje przy trunku.
Swoja droga, może Cezary dorzuci do swoich buildow...
Tak, nie wiesz, bo pewnie masz łącze <= 200 Mbps, więc nie zauważasz różnicy.
Poczytaj sobie: https://forum.openwrt.org/viewtopic.php?id=51726
Dokładnie tak, korzystam z 3G/4G. Teraz wszystko jasne, dzięki.
Zastanawiałem się skąd ja gościa znam. Pamiętałem go, bo on przeportował jeszcze jedną łatką od QCA: https://github.com/gwlim/mips74k-barrie … 82cdb91abf . Ta z kolei powodowała "płynniejsze" działanie systemu, też to było na forum openwrt.
(...)
Pojawił się też backport dla BB, jak ktoś chce, to niech testuje:
https://raw.githubusercontent.com/gwlim … ache.patch
Właśnie go zaaplikowałem (po drobnej korekcie) na ostatniej wersji BB (r43483), które specjalnie skompilowałem dla tego zadania.
Widać nieznaczną poprawę w szczytach DL, przy długotrwałym zasysaniu czegoś (dla testów zapodałem ze zdalnego serwera ftp zasysanie byczego *.m2ts, ok. 31 GB). Dodatkowo ustawiłem duże ramki w całej sieci i na wszystkich interfejsach (na wszystkich to działa). Ale chyba rozwiązaniem problemu ostatecznym to jednak nie jest.
Próbna kompilacja identycznego firmware bez tej łaty tylko nieznacznie gorzej (2-4 %) wypada przy identycznych warunkach transferu. Także na plus tej łaty jest jedynie podtrzymanie w dłuższym czasie raz osiągniętego maksimum w danym momencie.
Tak czy inaczej testuję dalej - ale chyba nie spodziewam się zauważyć jakichś większych zmian.
pepe2k napisał/a:(...)
Pojawił się też backport dla BB, jak ktoś chce, to niech testuje:
https://raw.githubusercontent.com/gwlim … ache.patchWłaśnie go zaaplikowałem (po drobnej korekcie) na ostatniej wersji BB (r43483), które specjalnie skompilowałem dla tego zadania.
Widać nieznaczną poprawę w szczytach DL, przy długotrwałym zasysaniu czegoś (dla testów zapodałem ze zdalnego serwera ftp zasysanie byczego *.m2ts, ok. 31 GB). Dodatkowo ustawiłem duże ramki w całej sieci i na wszystkich interfejsach (na wszystkich to działa). Ale chyba rozwiązaniem problemu ostatecznym to jednak nie jest.
Próbna kompilacja identycznego firmware bez tej łaty tylko nieznacznie gorzej (2-4 %) wypada przy identycznych warunkach transferu. Także na plus tej łaty jest jedynie podtrzymanie w dłuższym czasie raz osiągniętego maksimum w danym momencie.
Tak czy inaczej testuję dalej - ale chyba nie spodziewam się zauważyć jakichś większych zmian.
To chyba coś zepsułeś tą "drobną korektą" bo ja na iperfie (WDR3600) ze 170mbit wyszedłem na jakieś 280...
@g0f3r: podeślij mi swoją łatkę, wrzucę to do buildów, zawsze będzie to jakiś plus.
@g0f3r: podeślij mi swoją łatkę, wrzucę to do buildów, zawsze będzie to jakiś plus.
Nie ma "mojej" łatki, korzystam z backporta od alphasparc - tego, nad którym się zastanawiałeś skąd typa kojarzysz
https://raw.githubusercontent.com/gwlim … ache.patch
Na BB jak i buildzie CC z trunka ~280mbit, a 2 miesiące człowiek musiał siedzieć na AA.
"Devs closed tickets asking for official backport to BB, without explanation. I wonder if there are stability issues that they don't want to introduce to the release branch." to jest smutne
Ok, jak działa bezpośrednio to wrzucę.
@build000
CONFIG_NF_CONNTRACK_RTCACHE=y <-- masz to w konfigu?
Oczywiście, że tak - przecież bez tego i dalszej części kodu w odpowiednich *.h, i.t.d. nie byłoby tej funkcjonalności - drobna korekta dotyczyła jednej praktycznie 1 linii, która wprost nie pasowała i pociągała za sobą kilka kolejnych linii tworząc plik *.rej pliku config-3.10 (w wiadomym miejscu w target) - więc dokonałem tego ręcznie by pojawiły się stosowne linie, tzn.:
CONFIG_NF_CONNTRACK_RTCACHE=y
CONFIG_NF_DEFRAG_IPV4=y
CONFIG_NF_NAT=yCała reszta weszła sama, nie powodując żadnych błędów po patchowaniu.
EDIT:
Co ciekawe w linniach odnoszących się do "po" tych właściwych liniach, nie występuje w patchu np. linia
CONFIG_NF_NAT_IPV4=mktóra u mnie jest normalnie po wykonaniu make defconfig, zaraz po zassaniu źródeł i aktualizacji feedsów.
Być może w czymś się machnąłem, jednakże to bez większego znaczenia - dodanie tych linii ręcznie załatwia sprawę, gdyż moduł się kompiluje i jest dodawany do kodu jądra jako wbudowany.
Krótko mówiąc w patchu okazał się problematyczny jedynie ten fragment:
--- ./target/linux/generic/config-3.10 2014-12-09 23:39:16.603562133 +0800
+++ ./target/linux/generic/config-3.10 2014-12-09 23:38:56.184368996 +0800
@@ -2262,7 +2262,8 @@ CONFIG_NF_CONNTRACK_PROCFS=y
# CONFIG_NF_CT_PROTO_GRE is not set
# CONFIG_NF_CT_PROTO_SCTP is not set
# CONFIG_NF_CT_PROTO_UDPLITE is not set
-# CONFIG_NF_DEFRAG_IPV4 is not set
+CONFIG_NF_CONNTRACK_RTCACHE=y
+CONFIG_NF_DEFRAG_IPV4=y
CONFIG_NF_NAT=y
# CONFIG_NF_NAT_AMANDA is not set
# CONFIG_NF_NAT_FTP is not setOczywiście, że tak - przecież bez tego i dalszej części kodu w odpowiednich *.h, i.t.d. nie byłoby tej funkcjonalności - drobna korekta dotyczyła jednej praktycznie 1 linii, która wprost nie pasowała i pociągała za sobą kilka kolejnych linii tworząc plik *.rej pliku config-3.10 (w wiadomym miejscu w target) - więc dokonałem tego ręcznie by pojawiły się stosowne linie, tzn.:
CONFIG_NF_CONNTRACK_RTCACHE=y CONFIG_NF_DEFRAG_IPV4=y CONFIG_NF_NAT=yCała reszta weszła sama, nie powodując żadnych błędów po patchowaniu.
EDIT:
Co ciekawe w linia odnoszących się do "po" tych własciwych liniach, nie występuje w patchu np. liniaCONFIG_NF_NAT_IPV4=mktóra u mnie jest normalnie po wykonaniu make defconfig.
Być może w czymś się machnąłem jednakże to bez większego znaczenia - dodanie tych linii ręcznie załatwia sprawę, gdyż moduł się kompiluje i jest dodawany do kodu jądra jako wbudowany.
Nie wiem co jest, ale u mnie wąskim gardłem jest teraz upc...
Router już się nie poci
UPC w ogóle coś wałki kręci i tak podejżewam, że w sumie to nawet nie mam gdzie dobrze tego sprawdzić - od kilku dni jakaś degrengolada z transferem.
Zapodałem zasys 10 plików 1 GB z sugerowanego w BOK testowego ftp-a i procek w routerze się "spocił" zaledwie na 6-9 %, a transfer łączny osiągnął "zawrotną" prędkość...213 Mb/s...
Zaloguj się lub zarejestruj by napisać odpowiedź
eko.one.pl → Oprogramowanie / Software → CC/trunk i chyba dobre wieści
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc