Dotaz: aky pc na gateway???

[Jack]

Onedlho budem robit gateway pre LAN kde je 20 ludi. Cele to asi pobezi na clarkconnecte ale chcem sa opytat aky pocitac ma byt ten gateway. Staci pentium 233Mhz 128 Ram a disk nieco pod 2.5 GB? Odporucate mi tam dat debian alebo clarkconnect?

Odpovědi

[Pavel Jurcik]

POkud to bude jen gateway tak to bude v poho. Videl jsem i gw ze 486. Pokud na tom bude bezet NFS. popr. samba tak bude mozna malo mista na disku :). Ale to uz pak bude jina zalezitost. Jinak Clarkconnect neznam ale deb by stim nemel mit zadny problemy. Kazdopadne vsechno bude zaviset na sluzbach co spustis.

[Jack]

No, chcem tam vlastne spustit len maskaradu, transparentne proxy, smtp a cachujuci dns.

[vzk]

jedna sa o to kam to bude brana.. do inej siete? do internetu? DIAL UP? pevna lajna?.. aky prenos? zavisi to od vela veci... ak by to bola brana do netu cez dial up tak ti staci aj 386. keby to bola pevna lajna do netu uz budes potrebovat nieco rychlejsie.. takze s tou zostavickou to mozes buchnut kam len chces. a tiez je myslim uplne jedno ci tam nabuchas debian, alebo slackware... alebo MANDRAKE.. :)

[Jack]

pripojeni do internetu 512 Kb pre 20 ludi. takze aky stroj???????

[vzk]

Napriklad to pentium 233.. co mas k dispozicii

[Beda]

pokud je to pul megabajtu za vterinu, tak
mozna limitujici faktor bude transparetni http proxy a propustnost smerem k disku, pokud to je nejaka vykopavka disk, ktery neumi dma a sekvencni pristup ma nekde kolem (6Mb/s), tak asi ve spickach posle cely stroj nekam, pokud bude mit dost paralelnich spojeni a vetsina bude http provoz (mozna se ale mylim a tech 128Mib ram to bude stihat v narazovkach kompenzovat... ale v trvlejsich spickach uz asi bude ten disk poznat)
projevit by se to mohlo prilis velkym poctem vlken squidu, spolu s cekanim na diskovy i/o... s tim, ze nekdo poleze na netu jinam a bude cekat na odpoved dns a bude chvili trvat, nez se doprepinaji procesy/vlakna a dostane se na radu odpovidani dns dotazu (prvni zpozdeni), druhy bude u vytvareni http spojeni, nez se zase doprepina do toho kteryho vlkna squidu (druhy zpozdeni - handshake pri vytvoreni spojeni) a dalsi kolecko, nez se poslou data tam a zpet a mezi tim pripadne nacachuji (treti zpozdeni)
hadam, ze ve dvaceti kompech(lidech) i pokud se budou snazit je 5 vterin premrstena hodnota pro celkovy zpozdeni ale to je skutecne jen hadani z kristalove koule...
jestli disk umi dma, tak uz to muze brzdit asi jen pamet(swapovani), protoze bind si drzi pri behu celou cache v pameti a squid pro zmenu indexy a dalsi drobnosti... ale zase jen v pripade ze bude 20 uzivatelu i spousta vytizenych squidu... i kdyz spis nez swapovani bude monohem vetsi zpomaleni v dusledku prepinani kontextu(vyprazdneni TLB a procesorovych cache a front a vubec vseho co neovlivnite a je dusledek lacine x86 architektury) v celkovym souctu asi tak zpomleni pul na pul proti cekani na nacteni stranky z disku pri cache hit a cekani na volny diskovy i/o blokovany v dusledku swapovani nebo ukladani squidem do cache
jestli tam pobezi vytizeny mail server, tak bych asi jeste doporucil "nscd" nebo podobnou vec, ktera dela cache pro resolver v glibc, aby glibc resolver nemusel vyrabet dns dotazy a posilat je pres loopback bindu, tak sahne (skoro) primo do nscd cache. malinko to odlehci a urychli i kdyz neni vytizeny mail/news server... i kdyz o nesech se nic nepsalo a spammery snad tolerovat nebudete.