Użytkownik "Commercial Networks - Daniel Piekacz" <p...@c...com.pl> napisał w
wiadomości news:20020919110139.U31336-100000@cn.com.pl...
>
> On Thu, 19 Sep 2002, Marcin Scieslicki wrote:
>
> >
> > Użytkownik "Steven Jurczyk" <s...@p...pl> napisał w wiadomości
> > news:3d885e65$1@news.home.net.pl...
> > > > Też mam podobny wynik - max transfer na porcie ethernetowym routera
> > > > dostępowego 1850 kb/s (mierzone MRTG). Czyli pewnie tak ma być :-).
> > > Niestety
> > > > nie przez całą dobę (rano i w nocy to oczywiste - ludzie śpią albo
> > > pracują),
> > > > natomiast w godz. np. 16-18 transfer jest mniejszy, choć na 100%
> > > obciążenie
> > > > sieci jest duże.
> > >
> > > A czy pomysleliscie ze pod warstwa IP (dla ktorej robione sa
statystyki
> > > przez mrtg) sa jeszcze inne warstwy (Frame-Relay, hdlc), ktore czesc
pasma
> > > zabieraja dla siebie? Oraz o tym ze bardzo czesto modemy hdsl (nie
wiem
> > jak
> > > to wyglada w sdsl'ach) konfigurowane sa tak aby jeden z 32 slotow byl
> > > przeznaczony do zarzadzania - a wiec zjada na to 64 kbit/s...
> > >
> > > 1850 kbit/s dla lacza fr 2 mbit/s jest to wynik bardzo dobry...
Widzialem
> > > troche lepsze ale to wynikalo ze specyfiki lacza...
> >
> > To jest przykład z PVC do Polpak-T z CIR=0, i to ładnie widać zobacz, iż
> > pakiety DE=input pkts, co znaczy, że każdy pakiet na wejściu przekroczył
> > kontrakt ruchowy, ale to nie znaczy że router musiał zwolnić transmisję,
do
> > tego służą pakiety BECN i FECN a jak widać w tym konkretnym przypadku
było
> > ich niewiele (~0,016%) zatem jeżeli na tym łączy byłby niski transfer a
> > operator mówiłby o "zbyt małym, zerowym CIRze" to można mu udowodnić, iż
> > kłamie, lub że, ma źle skonfigurowaną sieć FR (nieprzekazywanie
informacji o
> > przeciążeniu) co może być powodem reklamacji.
> >
> >
>
> FECN (Forward Error Congestion Notification) - trafia do odbiorcy
> BECN (Backward Error Congestion Notification) - trafia do nadawcy
> (zwrotny)
>
> nadawca my(czyli odbiorca)
> ----> FECN
> A ----> dane B
> BECN <----
>
> U siebie policzyles BECN/IN*100% a to wg mnie
> jest bledne bo tyczy sie ruchu wychodzacego od ciebie.
> Powinno byc 5497239/265598301 =(ok)2,07% danych
> przychodzacych do ciebie jest opoznianych
> (odrzucanych) ze wzgledu na przeciazenie
> lacz czy portu.
>
>
> Inny przyklad z zycia wziety
> input pkts 1465732418 output pkts 1698626649 in bytes 2332319999
> out bytes 344400538 dropped pkts 0 in FECN pkts 104590259
> in BECN pkts 670 out FECN pkts 0 out BECN pkts 0
> in DE pkts 1465732418 out DE pkts 0
> out bcast pkts 0 out bcast bytes 0
> pvc create time 10w1d, last time pvc status changed 2w1d
>
> 5 minute input rate 1394000 bits/sec, 224 packets/sec
> 5 minute output rate 741000 bits/sec, 258 packets/sec
>
> Tu juz widac ze pakietow oznaczonych bitem FECN jest znacznie wiecej
> bo okolo 7,13%. Input rate na tym laczu od juz dluzszego czasu nie
> podskoczyl do 1790000 bits/sec.
>
> Kolejny przyklad inne lacze w tym samym miescie inny wezel POLPAK-T
> input pkts 525101135 output pkts 554889315 in bytes 422643597
> out bytes 423876741 dropped pkts 2 in FECN pkts 30227058
> in BECN pkts 6 out FECN pkts 0 out BECN pkts 0
> in DE pkts 525101135 out DE pkts 0
> out bcast pkts 0 out bcast bytes 0
> pvc create time 4w3d, last time pvc status changed 4w3d
> Tu wychodzi troche mniej ok 5,76%
>
> Jezeli sie myle to moze ktos mnie poprawi.
>
Ok, mój błąd źle zerknałem na wyniki ale to i tak nie zmienia sytuacji, że
tylko do 6% ruchu masz odrzucane ze zwględu na przeciążenie (rzecz jasna to
jest tylko statystycznie). Wartości chwilowe są inne a je możesz zobaczyć
sciągając dane odnośnie warstwy FR do mrtg i porównując z danymi odnośnie
ruchu IP.

Marcin

ps. Sprawdź sobie przy okazji liczniki błędów na warstwie fizycznej może się
okazać, iż z powodu złej miedzi masz za dużo błędów na routerze co też
spowoduje obniżenie sprawności łącza.