🚀 go-pugleaf

>>>>> "Jacek" == Jacek Grodzki <jacgro@venus.ci.uw.edu.pl>:
 Jacek> Kilka przykładów:
[...]
 Jacek> Czy to tylko takie wrażenie, czy tak powinno być?  

Jeśli pokażesz, że statystycznie znacząca liczba artykułów idzie tą
drogą, to faktycznie mamy problem.

Z tego co widzę, wygląda jednak na to że trafiłeś na przypadkowe parę
artykułów (np. gdy serwer news.uw.edu.pl robił expire), które z ICM
wcześniej poszły do USA niż do news.uw.edu.pl.

pozdrawiam,
--J.

Tue, 16 Mar 1999 23:31:20 +0100, Jacek Grodzki na pl.internet.polip napisał:
>Kilka przykładów:

>Czy to tylko takie wrażenie, czy tak powinno być?

generalnie isc nie powinno, ale czasem moze. (temat kiedys -- tak z
dwa lata temu -- walkowany przez Michala Jankowskiego na
pl.news.admin.). 
 
Swiadczy o pewnym zlym (technicznie, bo wgledy ,,polityczne'' 
moga byc wazniejsze) zaplanowaniu sposobu przekazywania newsow. 
Niepokojace zwlaszcza jesli w grupach pl. 

Z alt.sci.sociology niestety nic nadzwyczajnego. ;-(. 


-- 
Ziemek Borowski ZB137-RIPE http://faq-bot.ziembor.waw.pl/zmb/ 

Jacek Grodzki (jacgro@venus.ci.uw.edu.pl) wrote:
> Kilka przykładów:
> 
> Message-ID: <7cm9mk$ldk$1@sunsite.icm.edu.pl>
> Path:uw.edu.pl!newsgate.cistron.nl!het.net!news.maxwell.syr.edu!newshub.northeast.verio.net!hammer.uoregon.edu!news.icm.edu.pl!not-for-mail
> 
> Czy to tylko takie wrażenie, czy tak powinno być?

Uczeni admini newsow z pewnoscia odpowiedza, ze to jest prawidlowo, bo
system dobrze dziala. W koncu ten news trafil przeciez tam gdzie powinien.
Jednak ten post nalezy rozpatrywac w kontekscie innych dyskusji: dlaczego
lacza sa zatloczone i dlaczego Internet tak wolno dziala.  Ano dlatego, ze
feedy newsowe sa konfigurowane w duzej mierze bez ladu i skladu, a w
szczegolnosci bez uwzglednienia polityki routingu stosowanej przez tzw.
operatorow. 

-- 
Pozdrowienia,

Maciek

>>>>> "Maciek" == Maciek Uhlig <muhlig@helios.cto.us.edu.pl>:
 Maciek> Jacek Grodzki (jacgro@venus.ci.uw.edu.pl) wrote:
 >> Kilka przykładów:
 >> 
 Message-ID: <7cm9mk$ldk$1@sunsite.icm.edu.pl>
 Path: uw.edu.pl!newsgate.cistron.nl!het.net!news.maxwell.syr.edu!newshub.northeast.verio.net!hammer.uoregon.edu!news.icm.edu.pl!not-for-mail
 >>  Czy to tylko takie wrażenie, czy tak powinno być?

 Maciek> Uczeni admini newsow z pewnoscia odpowiedza, ze to jest
 Maciek> prawidlowo, bo system dobrze dziala. W koncu ten news trafil
 Maciek> przeciez tam gdzie powinien.  Jednak ten post nalezy
 Maciek> rozpatrywac w kontekscie innych dyskusji: dlaczego lacza sa
 Maciek> zatloczone i dlaczego Internet tak wolno dziala.  Ano dlatego,
 Maciek> ze feedy newsowe sa konfigurowane w duzej mierze bez ladu i
 Maciek> skladu, a w szczegolnosci bez uwzglednienia polityki routingu
 Maciek> stosowanej przez tzw.  operatorow.

Z pewnością jesteś dobrze poinformowany i masz podstawy, by tak
twierdzić?

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

--J.

Jacek Grodzki <jacgro@venus.ci.uw.edu.pl> wrote:
> Kilka przykładów:

> Message-ID: <7cm9mk$ldk$1@sunsite.icm.edu.pl>
> Path:uw.edu.pl!newsgate.cistron.nl!het.net!news.maxwell.syr.edu!newshub.northeast.verio.net!hammer.uoregon.edu!news.icm.edu.pl!not-for-mail

Oto Twój własny artykuł: ;))

Path: lt.wsisiz.edu.pl!wsisiz.edu.pl!news.icm.edu.pl!uw.edu.pl!not-for-mail
Message-ID: <36EEDBB8.184B25CE@venus.ci.uw.edu.pl>

Więc chyba w większości przypadków nie idzie...


-- 

                    _[   Łukasz Trąbiński   ]_                    
PgP Key: finger:lukasz@oceanic.wsisiz.edu.pl, SysAdmin @wsisiz.edu.pl

Jan Rychter (jwr@icm.edu.pl) wrote:

> Z pewnością jesteś dobrze poinformowany i masz podstawy, by tak
> twierdzić?

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

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

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

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

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

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

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

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

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

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

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

-- 
Pozdrowienia,

Maciek

Maciek Uhlig <muhlig@helios.cto.us.edu.pl> wrote:
> Druga uwaga dotyczy ruchu newsow na podstawie zupelnie przypadkowo 
> wybranych artykulow:

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

> W tym przypadku mamy do czynienia z: ICM-TPSA-POL34-NASK-POL34 - tam i z 
> powrotem POL34-NASK.
> Owszem, to ja biore z NASK,

Wlasnie. Mimo kilku porzadnych serwerow w sieci pol34, w ktorej
news.cto.us.edu.pl stoi juz od dawna.

> ale efekt jest taki, ze lacze POL34-NASK jest podwojnie obciazone.

niestety. Nie wiem jak inni, ale np. ja z tego co wiem, nie feeduje nic
do sieci NASK, a feed mam dobry. Nie pamietam, ale swego czasu jak
ruszylo pol34, to telepie mi sie po lbie, ze wysylalem maila o feed
pomiedzy zeusem a heliosem (a moze mi sie tylko tak wydaje?)

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

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

Kolejny raz: helios ma afaik jeden feed z maszyna pol34, drugi z
naskiem. O ile pierwszy rozumiem (rura jest duza), to drugiego
niezupelnie, bo w sieci pol34 sa juz dosc duze i stabilnie dzialajace
serwery...

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

No nie wiem. Ja staram sie byc na biezaco z topologia sieci,
przynajmniej jesli idzie o swoj kawalek.

-- 
-- Andrzej Bort                 bort<at>polsl.gliwice.pl, (032) 230-76-86, 
-- Centrum Komputerowe Politechniki Śl.,     44-100 Gliwice, Akademicka 16
-- ****** Moje prywatne opinie są tylko i wyłącznie moimi opiniami. ******
-- ** The office box said: W'95, NT 4.0 or better. So I installed Linux **

Andrzej Bort (bort@polsl.gliwice.pl) wrote:

> Kolejny raz: helios ma afaik jeden feed z maszyna pol34, drugi z
> naskiem. O ile pierwszy rozumiem (rura jest duza), to drugiego
> niezupelnie, bo w sieci pol34 sa juz dosc duze i stabilnie dzialajace
> serwery...
> 

Ja bym moze nie chcial, aby dyskusja skonczyla sie na heliosie u mnie, 
ale prosze:

System            Connects  Offered   Took Refuse Rejct Accpt   Elapsed
info.nask.pl           297   225209 191643  16658 16908   85% 232:31:33 
polonez.man.lodz.pl     51   151200  25629  82796 42775   16%  47:20:21

Mam przekonanie, ze NASK ma stabilny i jakby wczesniejszy feed - dlatego 
dotad biore z NASKu.

Pozdrowienia,
Maciek

Maciek Uhlig <muhlig@helios.cto.us.edu.pl> wrote:
> Andrzej Bort (bort@polsl.gliwice.pl) wrote:
>> Kolejny raz: helios ma afaik jeden feed z maszyna pol34, drugi z
>> naskiem. O ile pierwszy rozumiem (rura jest duza), to drugiego
>> niezupelnie, bo w sieci pol34 sa juz dosc duze i stabilnie dzialajace
>> serwery...
> System            Connects  Offered   Took Refuse Rejct Accpt   Elapsed
> info.nask.pl           297   225209 191643  16658 16908   85% 232:31:33 
> polonez.man.lodz.pl     51   151200  25629  82796 42775   16%  47:20:21

> Mam przekonanie, ze NASK ma stabilny i jakby wczesniejszy feed - dlatego 
> dotad biore z NASKu.

*ILE* wczesniejszy?
5 sekund? Minute? Godzine? Dobe?

-- 
-- Andrzej Bort                 bort<at>polsl.gliwice.pl, (032) 230-76-86, 
-- Centrum Komputerowe Politechniki Śl.,     44-100 Gliwice, Akademicka 16
-- ****** Moje prywatne opinie są tylko i wyłącznie moimi opiniami. ******
-- ** The office box said: W'95, NT 4.0 or better. So I installed Linux **

Maciek Uhlig <muhlig@helios.cto.us.edu.pl> wrote:
[----]
: Mam przekonanie, ze NASK ma stabilny i jakby wczesniejszy feed - dlatego 
: dotad biore z NASKu.
Innymi słowy, belki z własnego oka nie wyjąłeś. Chcesz optymalizować 
feedy pod kątem topologii routingu, ale własny wolisz mieć z dobrego 
źródla, a że to nieoptymalne z punktu widzenia topologii - trudno...?
No to nie dziw się, że 90% serwerów ma feed z sunsite.
-- 
Szymon Sokol (SS316-RIPE, SS4004) --  Network Manager                        B
Computer Center, University of Mining and Metallurgy, Cracow, Poland.        O
http://galaxy.uci.agh.edu.pl/~szymon/   PGP 2.x: 0x61094A7D, 5.x: 0xF9289982 F
Free speech includes the right not to listen, if not interested - RAHeinlein H

Maciek Uhlig <muhlig@helios.cto.us.edu.pl> wrote:
> Andrzej Bort (bort@polsl.gliwice.pl) wrote:

>> Kolejny raz: helios ma afaik jeden feed z maszyna pol34, drugi z
>> naskiem. O ile pierwszy rozumiem (rura jest duza), to drugiego
>> niezupelnie, bo w sieci pol34 sa juz dosc duze i stabilnie dzialajace
>> serwery...
>> 

> Ja bym moze nie chcial, aby dyskusja skonczyla sie na heliosie u mnie, 
> ale prosze:

> System            Connects  Offered   Took Refuse Rejct Accpt   Elapsed
> info.nask.pl           297   225209 191643  16658 16908   85% 232:31:33 
> polonez.man.lodz.pl     51   151200  25629  82796 42775   16%  47:20:21

> Mam przekonanie, ze NASK ma stabilny i jakby wczesniejszy feed - dlatego 
> dotad biore z NASKu.

Polonez IMO sie nie wyrabia. Jak chcesz, to moge Ci zestawic na dzien/dwa
feed ode mnie. Zobaczymy jak wtedy bedzie wykladala ta statystyka :-)


-- 
-ml

>>>>> "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

Jan Rychter wrote:

> 
>  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].
> 

bo problem nie wtedy, gdy jest kilka zagranicznych feedow do jednego
serwera, tylko gdy jest kilka feedow do roznych serwerow po tych samych
laczach. niestety ostatnio kazdy chce miec wlasny feed zagraniczny
(bo to zwieksza range serwera, prawda ?) i sciagane jest kilka razy 
to samo.

idealna wg mnie sytuacja bylaby wtedy gdyby, jeden duzy serwer mial
kilka feedow przychodzacych z zagranicy po roznych laczach (nask,
tpnet, pol-34) - wtedy nie sciagalby dwa razy tych samych artykulow.
oraz kilka innych serwerow z opoznionymi feedami 'backupowymi',
czyli w normalnej sytuacji pobieralyby artykuly z glownego serwera,
a w przypadku jego awarii samodzielnie.

wszyscy by na tym skorzystali.

--w

Jan Rychter <jwr@icm.edu.pl> wrote:
[chlast!]
> 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.

W kwestii formalnej: polsl[1] nie ma feedu z NASK. Ma go natomiast
US[2].

[1] polsl == news.polsl.gliwice.pl, admin: ja.
[2] US (Uniwersytet Śląski) == news.cto.us.edu.pl, admin: M.Uhlig.

Dziękuję za uwagę.

-- 
-- Andrzej Bort                 bort<at>polsl.gliwice.pl, (032) 230-76-86, 
-- Centrum Komputerowe Politechniki Śl.,     44-100 Gliwice, Akademicka 16
-- ****** Moje prywatne opinie są tylko i wyłącznie moimi opiniami. ******
-- ** The office box said: W'95, NT 4.0 or better. So I installed Linux **

Jan Rychter <jwr@icm.edu.pl> wrote:
[...]
>  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ł?
[...]

Tylko uzupelnie. Wystawielm Mackowi probnie feed po POL34. Nie uwazam, aby
to bylo logiczne rozwiazanie, ale jest to lepsze niz obecne. najlepiej
byloby zestawic feed pomiedzy polsl.gliwice.pl i cto.us.edu.pl.



-- 
-ml

Marcin Labuda <martin@task.gda.pl> wrote:
>> 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ł?
> Tylko uzupelnie. Wystawielm Mackowi probnie feed po POL34. Nie uwazam, aby
> to bylo logiczne rozwiazanie, ale jest to lepsze niz obecne. najlepiej
> byloby zestawic feed pomiedzy polsl.gliwice.pl i cto.us.edu.pl.

Jak najbardziej ZA. Myślę, że innxmit (bo taką metodą wypycham newsy)
wyrobi się. Nawet przy big8.

-- 
-- Andrzej Bort                 bort<at>polsl.gliwice.pl, (032) 230-76-86, 
-- Centrum Komputerowe Politechniki Śl.,     44-100 Gliwice, Akademicka 16
-- ****** Moje prywatne opinie są tylko i wyłącznie moimi opiniami. ******
-- ** The office box said: W'95, NT 4.0 or better. So I installed Linux **

Maciek Uhlig (muhlig@helios.cto.us.edu.pl) wrote on 17 Mar 1999 14:02:24 GMT:
MU> Ja bym moze nie chcial, aby dyskusja skonczyla sie na heliosie u mnie, 
MU> ale prosze:

MU> System            Connects  Offered   Took Refuse Rejct Accpt   Elapsed
MU> info.nask.pl           297   225209 191643  16658 16908   85% 232:31:33 
MU> polonez.man.lodz.pl     51   151200  25629  82796 42775   16%  47:20:21

MU> Mam przekonanie, ze NASK ma stabilny i jakby wczesniejszy feed - dlatego 
MU> dotad biore z NASKu.

Z powyższego wynika tyle, że info.nask.pl łączy się częściej, a przez
to ma szanse więcej wysłać.  Mniejsza liczba połączeń z poloneza jest
prawdopodobnie spowodowana tym, że w ciągu pojedynczego 10-minutowego
połączenia się nie wyrabia ze wszystkimi artykułami i dlatego trwa to
dłużej.  Ale to raczej z winy samego poloneza (jest to ogólnie znanym
faktem), a nie sieci po drodze.  Polonez ma być niedługo zmieniany na
szybszą i lepszą maszynę, więc problem powiniwn sam zniknąć.

Próbowałeś kiedyś oszacować o ile wcześniejszy jest feed naskowy?
5 minut?  10?  Wystarczy grep i /var/log/news/news{,.notice}.

-- 
 _________
(_   _' __) Tomasz R. Surmacz *-* Work:(071)3202636, tsurmacz@ict,pwr,wroc,pl
  |  (__  \ http://www.ict.pwr.wroc.pl/~tsurmacz/ *--* Home: ts @wroc,apk,net
  |__(____/ For PGP key finger tsurmacz@cyber.ict,pwr,wroc.pl *-* irc: TomekS

Jan Rychter wrote:
> 
> >>>>> "Jacek" == Jacek Grodzki <jacgro@venus.ci.uw.edu.pl>:
>  Jacek> Kilka przykładów:
> [...]
>  Jacek> Czy to tylko takie wrażenie, czy tak powinno być?
> 
> Jeśli pokażesz, że statystycznie znacząca liczba artykułów idzie tą
> drogą, to faktycznie mamy problem.
> 
> Z tego co widzę, wygląda jednak na to że trafiłeś na przypadkowe parę
> artykułów (np. gdy serwer news.uw.edu.pl robił expire), które z ICM
> wcześniej poszły do USA niż do news.uw.edu.pl.
> 

Mam u siebie na dysku 4243 artykuły z 21 polskich grup dyskusyjnych,
ściągnięte z news.uw.edu.pl, które zawierają w polu "Path:"
news.icm.edu.pl. 754 z nich ma w polu "Path:" zarówno news.icm.edu.pl,
jak newsgate.cistron.nl (wziąłem do testu cistrona, nie jakiś sewer
amerykański, bo i tak przez niego chyba przechodzi większość artykułów
z  różnych serwerów w USA do news.uw.edu.pl).
Nie mam pojęcia, czy to jest znaczące statystycznie.
Trzymam artykuły z ostatnich 21 dni. Wynik jest oczywiście
zniekształcony przez działanie moich filtrów (ale nie wrzucam go kf-u po
"Path:" ;-)).
-- 
Pozdrawiam, Jacek Grodzki        _/_/_/    _/_/   _/_/
mailto:jacgro@venus.ci.uw.edu.pl     _/  _/  _/ _/
mailto:jacgro@netscape.net          _/  _/_/_/ _/
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/  _/  _/   _/_/_/_/_/_/_/_/_/_/