On Thu, 03 Jan 2008 23:08:34 +0100, widynek wrote
> > Dariusz Kowalczyk
>
> Dzieki za wyczerpujaca odpowiedz :)
>
> Nie kumam tylko jednego - warstwa druga - czyli adresy fizyczne urzadzen...
> Czyli wszystkie urzadzenia, ktorych "predkoscia" zawiadujemy musza byc w tym
> samym segmencie sieci ?
>
> pozdrawiam,
> widynek
>
> _______________________________________________
> lms mailing list
> lms(a)lists.lms.org.pl
> http://lists.lms.org.pl/mailman/listinfo/lms
tak ale segmenty sieci mogą być podzielone na vlany dla których ewx jest przezroczysty,
nie będą sie więc urządzenia widzieć bezpośrednio pomiędzy vlanami inaczej jak przez
router który będzie zapewniał routing miedzy vlanami ale dla ewx-a będą widoczne jak by
były przyłączone do jednej sieci. aby uzyskać taka funkcjonalność wciskach go pomiedzy
swict z portem tagujacym ramki a router (np na linuxie) terminujacy vlany ewnetulanie
drugi switch z portem tagujacym ramki
Dariusz Kowalczyk
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
> To jest słaby sprzęt? ;-)
> Zobacz jakie CPU siedzą np. w juniperach.
> Prawdziwie sprzętowe rozwiązania mają wspomaganie realizowane przez
> układy ASIC.
Stosunkowo słaby, bo w środku pewnie zoptymalizwany *bsd pewnie z serii 4.11(licencja
bsd pozwala na ukrycie kodu i wypuszczenia pod swoja nazwą ) więc trochę musi dzwigać.
Zgadza sie prawdziwie sprzętowe rozwiązania mają ASIC (np switche) ale sam ASIC nie
załatwi komunikacji poprzez snmp logowania przez ssh itp bo zwyczajnie nie opłaca sie
robienie czegoś takiego na asicu bo byłoby zbyt kosztowne więc np switche L3 czy
zarządzalne maja osobne procki oprócz ASIC-a do takich rzeczy, ale jak sam napisałeś
linux ale i bsd umożlwia sterowanie kontrolą przepływu ramek L2 ale jakoś nie widzę
żeby ktoś rozdawał za darmo soft dla takiej funkcjonalności albo rozpisywał sie na
stronach jak coś takiego zrobić i np zintegrować z lms...goście zrobili więc gotowe
pudełko zarządzalne przez snmp lub konsole (do wyboru) do regulacji pakietów w L2 i
puścili do sprzedaży i nie ważne na czym to jest. Jest to gotowy do użycia prosty we
wdrożeniu w sieci produkt, i co ważne dla producenta bardzo tani w produkcji (na pewno
nie więcej niż 1000zł).. trzeba się więc cieszyć a nie narzekać ;-). Innym aspektem jest
ograniczenie regulowanych prędkości do 100Mbps/100Mbs (poprzez 10Mbps i 34Mbps w
konkretnych modelach) oraz nie mała cena oraz sposób licencjonowania ... może kiedyś
zdecydując sie sprzedawać taniej a więcej wtedy nikt nie będzie marudził i wyżywał na
linuxie bo nie bedzie mu sie ani chciało ani opłacało na razie się opłaca. Kupuje więc
ten kto ma kasę.\ i potrzebuje takiej funkcjonalności (np GTS ).
Ważne, że jest taki sprzęt, jest polska myśl techniczna i działa! Nie jest to takie hop
siup bo inaczej dlaczego nie maja w Polsce konkurencji.
ASICI są fajne ale jak sie robi sprzęt w setkach tysięcy egzemplarzy, dopiero wtedy się
opłacają w innym przypadku nie ma nic tańszego od nieprodukowanych już modeli procków i
płyt głównych zalegających magazyny a posiadający wystarczający zapas mocy do
realizacji konkretnego projektu.
Teraz za 50-80zl można kupić używany markowy komputer na Pentium2 który w rękach
odpowiedniego człowieka mógłby np sterować cała inteligentna chałupą z systemem
alarmowym i światełkami na choince oraz dostępem do internetu, firewallem i serwerem
plików włącznie lub satelita telekomunikacyjnym bo z odpowiednim oprogramowaniem ma aż
nadto zapas mocy do takich spraw ale kogo to obchodzi, przecież komputer jest już stary
brzydki zużywa dużo prądu ...:-) liczą sie tylko nowości. Świat jest dziwny :-). W
szafie mam P2 400Mhz na którym kiedyś miksowalem 32 slady audio z efektami na każdym
śladzie oraz projektując na Protelu czy Orcadzie a teraz ten procek jest mniej wart
niż kilogram zielonych jabłek i nikt go już nie chce używać a przecież nie utracił
przydatności do użycia ;_) bo działa...ba nawet nie potrzebował wiatraka tylko duży
radiator, wniosek procek i urządzenie zbudowane na nim jest warte tyle ile
funkcjonalności softu nie inaczej.
Dariusz Kowalczyk
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
03-01-08, widynek <widynek(a)o2.pl> napisał(a):
> Nie kumam tylko jednego - warstwa druga - czyli adresy fizyczne urzadzen... Czyli wszystkie urzadzenia, ktorych "predkoscia" zawiadujemy musza byc w tym samym segmencie sieci ?
[...]
Nie
--
Wojciech Ziniewicz
Unix SEX :{look;gawk;find;sed;talk;grep;touch;finger;find;fl
ex;unzip;head;tail; mount;workbone;fsck;yes;gasp;fsck;more;yes;yes;eje
ct;umount;makeclean; zip;split;done;exit:xargs!!;)}
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
> Dariusz Kowalczyk
Dzieki za wyczerpujaca odpowiedz :)
Nie kumam tylko jednego - warstwa druga - czyli adresy fizyczne urzadzen... Czyli wszystkie urzadzenia, ktorych "predkoscia" zawiadujemy musza byc w tym samym segmencie sieci ?
pozdrawiam,
widynek
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
On Thu, 3 Jan 2008 22:18:48 +0100, Dariusz Kowalczyk wrote
> nie wdajać sie w rozważanie na modelem osi/iso warstwa druga to w
> naszym przypadku pakiety ethernet, urządzenia pracujace w tej
> warstwie (np switche) nie obchodzą portokoły warstw wyższych.
> Dlatego analizowanie pakietów ethernet nie potrzebuje wydajnych
> procków z duzymi pamieciami cache, wielopotokowymi itd z
> rozbudowanymi algorytmiami predykcji (przewidywania instrukcji)
> jakie sa bardzo porządane w desktopach czy serwerach, a mimo to
> zapewnia bardzo precyzyjne z dokładnościa do ramek ethernet
> sterowanie i regulacje pakietów wnosząc minimalnie(nieporównanie
> bardziej niż wnoszone przez regulator w warstwie trzeciej)
> stosunkowo łatwe do okreslenia opóznienia pakietów.
Wszędzie powinieneś używać słowa ramka, ramki, ramek, etc.
> Stąd nie należy się dziwic ze tak "słaby" sprzęt i 128Mb ramu
> wystarczy EWX-owi regulowac pasmo dla paru tysiecy klientów wnosząc
> opóznienia żedu 0.1ms itd itp. Ja sie spodziewałem znaleźć tam
> słabsze procki np Intela Xscale bo tez dałyby sobie radę z regulacją
> w warstwie 2, albo dedykowane procki Texas Instrument (niestety za
> drogie :-) bo trzeba zrobic własnego boarda, jeśli nie tłucze sie w
> setkach tysiecy egzemplarzy) Standardowo linux reguluje pasmo w
> warstwie trzeciej (analizuje adresy ip urzadzenia) i potrzebuje
> nieporównanie potężniejszych procków oraz znacznie wiekszej ilości
> pamieci ram żeby zrobić "to samo" mowa tu o regulacji predkości i
> gwarantowania przepływi danych dla np 1000 czy 5000 urządzeń, trudno
> przez to uzyskac tak małe opóznienia pakietów oraz zagwarantowanie
> ich czasu pojawiania się. Czyli zagwarantowanie prezycyjnego
> sterowania i trzymanie sie założónych parametrów, jest to bardzo
> trudne bo procek musi analizowac znacznie większe porcje danych.
To jest słaby sprzęt? ;-)
Zobacz jakie CPU siedzą np. w juniperach.
Prawdziwie sprzętowe rozwiązania mają wspomaganie realizowane przez
układy ASIC.
> Regulacja prędkości w warstwie trzeciej nie jest tez przezroczysta
> dla sieci i nie da sie jej ot tak wprowadzić w dowolnym czasie
> trzeba ją zaplanować. Dlatego z reguły stawia sie router na linuxie
> ktory jednoczesnie zajmuje sie regulacja prędkości i robi sie to na
> etapie projektowanie sieci. Regulator prędkości w warstwie drugiej
> można wstawić ot tak kiedy sie chce bez zmieniania konfguracji ip i
> nikt nie zauważy że itnieje (zostanie potraktowany jak switch),
> można mu nawet wyłaczyc ip i zarządzać przez port rs232 przez to
> niemożliwe bedzie skomunikowanie sie z urządzeniem po ip i nie
> zaburzy to jego funkcjonowania.
Można dokładnie to co piszesz zrobić na jądrze linuksowym.
Sądzisz, że Etherwerx cały soft od zera napisał?
Co mi z opóźnienia 0,1ms? 1ms nie jest odczuwalna, a znacznie niższą
od 1ms uzyskuje się na porządnie sprofilowanym jądrze linuksowym.
Spójrz jeszcze na to jakie oni obsługują maksymalne przepływności.
> Dariusz Kowalczyk
Pozdrawiam, Tomek.
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
Ajjjj przepraszam, ortograf tam poszedł brzydki ąż się zarumieniłem ze wstydu czytając
swój post, pisze się rzędu a nie żędu ...nie jestem dyslektykiem ale czasem piszę
machinalnie takie kwiatki podobnie jak często zamieniam u na y, mimo, iż znam poprawną
pisownię :-).
Dariusz Kowalczyk
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
On Thu, 03 Jan 2008 21:28:18 +0100, widynek wrote
> > człowieka. Poza tym Linux nie robi zarządzania prędkością w warstwie drugiej jak
> > etherwerx a zarządzanie w warstwie drugiej prędkościami to całkiem inna jakość bo i
> > sposób zarządzania prędkością w warstwie drugiej daje operatorowi całkowicie inne
> > możliwości i efekty jakościowe (np gwarantowane i zdeterminowane opóźnienie
pakietów
> > przy przejściu przez urządzenie o co bardzo trudno w linuxie lub jakimkolwiek
> > niewyspecjalizowanym systemie operacyjnym )
>
> Co masz na mysli piszac zarzadzanie predkoscia w warstwie drugiej ? Co do
> opoznien - czy algorytm HFSC w (krzywa "real-time") w linuxie/bsd nie spelnia
> tego postulatu?
>
> Moje pytania nie sa ironiczne, pytam, bo nie do konca rozumiem (nie mialem
> stycznosci z Etherwerxem poza tym, ze raz go ogladalem podczas pracy w pewnej
> serwerowni)
>
> pozdrawiam,
> widynek
>
> _______________________________________________
> lms mailing list
> lms(a)lists.lms.org.pl
> http://lists.lms.org.pl/mailman/listinfo/lms
nie wdajać sie w rozważanie na modelem osi/iso warstwa druga to w naszym przypadku
pakiety ethernet, urządzenia pracujace w tej warstwie (np switche) nie obchodzą
portokoły warstw wyższych. Dlatego analizowanie pakietów ethernet nie potrzebuje
wydajnych procków z duzymi pamieciami cache, wielopotokowymi itd z rozbudowanymi
algorytmiami predykcji (przewidywania instrukcji) jakie sa bardzo porządane w
desktopach czy serwerach, a mimo to zapewnia bardzo precyzyjne z dokładnościa do ramek
ethernet sterowanie i regulacje pakietów wnosząc minimalnie(nieporównanie bardziej niż
wnoszone przez regulator w warstwie trzeciej) stosunkowo łatwe do okreslenia
opóznienia pakietów.
Stąd nie należy się dziwic ze tak "słaby" sprzęt i 128Mb ramu wystarczy EWX-owi
regulowac pasmo dla paru tysiecy klientów wnosząc opóznienia żedu 0.1ms itd itp. Ja
sie spodziewałem znaleźć tam słabsze procki np Intela Xscale bo tez dałyby sobie radę
z regulacją w warstwie 2, albo dedykowane procki Texas Instrument (niestety za
drogie :-) bo trzeba zrobic własnego boarda, jeśli nie tłucze sie w setkach tysiecy
egzemplarzy)
Standardowo linux reguluje pasmo w warstwie trzeciej (analizuje adresy ip urzadzenia)
i potrzebuje nieporównanie potężniejszych procków oraz znacznie wiekszej ilości
pamieci ram żeby zrobić "to samo" mowa tu o regulacji predkości i gwarantowania
przepływi danych dla np 1000 czy 5000 urządzeń, trudno przez to uzyskac tak małe
opóznienia pakietów oraz zagwarantowanie ich czasu pojawiania się. Czyli
zagwarantowanie prezycyjnego sterowania i trzymanie sie założónych parametrów, jest to
bardzo trudne bo procek musi analizowac znacznie większe porcje danych.
Regulacja prędkości w warstwie trzeciej nie jest tez przezroczysta dla sieci i nie da
sie jej ot tak wprowadzić w dowolnym czasie trzeba ją zaplanować. Dlatego z reguły
stawia sie router na linuxie ktory jednoczesnie zajmuje sie regulacja prędkości i robi
sie to na etapie projektowanie sieci. Regulator prędkości w warstwie drugiej można
wstawić ot tak kiedy sie chce bez zmieniania konfguracji ip i nikt nie zauważy że
itnieje (zostanie potraktowany jak switch), można mu nawet wyłaczyc ip i zarządzać
przez port rs232 przez to niemożliwe bedzie skomunikowanie sie z urządzeniem po ip i
nie zaburzy to jego funkcjonowania.
Dariusz Kowalczyk
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
> człowieka. Poza tym Linux nie robi zarządzania prędkością w warstwie drugiej jak
> etherwerx a zarządzanie w warstwie drugiej prędkościami to całkiem inna jakość bo i
> sposób zarządzania prędkością w warstwie drugiej daje operatorowi całkowicie inne
> możliwości i efekty jakościowe (np gwarantowane i zdeterminowane opóźnienie pakietów
> przy przejściu przez urządzenie o co bardzo trudno w linuxie lub jakimkolwiek
> niewyspecjalizowanym systemie operacyjnym )
Co masz na mysli piszac zarzadzanie predkoscia w warstwie drugiej ? Co do opoznien - czy algorytm HFSC w (krzywa "real-time") w linuxie/bsd nie spelnia tego postulatu?
Moje pytania nie sa ironiczne, pytam, bo nie do konca rozumiem (nie mialem stycznosci z Etherwerxem poza tym, ze raz go ogladalem podczas pracy w pewnej serwerowni)
pozdrawiam,
widynek
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
> Definiowanie typów dokumentów bez grzebania w kodzie by się jednak przydało :_)
>
> Dariusz Kowalczyk
>
Z czystej ciekawosci - jakich typow wam brakuje ? Bo ja poki co (tj. odkad mam 1.9.8 - od 2 dni chyba) uzylem tylko "umowa" oraz "zalacznik". Znalezliscie jakies konkretne rozwiazanie?
pozdrawiam,
widynek
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
