Freesco, NND, CDN, EOS

mam taki log w kernelu po restarcie nice :

Feb 4 01:02:03 router_nnd kernel: HTB init, kernel part version 3.17
Feb 4 02:07:32 router_nnd last message repeated 4 times
Feb 4 02:09:50 router_nnd last message repeated 2 times
Feb 4 02:16:24 router_nnd last message repeated 4 times
Feb 4 02:17:25 router_nnd last message repeated 2 times
Feb 4 02:24:27 router_nnd last message repeated 2 times
Feb 4 07:02:03 router_nnd last message repeated 2 times
Feb 4 09:02:02 router_nnd last message repeated 4 times
Feb 4 11:53:50 router_nnd last message repeated 4 times
Feb 4 14:55:46 router_nnd last message repeated 2 times
Feb 4 14:57:52 router_nnd last message repeated 4 times
Feb 4 17:07:12 router_nnd last message repeated 2 times
Czy ktoś wie o co chodzi?

Jakieś informacje na temat konfiguracji może podasz? Jakie NND, co zainstalowane itp...

_________________
Ludzie często, zamiast szukać prostych rozwiązań, komplikują sobie życie...

mysle że to nie ma związku bo wiem ze inni też mają taki log na całkiem innej konfiguracji ale napisze : kernel 32 nowe ip-route nowe ipp2p nowe iptables kolejkowanie imq wiec i nice leci w imq method .mam firewall czerwo najnowszy.ale wiem ze i bez imq ludzie mają taki log wiec myślę że to nie ma z tym związku.

i ty tak masz, i on tak ma, i jak tak mam
dopiszcie dalej

Glowy nie dam, ale to nie jest czasem poprostu informacja, ze zostalo uruchomione kolejkowanie htb?

niby nic sie nie sypie ale nie wiem co oznacza ten log wiec wolę zapytać i prosze sie nie nabijać panie MW....Nie jestem mocny w sprawach linuksa dlatego proszę o pomoc ...Martwi mnie również dlaczego użycie procesora tak u mnie szaleje po ręcznym restarcie nice?czy te dwie rzeczy mają coś ze sobą wspólnego?Jeżeli ktoś moze mnie oświecić to z góry dziękuję.

teraz wyłączyłem imq bo mnie już ta zabawa zaczęła wkur.. i po ustawieniu nice w method mark jest już zaje.... bo teraz mam już tak :-(


Feb 8 21:53:17 router_nnd kernel: HTB init, kernel part version 3.17
Feb 8 21:53:17 router_nnd kernel: HTB: quantum of class 10001 is big. Consider r2q change.
Feb 8 21:53:17 router_nnd kernel: HTB init, kernel part version 3.17


.Piszą ludzie że trzeba zmienić mtu ale jak to zrobić żeby ten log zniknął?

ja sie nie nabijam - a jesli urazilem to sorry.
mnie sie tez wydaje ze to sucha informacja o wlaczeniu o godzine X.

a co do tego:



dopiero zaczolbym sie martwic, gdyz podzial moze nie dzialac jak nalezy.
nice faktycznie wywala takie bledy, ja tez u siebie zauwazylem,
ma on kilka niedociagniec chociazby ograniczenia pasma routera do netu.
niby ma sie tyczyc danych pobieranych z routera a faktycznie obcina
ruch dla calej sieci ale tak jest przy squidzie, bez niego nie testowalem.

Znalazłem takie cuś :

It might be good time to touch concept of quantums now. In fact when more classes want to borrow bandwidth they are each given some number of bytes before serving other competing class. This number is called quantum. You should see that if several classes are competing for parent's bandwidth then they get it in proportion of their quantums. It is important to know that for precise operation quantums need to be as small as possible and larger than MTU.
Normaly you don't need to specify quantums manualy as HTB chooses precomputed values. It computes classe's quantum (when you add or change it) as its rate divided by r2q global parameter. Its default value is 10 and because typical MTU is 1500 the default is good for rates from 15 kBps (120 kbit). For smaller minimal rates specify r2q 1 when creating qdisc - it is good from 12 kbit which should be enough. If you will need you can specify quantum manualy when adding or changing the class. You can avoid warnings in log if precomputed value would be bad. When you specify quantum on command line the r2q is ignored for that class.

This might seem like a good solution if A and B were not different customers. However, if A is paying for 40kbps then he would probably prefer his unused WWW bandwidth to go to his own other service rather than to B. This requirement is represented in HTB by the class hierarchy.


Rozumiem że można quantum zmienić ręcznie i że powinno ono być większe od mtu i małe na ile to możliwe?Jak tego dokonać?Czy udało sie już komuś poprawić ten błąd?


MW przecież Ty umiesz bawić sie regułkami do quantum są przecież w Twoim skrypcie do IMQ .Nie możesz czegoś dopasować żeby to quantum pasowało dla nice w trybie mark?Jak miałem IMQ i poprawnie zrobiony config to nie było tego błędu w logach!

A czy ktoś może napisać co jest nie tak z restartem niceshapera?:

Przy każdym kolejnym restarcie komunikatów przybywa.

Znalazłem takie cuś :

It might be good time to touch concept of quantums now. In fact when more classes want to borrow bandwidth they are each given some number of bytes before serving other competing class. This number is called quantum. You should see that if several classes are competing for parent's bandwidth then they get it in proportion of their quantums. It is important to know that for precise operation quantums need to be as small as possible and larger than MTU.
Normaly you don't need to specify quantums manualy as HTB chooses precomputed values. It computes classe's quantum (when you add or change it) as its rate divided by r2q global parameter. Its default value is 10 and because typical MTU is 1500 the default is good for rates from 15 kBps (120 kbit). For smaller minimal rates specify r2q 1 when creating qdisc - it is good from 12 kbit which should be enough. If you will need you can specify quantum manualy when adding or changing the class. You can avoid warnings in log if precomputed value would be bad. When you specify quantum on command line the r2q is ignored for that class.

This might seem like a good solution if A and B were not different customers. However, if A is paying for 40kbps then he would probably prefer his unused WWW bandwidth to go to his own other service rather than to B. This requirement is represented in HTB by the class hierarchy.


Rozumiem że można quantum zmienić ręcznie i że powinno ono być większe od mtu i małe na ile to możliwe?Jak tego dokonać?Czy udało sie już komuś poprawić ten błąd?


MW przecież Ty umiesz bawić sie regułkami do quantum są przecież w Twoim skrypcie do IMQ .Nie możesz czegoś dopasować żeby to quantum pasowało dla nice w trybie mark?Jak miałem IMQ i poprawnie zrobiony config to nie było tego błędu w logach!


CZy należy sie przejmować dużym użyciem procka po ręcznym restarcie czy moze są to jakieś błędne wskazania mrtg?Bo przy takim układzie to trzeba by robić reboot po każdym restarcie nice??