NetworkPro Публикувано 29 Декември, 2008 Доклад Сподели Публикувано 29 Декември, 2008 Благодарности на оригиналния автор Jesper Dangaard Brouer, Kernel developer etc. Моя e-mail до MikroTik support: <*********@gmail.com> wrote: > > > No no, My friend, please read the http://www.adsl-optimizer.dk/thesis/main_final_hyper.pdf What MikroTik dev team could do is thoroughly analyze the ADSL Optimizer and include it as technology in MikroTik RouterOS AS SOON AS PОSSIBLE. Since ADSL is so wide spread! Quotes from http://www.adsl-optimizer.dk/thesis/main_final_hyper.pdf: Fig 6.1 Naive overhead approach, queue control is achieved through reducing the rate to 450 Kbit/s. The queue control is lost when the traffic pattern changes. 6.3 Summary We have demonstrated the effect and magnitude of the ADSL link layer overhead. We show a naive approach for achieving queue control, where the bandwidth is simply reduced a fixed amount to compensate for the overhead. The bandwidth had to be reduced by 62% to handle the worst-case situation. Choosing only to handle an average case packet alignment overhead together with a maximum of 300 packets/s, would require a bandwidth reduction of 33%. The naive approach violates our goal of avoiding to waste link capacity. To achieve queue control, we modify the Linux Traffic Control system to perform accurate link layer overhead modeling. We demonstrate that our implementation is accurate and attains continuous queue control during all traffic patterns. Furthermore, the solution achieves our goal of avoiding unnecessary waste link capacity when achieving queue control Although, we achieve a satisfying average delay of 44 ms for our high-priority packets, we are not satisfied with the delay variance or delay jitter of 108 ms, as it exceeds the delay jitter requirement of the variation-sensitive service classes. The following chapter investigates the achievable delay bounds and delay variation for high-priority packets. > > Hello, I'm happy to inform you, that setup and behavior described in that thesis is possible with features that we already have in RouterOS: http://wiki.mikrotik.com/wiki/Packet_Flow http://wiki.mikrotik.com/wiki/Queue http://wiki.mikrotik.com/wiki/HTB http://wiki.mikrotik.com/wiki/PCQ http://wiki.mikrotik.com/wiki/Burst http://wiki.mikrotik.com/wiki/Queue_Size Regards, Janis Megis <*********@gmail.com> wrote: > I am happy to hear this. But how am I going to for example make a queue that compensates for ATM overhead and delay in an optimal way? This is not possible with the current implementation. What MikroTik dev team could do is simply ... make use of the technology to help optimize all customers' adsl links. Maybe a finished ROS implementation of ADSL optimizer could have an option on a Ethernet interface to set its queue to be ADSL optimized or you could add a default queue type that is ADSL optimized. Regards. > Hello, Thank you for your recommendations. Regards, Normunds http://www.adsl-optimizer.dk може да се изтегли готов пакет, а това e INSTALL.TXT от него: ~~ $Id: INSTALL.txt 1257 2008-05-12 20:20:21Z brouer $ ------------------------------------------ Installation of the ADSL-optimizer ------------------------------------------ Jesper Dangaard Brouer (hawk_AT_diku--dot--dk) ------------------------------------------ $Date: 2008-05-12 22:20:21 +0200 (Mon, 12 May 2008) $ $Revision: 1257 $ ------------------------------------------ Introduction: ~~~~~~~~~~~~~ The ADSL-optimizer is targeted towards optimizing ADSL lines, including calculating/accounting for the ATM overhead associated with ADSL lines. This file only describes the basic Install recipe. For configuration see the file: {{design/config.apt}} Requires: ~~~~~~~~~ The software package have the following requirements. (The module that the requirement applies to is specified in [] brackets.) * The "tc" program need at least version 2.6.25 [queues] * The kernel need to be at least version 2.6.24 [queues] * The "iptables" software package [filter] * The "RRDtool" software package including perl RRDs module [graph] For graph viewing, some RRDtool frontend is needed. Our graph module only collects "tc" data into RRDtool files. We highly recomment "drraw" and supply some example files for "drraw" (in directory "saved") (which is hardcoded to use files from \'/var/spool/rrdqueues\'). The example files also uses information about the physical interface, which is collected with the program package "rrdcollect" (files stored in \'/var/spool/rrdcollect\'). The latency graph depends on "smokeping", but you will need to adapt that to your specific setup. Install instructions step-by-step: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1.) Unpack the ADSL-optimizer in a directory, preferable: "/usr/local/ADSL-optimizer" (we will refer to this directory as "$BASEDIR") 2.) Copy the $BASEDIR/sample.conf file to /usr/local/etc/ADSL-optimizer.conf. (Modify the first line of ADSL-optimizer.conf if not installed in the default location "/usr/local/ADSL-optimizer") 3.) Copy $BASEDIR/filter/expansions.conf.sample to expansions.conf in the same directory. Modify "expansions.conf" for your setup, the files eg. contains the definition of your "LOCALNET" IP-range. Read the {{design/config.apt}} for modifying the filter setup. * Init scripts ~~~~~~~~~~~~~~ The init-scripts are located in $BASEDIR/init.d/. 4.) (/etc/init.d/ADSL-filter) Modify the init-script: "ADSL-filter.init". It specifies which filter <base-script> and <scheme-script> to use. ( See under: $BASEDIR/filter/base/ and scheme/ ) Your will need to specify upstream and downstream interfaces in the ".base" file. 5.) (/etc/init.d/ADSL-queues) Modify the init-script: "ADSL-queues.init". It specifies the following parameters: * INTERFACE, which is the upstream interface. * UPSTREAM, what is the upstream link speed. * DOWNSTREAM (optional), only used for ACK rate calc. * ACK_RATE (optional), not used if DOWNSTREAM specified. * SCRIPT, which queueing script to use. 6.) Install the init-scripts by hand or use the "install.sh" script in the $BASEDIR/init.d directory. * Other ~~~~~~~ 7.) Change the device variabel in the script "tc-collector.pl" (in $BASEDIR/graph). Detecting the correct devices is on the TO-DO list... - Адрес на коментара Сподели в други сайтове More sharing options...
¤ DJ69 ¤ (ツ) ¤ Отговорено 29 Декември, 2008 Доклад Сподели Отговорено 29 Декември, 2008 Преди време бях теглил подобни неща но малко ме разобедиха че неработили и така и не намерих време да тествам.Ако има вариант за МТ по бих се надъхал.Но и малко не ми е ясно на какъв принцип е основано.освен да филтрира дадени пакети и заявки ама нз Адрес на коментара Сподели в други сайтове More sharing options...
NetworkPro Отговорено 29 Декември, 2008 Автор Доклад Сподели Отговорено 29 Декември, 2008 Прочети PDFа, Датчанина е инвестирал 9+ месеца труд и е кърнъл дивелъпър но pdfа е написан достъпно. Който "не знае" да прочетe PDFа, да узнае, да тества и да поства Мерси. - Адрес на коментара Сподели в други сайтове More sharing options...
NetworkPro Отговорено 29 Декември, 2008 Автор Доклад Сподели Отговорено 29 Декември, 2008 За стабилна дистрибуция, върху която да опитам ADSL Optimizer избирам CentOS... - Адрес на коментара Сподели в други сайтове More sharing options...
Mile Отговорено 30 Декември, 2008 Доклад Сподели Отговорено 30 Декември, 2008 Аз нямам adsl, но мога да пробвам да го подкарам на slackware. Така и не свикнах с debian-a, който за тази цел е перфектен. Всякакви обновявания стават с apt-get доста безболезнено за разлика от slack ъпгрейдите Адрес на коментара Сподели в други сайтове More sharing options...
slevin Отговорено 18 Януари, 2009 Доклад Сподели Отговорено 18 Януари, 2009 Нека добавя и аз нещо, на което бях попаднал преди време. http://www.tldp.org/HOWTO/ADSL-Bandwidth-Management-HOWTO/implementation.html Адрес на коментара Сподели в други сайтове More sharing options...
NetworkPro Отговорено 20 Януари, 2009 Автор Доклад Сподели Отговорено 20 Януари, 2009 Да, изграждането на изходящ HTB решава част от проблема, и ADSL Optimizer-а хвърля светлина върху ATM отместването демек дори и на безшумна ADSL линия - променливия upload, породен от наместването на Ethernet, IP и т.н. върху досадните ATM клетки, които са с малък и фиксиран размер. Подкарването може да отнеме цял ден Ако има ентусиасти - нека да се покажат. Аз са сега отлагам. - Адрес на коментара Сподели в други сайтове More sharing options...
NetworkPro Отговорено 8 Март, 2010 Автор Доклад Сподели Отговорено 8 Март, 2010 В момента по-добро решение за оптимизиране на кофти ADSL (и всякакви) линии е това: http://www.cfos.de/speed/cfosspeed_e.htm http://www.cfos.de/speed/whatsnew.shtml Добавената функционалност звучи много респектиращо. Дали си засужава, например в офис, или някъде където се налага да се иползва ADSL, да се добави един Windows hop за оптимизирането? Бих тествал с удоволствие За сега отлагам. Ако някои има ADSL линия която му се налага да оптимизира, и Windows машина зад нея - да пише (и на ЛС) - ще съдействам за подкарването и тестовете. Поздрави. - Адрес на коментара Сподели в други сайтове More sharing options...
Recommended Posts
Създайте нов акаунт или се впишете, за да коментирате
За да коментирате, трябва да имате регистрация
Създайте акаунт
Присъединете се към нашата общност. Регистрацията става бързо!
Регистрация на нов акаунтВход
Имате акаунт? Впишете се оттук.
Вписване