This is really a new type of binary optimization. There is no reason that the "translation" software be fast or even run during the execution of the optimized program. The idea would be to compile the binary with the normal optimizations in place (O4, say). This is a priori, or before-runtime, optimization. Then, choose a representative set of inputs to exercise the binary and run it using the "translator." The optimizations in this a posteriori process can be very aggressive. The performance of the code during this procedure may even be seriously hampered by the optimizations, but at the end, all of the fragments in the cache are then assembled into the NEW a posteriori optimized binary. We then have a program that takes full advantage of this wholistic optimization approach but doesn't carry the translation runtime baggage. I think that this would make an exciting research project, especially with the added bonus of being able to insert different front-ends into the translation application.
Even without pruning, that leaves plenty of room for the bootloader. And a great deal of that can be parred down. That is much easier than trying to build a initrd to fit on a floppy.
I think I will give this a try. The Pegasus drivers are available from http://www.monitor.bg/~petkan/ or www.scyld.com when they become available. These should work with the $30 USB-ethernet adapters from DLink. It seems that I will still have to boot from IDE hard drive temporarily to hack up the ROM. But, at least I won't have to try to mount a hard drive in there.
...and name a hard drive that you will want to be using in five years. My three-year old hard drives that are just slipping out of warrantee are 1.2s and 1.6s. Who cares!
...and name a hard drive that you will want to be using in five years. My three year hard drives are just slipping out of warrantee are 1.2s and 1.6s. Who cares!
Re:The Great Telephone Number Explosion...
on
CNN On IPv6
·
· Score: 1
As someone in the industry, maybe you can answer this? Why haven't phone companies develop dial-out-only phone lines for Internet usage. You could attach the secondary line billing to the standard primary phone line. You would not be able to recieve calls on the second line, but all of the phone lines permanently connected to modems wouldn't care. Perhaps there are routing and network issues that I am not aware of, but it would seem that the local telco switch would be able to handle such this situation with a simple software upgrade. Just wondering...
I don't think I can point a dish at another one when they're 5 miles apart.
Why not? Buy/borrow a GPS. That will at least get you close, and then adjust the dishes to maximize signal level. Of course, with GHz frequencies, you better be going from hilltop to hilltop because line of sight will be important.
The energy used to accelerate the ion stream is normally provided by solar cells. Once the craft is out far enough for the solar winds to die off, I suspect that the solar radiation too would be very weak. (scales like 1/r^2). You could always pack along a plutonium reactor I guess...but what kind of impression would a parcel of artificial fissile material make on our neighboring solar system. 8)
Do you have those kernel modifications handy? I was investigating using two Ultra33s to build a cheap RAID server about a year ago, but never found time to get multiple Promise cards working. Has support for multiple Ultra33/66 cards found its way into the standard 2.2 kernel tree?
As many people have already noted, using the Promise Ultra33 is an excellent way to approach Software RAID with IDE drives. There is some very useful information at Erik Hendriks' website at NASA Goddard:
They found that most of the "dual" channel IDE ports built into motherboards are not truly independent because of a shared buffer in the controller. This is a "feature" of the IDE controllers used and effectively limits the collective performance of the two IDE channels to roughly that of a single channel. The IDE channels on the Promise board are truly independent though. As their benchmarks show, placing one drive on one of the motherboard controllers and one on each of the Promise controllers yielded nearly three times the disk bandwidth of a single channel. Of course, this is for data striping, not RAID5, but the principle is the same.
For those interested in building a RAID5 server, this configuration makes a lot of sense. Use two disks on each channel of the Promise and two disk on the motherboard controller...five data and one parity and roughly 3x the bandwidth of a single drive.
Ethernet collisions are not a problem. No one uses hubs for Beowulf interconnects. Switched ethernet allows the network performance to scale with the number of nodes. Unfortunately, that is probably the real limiting factor...designing a large enough network. A typical two-tier approach would use 36- or 48-port Fast Ethernet switches with gigabit uplink ports connected to gigabit switches. I think you could assemble several hundred systems this way to a thousand systems. This is the approach LANL used for Avalon. Also, some of the big iron Cisco backplanes can take 24-port ethernet cards. I think some of them can support several hundred switched ports in a single tier.
Unfortunately, I don't know of an ethernet solution that could scale beyond several hundred systems and still provide uniform bandwidth and latency among all of the nodes. Beyond that point, you will need to come up with a scheme to partition to the network or just accept some performance penalty for crossing subdivisions boundaries of the cluster.
A windowmanager could potentially use direct rendering to blit into the root window, but X11 applications will still need 2d windows within the root window. So spinning windows or windows with perspective could at best be visual hacks in the root window, not real windows you can work with.
I disagree. If the 2D/3D integration is done properly, the 2D X output from an application should be mappable onto a 3D texture. AGP textures in system memory could made that blindly fast and fairly transparent to the OS and X applications. Just draw the X output to this virtual frame buffer that is mapped to a 3D texture (or maybe *textures*, depending on the 3D hardware texture size limitations). Once that mapping is done, the 3D hardware can rotate, scale, and shade that window as easily as anything else.
Xeon boards and other high-end 4-way+ SMP boards usually have memory interleaving or a crossbar instead of a system bus to keep the processors fed. I think that the 64-bit, 100 MHz memory bus in a BX chipset will be saturated rather quickly by 4-way SMP. If you need four Celerons, build another box and rlogin.
The Extreme Linux CD and most of the RPMs it contains are woefully out of date. The EL CD has a hacked RH 5.0 install with some kernel modifications, none of which are really necessary. Most clusters are being moved to 2.2.x kernels (for network and SMP reasons) and at least the channel bonding modifications have been moved to 2.2. My 24-node cluster is running 2.2.3 which I hand patched with the TCP_NoDelay and Channel Bonding modifications.
If you are serious about getting a cluster running, take a look at:
The egcs compiler issue is significant. If you examine the current state of the Alpha backend for egcs, you have a very good indication of the problems that a Merced port might face. The 21164 is missing one feature (out-of-order execution?) which makes instruction scheduling very important and seems to really limit overall egcs/Alpha performance. Alpha represents a rather small deviation from the current CPU "norm," but yet these problems have persisted for quite some time. EPIC and Merced present a vastly different architectual model, so I worry about the ability of egcs development to keep up. Of course, with Intel's recent interest in Linux, perhaps they will be gracious and help engineer the compiler.
You make valid points. We have 20 Alpha Linux systems that we use to crunch numbers 24/7 using our own parallel codes. For this purpose, the Alphas make perfect sense--porting our codes was pretty easy. We bought the first several systems complete with monitors and tried to use them as workstations. But I quickly concluded that it was too much trouble to deal with the little bugs in Alpha Linux applications (especially X), so I pulled the good video cards/monitors and other useful parts and used them to build Celeron front-end systems. The alphas are quite contentedly running headless on the shelf, and we just access them from the Intels. The last batch of alphas I bought doesn't even have video cards.
Do you have more information about this? The Math library release was a great start. It made a significant impact on the performance of our Alpha Linux cluster. We really need the Dec Uni...er Compaq Fortran compiler suite for our development work. I think I could scrape up a couple $K to put a copy of that on the head node in our cluster.
What are you talking about? The celeron uses the same core that P2s do. Intel simply failed to connect the SMP trigger line (BR#1?) on the Celeron SECC and produced specs that obscured the pin's location on the PPGA. When you connect that line to the appropriate edge connection, all of the normal memory coherency is in effect. If "Intel deliberately left the coherency stuff out of the Celeron," it would have increased development costs and, in turn, the cost of the shipped product. Hobbyists who are willing to violate their warrantee are reaping the benifits of Intel's little marketing creation.
You hit the nail on the head! The limited memory bandwidth of the Pentium architecture is the primary reason that SMP Pentiums are not a good idea. SMP with some 350 P2s or Celerons (with the appropriate modifications/slockets) makes a lot more sense. The PPro/P2 architecture does a very nice job with SMP. The SMP Pentium setups are kludges by comparision.
Connellsville, Scottdale, and Mt. Pleasant have cable modems too...from a different ISP than Uniontown. For being backwater southwestern PA, there sure is a lot of high tech activity. I guess mountain folk just like their porn.
I have long thought that CPU cooling could be done using a "heat pipe" design. Essentially, you would put a reservoir on top of the CPU, along with an internal heat sink. From the top of the reservoir, you would run a copper tube to a working fluid-to-air heat exchanger. You pressurize the device with refrigerant (like R-134a) so that the critical (boiling) temperature is at the operating temperature for the CPU. Then, as the CPU temperature rises, it will boil the refrigerant which will naturally bubble up the exterior heat exchanger. The heat exchanger can remove the heat and the condensing liquid will trickle back down the pipe. This approach uses convective heat transfer just like the water approach, but has two advantages. First, it is buoyancy driven and, as such, needs no pump. Second, the latent heat of fusion of the evaporating gas provides a significantly higher rate of heat transfer than the sensible heat of the moving water. This is a common approach for HVAC air-to-air heat exchangers. I am surprised someone hasn't tried it on CPUs yet. Something for you undergrads to play with...I have to go finish my dissertation.
Slashdot Mirror
This is really a new type of binary optimization. There is no reason that the "translation" software be fast or even run during the execution of the optimized program. The idea would be to compile the binary with the normal optimizations in place (O4, say). This is a priori, or before-runtime, optimization. Then, choose a representative set of inputs to exercise the binary and run it using the "translator." The optimizations in this a posteriori process can be very aggressive. The performance of the code during this procedure may even be seriously hampered by the optimizations, but at the end, all of the fragments in the cache are then assembled into the NEW a posteriori optimized binary. We then have a program that takes full advantage of this wholistic optimization approach but doesn't carry the translation runtime baggage. I think that this would make an exciting research project, especially with the added bonus of being able to insert different front-ends into the translation application.
/bin.......4620 KB
/sbin......4144
/boot......2165
Even without pruning, that leaves plenty of room for the bootloader. And a great deal of that can be parred down. That is much easier than trying to build a initrd to fit on a floppy.I think I will give this a try. The Pegasus drivers are available from http://www.monitor.bg/~petkan/ or www.scyld.com when they become available. These should work with the $30 USB-ethernet adapters from DLink. It seems that I will still have to boot from IDE hard drive temporarily to hack up the ROM. But, at least I won't have to try to mount a hard drive in there.
my SCSI drives have a 5 year warentee.
...and name a hard drive that you will want to be using in five years. My three-year old hard drives that are just slipping out of warrantee are 1.2s and 1.6s. Who cares!
...and name a hard drive that you will want to be using in five years. My three year hard drives are just slipping out of warrantee are 1.2s and 1.6s. Who cares!
As someone in the industry, maybe you can answer this? Why haven't phone companies develop dial-out-only phone lines for Internet usage. You could attach the secondary line billing to the standard primary phone line. You would not be able to recieve calls on the second line, but all of the phone lines permanently connected to modems wouldn't care. Perhaps there are routing and network issues that I am not aware of, but it would seem that the local telco switch would be able to handle such this situation with a simple software upgrade. Just wondering...
I don't think I can point a dish at another one when they're 5 miles apart.
Why not? Buy/borrow a GPS. That will at least get you close, and then adjust the dishes to maximize signal level. Of course, with GHz frequencies, you better be going from hilltop to hilltop because line of sight will be important.
The energy used to accelerate the ion stream is normally provided by solar cells. Once the craft is out far enough for the solar winds to die off, I suspect that the solar radiation too would be very weak. (scales like 1/r^2). You could always pack along a plutonium reactor I guess...but what kind of impression would a parcel of artificial fissile material make on our neighboring solar system. 8)
Do you have those kernel modifications handy? I was investigating using two Ultra33s to build a cheap RAID server about a year ago, but never found time to get multiple Promise cards working. Has support for multiple Ultra33/66 cards found its way into the standard 2.2 kernel tree?
As many people have already noted, using the Promise Ultra33 is an excellent way to approach Software RAID with IDE drives. There is some very useful information at Erik Hendriks' website at NASA Goddard:
http://www.beowulf.org/bds/disks.html
They found that most of the "dual" channel IDE ports built into motherboards are not truly independent because of a shared buffer in the controller. This is a "feature" of the IDE controllers used and effectively limits the collective performance of the two IDE channels to roughly that of a single channel. The IDE channels on the Promise board are truly independent though. As their benchmarks show, placing one drive on one of the motherboard controllers and one on each of the Promise controllers yielded nearly three times the disk bandwidth of a single channel. Of course, this is for data striping, not RAID5, but the principle is the same.
For those interested in building a RAID5 server, this configuration makes a lot of sense. Use two disks on each channel of the Promise and two disk on the motherboard controller...five data and one parity and roughly 3x the bandwidth of a single drive.
Ethernet collisions are not a problem. No one uses hubs for Beowulf interconnects. Switched ethernet allows the network performance to scale with the number of nodes. Unfortunately, that is probably the real limiting factor...designing a large enough network. A typical two-tier approach would use 36- or 48-port Fast Ethernet switches with gigabit uplink ports connected to gigabit switches. I think you could assemble several hundred systems this way to a thousand systems. This is the approach LANL used for Avalon. Also, some of the big iron Cisco backplanes can take 24-port ethernet cards. I think some of them can support several hundred switched ports in a single tier.
Unfortunately, I don't know of an ethernet solution that could scale beyond several hundred systems and still provide uniform bandwidth and latency among all of the nodes. Beyond that point, you will need to come up with a scheme to partition to the network or just accept some performance penalty for crossing subdivisions boundaries of the cluster.
A windowmanager could potentially use direct rendering to blit into the root window, but X11 applications will still need 2d windows within the root window. So spinning windows or windows with perspective could at best be visual hacks in the root window, not real windows you can work with.
I disagree. If the 2D/3D integration is done properly, the 2D X output from an application should be mappable onto a 3D texture. AGP textures in system memory could made that blindly fast and fairly transparent to the OS and X applications. Just draw the X output to this virtual frame buffer that is mapped to a 3D texture (or maybe *textures*, depending on the 3D hardware texture size limitations). Once that mapping is done, the 3D hardware can rotate, scale, and shade that window as easily as anything else.
Xeon boards and other high-end 4-way+ SMP boards usually have memory interleaving or a crossbar instead of a system bus to keep the processors fed. I think that the 64-bit, 100 MHz memory bus in a BX chipset will be saturated rather quickly by 4-way SMP. If you need four Celerons, build another box and rlogin.
The Extreme Linux CD and most of the RPMs it contains are woefully out of date. The EL CD has a hacked RH 5.0 install with some kernel modifications, none of which are really necessary. Most clusters are being moved to 2.2.x kernels (for network and SMP reasons) and at least the channel bonding modifications have been moved to 2.2. My 24-node cluster is running 2.2.3 which I hand patched with the TCP_NoDelay and Channel Bonding modifications.
If you are serious about getting a cluster running, take a look at:
http://www.xtreme-machines.com/x-cluster-qs.html
This is very up-to-date and basically begins by advising you to use your EL CD as a coaster.
Mike Prinkey
The egcs compiler issue is significant. If you examine the current state of the Alpha backend for egcs, you have a very good indication of the problems that a Merced port might face. The 21164 is missing one feature (out-of-order execution?) which makes instruction scheduling very important and seems to really limit overall egcs/Alpha performance. Alpha represents a rather small deviation from the current CPU "norm," but yet these problems have persisted for quite some time. EPIC and Merced present a vastly different architectual model, so I worry about the ability of egcs development to keep up. Of course, with Intel's recent interest in Linux, perhaps they will be gracious and help engineer the compiler.
You make valid points. We have 20 Alpha Linux systems that we use to crunch numbers 24/7 using our own parallel codes. For this purpose, the Alphas make perfect sense--porting our codes was pretty easy. We bought the first several systems complete with monitors and tried to use them as workstations. But I quickly concluded that it was too much trouble to deal with the little bugs in Alpha Linux applications (especially X), so I pulled the good video cards/monitors and other useful parts and used them to build Celeron front-end systems. The alphas are quite contentedly running headless on the shelf, and we just access them from the Intels. The last batch of alphas I bought doesn't even have video cards.
Do you have more information about this? The Math library release was a great start. It made a significant impact on the performance of our Alpha Linux cluster. We really need the Dec Uni...er Compaq Fortran compiler suite for our development work. I think I could scrape up a couple $K to put a copy of that on the head node in our cluster.
What are you talking about? The celeron uses the same core that P2s do. Intel simply failed to connect the SMP trigger line (BR#1?) on the Celeron SECC and produced specs that obscured the pin's location on the PPGA. When you connect that line to the appropriate edge connection, all of the normal memory coherency is in effect. If "Intel deliberately left the coherency stuff out of the Celeron," it would have increased development costs and, in turn, the cost of the shipped product. Hobbyists who are willing to violate their warrantee are reaping the benifits of Intel's little marketing creation.
You hit the nail on the head! The limited memory bandwidth of the Pentium architecture is the primary reason that SMP Pentiums are not a good idea. SMP with some 350 P2s or Celerons (with the appropriate modifications/slockets) makes a lot more sense. The PPro/P2 architecture does a very nice job with SMP. The SMP Pentium setups are kludges by comparision.
Connellsville, Scottdale, and Mt. Pleasant have cable modems too...from a different ISP than Uniontown. For being backwater southwestern PA, there sure is a lot of high tech activity. I guess mountain folk just like their porn.
I have long thought that CPU cooling could be done using a "heat pipe" design. Essentially, you would put a reservoir on top of the CPU, along with an internal heat sink. From the top of the reservoir, you would run a copper tube to a working fluid-to-air heat exchanger. You pressurize the device with refrigerant (like R-134a) so that the critical (boiling) temperature is at the operating temperature for the CPU. Then, as the CPU temperature rises, it will boil the refrigerant which will naturally bubble up the exterior heat exchanger. The heat exchanger can remove the heat and the condensing liquid will trickle back down the pipe. This approach uses convective heat transfer just like the water approach, but has two advantages. First, it is buoyancy driven and, as such, needs no pump. Second, the latent heat of fusion of the evaporating gas provides a significantly higher rate of heat transfer than the sensible heat of the moving water. This is a common approach for HVAC air-to-air heat exchangers. I am surprised someone hasn't tried it on CPUs yet. Something for you undergrads to play with...I have to go finish my dissertation.