🚀 go-pugleaf

>: Bo zmniejszy�o si� obci��enie.
>
>Ten argument raczej odpada. Obci��enie generowane przez disklessy jest co
>prawda niepomijalne (ok. 4 MB na jeden boot), ale zdarza�o mi si�
>obci��a� serwer _znacznie_ mocniej.
>
>Mianowicie wymy�li�em sobie, �e potrzebuj� procedury zdalnej instalacji
>zawarto�ci dysk�w lokalnych na wszystkich komputer�w w laboratorium na
>podstawie zmian wprowadzonych na jednym - z tego jednego zgrywam image
>a potem na pozosta�ych ci�gn� image przez FTP, a potem go odpowiednio
>"customizuj�" - IP, itp.
>I zdarzy�o mi si� ju� kilka razy, �e 10 komputer�w ci�gn�o setki MB
>(ka�dy) i to wszystko z powodzeniem przechodzi�o przez kart�
>sieciow� na serwerze - ograniczeniem w tym momencie by�a raczej
>przepustowo�� samego Ethernetu.
To ja si� poddaj�. Chocia� musz� powiedzie�, �e nie tak dawno na padaj�cej
karcie (nomen omen, NE2000 ;-) NFS stawa�, a FTP chodzi�o ca�kiem przyzwoicie.
Mo�e mechanizm timeout�w jest inny? W ko�cu TCP mo�e kaza� sobie przes�a�
tylko brakuj�cy kawa�ek, a pakiety mog� przychodzi� nie po kolei.
Za��my, �e co 20 pakiet zdycha. Na NFSie nie ma ACK, zatem je�eli
odczyt jest �ci�le sekwencyjny, oznacza to, �e co 30 KB (przy MTU 1500)
mamy sekundowy przest�j. FTP radzi sobie z takimi sytuacjami du�o lepiej.
Trzeba zajrze� do dokumentacji protoko��w. W ka�dym razie po zmniejszeniu
timeoutu do chamskiego 0.4 s sytuacja nieco si� poprawi�a. Nie mog�em
jednak przesadza�, bo zala�bym serwer NFS nadmiarowymi ��daniami.
Krzysiek