🚀 go-pugleaf

>>>>> "Maciek" == Maciek Uhlig <muhlig@helios.cto.us.edu.pl>:
 Maciek> Jan Rychter (jwr@icm.edu.pl) wrote:
 >> Z pewnością jesteś dobrze poinformowany i masz podstawy, by tak
 >> twierdzić?

 Maciek> Z pewnoscia nie jestem dobrze poinformowany, gdyz dostepne
 Maciek> informacje o feedach sa w duzej mierze nieaktualne. Natomiast
 Maciek> istotnie, mam podstawy do tego co napisalem. Nie tak dawno
 Maciek> spotkalem sie z opinia czlowieka, ktorego zdanie sobie cenie,
 Maciek> ktory na pytanie "co zrobic, aby poprawic warunki lacznosci"
 Maciek> odpowiedzial "moze poprawic feedy Usenetowe". Poza tym mam
 Maciek> swoje wlasne obserwacje, o ktorych dalej.

Pozwolę sobie nie zgodzić się z Tobą.

 >> Tak wnioskuję, bo bardzo autorytatywnie wygłosiłeś właśnie poważny
 >> sąd. Teraz prosiłbym, byś poparł go argumentami i faktami.

 Maciek> Pierwsza uwaga dotyczy ICM. Podajecie na stronie usenetowej, ze
 Maciek> macie 24 feedy przychodzace (z czego 9 zagranicznych) i 39
 Maciek> feedow wychodzacych.  Wydaje mi sie, ze nie macie
 Maciek> kilkudziesieciu fizycznych lacz, a raczej kilka. Stad tez na
 Maciek> jedno lacze fizyczne przypada srednio okolo 10 feedow.
 Maciek> Przypuszczam, ze duza czesc pasma - w przypadku feedow
 Maciek> przychodzacych - wykorzystana jest na narzut protokolu w celu
 Maciek> odrzucania artykulow juz otrzymanych. W przypadku feedow
 Maciek> wychodzacych z pewnoscia wystepuje powielanie transmitowanych
 Maciek> informacji.

Akurat te informacje nie są już aktualne. Ale zróbmy pewne założenia i
policzmy. Załóżmy (kiepski) non-streaming feed. Jedna wymiana
IHAVE/odpowiedź to powiedzmy 40 bajtów (zaokrąglone w górę):

>>> ihave <oiasdj324$lsafd@blah.blah.com>
<<< 440 (albo inny kod numeryczny)

Pełen feed potrafi osiągać (cały czas zaokrąglamy w górę) około 400000
artykułów na dobę. Załóżmy że dostaję go z jednego serwera w całości, a
10 innych próbuje mi go upychać (całego!) [3] i nie udaje im się. Ile pasma
na to idzie? Policzmy:

40 bajtów * 400000 * 10 = 160000000 = 160MB

160MB = 1280000000 bitów
1280000000 / (24 * 3600) = 14814

ergo, mając 10 redundantnych pełnych feedów marnuję w sumie na
wszystkich swoich łączach 14kbps pasma [1].

 Maciek> Druga uwaga dotyczy ruchu newsow na podstawie zupelnie
 Maciek> przypadkowo wybranych artykulow:

Jak już nie raz pisałem [2]: "przypadkowo wybrane artykuły" nie wykazują 
NIC. Dopiero próbka statystyczna jest jakkolwiek znacząca. Jeśli chcesz, 
"zbadam" feedy w godzinach gdy większość serwerów wykonuje codzienne
czynności administracyjne (expire, itp) -- gwarantuję Ci, że będą
"kosmiczne" i będą szły najdziwniejszymi drogami. Pozostawię domyślnemu
czytelnikowi dopowiedzenie sobie dlaczego.

 Maciek> Path 1:
 Maciek> news.cto.us.edu.pl!news.nask.pl!news.man.lodz.pl!merkury.piotrkow.tpsa.pl!
 Maciek> orion.cst.tpsa.pl!news.icm.edu.pl!news-spur1.maxwell.syr.edu!..........

 Maciek> W tym przypadku mamy do czynienia z: ICM-TPSA-POL34-NASK-POL34
 Maciek> - tam i z powrotem POL34-NASK. Owszem, to ja biore z NASK, ale
 Maciek> efekt jest taki, ze lacze POL34-NASK jest podwojnie obciazone.

No właśnie -- to wyjaśniliśmy sobie jedno: masz niepotrzebny feed z
NASK. Nie odzwierciedla on żadnej topologii łącz i jest zupełnie
niepotrzebny. Na Twoim miejscu nie pisałbym tego, co piszesz, bez
uprzedniego skasowania takiego feedu.

 Maciek> Path 2:
 Maciek> news.cto.us.edu.pl!news.nask.pl!news.icm.edu.pl!news.man.poznan.pl!
 Maciek> news.man.lodz.pl!newsfeed1.telenordia.se!.........

 Maciek> Tutaj feed po pierwsze przychodzi (i pewnie wychodzi do, nie
 Maciek> jestem pewien) z telenordii, a wiec przez waziutkie lacze POL34
 Maciek> do swiata.  Pytanie - po co? Po drugie, podobnie jak
 Maciek> poprzednio: POL34-ICM-NASK-POL34

Drugie: ponownie, Twój niepotrzebny feed. Pierwsze: bo tak się zdarzyło, 
nie ma powodu żeby tędy coś nie przyszło.

 Maciek> Path 3:
 Maciek> news.cto.us.edu.pl!news.nask.pl!news.icm.edu.pl!news.task.gda.pl!
 Maciek> news.man.lodz.pl!news-fra1.dfn.de!..........

 Maciek> To pewnie nowy feed, do POL34 z Niemiec, ale w obrebie POL34 do
 Maciek> Gdanska i zaraz z powrotem do ICM-NASK i znow do POL34.

I znowu, Twój niepotrzebny feed zapycha wąskie łącze NASK-POL34. Po co,
skoro np. news.icm.edu.pl ma w tej chwili świetną łączność i z NASK i z
POL34 i feed stąd (a najlepiej z bliższego Tobie serwera POL34)
znakomicie by wystarczył?

 Maciek> Wiadomo, ze mamy waskie gardlo pomiedzy POL34 i
 Maciek> TPNET. Wypadaloby przeanalizowac sytuacje i doprowadzic do
 Maciek> minimalizacji ruchu na tym odcinku. Jednakze to mozna zrobic
 Maciek> jedynie z centralnej perspektywy, a o tym, jakie maja byc feedy
 Maciek> newsowe powinni decydowac admini sieci, ktorzy znaja warunki
 Maciek> techniczne na laczach fizycznych. Tymczasem teraz decyduja o
 Maciek> tym admini serwerow, a ci niekoniecznie maja pelne rozeznanie
 Maciek> sytuacji.

Niektórzy admini serwerów równocześnie zajmują się siecią, więc nie jest 
to ogólnie prawda. Co do minimalizacji ruchu -- myślę, że pierwszy krok
należy do Ciebie. Wszyscy czekamy aż nie będzie feedu NASK-polsl.

pozdrawiam,
--J.

[1] jak zawsze, proponuję się dobrze zastanowić i policzyć, zanim się
napisze "duża część pasma" i tym podobne rzeczy...
[2] i nie tylko ja
[3] rzadko kto organizuje sobie 10 pełnych feedów