Re: vmware problem
hi,i think i install the vmware server correctly,but when I config it ,there is something wrong: I install the base-system with the iso: http://debian-amd64.alioth.debian.org/install-images/sid-amd64-netinst.iso change the sources.list: -- sarge deb http://debian-amd64.alioth.debian.org/sarge/ testing main deb-src http://debian-amd64.alioth.debian.org/sarge/ testing main sid deb http://debian-amd64.alioth.debian.org/pure64 sid main deb-src http://debian-amd64.alioth.debian.org/pure64 sid main deb http://bach.hpc2n.umu.se/pure64 sid main deb-src http://bach.hpc2n.umu.se/pure64 sid main deb http://bytekeeper.as28747.net/amd64/alioth/pure64 sid main deb-src http://bytekeeper.as28747.net/amd64/alioth/pure64 sid main deb http://debian.inode.at/pure64/ sid main deb-src http://debian.inode.at/pure64/ sid main deb ftp://ftp.de.debian.org/debian-amd64/pure64/ sid main deb-src ftp://ftp.de.debian.org/debian-amd64/pure64/ sid main deb http://ftp.kaist.ac.kr/pub/debian-amd64/pure64/ sid main deb-src http://ftp.kaist.ac.kr/pub/debian-amd64/pure64/ sid main deb http://mirror.phy.bnl.gov/debian-amd64/ sid main - apt-get upgrade apt-get install gcc-3.4 cd /usr/bin ln -s gcc-3.4 gcc apt-get install perl apt-get install make apt-get install kernel-headers-2.6.8-9-amd64-k8 apt-get install g++-3.4 run vmware-install.pl and any-any84's runme.pl the problem is when i run the vmware-config.pl -- Generating SSL Server Certificate Unable to get the last modification timestamp pf the destination file /etc/vmware/ssl/rui.key Exection aborted - i found the /etc/vmware/ssl is existed and the rui.key is existed can you help me?
Re: Re: Finalize install questions
On Sun, 2004-12-05 at 11:01 -0700, Robert LeBlanc wrote: > > Currently, apps like mplayer and OpenSSL run much faster on x86-32 > > because such core routines are in hand-coded assembler. > > > For most other things, though, GCC 3.4 uses the extra 8 registers > > to good effect. > > I think that is where we will see most of our improvements is in > doubling the registers, since so much of what gets done is > recalculating recent values. By not going back to main memory or even > L2 cache, I think we can get a significant performance increase (ie. > An hour less run time for a 24 hour period). I guess I would have to > run tests to see. Another problem is that these programs can be memory > hogs and the nodes only have 512 MB of RAM which is another concern. Lack of sufficient RAM seems like a much bigger issue than 32 vs 64. -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. "The President has kept all the promises he intended to keep." George Stephanopolous signature.asc Description: This is a digitally signed message part
Re: Finalize install questions
Robert LeBlanc wrote: Hey guys, We have purchased a 65 node cluster of Opterons last December and I have been following the development of the port off and on since then. I think that the port may be mature enough to put on our production environment just because I think that our biology applications could benefit from a 64 bit compile. I am still sketchy on some things that I hope you guys can help me out with. I'd suggest you bring up the cluster as i386 with network booting so you can trivially switch kernels so that you can have a stable cluster for running critical jobs immediately. Then, you can look into building a 64 bit kernel (with 32 bit emulation). Once you have a biarch kernel that appears to work reliably on one node, you can push it out to the whole cluster and have the capability for 64 bit software on the cluster even though the whole operating system is still reliably and running in i386. First, a program needs to be specifically written for 64 bits? You get benefits in two key areas and one disadvantage from using AMD64 in userspace: * More registers, which is transparent to the application since this is handled by the compiler, * More virtual address space, which would be transparent to the application but usually is not, * Larger pointers (associated with the address space) which are no longer the same size as an int. As mentioned by others, the way programs normally have trouble is due to the fact that the author made the assumption that an int and a pointer are both 32 bits long. There are other type-size related problems, but that's often the most difficult one. In general, if the code already runs on other 64 bit architectures, you're probably ok. If it's only ever been i386 ... worry. One problem is that existing programs are normally written to assume a 1GB address space and, if they need more, they include a built in paging mechanism to store their additional data. As long as the paging mechanism is being used, there is no advantage to recompiling the program for 64 bit operation ... you may as well keep it as 32 bit and use a 64 bit kernel with it. Or by just recompiling using 64-bit libs usually good enough? It's certainly worth trying, and then running a regression suite against it ... Fifth, would I be able to mirror the port for the cluster nodes? There is no difference (in terms of management) between i386 and amd64 ... that I'm aware of. Alex.
Re: Re: Finalize install questions
> Currently, apps like mplayer and OpenSSL run much faster on x86-32 > because such core routines are in hand-coded assembler. > For most other things, though, GCC 3.4 uses the extra 8 registers > to good effect. I think that is where we will see most of our improvements is in doubling the registers, since so much of what gets done is recalculating recent values. By not going back to main memory or even L2 cache, I think we can get a significant performance increase (ie. An hour less run time for a 24 hour period). I guess I would have to run tests to see. Another problem is that these programs can be memory hogs and the nodes only have 512 MB of RAM which is another concern. Robert LeBlanc
Re: Finalize install questions
On Sun, 2004-12-05 at 14:37 +0100, Jan-Benedict Glaw wrote: > On Sat, 2004-12-04 23:29:48 -0700, Robert LeBlanc <[EMAIL PROTECTED]> > wrote in message <[EMAIL PROTECTED]>: > > First, a program needs to be specifically written for 64 bits? Or by > > just recompiling using 64-bit libs usually good enough? > > A program needs to be *cleanly* written to compile on a 64 bit system. > However, that's not usually the case, especially if the program was > never ever tested on anything but i386. > > Also, not all programs run faster because of being compiled to 64 bit > programs; to be honest, I expect that most programs would better stay in > 32 bit because of memory size. We'll never know, I guess, since x86-64 isn't *just* AthlonXP extended by 32 bits. > If you *really* want to take advantage of the 64 bit Opteron, you should > have an eye on the code GCC generates. At some time, it may be better to > code core routines (for mathematical computing) in assembler or to use > existing libraries that do exactly this... Currently, apps like mplayer and OpenSSL run much faster on x86-32 because such core routines are in hand-coded assembler. For most other things, though, GCC 3.4 uses the extra 8 registers to good effect. > > Second, to install a 64-bit kernel, you have to be running a 64-bit > > kernel using deb packages? > > No. 64 bit userspace needs a 64 bit kernel, but all other combinations > have no further dependancies. > > MfG, JBG > -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. "He that would live in peace and at ease must not speak all he knows or all he sees." Benjamin Franklin signature.asc Description: This is a digitally signed message part
Re: Finalize install questions
On Sat, 2004-12-04 23:29:48 -0700, Robert LeBlanc <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > First, a program needs to be specifically written for 64 bits? Or by > just recompiling using 64-bit libs usually good enough? A program needs to be *cleanly* written to compile on a 64 bit system. However, that's not usually the case, especially if the program was never ever tested on anything but i386. Also, not all programs run faster because of being compiled to 64 bit programs; to be honest, I expect that most programs would better stay in 32 bit because of memory size. If you *really* want to take advantage of the 64 bit Opteron, you should have an eye on the code GCC generates. At some time, it may be better to code core routines (for mathematical computing) in assembler or to use existing libraries that do exactly this... > Second, to install a 64-bit kernel, you have to be running a 64-bit > kernel using deb packages? No. 64 bit userspace needs a 64 bit kernel, but all other combinations have no further dependancies. MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier BÃrger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
Re: Finalize install questions
On Sat, 2004-12-04 at 23:29 -0700, Robert LeBlanc wrote: > Hey guys, > > We have purchased a 65 node cluster of Opterons last December and I > have been following the development of the port off and on since then. > I think that the port may be mature enough to put on our production > environment just because I think that our biology applications could > benefit from a 64 bit compile. I am still sketchy on some things that > I hope you guys can help me out with. I hate to say this on a Debian list, but have you looked at Gentoo lately? > First, a program needs to be specifically written for 64 bits? Or by > just recompiling using 64-bit libs usually good enough? A properly written C program should work. The big problem area is the assumption that sizeof pointer == sizeof int == sizeof long. Programs written in other languages, where pointers are not visible to the programmer, should also just need to be recompiled. For example, FORTRAN doesn't care whether you are on a 16 bit or a 64 bit system. > Second, to install a 64-bit kernel, you have to be running a 64-bit > kernel using deb packages? > > If the second is the case, then third: I would have to compile a > 64-bit net boot kernel for the nodes. I have never cross-compiled and > tried once before without any luck. Any real other HOW-TOs for > compiling an AMD 64 kernel. By the way, the cross-compile that I tried > was AMD64 a few months ago from the docs on the port page. > > Forth, do you feel that the port is mature enough to run apps that > could run for months at a time? > > Fifth, would I be able to mirror the port for the cluster nodes? > > > > I am just worried that a lot can go wrong. I already will have to > break my mirror to install the AMD64 port side by side with the i386 > port. With a machine that is used to capacity most of the time, I hate > having lots of down time. -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. "The man who has gotten everything he wants is all in favor of peace and order." Jawaharlal Nehru signature.asc Description: This is a digitally signed message part
Finalize install questions
Hey guys, We have purchased a 65 node cluster of Opterons last December and I have been following the development of the port off and on since then. I think that the port may be mature enough to put on our production environment just because I think that our biology applications could benefit from a 64 bit compile. I am still sketchy on some things that I hope you guys can help me out with. First, a program needs to be specifically written for 64 bits? Or by just recompiling using 64-bit libs usually good enough? Second, to install a 64-bit kernel, you have to be running a 64-bit kernel using deb packages? If the second is the case, then third: I would have to compile a 64-bit net boot kernel for the nodes. I have never cross-compiled and tried once before without any luck. Any real other HOW-TOs for compiling an AMD 64 kernel. By the way, the cross-compile that I tried was AMD64 a few months ago from the docs on the port page. Forth, do you feel that the port is mature enough to run apps that could run for months at a time? Fifth, would I be able to mirror the port for the cluster nodes? I am just worried that a lot can go wrong. I already will have to break my mirror to install the AMD64 port side by side with the i386 port. With a machine that is used to capacity most of the time, I hate having lots of down time. Thanks for the help and patience, Robert LeBlanc Brigham Young University
