Having delt a lot with IBM DB2 support, I can tell you that it's a very sharp double-edged sword. Yes, you can get product support (for a rather expensive price), but it's honestly not very good. In fact I'd say it's really bad in the cases where you really need it, such as when a production system is crashing or doing other things that make no sense.
Also, if linux is super-important to you, be aware that DB2 on linux isn't up to production quality yet (unless you throw massive amounts of hardware at it, and even then it's marginal). It appears IBM is still learning the linux ropes. Support for DB2 on linux also isn't as good as on other OS's, from what I've heard. (It's certainly not as good as on AIX, which is what we now run DB2 on, but that's no surprise;) ). I can't say db2's performance or stability on windows is all that great either. If you must go with x86 hardware for your database, then you should probably look at MSSQL or maybe Oracle.
Also, while I haven't looked at PostgresSQL, they'd be very hard pressed to do a worse job on documentation than DB2.
Not to mention that the RS6000 architecture is all about memory bandwidth. The higher end machines use a crossbar that is capable of 19.6 GIGABYTES/sec. Try that on an x86 (or even most other bigiron, for that matter). This is why RS6000s kick so much ass on databases, and why many people are moving their Oracle installs from Sun to RS6000 (keep in mind that Oracle charges per CPU).
Re:Don't understand how Linux AIX ?
on
IBM Wants Linux
·
· Score: 2
I'm not an AIX expert by any means, but heres a few things... hopefully someone with more AIX experience can chime in.
Scheduler: We run db2 on AIX/RS6000. We used to run it on linux/X86, but that was extremely painful, for a variety of reasons. On our linux systems, if the run queue ever got much over 100 processes, even for a very short period of time, the OS would tailspin into a state where the kernel was using 99% of the CPU time. On the AIX box, I've seen the run queue get as high as 900, and the box just worked through it. While having the queue hit even 100 isn't something I like seeing, I do expect the system to be able to work through it, assuming it's a short-term load (as was the case). Even when DB2 on AIX does go off the deep end (we have a bug where it occasionally puts the kernel into a high CPU load), the kernel maxes out at ~90% CPU, so you can still get into the box and do things.
Filesystem: you simply can't compare the capabilities of JFS to ext2fs. Things like being able to resize filesystems and being able to determine where on the platter they are placed (though I'm not sure this is used much today). And I know very little about what JFS can do; I'm sure there's others that have much more info.
Yes, linux does have RFS, but that brings me to the next point...
Maturity: AIX has been around for a very long time... AIX 4.x alone has probably been around as long as linux. This means far, far fewer bugs, and much, much more optimization. Look at the recent rewrite of the linux vm system as an example... AIX enjoys years and years of research while linux is arguably still in a 'growing up' phase.
Advanced features: Take a look at what's comming up in AIX5L. Things like advanced clustering (more advanced and capable than anything I've heard of for linux or any other free OS). Not to mention things like HACMPS.
This doesn't mean that Linux is an 'inferior' OS; only that it's targeted at a different market than AIX. (AIX on a desktop? Ewww...)
Unfortunately, I don't have the original copy of this, so I'm doing it from memory. Possibly urban legend, but funny none the less. This was overheard on a west-coast Air Traffic Control frequency:
pilot: Request permission for FL85 (FL85 is 85,000 feet; far above the service ceiling of almost all aircraft)
ATC: if you think you can reach it, sure thing; it's all yours
SR-71 pilot: Roger, descending from FL100
"Also, the X-15 was dropped from a bomber after being carried to altitude. The SR-71 had its theoretical limits as above. This is a step beyond either--something that would take off on its own and fly faster than the X-15."
Read the article...
"As such, the X-43A will be mounted to an Orbital Science Corp. Pegasus rocket, which boosts the aircraft to the required speed, or about Mach 5 or greater. [...] For the test flight, a modified B-52 bomber with the X-43A attached to the wing will fly to the California coast from Edwards and launch the aircraft along with the booster rocket near San Nicolas Island southwest of Los Angeles. The B-52, built in the 1950s, is one of the oldest around and has been used on some of the most important projects in aerospace history including the air launch of the X-15 and other experimental wingless aircraft."
Also, I don't see where you get that the X-43A doesn't have to carry it's own fuel, either. Even though it gets a rocket powered assist from a rocket that gets a jet-fuel powered assist, it still carries fuel of it's own.
If you're having difficulty with the installer, I suggest taking a look and ensuring that all your hardware is on the supported hardware list (http://www.freebsd.org/handbook/install-hw.html). FreeBSD can definitely be picky about the hardware that it runs on. Also, you might try doing just a basic install, then cvsup'ing to get everything else.
SpaceflightNow.com has tons of info on everything that flies into space. For example, you can also read about the status of a launch to place another GPS bird in orbit here. The link for that shuttle flight also has lots of info on the 'hack' they did to the shuttle while it was on the pad to replace a hydraulics unit (first time they've ever attempted that).
It's my hope that this is what they mean by: "we will have the opportunity to improve some other aspects of client operation. In particular, we plan to add more configurable checkpointing and a better display of progress" in their announcement.
Your hope is correct. During our beta testing (using OGR-23), we found -4 stubs to be perfectly sized, but they are obviously a bit large for OGR-24, so we will be switching to -5 stubs. The estimates I've heard are that the -5 stubs will be ~1/10th the size of -4 stubs, but this is only an estimation.
As mentioned, we will also be changing the status bar so that it updates more frequently.
We gave ourselves another 6 hours to do last-minute proxy upgrades and what-not, so the new time to 'flip the switch' is 0600 GMT. If you'll be asleep at that time, fear not: your clients should automagically connect at 0615 GMT and grab OGR blocks, assuming that you've enabled the contest.
There is one possibility that you forget: the clients could legitimately be there. There are many people in acedamia that love distributed.net and fully support it's use, and oftentimes, the client is installed by an admin.
Unfortunately, there are those who install the client without permission, and against the distributed.net AUP.
because it was supposed to add stability and scalability that was not available in the NT/SQL config they had before.
Statsbox II is more stable and scalable than Statsbox I. sbI was having more and more hardware issues. It was also a single Pentium 166 that was OC'd to 200MHz. sbII is currently a dual PII-300, and the motherboard should support any Slot 1 CPU. This mobo will also support up to 1G of RAM and currently has 1/2G installed. sbI was maxed out with 256M, iirc.
Well, it's no faster. Crashes and corrupts just as often,
Based on what measure? The RC5 statsrun dropped from over 6 hours with stats turned off to under 4 hours with stats left on. Even with the ever increasing RC5 statsrun time (it will keep getting longer until the project is done) and CSC stats, we're still finishing stats in less time than on sbI, and we're leaving HTTP access enabled durring the run.
We've also had far less unexpected downtime with this setup than with sbI. In fact, I can't think of any hardware issues that have affected sbII. The current problem was caused by human error, read my.plan for more info.
they have failed misserably at putting the functionality back into the stats pages.
This is the only argument yake that holds any weight, as far as I can see, but I'd like to know what is missing other than all of the CPU/OS info that the old site had? Also please note that there is CPU/OS info available for CSC (see here and here).
Since I do d.net more 'cause stats are cool than any other reason, it kinda pisses me off...
You're certainly not the only participant who is a stats-junkie (I'm one myself). We do try and take stats very seriously, but unfortunately, there's only so much time in our days. Nugget, Bruce, and I are working on our next version of stats, which will be far more robust (and hopefully will include cross-project stats). Sometime in the future, we will also be looking to bring some more PHP and SQL folks on-board.
I hope you can undertand how discouraging a post that is full of misinformation can be to those of us who are working to improve stats.
Our true purpose is to promote wide-area distributed computing... encryption contests just happen to be the vehicle we've used to do that so far. OGR will be the first contest that breaks that mold.
For those who are interested, I would suggest taking a peek at our mission statement.
We're not aware of any current issues with RC5 or CSC stats, other than this teams issue (teams are cross-project, so this problem will affect both RC5 and CSC stats).
We started working on CSC not long after the contest was announced. I don't have the announcement handy, but I believe we announced we'd be working on it sometime in May or June of 1999. That announcement would probably have more details, but in a nutshell, we did CSC because it was relatively easy to add to our current network infrastructure, and because it would be a nice, quick contest that would serve as a nice break from RC5-64. Since we only keep 20% of the prize, I wouldn't say we really did it for financial reasons, not that $2k EURO is anything to sneeze at. }:8)
As for posting Dcypher announcements, I will only mention that there have been several articles posted about Dcypher, and several articles posted about distributed.net since Dcypher opened it's doors.
I havn't had a chance to talk to Nugget yet, so I don't know what he saw or what reports he had, but I think that what happened is that all team joins for Dec. 30 were lost. Unfortunatly, we had no way to recover those, so anyone who joined a team or changed their team affiliation on Dec. 30 would be affected. IIRC, we saw about 10 people from Dec. 26-Dec. 29 who changed their teams, so this will probably affect only a very, very small number of people. Since I havn't talked to Nugget yet, there could be something else going on that I'm not aware of though.
As others have pointed out, no blocks have been lost, and if you weren't on a team before, your blocks will all get assigned when you join the team of your choice (part of the nightly statsrun assigns any blocks for a given participant with a team ID of 0 to that participant's current team, assuming that their current team isn't 0).
Sorry for the confusion. As other's have mentioned this really isn't a big deal. Of course, it never hurts to get mentioned on/. }:8)
"Why would you possibly want to control computers directly from your brain if you can do it by moving your hand, your fingers? I think some people use their imaginations a bit too much."
I can't live without my Gateway AnyKey keyboard... I know that there's programs that will allow you to do keyboard macros, but you simply can't beat the convenience of having programmable macros available right from the keyboard! I know it sounds silly/dumb, but once you've gotten used to it, you can't do without. I've got 2 extra ones just in case Gateway stops making them.
The US has had space technology leak out
on
China Enters Space
·
· Score: 1
If you read Insight Magazine (website at http://www.insightmag.com/), then you will have seen numerous reports on how poor security (and worse) has allowed a lot of space technology to leave the US for China.
As for the space shuttle, it's a pretty safe bet that it was developed by the US. Don't forget that it's like the 4th generation of US rocketry.
Well, unfortunately I'd have to admit that we don't always move as fast as I'd like to see, but I certainly don't think that we're slow, blumbering, or don't get anything done. In 6 months we've expanded our network to be able to handle non cryptographic contests (OGR), have launched one new contest, and are very close to launching a second new contest. This is on top of all the normal day-to-day operational work that goes on.
I can understand wanting to have the fastest, most efficient cores possible, we'd also like to see that. But how long do we wait for highly optimized cores (FWIW, I was told by our coders that they did in fact spend time optimizing the cores)? We may only be working on this contest for a matter of weeks, so does it make sense for our coders to spend time on optimizing CSC, when they could be working on finishing OGR? Maybe it does, maybe it doesn't. As it turns out, we've had numerous offers from people to work on x86 ASM cores since the source was released yesterday, so it is quite possible we'll have optimized cores available some time soon, at least for the x86 architecture.
As far as stats go, I guess that is one advantage that a smaller effort will always have over a larger one: the ability to reach very high levels in the stats. Unfortunately, that's completely counter to the entire concept of distributed computing, where each CPU does a very small piece of work. On the other hand, a new contest like CSC does provide the perfect opportunity to climb in our stats.
IANAC (I am not a coder:) ), but we havn't done any core optimizations in the current client. If we get a large portion of our users converting over, we probably won't have to either, since we could exhaust the entire keyspace in a matter of weeks. Assuming that's the case, we're much better off getting unoptimized clients out the door, rather than spending weeks working on hand tuned assembly language cores.
One of the interesting things that happens when you get a very large group of CPUs together is that you don't always need or want to be very effecient on the CPU level... it's more important to be effecient at the *network* level. In this case, we're trading off effeciency in CPU cycles for time. Another potential example is algorithms that do not parallelize well, ones that need lots of inter-process communication for example. It might be possible to modify these algorithms to remove some of the inter-process communications at the cost of increasing CPU power needed. This wouldn't make sense if you were running on a single power machine, but if you're using a wide-area distributed computing network, it could make a *lot* of sense.
This isn't cast in stone, but we would most likely convert it to US$, since there would most likely be a 10kEuro check made out to us, and then we would split the prize 60/20/10/10 to the charity voted for by the participants/distributed.net itself/the user who finds the key/that users team (if the user is not on a team, they get 20%).
If the winning user or team were located in Europe, we might ask CS if they'd be willing to send checks directly to them.
The l ink in the above comment is actually a presentation about the cluster. Here's the juicy bits:
- The primary purpose is to be a scalability testbed - They expect the cluster to eventually grow to 1000+ nodes (they have a timeline that indicates that they should be getting ready to install the next 768 nodes RSN) - They mention some sample applications - There's a 16' x 8' Active Mural - It will be open to open source development groups and 'people who ask nicely' - They mention some of the unique management issues here and here - The cluster is organized as "towns" - The cluster is actually comprised of 3 12 systems in it's current config. - Here's the system configurations and network topology
We sucessfully completed RSA rc5-56 challange October 22, 1997 (See our full history at http://www.distributed.net/history.html ), over two years ago. We are currently working on rc5-64, which is 256 times harder than rc5-56. Were we to tackle rc5-56 again, we could crack it in a matter of days.
Unfortunatly, my experience with trying to get help in #freebsd has been pretty bad in general, and I'd like to think I'm not asking very dumb questions. Generally, it's a bad place to go for help; in fact, I'd say it's the wrong place to go for help since the topic is often "This isn't a help channel! http://freebsd.org or RTFM".
There is #freebsdhelp, which is much more 'user friendly' but unfortunately doesn't have as many people in it (when someone in #freebsd does decide to answer your question you usually know immediately, whereas #freebsdhelp is much 'slower').
I really love FreeBSD, and I *personally* find it much easier to work with than RedHat (the only Linux I've ever tried). I just wish the online support was a little better.
Yes, the 'core' is open source, and we love it when anyone sends us any patches to the cores that increase their speed.
Using the FPU in parallel is something that has been tossed around (along with a 'core' for video cards and printers), but no work has been done that I'm aware of.
Slashdot Mirror
Having delt a lot with IBM DB2 support, I can tell you that it's a very sharp double-edged sword. Yes, you can get product support (for a rather expensive price), but it's honestly not very good. In fact I'd say it's really bad in the cases where you really need it, such as when a production system is crashing or doing other things that make no sense.
;) ). I can't say db2's performance or stability on windows is all that great either. If you must go with x86 hardware for your database, then you should probably look at MSSQL or maybe Oracle.
Also, if linux is super-important to you, be aware that DB2 on linux isn't up to production quality yet (unless you throw massive amounts of hardware at it, and even then it's marginal). It appears IBM is still learning the linux ropes. Support for DB2 on linux also isn't as good as on other OS's, from what I've heard. (It's certainly not as good as on AIX, which is what we now run DB2 on, but that's no surprise
Also, while I haven't looked at PostgresSQL, they'd be very hard pressed to do a worse job on documentation than DB2.
Not to mention that the RS6000 architecture is all about memory bandwidth. The higher end machines use a crossbar that is capable of 19.6 GIGABYTES/sec. Try that on an x86 (or even most other bigiron, for that matter). This is why RS6000s kick so much ass on databases, and why many people are moving their Oracle installs from Sun to RS6000 (keep in mind that Oracle charges per CPU).
I'm not an AIX expert by any means, but heres a few things... hopefully someone with more AIX experience can chime in.
Scheduler: We run db2 on AIX/RS6000. We used to run it on linux/X86, but that was extremely painful, for a variety of reasons. On our linux systems, if the run queue ever got much over 100 processes, even for a very short period of time, the OS would tailspin into a state where the kernel was using 99% of the CPU time. On the AIX box, I've seen the run queue get as high as 900, and the box just worked through it. While having the queue hit even 100 isn't something I like seeing, I do expect the system to be able to work through it, assuming it's a short-term load (as was the case). Even when DB2 on AIX does go off the deep end (we have a bug where it occasionally puts the kernel into a high CPU load), the kernel maxes out at ~90% CPU, so you can still get into the box and do things.
Filesystem: you simply can't compare the capabilities of JFS to ext2fs. Things like being able to resize filesystems and being able to determine where on the platter they are placed (though I'm not sure this is used much today). And I know very little about what JFS can do; I'm sure there's others that have much more info.
Yes, linux does have RFS, but that brings me to the next point...
Maturity: AIX has been around for a very long time... AIX 4.x alone has probably been around as long as linux. This means far, far fewer bugs, and much, much more optimization. Look at the recent rewrite of the linux vm system as an example... AIX enjoys years and years of research while linux is arguably still in a 'growing up' phase.
Advanced features: Take a look at what's comming up in AIX5L. Things like advanced clustering (more advanced and capable than anything I've heard of for linux or any other free OS). Not to mention things like HACMPS.
This doesn't mean that Linux is an 'inferior' OS; only that it's targeted at a different market than AIX. (AIX on a desktop? Ewww...)
Unfortunately, I don't have the original copy of this, so I'm doing it from memory. Possibly urban legend, but funny none the less. This was overheard on a west-coast Air Traffic Control frequency:
pilot: Request permission for FL85 (FL85 is 85,000 feet; far above the service ceiling of almost all aircraft)
ATC: if you think you can reach it, sure thing; it's all yours
SR-71 pilot: Roger, descending from FL100
Read the article...
"As such, the X-43A will be mounted to an Orbital Science Corp. Pegasus rocket, which boosts the aircraft to the required speed, or about Mach 5 or greater. [...] For the test flight, a modified B-52 bomber with the X-43A attached to the wing will fly to the California coast from Edwards and launch the aircraft along with the booster rocket near San Nicolas Island southwest of Los Angeles. The B-52, built in the 1950s, is one of the oldest around and has been used on some of the most important projects in aerospace history including the air launch of the X-15 and other experimental wingless aircraft."
Also, I don't see where you get that the X-43A doesn't have to carry it's own fuel, either. Even though it gets a rocket powered assist from a rocket that gets a jet-fuel powered assist, it still carries fuel of it's own.
If you're having difficulty with the installer, I suggest taking a look and ensuring that all your hardware is on the supported hardware list (http://www.freebsd.org/handbook/install-hw.html). FreeBSD can definitely be picky about the hardware that it runs on. Also, you might try doing just a basic install, then cvsup'ing to get everything else.
http://spaceflightnow.com/news/n0012/21pluto/
SpaceflightNow.com has tons of info on everything that flies into space. For example, you can also read about the status of a launch to place another GPS bird in orbit here. The link for that shuttle flight also has lots of info on the 'hack' they did to the shuttle while it was on the pad to replace a hydraulics unit (first time they've ever attempted that).
It's my hope that this is what they mean by: "we will have the opportunity to improve some other aspects of client operation. In particular, we plan to add more configurable checkpointing and a better display of progress" in their announcement.
Your hope is correct. During our beta testing (using OGR-23), we found -4 stubs to be perfectly sized, but they are obviously a bit large for OGR-24, so we will be switching to -5 stubs. The estimates I've heard are that the -5 stubs will be ~1/10th the size of -4 stubs, but this is only an estimation.
As mentioned, we will also be changing the status bar so that it updates more frequently.
Moo!
dB!
We gave ourselves another 6 hours to do last-minute proxy upgrades and what-not, so the new time to 'flip the switch' is 0600 GMT. If you'll be asleep at that time, fear not: your clients should automagically connect at 0615 GMT and grab OGR blocks, assuming that you've enabled the contest.
Sorry for any 'cowfusion' }:8)
There is one possibility that you forget: the clients could legitimately be there. There are many people in acedamia that love distributed.net and fully support it's use, and oftentimes, the client is installed by an admin.
Unfortunately, there are those who install the client without permission, and against the distributed.net AUP.
To take your comments one at a time...
.plan for more info.
because it was supposed to add stability and scalability that was not available in the NT/SQL config they had before.
Statsbox II is more stable and scalable than Statsbox I. sbI was having more and more hardware issues. It was also a single Pentium 166 that was OC'd to 200MHz. sbII is currently a dual PII-300, and the motherboard should support any Slot 1 CPU. This mobo will also support up to 1G of RAM and currently has 1/2G installed. sbI was maxed out with 256M, iirc.
Well, it's no faster. Crashes and corrupts just as often,
Based on what measure? The RC5 statsrun dropped from over 6 hours with stats turned off to under 4 hours with stats left on. Even with the ever increasing RC5 statsrun time (it will keep getting longer until the project is done) and CSC stats, we're still finishing stats in less time than on sbI, and we're leaving HTTP access enabled durring the run.
We've also had far less unexpected downtime with this setup than with sbI. In fact, I can't think of any hardware issues that have affected sbII. The current problem was caused by human error, read my
they have failed misserably at putting the functionality back into the stats pages.
This is the only argument yake that holds any weight, as far as I can see, but I'd like to know what is missing other than all of the CPU/OS info that the old site had? Also please note that there is CPU/OS info available for CSC (see here and here).
Since I do d.net more 'cause stats are cool than any other reason, it kinda pisses me off...
You're certainly not the only participant who is a stats-junkie (I'm one myself). We do try and take stats very seriously, but unfortunately, there's only so much time in our days. Nugget, Bruce, and I are working on our next version of stats, which will be far more robust (and hopefully will include cross-project stats). Sometime in the future, we will also be looking to bring some more PHP and SQL folks on-board.
I hope you can undertand how discouraging a post that is full of misinformation can be to those of us who are working to improve stats.
Our true purpose is to promote wide-area distributed computing... encryption contests just happen to be the vehicle we've used to do that so far. OGR will be the first contest that breaks that mold.
For those who are interested, I would suggest taking a peek at our mission statement.
We're not aware of any current issues with RC5 or CSC stats, other than this teams issue (teams are cross-project, so this problem will affect both RC5 and CSC stats).
We started working on CSC not long after the contest was announced. I don't have the announcement handy, but I believe we announced we'd be working on it sometime in May or June of 1999. That announcement would probably have more details, but in a nutshell, we did CSC because it was relatively easy to add to our current network infrastructure, and because it would be a nice, quick contest that would serve as a nice break from RC5-64. Since we only keep 20% of the prize, I wouldn't say we really did it for financial reasons, not that $2k EURO is anything to sneeze at. }:8)
As for posting Dcypher announcements, I will only mention that there have been several articles posted about Dcypher, and several articles posted about distributed.net since Dcypher opened it's doors.
Moo!
dB!
I havn't had a chance to talk to Nugget yet, so I don't know what he saw or what reports he had, but I think that what happened is that all team joins for Dec. 30 were lost. Unfortunatly, we had no way to recover those, so anyone who joined a team or changed their team affiliation on Dec. 30 would be affected. IIRC, we saw about 10 people from Dec. 26-Dec. 29 who changed their teams, so this will probably affect only a very, very small number of people. Since I havn't talked to Nugget yet, there could be something else going on that I'm not aware of though.
/. }:8)
As others have pointed out, no blocks have been lost, and if you weren't on a team before, your blocks will all get assigned when you join the team of your choice (part of the nightly statsrun assigns any blocks for a given participant with a team ID of 0 to that participant's current team, assuming that their current team isn't 0).
Sorry for the confusion. As other's have mentioned this really isn't a big deal. Of course, it never hurts to get mentioned on
dB!
decibel@distributed.net
Nuff 'said. }:8)
I can't live without my Gateway AnyKey keyboard... I know that there's programs that will allow you to do keyboard macros, but you simply can't beat the convenience of having programmable macros available right from the keyboard! I know it sounds silly/dumb, but once you've gotten used to it, you can't do without. I've got 2 extra ones just in case Gateway stops making them.
If you read Insight Magazine (website at http://www.insightmag.com/), then you will have seen numerous reports on how poor security (and worse) has allowed a lot of space technology to leave the US for China.
As for the space shuttle, it's a pretty safe bet that it was developed by the US. Don't forget that it's like the 4th generation of US rocketry.
Well, unfortunately I'd have to admit that we don't always move as fast as I'd like to see, but I certainly don't think that we're slow, blumbering, or don't get anything done. In 6 months we've expanded our network to be able to handle non cryptographic contests (OGR), have launched one new contest, and are very close to launching a second new contest. This is on top of all the normal day-to-day operational work that goes on.
I can understand wanting to have the fastest, most efficient cores possible, we'd also like to see that. But how long do we wait for highly optimized cores (FWIW, I was told by our coders that they did in fact spend time optimizing the cores)? We may only be working on this contest for a matter of weeks, so does it make sense for our coders to spend time on optimizing CSC, when they could be working on finishing OGR? Maybe it does, maybe it doesn't. As it turns out, we've had numerous offers from people to work on x86 ASM cores since the source was released yesterday, so it is quite possible we'll have optimized cores available some time soon, at least for the x86 architecture.
As far as stats go, I guess that is one advantage that a smaller effort will always have over a larger one: the ability to reach very high levels in the stats. Unfortunately, that's completely counter to the entire concept of distributed computing, where each CPU does a very small piece of work. On the other hand, a new contest like CSC does provide the perfect opportunity to climb in our stats.
Moo!
dB!
IANAC (I am not a coder :) ), but we havn't done any core optimizations in the current client. If we get a large portion of our users converting over, we probably won't have to either, since we could exhaust the entire keyspace in a matter of weeks. Assuming that's the case, we're much better off getting unoptimized clients out the door, rather than spending weeks working on hand tuned assembly language cores.
One of the interesting things that happens when you get a very large group of CPUs together is that you don't always need or want to be very effecient on the CPU level... it's more important to be effecient at the *network* level. In this case, we're trading off effeciency in CPU cycles for time. Another potential example is algorithms that do not parallelize well, ones that need lots of inter-process communication for example. It might be possible to modify these algorithms to remove some of the inter-process communications at the cost of increasing CPU power needed. This wouldn't make sense if you were running on a single power machine, but if you're using a wide-area distributed computing network, it could make a *lot* of sense.
Decibel
decibel@distributed.net
This isn't cast in stone, but we would most likely convert it to US$, since there would most likely be a 10kEuro check made out to us, and then we would split the prize 60/20/10/10 to the charity voted for by the participants/distributed.net itself/the user who finds the key/that users team (if the user is not on a team, they get 20%).
If the winning user or team were located in Europe, we might ask CS if they'd be willing to send checks directly to them.
Decibel
distributed.net Controller
decibel@distributed.net
The l ink in the above comment is actually a presentation about the cluster. Here's the juicy bits:
- The primary purpose is to be a scalability testbed
- They expect the cluster to eventually grow to 1000+ nodes (they have a timeline that indicates that they should be getting ready to install the next 768 nodes RSN)
- They mention some sample applications
- There's a 16' x 8' Active Mural
- It will be open to open source development groups and 'people who ask nicely'
- They mention some of the unique management issues here and here
- The cluster is organized as "towns"
- The cluster is actually comprised of 3 12 systems in it's current config.
- Here's the system configurations and network topology
We sucessfully completed RSA rc5-56 challange October 22, 1997 (See our full history at http://www.distributed.net/history.html ), over two years ago. We are currently working on rc5-64, which is 256 times harder than rc5-56. Were we to tackle rc5-56 again, we could crack it in a matter of days.
dB!
decibel@distributed.net
Unfortunatly, my experience with trying to get help in #freebsd has been pretty bad in general, and I'd like to think I'm not asking very dumb questions. Generally, it's a bad place to go for help; in fact, I'd say it's the wrong place to go for help since the topic is often "This isn't a help channel! http://freebsd.org or RTFM".
There is #freebsdhelp, which is much more 'user friendly' but unfortunately doesn't have as many people in it (when someone in #freebsd does decide to answer your question you usually know immediately, whereas #freebsdhelp is much 'slower').
I really love FreeBSD, and I *personally* find it much easier to work with than RedHat (the only Linux I've ever tried). I just wish the online support was a little better.
dB!
Yes, the 'core' is open source, and we love it when anyone sends us any patches to the cores that increase their speed.
Using the FPU in parallel is something that has been tossed around (along with a 'core' for video cards and printers), but no work has been done that I'm aware of.