Шейпинг, който да гарантира bandwidth за стриймовете #4

New Issue

2016-07-27T07:32:23+03:00

ignisf commented

2016-07-27 07:32:23 +03:00

(Migrated from github.com)

От миналата година https://github.com/OpenFest/openfest-2015-network/issues/42

ignisf commented

2016-08-25 10:55:48 +03:00

(Migrated from github.com)

https://wiki.openwrt.org/doc/howto/packet.scheduler/packet.scheduler.example4 ?

krokodilerian commented

2016-08-25 11:15:48 +03:00

(Migrated from github.com)

Не знам дали политически искаме да shape-ваме и дали ще постигнем нещо по-добро. Ще ни помогне в момента, в който някой точи torrent-и, иначе като цяло прави по-трудно да си напълним канала :)

zeridon commented

2016-08-25 11:39:54 +03:00

(Migrated from github.com)

В случая не виждам какво толкова политическо има. Необходим е гарантиран канал за да излезнат стриймовете навънка (2-4 стрийма по 1-3 мбита). Останалото да си е free-for-all. Евентуално приоритизация на дребен трафик (dns, icmp).

krokodilerian commented

2016-08-25 11:47:20 +03:00

(Migrated from github.com)

Ами ние изходящ трафик почти нямаме, изобщо не се притеснявам за stream-овете.

ignisf commented

2016-08-25 11:52:52 +03:00

(Migrated from github.com)

Почти не сме имали досега, you never know кога някой ще се шибне в някой суич и ще почне да прави мизерии. Докато го намерим стриймове ще няма =).

Освен това стриймовете ти са по TCP и ACK-овете от сървъра е редно да могат да стигат (и то навреме) дори някой да тегли яко.

Иначе замислите са два – едновременно да са приоритизирани „потоците“ на стриймовете над всичко останало (или да им се гарантира BW) И да се приложи scheduling политика, която да позволява използването на нета дори при запълнен ъплинк. Разпределянето на bandwidth-а поравно е вредно и не ни трябва. Трябва ни нещо да се грижи лейтънсито да е ниско за всички, ако се случи някой да е напълнил ъплинка. Мисля, че FQ CODEL се грижи за това. Further research needed.

Почти не сме имали _досега_, you never know кога някой ще се шибне в някой суич и ще почне да прави мизерии. Докато го намерим стриймове ще няма =). Освен това стриймовете ти са по TCP и ACK-овете от сървъра е редно да могат да стигат (и то навреме) дори някой да тегли яко. Иначе замислите са два – едновременно да са приоритизирани „потоците“ на стриймовете над всичко останало (или да им се гарантира BW) И да се приложи scheduling политика, която да позволява използването на нета дори при запълнен ъплинк. Разпределянето на bandwidth-а поравно е вредно и не ни трябва. Трябва ни нещо да се грижи лейтънсито да е ниско за всички, ако се случи някой да е напълнил ъплинка. Мисля, че FQ CODEL се грижи за това. Further research needed.

ignisf commented

2016-08-25 12:01:37 +03:00

(Migrated from github.com)

И допълнително можем да проиграем сценарии да проверим какво ще се случи без шейпинг и ако има нужда, да го правим.

krokodilerian commented

2016-08-25 13:02:29 +03:00

(Migrated from github.com)

Ами... явно ще разпъваме вече setup-а в лаба. Иначе, моите сблъсъци с linux-ките shaper-и не са от най-приятните и още нямам голяма вяра в тях, но определено може да симулираме.

👍 1

ignisf commented

2016-08-28 15:09:45 +03:00

(Migrated from github.com)

Затваряме засега

ignisf commented

2016-09-08 13:58:05 +03:00

(Migrated from github.com)

Отварям наново, защото според мен е редно поне да проучим ефекта от сетване на mq (tc-mqprio(8)) на eth0 и eth1 и fq_codel (tc-fq_codel(8)) по подразбиране. Мрежовите карти на eric поддържат multiqueue.

krokodilerian commented

2016-09-08 14:38:54 +03:00

(Migrated from github.com)

В момента се тества в лаба и ефектът е учудващо добър. Може да взема да си променя мнението :)

ignisf commented

2016-11-06 02:26:31 +02:00

(Migrated from github.com)

Така и не стигнахме до това

Sign in to join this conversation.