Salut, Recent am rescris script-ul meu htb si bazandu-ma pe codul sursa de la mipclasses am facut marcaje pt web metropolitan/ counter-strike / etc / bulk traffic
apoi am bagat trafic-ul respectiv in clase am facut alte marcaje inainte de cele de metro (web /icmp / bulk ) care ar fi ramas doar cu traficul de pe extern in urma remarcarii traficului de metro(dupa ce am bagat cu tc filter metro in anumite clase...restul traficului ramas marcat anterior metro = extern web/icmp/bulk). Folosesc de asemenea esfq pe interfata interna cu hash dupa destinatie. Pe upload am facut la fel. Rezultatul: ma confrunt cu aceeasi problema pe care o aveam si am avut-o si cu script-urile de acum ceva vreme. Pentru traficul de tip bursty gen icmp, web sau pt cazurile cand in cadrul unui joc online rata se schimba si trebuie ca rate estimator-ul de la htb sa determine cat trebuie alocat in plus clasei respective ma confrunt cu un delay destul de mare. Pt icmp... daca dau un ping www.gooogle.com primesc reply-uri la 80-90ms ..si dupa 6 reply-uri la 80-90 ..primesc inca doua pe la 200-300ms apoi se revine la 80-90. Pt counter-strike la fel merge variat la anumite intervale de timp dar isi revine repede in normal. un tc -s -d class show dev eth1 si eth0 imi arata cum se imprumuta banda libera intre clase si nu am remarcat nici o problema aici. Am ratele specificate sub rata reala a conexiunii pe care o posed (un adsl de la pcnet). Am vreo sansa sa scap de prob asta ? Am inteles in trecut de pe lartc ca delay-ul si problema cu care ma confrunt pt traficul bursty este datorata algoritmului folosit de htb si ca n-as avea nici o sansa de mai bine. --- Detalii despre listele noastre de mail: http://www.lug.ro/
