|
Hi Rossano, > I am so sorry. I Accidentally deleted the message reply for the question > forward. Please return that mail for me.... No problem, also I send you (and mail list) a short description that can be very helpful. (from http://drbl.sourceforge.net/faq/) and more. What's the difference between DRBL and LTSP ? * DRBL (Diskless Remote Boot in Linux). http://drbl.sourceforge.net/ * LTSP (Linux Terminal Server Project). http://www.ltsp.org/ DRBL uses PXE or etherboot to let the client machine boot, which is similar to LTSP (Linux Terminal Server Project). While LTSP is a centralized server, all the users from the client machines access the LTSP server to run their applications on the LTSP server. You use the client's keyboard and mouse to input, and the client's monitor to display the results. This is great when you use a thin client. You have to increase the server requirements when you have more than 20 or 30 clients. On the other hand, DRBL uses NFS and NIS to provide boot services to the client machines, so DRBL server is just a NFS and NIS server. All the users from all the client machines just access the DRBL server to request files or authentication. Packages are loaded to the client machines and use their own CPU and RAM for processing. Therefore, you can use a common PC as the DRBL server, since it's only doing file and authentication serving. The client machines, however, should be powerful enough to run the applications they need. Our typical installations using DRBL to deploy the Linux classroom have around 30 to 40 clients. Both LTSP and DRBL have their own roles, you can choose what you want depending on your situation. PXE (Preboot eXecution Environment) Appendix D - PXE (http://autocluster.wustl.edu/) PXE or the Preboot eXecution Environment was Intel's answer to the problem of the computer starting in real mode and only being able to access 640k of system memory. An older way to boot a computer over a LAN was with a program called tftp (trivial file transfer protocol) and BOOTP (boot protocol). The problem is that receiving end of tftp runs in real mode and so can only download an image that is at most the remainder of 640k after tftp loads itself. At first, I tried to get an image below this critical value (it turned out to be about 512k) but I met with disaster. openMosix requires a /proc filesystem as do many modern day GNU/Linux features. The only way to get a functional image below the 512k barrier was to eliminate the /proc filesystem, which adds about 70k to the kernel image. It would boot, but wouldn't really do anything else after that. The answer was to use PXE. PXE solves the memory problem by using BOOTP and tftp to load a tiny part of itself that puts the computer into protected mode. Once in protected mode, the tftp has access to all of the systems memory. It then continues loading the rest of itself and whatever image data. The original PXE that I used was an undocumented Intel PXE server and PXE loader. I hunted down "the" PXE specification from some obscure Russian server and divined configuration options after a few hours and got it to work. Then I discovered the SYSLINUX (link) project. They didn't have a PXE server, but they had a MUCH better and well documented, not to mention open source, PXE bootloader. As of RedHat 9, there is an included functional PXE server. If your distribution of choice doesn't seem to have one, use rpmfind.net to locate the most recent source code for the server and build and install it. The first task that you must perform after installing DRBL (better with PXE) is test ervery client with a simple benchmark, for example with lmbench. http://packages.debian.org/unstable/admin/lmbench Lmbench is a set of utilities to test the performance of a unix system producing detailed results as well as providing tools to process them. It includes a series of micro benchmarks that measure some basic operating system and hardware metrics: * file reading and summing * memory bandwith while reading, writing and copying * copying data through pipes * copying data through Unix sockets * reading data through TCP/IP sockets And I send you the mesage reply. The reply shows how to test a LAM/MPI cluster, the increase in the power of computing. > Begin message reply Friday 15 Apr de 2005 19:14, Rossano Renir Comunelo wrote: > We have 8 nodes in at dedicated network. DRBL installed successfuly and > the nodes work very well (I hope it!!!!). I want realize benchmark test. > How do I to begin?? > > thks Sat 16 Apr de 2005 09:26:49, Robert Antoni Buj Gelonch wrote: Hi Rossano, First, please take a look at this URL: http://netmirror.org/mirror/lam-mpi.org/papers/perf/ The LAM/MPI result will be like this: http://netmirror.org/mirror/lam-mpi.org/papers/perf/lam60-perf-data.php Later, you can try SKaMPI and more: http://www-unix.mcs.anl.gov/mpi/tools.html Regards, Robert >End message reply Regards, Robert |