I got my hands on yet another MSI 6905 ver 2.3 slotket (as if I didn't already have enough of these grinning face with sweat ).
Tested it with many socket 370 CPUs (including Pentium 3 1 GHz, VIA C3 Nehemiah, etc) on a few motherboards (Asus P3B-F, Gigabyte 6BXC rev 2.0, Amptron PII-3100B) and everything seems to work great, however, I noticed that it has a mod that I don't quite understand.
Basically, it connects the LINT1/NMI pin to ground through a capacitor (see attached pics). I did some digging and came out empty, this mod doesn't appear to have been "a thing". Maybe it can improve the compatibility with certain motherboards or, perhaps, improve stability (suppresses transient spikes/high-frequency noise)? What do you think, does this ring a bell in any way? I'm thinking of removing it because, from my experience, this mod is not needed. Here are a few pics:
2 x PLCC-68 / 4 x PGA132 / 5 x Skt 3 / 1 x Skt 4 / 9 x Skt 7 / 12 x SS7 / 1 x Skt 8 / 14 x Slot 1 / 6 x Slot A
5 x Skt 370 / 8 x Skt A / 2 x Skt 478 / 2 x Skt 754 / 3 x Skt 939 / 7 x LGA775 / 1 x LGA1155
Current PC: Ryzen 7 9800X3D
Backup: Ryzen 7 5800X3D
It is probably a factory mod. Photo's of the pcb show that the version of week 34/2000 has it but the version of week10/2000 did not (yet)
Very interesting! Thank you, @PARKE!
It did not occur to me that this could actually be a factory mod, since I own multiple versions of this slotket (v1.1, v2.0, v2.3) and none of them have it. It's so strange that it was needed, especially for such a late revision.
2 x PLCC-68 / 4 x PGA132 / 5 x Skt 3 / 1 x Skt 4 / 9 x Skt 7 / 12 x SS7 / 1 x Skt 8 / 14 x Slot 1 / 6 x Slot A
5 x Skt 370 / 8 x Skt A / 2 x Skt 478 / 2 x Skt 754 / 3 x Skt 939 / 7 x LGA775 / 1 x LGA1155
Current PC: Ryzen 7 9800X3D
Backup: Ryzen 7 5800X3D
It seems that it was not easy going for MSI getting their slotkets right. VER. 2.1 of the Master was an improved pcb edition with a 4-pin JP3 block but the pcb's of VER. 2.2 and VER 2.3 look the same as REV. 2 but with stickers applied. It happened between week 7/2000 and week 34/2000. This shows the development for as far as I have been able to piece it together and it may be only part of the story:
@bloodem - Can you please test Via C3 Nehemiah with your MSI slotket and 3DMark2000 (for 48 hours)? I am having stability issues with my Abit Slotket iii. The symptom is that it will crash to desktop after a few hours. I don't have the issue with Ezra-T.
edit 2/20/2025: Confirmed the Abit slotket was the issue. See here.
Last edited by mockingbird on 2025-02-20, 14:07. Edited 1 time in total.
It seems that it was not easy going for MSI getting their slotkets right. VER. 2.1 of the Master was an improved pcb edition with a 4-pin JP3 block but the pcb's of VER. 2.2 and VER 2.3 look the same as REV. 2 but with stickers applied. It happened between week 7/2000 and week 34/2000. This shows the development for as far as I have been able to piece it together and it may be only part of the story
What's weird is that I never really had any issues with any of the versions. They all run very well even with more power hungry CPUs.
Well, truthfully, I never had issues with any slotkets, even the cheap no-names that I have never gave me any headaches.
@bloodem - Can you please test Via C3 Nehemiah with your MSI slotket and 3DMark2000 (for 48 hours)? I am having stability issues with my Abit Slotket iii. The symptom is that it will crash to desktop after a few hours. I don't have the issue with Ezra-T.
Strange. I absolutely ran 3DMark 2000 stability tests for many hours when previously testing various Nehemiah overclock frequencies/voltages and, outside of general instability when exceeding the maximum frequency that a chip could handle, they ran fine.
Anyway, I have a P3B-F board with a Nehemiah right next to me, so I'll start a test now and report back. grinning face
2 x PLCC-68 / 4 x PGA132 / 5 x Skt 3 / 1 x Skt 4 / 9 x Skt 7 / 12 x SS7 / 1 x Skt 8 / 14 x Slot 1 / 6 x Slot A
5 x Skt 370 / 8 x Skt A / 2 x Skt 478 / 2 x Skt 754 / 3 x Skt 939 / 7 x LGA775 / 1 x LGA1155
Current PC: Ryzen 7 9800X3D
Backup: Ryzen 7 5800X3D
What's weird is that I never really had any issues with any of the versions. They all run very well even with more power hungry CPUs.
Well, truthfully, I never had issues with any slotkets, even the cheap no-names that I have never gave me any headaches.
Maybe the production or the post production selection was not stable. I have run across a couple of reports that the VER. 2 gave problems with Coppermines. Plus there must have been a reason for the quick succession of revisions I think. The first generation (without the Master denomination) was also not without problems; REV 1.1 with pcb "B" was called back.
Strange. I absolutely ran 3DMark 2000 stability tests for many hours when previously testing various Nehemiah overclock frequencies/voltages and, outside of general instability when exceeding the maximum frequency that a chip could handle, they ran fine.
Anyway, I have a P3B-F board with a Nehemiah right next to me, so I'll start a test now and report back. grinning face
Thanks, much appreciated. I have another Nehemiah on its way in the mail and I'm picking up a different model slotket today so I'll see if that helps... But I am leaning towards the CPU being defective since my Ezra-T is completely stable.
Thanks, much appreciated. I have another Nehemiah on its way in the mail and I'm picking up a different model slotket today so I'll see if that helps... But I am leaning towards the CPU being defective since my Ezra-T is completely stable.
You're welcome. 3DMark2000 has been running in a loop for 5.5 hours now, no crashes.
I should also mention that this particular Nehemiah is kind of a golden sample, it's overclocked to 1.53 GHz (FSB133 x 11.5), at the default voltage (1.45V)
Full system specs, for posterity:
MB: Asus P3B-F rev 1.03
CPU: VIA C3 "Nehemiah" 1.2 GHz OC @ 1.53 GHz /1.45V w/ Slotket MSI MS-6905 "Master" ver 2.3
RAM: KINGSTON 256 MB SDRAM PC133 CL2 (KVR133X64C2/256) | Timings: 2/2/2/4
GPU: Asus GeForce 3 64MB OC @ Ti 500 clocks / Detonator 7.76
STORAGE: Compact Flash 128 GB
OS: Win98SE (no patches) / DirectX 7.0
2 x PLCC-68 / 4 x PGA132 / 5 x Skt 3 / 1 x Skt 4 / 9 x Skt 7 / 12 x SS7 / 1 x Skt 8 / 14 x Slot 1 / 6 x Slot A
5 x Skt 370 / 8 x Skt A / 2 x Skt 478 / 2 x Skt 754 / 3 x Skt 939 / 7 x LGA775 / 1 x LGA1155
Current PC: Ryzen 7 9800X3D
Backup: Ryzen 7 5800X3D
I just installed the slotket that I had waiting for me at the P.O (testing on a QDI BX board, for now) and started the loop... Yes, I think I got 5 hours with it but the kicker was always when I came back the next day, it was crashed to desktop...
I forgot to ask you to set the benchmark to 1024x768x32 and max everything out.
I just installed the slotket that I had waiting for me at the P.O (testing on a QDI BX board, for now) and started the loop... Yes, I think I got 5 hours with it but the kicker was always when I came back the next day, it was crashed to desktop...
I forgot to ask you to set the benchmark to 1024x768x32 and max everything out.
I will report back how my test went.
I left it yesterday for a couple more hours, stopped it after ~ 7.5 hours (no issues).
1024x768x32 shouldn't make a difference, in fact it would be a worse test, because it stresses the GPU more and the CPU less. So, if you are suspecting a CPU related problem, it makes sense to actually go with 640 x 480 x 16.
2 x PLCC-68 / 4 x PGA132 / 5 x Skt 3 / 1 x Skt 4 / 9 x Skt 7 / 12 x SS7 / 1 x Skt 8 / 14 x Slot 1 / 6 x Slot A
5 x Skt 370 / 8 x Skt A / 2 x Skt 478 / 2 x Skt 754 / 3 x Skt 939 / 7 x LGA775 / 1 x LGA1155
Current PC: Ryzen 7 9800X3D
Backup: Ryzen 7 5800X3D
I left it yesterday for a couple more hours, stopped it after ~ 7.5 hours (no issues).
1024x768x32 shouldn't make a difference, in fact it would be a worse test, because it stresses the GPU more and the CPU less. So, if you are suspecting a CPU related problem, it makes sense to actually go with 640 x 480 x 16.
I'll have to call your test inconclusive then, not that I want to seem like an ingrate, to the contrary I still do appreciate the test...
But I would like at least a 24 hours test with 1024x768x32bpp. I'm pretty certain my Nehemiah also did 7+ hours, the question was always if I would see it kicked to desktop when I came back the next day (i.e. 24 hours later).
P2 Deschutes, P3 Katmai, P3 Coppermine, Ezra-T all were able to pass this test.... Nehemiah doesn't. Both Ezra-T and Nehemiah have the hybrid AGTL+ functionality so I can rule that out (unless there was some major revision to it from Ezra-T to Nehemiah that broke something). But I also tested the Nehemiah with a Lin-Lin to trigger the AGTL+ mode, and that didn't change anything.
Did I mention that I am also always running these tests with an underclocked CPU (900Mhz) and always with a 100Mhz FSB?
But I am taking your advice, and I'm now testing my Nehemiah (it's a 1.2Ghz variant, btw) with my new slotket on my 6BXC board at 640x480x16. The GPU is a GeForce 4 MX440 with T&L enabled. I can later match your GeForce3 if need be to rule that out as well (and yes, I've tried several different GeForce 4 MX cards to rule that out). On a side note, I found the GeForce 4 MX to be a much better choice for this type of system. You can run it without a fan, and in most use cases you don't lose much by dropping to it from a GF3.
I also ran some tests with my P3B-F but I won't go into detail at this time because I have not yet established the reliability of that board... But I have several other boards I am working with to double-check my findings (P2B, P2B-S, 6BXC, QDI P6I440).
I'll have to call your test inconclusive then, not that I want to seem like an ingrate, to the contrary I still do appreciate the test...
Still, if you want to stress test the CPU as much as possible, going with 32bit color is not the way to do it; and the higher color depth would definitely NOT cause the Nehemiah to crash (the CPU itself couldn't care less about the color depth), unless there's a different problem at play here... hard to say. It might even be the nVIDIA driver itself that, for some reason, with your specific hardware combo, craps out when using the Nehemiah.
My suggestion is to try a clean OS install, with an older GPU (such as GeForce 2 MX) and an older nVIDIA driver (like the 7.76).
From personal experience, I know that 3DMark2000 tends to crash to desktop when either the CPU or memory (or both) are unstable. But I'm sure there could be many other issues that cause this type of crash.
Having said that, I would have gladly kept the benchmark running for 24 hours, unfortunately the retro test bench is in my bedroom and my brain refuses to sleep with continuous fan noise. What's funnier is that I also have the same issue with the modern PC (which is virtually inaudible), yet my brain still hears it during the night. rolling on the floor laughing
However, what I can do is run a ~15 - 16 hour test tomorrow, starting from 7 AM up to ~11 PM, and this time I'll go with 1024 x 768 x 32. grinning face Let me know if you think this test would be useful.
2 x PLCC-68 / 4 x PGA132 / 5 x Skt 3 / 1 x Skt 4 / 9 x Skt 7 / 12 x SS7 / 1 x Skt 8 / 14 x Slot 1 / 6 x Slot A
5 x Skt 370 / 8 x Skt A / 2 x Skt 478 / 2 x Skt 754 / 3 x Skt 939 / 7 x LGA775 / 1 x LGA1155
Current PC: Ryzen 7 9800X3D
Backup: Ryzen 7 5800X3D
Still, if you want to stress test the CPU as much as possible, going with 32bit color is not the way to do it; and the higher color depth would definitely NOT cause the Nehemiah to crash (the CPU itself couldn't care less about the color depth), unless there's a different problem at play here... hard to say. It might even be the nVIDIA driver itself that, for some reason, with your specific hardware combo, craps out when using the Nehemiah.
My suggestion is to try a clean OS install, with an older GPU (such as GeForce 2 MX) and an older nVIDIA driver (like the 7.76).
These are the default 3DMark Tests that run on my setup:
11) Game 1 - Helicopter - Low Detail 22) Game 1 - Helicopter - Medium Detail 33) Game 1 - Helicopter - High Detail 44) Game 2 - Adventure - Low Detail 55) Game 2 - Adventure - Medium Detail 66) Game 2 - Adventure - High Detail 77) CPU Speed 1/2 (Game 1 - Helicopter) 88) CPU Speed 2/2 (Game 2 - Adventure) 99) Fill Rate (Single-Texturing) 1010) Fill Rate (Multi-Texturing) 1111) High Polygon Count (1 Light) 1212) High Polygon Count (4 Lights) 1313) High Polygon Count (8 Lights) 1414) 8MB Texture Rendering Speed 1515) 16MB Texture Rendering Speed 1616) 32MB Texture Rendering Speed 1717) 64MB Texture Rendering Speed 1818) Bump Mapping (Emboss, 3-pass) 1919) Bump Mapping (Emboss, 2-pass) 2020) Bump Mapping (Emboss, 1-pass) 2121) Bump Mapping (Environment) - SKIPPED 2222) Image Quality - Theoretical 2323) Image Quality - Game
I need to confirm that the exact same tests are running at 640x480x16bpp as were running on 1024x768x32bpp. I am not 100% certain that this is the case, but I will elaborate more on that later.
From personal experience, I know that 3DMark2000 tends to crash to desktop when either the CPU or memory (or both) are unstable. But I'm sure there could be many other issues that cause this type of crash.
The precise reason why I don't want to start troubleshooting the issue in software is that the test result only changes when the hardware changes, and more specifically, when this particular CPU is used. So I believe that I have strong enough of an empiricism to exclude software as the cause of the issue here. In my view, there are only the following two possibilities:
1) My CPU is bad
2) Nehemiah is very sensitive as to which slotket is being used
I am trying to rule out the second option, and that's why I posted in this thread... The MS6905 2.3 is supposed to be the gold standard of slotkets. On my part, I am testing my own slotket which I obtained only yesterday to also try to rule this out (or to confirm it). It is looking somewhat plausible though, because I can state that it is the only slotket so far that has worked on my P3B-F with Nehemiah (though it did crash in 3DMark -- but again - I don't want to jump to conclusions with my P3B-F, Coppermine without any slotket at 100Mhz FSB also crashed on it).
My first test with this 'new' slotket did not go well. I did my usual test of 1024x768x32bpp but on my QDI P6I440BX board... It crashed to desktop. I am now testing with it on my Gigabyte GA-6BXC board with your recommended settings of 640x480x16bpp and it's been running fine for a couple of hours. But as I said, this is not a conclusive result for me. The first indicator for me will be to see if it can survive the test for 24 hours... If it does, I will proceed to test at 1024x768x32bpp and see if that lasts 24 hours. If it doesn't, I will wait to hear your result. If yours passes, I will test with my Nehemiah that is due to arrive in the mail. If that also fails, I will conclude that the MSI Slotket is the only one that can run the Nehemiah 100% reliably. I'm hoping that is not the case, because they are rare and expensive. If that is the case, then I'll abandon this build.
This was meant to be an 'all-in-one' system, but I do have a separate 386, 486 and Pentium MMX, as well as a "fast" Windows 98 machine.
I'm not revealing the model of the slotket I am testing with to discourage tech hoarders should it be proven reliable, so just to be clear: I am NOT testing with an MS6905 2.3 (I don't own one).
Having said that, I would have gladly kept the benchmark running for 24 hours, unfortunately the retro test bench is in my bedroom and my brain refuses to sleep with continuous fan noise. What's funnier is that I also have the same issue with the modern PC (which is virtually inaudible), yet my brain still hears it during the night. rolling on the floor laughing
However, what I can do is run a ~15 - 16 hour test tomorrow, starting from 7 AM up to ~11 PM, and this time I'll go with 1024 x 768 x 32. grinning face Let me know if you think this test would be useful.
I completely understand. That's a medical condition called hyperacusis and is nothing to be ashamed of. Thanks, yes, it would absolutely be useful and I look forward to hearing back. To add to my deductive process, if your system fails this test, I will then conclude that the Nehemiah is inherently flawed.
I need to confirm that the exact same tests are running at 640x480x16bpp as were running on 1024x768x32bpp. I am not 100% certain that this is the case, but I will elaborate more on that later.
When running in 32bit color, unless you apply one of the modern patches, 3DMark2000 will not run the CPU tests (which do run in 16 bit color). Either way, more tests will run in 16bit color, so that's good. grinning face
The precise reason why I don't want to start troubleshooting the issue in software is that the test result only changes when the hardware changes, and more specifically, when this particular CPU is used. So I believe that I have strong enough of an empiricism to exclude software as the cause of the issue here.
Your assumption is perfectly understandable, however, after having worked for 20 years in this field, I can say that nothing surprises me anymore. And I've certainly had my fair share of software issues that appear out of nowhere when making hardware changes.
If that also fails, I will conclude that the MSI Slotket is the only one that can run the Nehemiah 100% reliably.
Definitely not the case. And, as a proof, tomorrow I will run the test with a different no-name slotket: the FastFame 370SPC rev 1.0. I bought a bunch of these 4 - 5 years ago for $5 a piece.
This particular slotket model was actually mentioned by Intel as being one of the slotkets that failed their internal testing, and yet I've never encountered a single issue with it, even when using more power-hungry CPUs like the P3 1 GHz Coppermine. The Nehemiah runs fine with it, in fact it always ran so well that one of my Nehemiah CPUs is permanently paired with one of these slotkets, always ready for a testing platform. grinning face
I completely understand. That's a medical condition called hyperacusis and is nothing to be ashamed of. Thanks, yes, it would absolutely be useful and I look forward to hearing back. To add to my deductive process, if your system fails this test, I will then conclude that the Nehemiah is inherently flawed.
Not sure if my condition actually has a medical name, because I can sleep just fine with intermittent loud noises, but, for some reason... my brain just doesn't like the continuous sound of fans when it's trying to sleep. grinning face
Will get back tomorrow with the new test results.
2 x PLCC-68 / 4 x PGA132 / 5 x Skt 3 / 1 x Skt 4 / 9 x Skt 7 / 12 x SS7 / 1 x Skt 8 / 14 x Slot 1 / 6 x Slot A
5 x Skt 370 / 8 x Skt A / 2 x Skt 478 / 2 x Skt 754 / 3 x Skt 939 / 7 x LGA775 / 1 x LGA1155
Current PC: Ryzen 7 9800X3D
Backup: Ryzen 7 5800X3D
When running in 32bit color, unless you apply one of the modern patches, 3DMark2000 will not run the CPU tests (which do run in 16 bit color). Either way, more tests will run in 16bit color, so that's good. grinning face
Yes! That's exactly right. That's what I noticed was being skipped.
Definitely not the case. And, as a proof, tomorrow I will run the test with a different no-name slotket: the FastFame 370SPC rev 1.0. I bought a bunch of these 4 - 5 years ago for $5 a piece.
This particular slotket model was actually mentioned by Intel as being one of the slotkets that failed their internal testing, and yet I've never encountered a single issue with it, even when using more power-hungry CPUs like the P3 1 GHz Coppermine. The Nehemiah runs fine with it, in fact it always ran so well that one of my Nehemiah CPUs is permanently paired with one of these slotkets, always ready for a testing platform. grinning face
Yes I have one of those I've been meaning to repair... I ripped off one of the resistor packs (56R) when removing the heatsink (they place it to close to the retainer clip) and I have one or two other broken resistor packs. I will also test with that (will repair it tonight in preparation for tomorrow), thanks for reminding me.
My Nehemiah has been running 3DMark2000 for around 4 or 5 hours now. Tomorrow morning I'll re-do the test at 1024x768x32bpp if it is still running by then. My prediction is that it will survive the 640x480 loop but crash on the 1024x768 loop.
My Nehemiah has been running 3DMark2000 for around 4 or 5 hours now. Tomorrow morning I'll re-do the test at 1024x768x32bpp if it is still running by then. My prediction is that it will survive the 640x480 loop but crash on the 1024x768 loop.
If it survives 640 x 480 but crashes at 1024 x 768, then, without a shadow of a doubt, you can confidently exclude the Nehemiah (or the slotket) as being the cause of the instability. The CPU does not give a rat's ass about the screen resolution or color depth you are running at.
I also started the benchmark more than two hours ago, with the FastFame slotket, this time at 1024 x 768 x 32 (see the screenshot below), as you requested. I'll get back at the end of the day with the results.
Also adding some close-up pictures with the FastFame slotket (and the resistor arrays), maybe it will help you fix yours.
2 x PLCC-68 / 4 x PGA132 / 5 x Skt 3 / 1 x Skt 4 / 9 x Skt 7 / 12 x SS7 / 1 x Skt 8 / 14 x Slot 1 / 6 x Slot A
5 x Skt 370 / 8 x Skt A / 2 x Skt 478 / 2 x Skt 754 / 3 x Skt 939 / 7 x LGA775 / 1 x LGA1155
Current PC: Ryzen 7 9800X3D
Backup: Ryzen 7 5800X3D
Have you tried a different GPU to rule your current one out as the cause of your issues? Normally when you raise the resolution and increase the color depth and fidelity settings you shift more load to the GPU and lower the load of the CPU in the process. The harder the GPU has to work you tend to get lower fps which puts less load on the CPU as it doesn't have to feed the GPU data as fast.
If it survives 640 x 480 but crashes at 1024 x 768, then, without a shadow of a doubt, you can confidently exclude the Nehemiah (or the slotket) as being the cause of the instability. The CPU does not give a rat's ass about the screen resolution or color depth you are running at.
I don't necessarily agree with this, but let's see. My Nehemiah at 900Mhz (9x100) survived 640x480x16 almost 24 hours, I'm calling it. Now I'll escape out of it, launch an MS-DOS window and run 'setmul 12' for 12x100 (it's default value is 9x133 = 1.2Ghz, but I prefer to use a 100mhz FSB), and then loop at 1024x768x32bpp for another 24 hours. If it survives that, I'll call this new slotket good, but I still don't understand why Ezra-T survived this test with the Abit Slotket but not Nehemiah.
I also started the benchmark more than two hours ago, with the FastFame slotket, this time at 1024 x 768 x 32 (see the screenshot below), as you requested. I'll get back at the end of the day with the results.
Also adding some close-up pictures with the FastFame slotket (and the resistor arrays), maybe it will help you fix yours.
I realized I don't have the 370SPC, but rather the "370CPU" which is iffy at best... I soldered in the resistor packs yesterday (and added a missing 0.1uF) and the slotcket is I would say unusable (got it to post maybe once and immediately gave up on it)... But it's a common one and not that important so I'll leave it be. The 370SPC looks to be a similar but albeit much newer version of it.
Ok, thanks, I look forward to your report and I'll report back with my results as well.
Have you tried a different GPU to rule your current one out as the cause of your issues? Normally when you raise the resolution and increase the color depth and fidelity settings you shift more load to the GPU and lower the load of the CPU in the process. The harder the GPU has to work you tend to get lower fps which puts less load on the CPU as it doesn't have to feed the GPU data as fast.
Yes, I've ruled that out, but I'll probably be experimenting more with that in the future if this test doesn't pass. I have also modified one of my boards (Asus P2B) to take 3.3V directly from the PSU for the AGP port, as to not rely on the motherboard's built in 5V to 3.3V circuit.