Re: futuro w warszawie

W odpowiedzi na <news:da42nh$6lj$1@nemesis.news.tpi.pl> popełnione przez
zdzichu:
>
> Uzytkownik "Marek" <coiler@op.pl> napisal w wiadomosci
> news:da0jq3$ulf$1@opal.futuro.pl...
> > wer wrote:
> >>
> >> Nie zapycham. Jakbys popatrzyl na traceroute to bys widzial, ze
> > > problemy sie zaczynaja w core layer, a nie w access layer. Jak nie
> > > nie widzisz to nie pisz glupot.
> >
> > Widze i wiem ze w futuro tak jest. Icmp z routera na 1 hopie w futuro
> > omija kolejke, w ktorej ruch jest ciety, wiec skok czasu masz na
> > nastepnym hopie.
> > To nie sa glupoty, dopytaj ich jak nie wierzysz i zerknij na swoj
> > wykres ruchu
> > jesli go wogole robisz.
>
> nie znam topologii pro futuro ale gosc nie zapycha lacza
> do routera brzegowego swojego dostawcy dostaje sie w 38ms i nic do tego
> nie maja kolejki

Tak może się wydawać, ale na większości routerów Futuro jest akurat tak, jak
pisze Marek, a poniżej przykład z Lublina.

Łącze nieobciążone:
1 <10 ms <10 ms <10 ms 192.168.1.254
2 5 ms 4 ms 4 ms 62.233.195.157
3 11 ms 12 ms 11 ms 62.233.128.73
4 18 ms 12 ms 11 ms 62.233.128.69
5 * ^C

Łącze znacznie obciążone:
1 <10 ms <10 ms * 192.168.1.254
2 12 ms 13 ms 14 ms 62.233.195.157
3 648 ms 522 ms 614 ms 62.233.128.73
4 647 ms 625 ms 602 ms 62.233.128.69
5 * *

i w tym samym czasie jest to widziane z zewnątrz tak:

Sat Jul 2 17:59:49 2005
Hostname %Loss Rcv Snt Avg Worst
[...]
2. 62.233.128.3 0% 41 41 11 151
3. 62.233.128.70 0% 41 41 9 70
4. 62.233.128.78 0% 41 41 8 13
5. 62.233.195.158 0% 40 40 568 1213

> w momencie tego pomiaru problem pojawil sie na styku futuro-task

Gdyby tak było, czasy na 4. hopie (pierwszy traceroute) byłyby niskie.

-- 
Pozdrawiam, J. Maślanka