Posts by Professor Ray

1) Message boards : Number crunching : Minirosetta 3.73-3.78 (Message 79435) Posted 24 Jan 2016 by Professor Ray Post: This version uses the latest Rosetta source code which includes an improved score function, new protocols (for example a new cyclic peptide modeling protocol), and some modifications to the graphics application. This insinuated itself whilest crunching a v3.65 WU was retained in memory. Currently my machine is crunching WCG WU - both v3.65 & v3.71 Rosetta WU are RAM'd - prolly to swap space that's been striped across two U160 15k SCSI HDD. Its a pain in the neck - but I do it - when that v3.65 is done, I can gets rid of the old DB zip? And THEN only make symlinks to the newest DB? I've mentioned this before: I'd like better control over the DB extract process - so as to automate via script the symlink creation; but I was shouted down, belittled and trivialized by those superior to myself. I understand; that's the consequence of progress. :( That notwithstanding, once I can participate with 'progress' I'm certain I'll be a happy camper. ;) Imagine crunching on the video card, or even surpassing the 3.5GB memory constraint because of the hardware platform my O/S runs on! Oh, the future is such halcyion days!
2) Message boards : Number crunching : It seems I'm back into the fold (Message 79273) Posted 22 Dec 2015 by Professor Ray Post: Heh heh heh; I just realized that's a pun. There were some issues a while back crunching Rosetta WU's on my PIII-1400S - a non-SSE2+ CPU - and I put the project on suspension, i.e., no new work. I've been dealing with delayed write errors / drive not ready, adpu160m error codes for the last two years. Since mid-summer this year the problem became excruciating in severity; multiple occurrences of HDD with multiple logical partitions suddenly becoming 'unallocated'. NOTHING was never EVER consistent, albeit things seemed associated, e.g., heat, humidity, arbitrary HDD, arbitrary SCA2 SCSI connector, SCSI terminator, SCSI cable/SCA2/terminator LVD compatibility, etc.. After one of the HDD 'un-delete' - of all associated partitions and $MFT - using a utility I'm not going to spam-about recovery procedures, BOINC suddenly began to download AND PROCESS - successfully - Rosetta WU's. BTW, I discovered what the gremlin in my system was: a sagging +5v rail in my 500w PSU. I NEVER thought to examine that aspect since I ran for 8 years on a 300w Tiger PSU, and replaced it with a unit having 5/3 capacity. Never in my wildest imagination would I have dreamed that in less than TWO YEARS such PSU couldn't meet the wattage of 3x 15k SCSI HDD @ 12v1A / 5v@1.2A... It wasn't until I stuck a multi-meter's probe's into the various molex-connector connections and observed what voltages I had while the system was running and to the point of failure, i.e., no snse, drive not ready, et ali. Whenever the +5v went to +4.59v, whichever drive was being accessed suddenly disconnected from the buss. The mobo HW-monitor I was using never suggested such deep sag at the peripheral. Spend $100 real-value for a PSU and replace your existing OEM / VAR PSU if its more than two years old, or unless you KNOW you paid x-tra big-time for upgrade. The foregoing notwithstanding: I'm quite happy to be happy to be back crunching Rosetta on my ancient machine. I'm happy to be doing so for as long as you'll have me. If the powers that be decide to throw me under the bus in favor of GPU or SSE2+ ONLY machines, I'll throw the project under the bus - as I did Einstein today.
3) Message boards : Number crunching : Minirosetta 3.62-3.65 (Message 78818) Posted 18 Sep 2015 by Professor Ray Post: For all of you tech snobs out there, keep your condescending, denigrating, snarky, belittling, and superior comments to yourself; contact me via private mail for the particulars on sending me the hardware that meets your minimum standards of acceptance to be cool as a humanitarian aide gesture. There's a reason that I'm running the hardware platform that I am. Instead of snarking down at me, and people like me, why don't you offer a helping hand and send us all that glorious hardware that meets the requirements to be cool enough to be in the same room as you?
4) Message boards : Number crunching : Minirosetta 3.62-3.65 (Message 78817) Posted 18 Sep 2015 by Professor Ray Post: I'm very sad to see that my darling Rosetta - of 10 years - has broken up with me - throwing me under the bus - akin to a Twitter / Facebook break-up posting. It is presently the 5th best producing project behind Cosmology, Leiden, SETI & WCG. Over the last decade we've had some good times though; 23379 WU credits worth. FWIW: Einstein recently did the same thing to me. It STILL is my second best WU cruncher - despite abandoning me in favor of GPU centric cruncher hosts - nearly a 1 1/2 years after their hardware efficiency optimization. I foresee a day in the near future when I'm going to take all my old electronic equipment - old motherboards, video cards, RAM, power supplies, VCR, TV, et ali - and toss it all into a 55 gal drum supported by cinder-blocks. I'm going to light a charcoal fire underneath, douse the barrel contents with lighter fluid, and cook it for a week. The slag that comes out of that kiln I'll sell to a recycler. That's what I think of your project 'upgrades' requiring new hardware.
5) Message boards : Number crunching : Minirosetta 3.62-3.65 (Message 78805) Posted 16 Sep 2015 by Professor Ray Post: ALL of my Rosetta WU blow up immediately on my PIII-1400S Win 2003 R2 system.
6) Message boards : Number crunching : ninirosetta_database slot folder (Message 78147) Posted 21 Apr 2015 by Professor Ray Post: FWIW, my Win2003 R2 system runs on a TUV4x PIII-1400S w/ 3x 512MB SDRAM, Adpu160m dual-channel SCSI host controller w/ 3x Fujitsu MAX3073NC 15k HDD platform. %SYSDRIVE% capacity = 11.7GB w/ 1.21GB free, w/ 1.5GB fixed size page file with the NTFS meta-file layout optimized such that directories immediately precede $MFT, followed by custom-defined 'space-reserved for $MFT', followed by $LOG, $BITMAP, $MFTMirr. The other NTFS metafiles, i.e., $SECURE, $REPARSE, $UPCASE, $ATTRDef and $USRJRNL are placed on the tracks outer to, and immediately adjacent, to the track holding the $MFT. Moreover, $USRJRNL has been custom-sized for optimum fragmentation minimization, in that the $USRJRNL file is locked during Windows Protected Mode and therefor can only be defragged at boot-time before Windows Protected Mode starts. Furthermore, default size of both $USRJRNL and 'space-reserved-for-MFT' are stupidly huge, i.e., for the latter it amounts to 25% of HDD - or partition - capacity and is placed by default at the outer 60% tracks. My 11.7GB capacity / 1.2GB free %MFT is 62MB with 34MB 'reserved-for-MFT' space. The $USRJRNL metafile by default is also much larger than necessary. It is a FIFO type sparse file, i.e., when NTFS journaling entries exceed the max size, it truncates the first journal entries, and scatters unmovable blocks throughout the drive. My custom sized $USRJRNL amounts to 5 blocks. Default sized $USRJRNL would scatter hundreds of blocks around the drive that are unmovable. Drive layout is further optimized where 33% of the most used files are organized to the very outer tracks, the remainder sorted to the very inner tracks. The outer tracks are sorted by last modification date descending, and the inner tracks by last access date decending. As such the BOINC projects folders are located in the outer tracks of the inner section, and all the BOINC project slots are on the inner tracks of the outer section. Each is immediately adjacent to the large segment of fee-space which itself is bisected by the $MFT and the page file. Defragging is quick, with minimal thrashing of the HDD in that all fragmentation occurs within one track of all available free-space; 70% of the files are never touched in that they are rarely accessed or modified. The thing is that the MiniRosetta Datase ZIP file lives in the Rosetta Project folder, which in itself isn't a problem. But the contents of this folder get extracted to the Rosetta slots folder, and since those contents are never modified, it gets sorted into very inner tracks during defrag. Now 60% of the HDD gets thrashed during defrag. I fixed the first part of the problem by putting the Rosetta Project folder onto an outter partition of a second drive and created a reparse point - symbolic link - to it into the BOINC Projects folder. BOINC is fat, dumb and happy, and runs as if the Rosetta Project folder lives in %SYSDRIVE% BOINC installation. I fix the second aspect to the problem by creating a junction point for the Rosetta Project slot folder MiniRosetta Database folder that also points to a folder living on the outer partion of the other drive - which incidentally hosts another 1.5 GB page file - the two page files comprising one striped swap file. But dealing with that is manually tedious in that I have to manually extract the contents of the ZIp, pick as link-source, drop as junction in BOINC/Projects/slots, delete the existing miniRosetta_database, and rename the junction point and then delete the trash bin. All of that could be nicely accomplished with a script contained in the minirosetta_database.ZIP if it could be an SFX, i.e., self extracting executable. Then I wouldn't have to do diddle squat as all the reparse - junction - points would be generated by script. One obvious solution would be to migrate the BOINC_Data folder to the alternate HDD where the Rosetta Project folder in specific has been migrated to. However, that HDD hosts a second O/S for my dual-boot system and hosts its own set of mitigating circumstances akin the aforementioned and therefor would be less than ideal; it serves for just this specific use, i.e., hosting Rosetta Project folder and extracted contents of the minirosetta_database.ZIP. BTW, all this talk about reparse / junction points is particular to WinXP technology. In VISTA, Win7 and Win8, the functionality exists for outright 'symbolic links', where specific files can be linked across HDD (which WinXP technology only allows for folders). The sad fact of the matter given my personal financial constraints, the hardware platfor and O/S currently implemented are what they are and won't change in the foreseeable future.
7) Message boards : Number crunching : ninirosetta_database slot folder (Message 77972) Posted 24 Feb 2015 by Professor Ray Post: What I've done is create a junction, i.e., reparse point for the //projects/boinc.bakerlab.org_rosetta folder having target being on another disk. That offloads the 207MB minirosetta_database_3d2618f.zip file. I've extracted the contents of that miniroettaDB ZIP to a separate folder, i.e., minirosetta_database, on the same drive. That offloads another 317MB for the transient DB folder, netting a total 1/2GB space saved on %SYSTEMDRIVE%. Is it possible to replace the existing ZIP file with an SFX - implementing a pre-extraction batch / script - or perhaps, ideally, the script itself. The script - either CMD or BAT - would accomplish automagically creation of junction - reparse point - in the //SLOTS working directory for the current WU having target of this once-for-all-time extracted minirosetta_database ZIP. Right now its tedious in that such needs to be accomplished manually.
8) Message boards : Number crunching : ninirosetta_database slot folder (Message 77557) Posted 7 Oct 2014 by Professor Ray Post: I drilled into the matter a bit and noticed the comprehensive content of the database folder. Moreover, I discerned that content within that folder was indeed being sorted into the outer - high performance - tracks. I don't believe that its using a significant amount of the folder content however. I think what I'm going to end up doing is alter the defrag method based on the presence of Rosetta WU. Next time its not present on the HDD, I'll do a strict sort defrag as aforementioned; everything will be defrag'd and compacted to sonsolidate free space in a strict sort order. However, after that whenever it shows up again, I'll implement a generic consolidate defrag. That one doesn't implement the strict sort as described, but throws files into either section on a first come first serve basis with the ultimate aim of purely consolidating free space. That, over time, becomes increasingly inefficient as the method throws files into holes wherever it can with the objective being purely that of free space consolidation. That notwithstanding, the minisrosetta_database contents will get sorted into the very outer tracks of the inner - archive - section, and the high performance attributed database files will get lain on the inner tracks of the high performance section. That's cause the stuff already there won't get moved. Very much akin to shaking a jar of various sized grains. That way only the inner most tracks of high performance, e.g., all BOINC slot folders containing WU, checkpoints and result files, and the very outer tracks of the inner archive tracks - containing, e.g., BOINC project exectutable folders - will be affected by defrag. I think this is a design flaw; the project should extract the mniRosetta_database and blow away what it doesn't need for the specific WU its crunching. Space is being wasted by redundant - and unused - data, i.e., that which is archived in the BOINC_Dataprojectsboinc.bakerlab.org_rosetta zip file(s). I fully comprehend why that monstrosity lives there: so 300MB of data doesn't need to be downloaded with each WU. Just seems inefficient use of client resources though.
9) Message boards : Number crunching : ninirosetta_database slot folder (Message 77547) Posted 5 Oct 2014 by Professor Ray Post: In the slot 2 folder of my currently executing WU is a subfolder - minirosetta_database - that comprises 309MB (316 w/ slack). This guy is a little bit of a prollem. I layout the HDD in three sections according to Pareto's Rule, 80% o the time 20% of the files are actually used. The outter tracks are reserved for high performance related files - most frequently used - and are sorted by last modification time descending. The middle section is dedicated to free space and the NTFS metafiles, e.g., $MFT, $MFT reserved space, $USN_Journal, etc. NTFS metafiles and the page file are continguous and bisect the freespace. The inner tracks are the least used sorted by last access date descending. With this scheme, modified files will have near immediate access to free-space. File fragmentation is constrained to within less than 15% of the disk area. Moreover, files that do not meet high performance criterion - most frequently used - are lain on the very outer tracks of the inner 'archive' section according to date last access. In general this prevents churning of data on the HDD during defrag; files will be consolidated fairly near to where they exist in fragmented form, e.g., previous AV def file that become a 'repair' version if the AV def update fails; the 'live' AV def lives in the very outer tracks - to facilitate boot-time - and the repair copy lives in the outer tracks of the least-used 'archive' section. In theory fine and dandy and in general works fairly well. The problem with the scheme is that the minirosetta_database folder gets laid out 1/3 of the way into the least used portion of the drive. UD3 puts it there based on use, i.e., access or modification. What ends up happening, because the folder is transient from WU to WU, the inner 80% of data is constantly getting thrashed from defrag to defrag predicated on whether a Rosetta WU is being crunched, or not. What good is that folder if its not being used?
10) Message boards : Cafe Rosetta : Played by humans - scored by nature (Message 77455) Posted 12 Sep 2014 by Professor Ray Post: http://eterna.cmu.edu/web/ Very cool "game" that allows users to create RNA molecules and ultimately propose tests to be conducted in the laboratory that will cost umpteen $billions. There's a pretty steep learning curve, i.e., understanding different amino acid-base types, their bonding affinity, essential shapes that RNA forms based on types of bonds established and ultimately what is referred to as 'free energy', i.e., potential energy, that any arbitrary sequence of amino acid-base pairs intrinsically possesses to affect the folding of the RNA sequence. The stupefying science notwithstanding, its a game that avails itself of the stupendous characteristic of the human brain: pattern recognition and intuition. Players get a *feel* for what works and what won't. 4th graders play this game all talkin' about problems their trying to solve, invoking the rules of the game as if they're doctoral undergrad students - despite not understanding anything about the rules except that the rules exist - and they fully understand performing the spin-move in DOOM, HALO, et ali w/ out having a glimmer of understanding with respect to kinematics of motion in 6 degrees-of-freedom and couldn't integrate the most simple equations with respect to such to save their immortal soul. But any teeny-bopper knows how to do the spin-move on their X-Box / GameBoy / et ali. And that's what eteRNA attempts to tap: the arcane power of humane intuition. By the time any arbitrary player has achieved the proverbial "level 33", there are actual real-life laboratories populated by scores of actual undergraduates, doctoral thesis study-students and Ph.D's having minions, that are willing to go to before the powers-that-be, to spend $billions to performs experiments to discern which of the three solutions for some arbitrary RNA molecule puzzle actually work. Just thought I'd share that (in case nobody's ever heard of this). WARNING: highly addictive, will consume trillions of otherwise unneeded heartbeats and cause many many many sleepless nights. The OP is to be wholly and totally held free of any claims to indemnity either real or wholly imagined. Void where prohibited. You mileage may vary. Not valid in the state of shock or confusion. Use at your own risk; caveat emptor.
11) Message boards : Number crunching : Fullatom mismatch - computation error (Message 77452) Posted 11 Sep 2014 by Professor Ray Post: The above WU is the only one that's died so far. That notwithstanding, it seems that that error encountered is not unheard of: http://ralph.bakerlab.org/forum_thread.php?id=557&nowrap=true#5785
12) Message boards : Number crunching : Fullatom mismatch - computation error (Message 77451) Posted 11 Sep 2014 by Professor Ray Post: http://boinc.bakerlab.org/rosetta/result.php?resultid=690468920 <core_client_version>7.0.64</core_client_version> <![CDATA[ <message> Incorrect function. (0x1) - exit code 1 (0x1) </message> ... Continuing computation from checkpoint: chk_S_00000015_FastRelax__chk28_fa ... success! ERROR: Fullatom mismatch in checkpointer. ERROR:: Exit from: ......srcprotocolscheckpointCheckPointer.cc line: 379 std::cerr: Exception was thrown: [ERROR] EXCN_utility_exit has been thrown from: ......srcprotocolscheckpointCheckPointer.cc line: 379 ERROR: Fullatom mismatch in checkpointer. </stderr_txt> ]]>
13) Questions and Answers : Wish list : Comodo Internet Security - Trusted Vendor List Sign Up (Message 67799) Posted 24 Sep 2010 by Professor Ray Post: Given the dynamic nature of BOINC projects, i.e., multiple clients that may be viable depending on the science that is being conducted for any arbitrary project's WUs, it would facilitate things for project participants that utilize firewalls, HIPS applications such as Comodo Internet Security, if project developers would digitally sign their binaries with a certificate from a trusted CA. http://internetsecurity.comodo.com/trustedvendor/signup.php The above URL is a link to a form that allows software vendors to request the addition of their software to the Trusted Vendor List that ships with Comodo Internet Security. This ensures their software will be automatically trusted by the application. •Your software must be available for download by [Comodo] technicians •Your software must be code signed with a certificate from a trusted CA (self-signed code signing certs are not acceptable) •The 'Company Name' you provide below matches the name of the signer on the certificate •You must provide a valid email address
14) Message boards : Number crunching : Application phoning home? Why? (Message 67709) Posted 11 Sep 2010 by Professor Ray Post: In fact I've detached from the project.
15) Message boards : Number crunching : Application phoning home? Why? (Message 67708) Posted 11 Sep 2010 by Professor Ray Post: Succinctly put: What permissions should I establish for BOINC 'projects' as a global rule to phone home in event of tiny nuclear accident where a little bit radiation was let out? I need to know PRECISELY who should be notified by whom? This circumstance is bizarro world. I've NEVER seen this since Apr 2010 (and my machine is a BOINC goose for WU's). I aint givin' no BOINC project carte blanche inter-web access. Aint happeninin'. Aint NO way. Roger that. RESTRICTION! NO new tasks Talk to me, we'll discuss unrestricting the project.
16) Message boards : Number crunching : Application phoning home? Why? (Message 67707) Posted 11 Sep 2010 by Professor Ray Post: Succinctly put: What permissions should I establish for BOINC 'projects' as a global rule to phone home in event of tiny nuclear accident where a little bit radiation was let out? I need to know PRECISELY who should be notified by whom? This circumstance is bizarro world. I've NEVER seen this since Apr 2010 (and my machine is a BOINC goose for WU's). I aint givin' no BOINC project carte blanche inter-web access. Aint happeninin'. Aint NO way. Roger that. RESTRICTION !
17) Message boards : Number crunching : Application phoning home? Why? (Message 67704) Posted 11 Sep 2010 by Professor Ray Post: Succinctly put: What permissions should I establish for BOINC 'projects' as a global rule to phone home in event of tiny nuclear accident where a little bit radiation was let out? I need to know PRECISELY who should be notified by whom? This circumstance is bizarro world. I've NEVER seen this since Apr 2010 (and my machine is a BOINC goose for WU's). I aint givin' no BOINC project carte blanche inter-web access. Aint happeninin'. Aint NO way.
18) Message boards : Number crunching : Application phoning home? Why? (Message 67703) Posted 11 Sep 2010 by Professor Ray Post: Interesting. Yes, I noticed that that IP address is in my MSECN.net port 80 zone. That's one of the things I wondered about: why is Rosetta hitting MS' edge caching net? Both times Rosetta phoned home it coughed up a bit-ball: 9/10/2010 5:41:02 PM rosetta@home Restarting task lr5_jorj_combined_torsion_it05_run01_A_rlbd_1t2i_SAVE_ALL_OUT_IGNORE_THE_REST_DECOY_21164_1655_0 using minirosetta version 214 9/10/2010 5:46:36 PM rosetta@home Computation for task lr5_jorj_combined_torsion_it05_run01_A_rlbd_1t2i_SAVE_ALL_OUT_IGNORE_THE_REST_DECOY_21164_1655_0 finished 9/10/2010 5:46:36 PM rosetta@home Output file lr5_jorj_combined_torsion_it05_run01_A_rlbd_1t2i_SAVE_ALL_OUT_IGNORE_THE_REST_DECOY_21164_1655_0_0 for task lr5_jorj_combined_torsion_it05_run01_A_rlbd_1t2i_SAVE_ALL_OUT_IGNORE_THE_REST_DECOY_21164_1655_0 absent Rosetta phoned home at 5:46:13 PM After the final death throe tremor, he began downloading 'nother WU. It too horked a bit-ball: 9/10/2010 6:02:53 PM rosetta@home Starting Dengue9Sept2010_3c5x_1gis_ProteinInterfaceDesign_9Sep2010_21855_28_0 9/10/2010 6:02:54 PM rosetta@home Starting task Dengue9Sept2010_3c5x_1gis_ProteinInterfaceDesign_9Sep2010_21855_28_0 using minirosetta version 214 9/10/2010 6:12:05 PM rosetta@home Computation for task Dengue9Sept2010_3c5x_1gis_ProteinInterfaceDesign_9Sep2010_21855_28_0 finished 9/10/2010 6:12:05 PM rosetta@home Output file Dengue9Sept2010_3c5x_1gis_ProteinInterfaceDesign_9Sep2010_21855_28_0_0 for task Dengue9Sept2010_3c5x_1gis_ProteinInterfaceDesign_9Sep2010_21855_28_0 absent Rosetta phoned home at 6:09:25 PM and then went belly up. The WU immediately downloaded thereafter - gunn_fragments_SAVE_ALL_bla_bla_bla - hasn't started yet. If this is a 'computer security policy' permission issue, I haven't a clue; BOINC apps are co-equal master's of their own domain and god's of their little individual fiefdoms in accordance to 'computer security permissions' established for the 'BOINC_Projects file group. The 'BOINC_Projects' file group is defined as: %BOINC_data_HD%BOINC_Dataprojects* %BOINC_data_HD%BOINC_Dataslots* That file group has 'installer or updater' computer security policy permissions; they're essentially masters of their domain (kings of their castle), etc and can trash or obliterate each other's projects / slots to their hearts content. Moreover, %BOINC_Prog_HD%BOINC.exe has access rights to run as executable ANYTHING in the 'BOINC_Projects' file-group; long time ago I threw in the towel trying to define what's runnable in there. Furthermore, %BOINC_Prog_HD%BOINCmgr.exe has access rights to run as executable: %BOINC_Prog_HD%BOINC.exe %PROGRAMFILES%Internet Exploreriexplore.exe %BOINC_data_HD%projects* %SystemRoot%boinc.scr %BOINC_Prog_HD%boincscr.exe Why can't Rosetta use %BOINC_Data_HD%symbols? If Rosetta can't use that for what putatively is posited as being the cause to phone home, what the F do I need to waste 10% of a bloody GB?
19) Message boards : Number crunching : Application phoning home? Why? (Message 67696) Posted 10 Sep 2010 by Professor Ray Post: Just had Minirosetta_2.14_windows_intel386.exe try to phone home: 207.46.209.243 What is that IP address? Moreover, why is an app trying to phone anywhere? The only thing that has ever phone'd home is BOINC.exe and that to very specific and identifiable IP's relevant, pertainant and germane to either BOINC, or the project itself. The default destination IPs for BOINC.exe is defined by the project host names as seen in the message log when BOINC starts. The projects that require additional IP addresses for results are specifically SETI, Einstein, Lattice & Rosetta. The Rosetta specific IP's that have been resolved are: 140.142.20.107/140.142.20.125 The only exception to this is when BOINC.exe attempts to ascertain internet connection by attempting to contact IP's in the 1e100 domain. However, never have I seen projects attempt connection to any IP whatsoever. Furthermore, in this particular instance - never having occured before - no results are being transmitted as the IP connection attempt occurs shortly after Rosetta launches and begins processing WU.
20) Message boards : Number crunching : Win2003, Rosetta 2.05 & Comodo Firewall (Message 65526) Posted 11 Mar 2010 by Professor Ray Post: Nope, low density chips. The problem is I thought I had 3x256MB when the DIMMS I swapped in were actually 3x128. I'm virtually certain that's the issue here. While other projects have run just fine for the last two weeks, obviously Rosetta needs more physical RAM (despite having 1152MB swap file). The ECC RAM I swapped out I've been using for years. However, because of repeated NMI machine check memory parity errors after replacing a fried mobo, I figured the mobo damaged one (or more) of the DIMM modules. I know it damaged the slot-1 P3 1000; CPU running at 70+ Deg. C. plus all sorts of other errors too (non NMI machine check related). So I swapped out the ECC RAM with non-ECC RAM I had on hand (stuff I bought before I got the ECC RAM); they're Crucial CL2 non-ECC PC133 DIMMS. I originally paid $175 / stick. I got the ECC SDRAM a couple years later for a mere $75/256MB stick.) To my chagrin, I forgot the non-ECC sticks were only 128MB sticks. So I swapped the original 3 sticks of 256MB ECC SDRAM back in. Wouldn't you know it? Not a single NMI machine check error since this morning. Go figure. And I was getting them errors within minutes of each other. Machine was unuseable until I swapped all the RAM out with those 128MB sticks. Now I'm running on the original RAM with no errors. Dunno. Memtest86 checked out on all the RAM too, so I don't know. Its a used mobo, maybe the mobo's bad. Its a used CPU too, and the 866 is screaming at 976, so dunno. I've got a P3-S 1.4Ghz coming, along with 2x512 MB non-ECC CL2 PC133 SDRAM. Should be here any day now.

Next 20