> 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
A.L.E.C pisze:
> jpk wrote:
>
>> Witam!
>>
>> Zainstalowałem sobie w/w wersję i bardzo szybko zrobiłem downgrade.
>> Myślałem, że jak są typy taryf to w zależności o wybranego typu będzie
>> inna treść na fakturze... a tu nic to samo !! Nawet nie wiem gdzie można
>> dodawać kolejne typy itd. (są na sztywno w kodzie programu wpisane) :((
>>
>
> no jak na razie to jest tylko tyle
>
>
Kiedy można się spodziewać większej funkcjonalności? Chodzi mi zwłaszcza
aby w zależności od typu było można ustawić inny wpis na fakturze a
byłoby super jakby dało się typy i te wpisy ustawiać poprzez UI...
--
pozdrowienia
jpk
----------
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
> to ja jeszcze dodam odnośnie typów, że nie są one jak na razie
> definiowalne, trzeba grzebać w kodzie (lib/defaults.php)
>
Definiowanie typów dokumentów bez grzebania w kodzie by się jednak przydało :_)
Dariusz Kowalczyk
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
On Thu, 3 Jan 2008 20:02:22 +0100, Tomasz Chiliński wrote
> On Thu, 3 Jan 2008 19:32:47 +0100, Mariusz Barczyk wrote
> > Witam
>
> Witaj.
>
> > Wystarczyla chwila googlowania. Zobaczcie sami:
> >
> > http://picasaweb.google.com/lh/photo/vxEEfRikWTDHn4VKZidGdQ
> >
> > To faktycznie troche wygorowana cena jak za to urzadzenie... Jednak
> > nie ma jak Cisco. ;) Choc nie wiem co oni tam do srodka klada.
>
> Chipy na kartach sieciowych nie mogą być już słabsze - Realtek ;-)
> Pewnie w tych wyższych modelach wkładają Intele desktopowe, a w najwyższych
> serwerowe ;-)
>
Sądzę że inny powód kierował projektantem urządzenia, jak to ja bym projektował sprzęt
który ma działać w realtime to też chciałbym chip z dobrą dokładna dokumentacją oraz też
wybrałbym procek z jak najmniejsza pamięcią cache żeby potrafić określić
czas "obrabiania" pakietu przez procek. Musicie myśleć jak projektant inżynier, a nie
jak rozkapryszony podniecony i rozczytany w reklamach komputerowych klient. W świecie
specjalizowanych rozwiązań stosuje się układy tylko o takich parametrach jakie potrzebne
są do realizacji założeń projektowanego urządzenia to chyba oczywiste, że producent nie
widzi sensu marnować kasy swojej a także klienta czyż nie? Komputerowa branża
konsumencka kieruje sie całkiem innymi wytycznymi tam im bardziej wypasiony sprzęt nawet
jak nie potrzebny taki to lepszy :_). Akurat rozmawiamy o Etherwerxie ale to się tyczy
każdego wąsko wyspecjalizowanego sprzętu. Skoro (a najwyraźniej tak jest) wystraczył
realtek i daje sobie radę to po co pakować coś droższego po to żeby uszczęśliwić klienta
który zerknie do środka ;_)? gdy tym sie kierowali producenci profesjonalnego sprzętu to
by Cisco robiło przezroczyste obudowy :_). Inna sprawa że zaglądający do wirtualnego
środka EWX-a na google woleliby ujrzeć tam (łącznie ze mną samym bo lubię ładnie
zaprojektowane od strony elektronicznej urządzenia) dedykowana zaprojektowaną płytę
głowną z układami o ktorych nie mieliby pojęcia do czego służą lub których nie można
kupić w sklepie :-) wtedy ich szacunek dla producenta byłby murowany ...a tak producent
niestety musi sie nasłuchać :_) i nie ważne jest dla większości to że udało mu sie
sklecić z uważanych za mierne elementów konkretne wyspecjalizowane urządzenie o bardzo
dobrych parametrach technicznych spełniających wszystkie założenia projektowe i odnieść
sukces ekonomiczny i uznanie firm z branży korzystających z tego urządzenia :_)
Otworzylibyście niegdysiejsze firewalle Cisco z serii Pix lub zaj.....drogie firewalle
Nokii to zobaczylibyście że w środku często był tam PII300-400Mhz lub pózniej P3 :_)
Sprzęt był więc warty maksymalnie 300-400USD a nie 5tys czy 10tyś dolarów a cisco i
Nokia sprzedały tego setki tysięcy egzemplarzy ;_)
Dariusz Kowalczyk
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
