Periodic, repeating pauses w grinding sound

GaryF

Member
May 1, 2001
64
0
0
Over the weekend, I installed an Athlon 1.3GHz, retail kit, (upgrade from Duron 850MHz), a Pioneer 305S (SCSI) DVD-ROM (replacing a Plextor SCSI CD-ROM), and a Quantum 60GB Fireball Plus AS IDE (in addition to existing IBM 20GB and 10GB drives, all 7200RPM). I also removed my one stick of 128MB 100MHz memory, leaving just the 256MB of 133MHz memorhy (Crucial), and set the board jumper to run at 133MHz FSB. Everything worked first time.

Last night I was getting the following peculiar, annoying phenomenon: about every two minutes or so, there would be a light grinding noise, and the system would pause. This would last about a second, at most two. After a few seconds it would repeat, and again a third time. (Possibly a fourth or fifth; I didn't count.) But then it would go away, and I could get back to work for another two minutes or so. The pause in the system wasn't total - the mouse would stop tracking, but I could type with very slow responsiveness - sometimes the characters would be queued and all appear at once after the noise stoped.

I tried inserting a CD-ROM into the Pioneer, but the problem continued even with a perfectly readable CD-ROM in the drive. I had run a full scandisk on the drive on Sunday (many hours - perhaps not a good idea). I have the free IBM S.M.A.R.T monitor utility, and it reports no errors on any of the three hard drives. I also have the VIA hardware monitor, and it reports CPU temperature around 42 C and system temperature around 22 C, both of which seem fine. It also reports a CPU fan speed around 4852, which is lower than my previous (default) trigger RPM of 5000, but with the temperature ok, I'm assuming this fan speed is also ok.

As soon as I get the chance, hopefully tonight, I'll reopen the case and see if I can track down the sound. However, the timing of this problem seems so peculiar that I'm wondering if it isn't tried to some software setting triggering some operation.

For what it's worth, this is an IWILL KK266 system, with Windows ME, a 300W power supply (Antec, if memory serves), a Plextor CD-RW (in addition to the new Pioneer DVD-ROM), an old Connor/Seagate Travan TR-3 tape drive, and a floppy drive.

Any suggestions as to likely culprits, or tactics for chasing this down, will be appreciated.

Many Thanks,

Gary
 

jmitchell

Senior member
Oct 10, 2001
212
0
0
disconnect the ide, er.. scsi, ide, and power from your cdrom, and 2 extra hard drives... if the problem still occurs, then I would probably attribute it to your primary hard drive, and if it stops, well, then its obviously one of those disconnected hardware components... You didnt say where the sound was coming from though... and if you run a scandisc on your cdrom, arent you just scanning the cd in the drive? Its not a real drive diagnostic.

j:confused:
 

GaryF

Member
May 1, 2001
64
0
0
Sorry for my poor wording. I ran the scandisk on the new hard drive, not the DVD drive.

Certainly trying to isolate the source of the sound is the obvious first step, and disconnecting drives here and there is the obvious second step. It's just that the periodicity of this behavior is so distinctive, I was hoping it would be a recognizable problem.

Gary
 

Fallen Kell

Diamond Member
Oct 9, 1999
6,184
520
126
Well, for starters, it shoulds to me to be a swapping issue (i.e. virtual memory on the harddrive). This would and does periodically completely slow down a system when important data is being read from and to the harddrive. If for instance, the data that is needed for a currently running program is on the harddrive, the system will stop doing everything else as it waits to read that data from the harddrive. Keyboard will usually still work as it is implemented through interupts (i.e. it interupts the current program to get the data input). The mouse location is also interupt based, but the drawing of the mouse on the screen is not and is very low priority. I am willing to bet good money that this is the reason for your problem, especially since you removed some of your RAM, you system has an even greater need for using its swap memory. You probably never had as much problem before when you had the extra RAM installed, but now you are seeing the effects of not having that extra 128 megs of RAM.
 

GaryF

Member
May 1, 2001
64
0
0
Close, but not quite. I wasn't doing enough to need to swap.

The problem was much, much dumber, but thankfully, also not a hardware problem.

For some reason, the IBM S.M.A.R.T. drive monintoring utility had set the interval for the short self test on the new Fireball drive to be 2 minutes, and the interval for the long self test to 35 minutes. Totally bogus. The settings for the 2 IBM drives were what I believe to be the correct defaults, namely 12 and 48 hours, respectively. I reset the interval on the Fireball, and everything's fine. And in spite of the stupidity of this, I'm happy I don't have to send hardware back during the busy shipping season.

Gary
 

Mikendi

Platinum Member
Jul 19, 2000
2,533
0
0
Gary are your new SCSI devices properly terminated and ID'd? When it makes the noise does the floppy light come on by any chance? Is your new hard drive jumpered correctly and what is it's designation?
 

GaryF

Member
May 1, 2001
64
0
0
Thanks for your suggestions (all good), but as you can see from my previous note, I found the problem.

Your point about the SCSI drives does remind me of an interesting phenomenon. The first time I booted after the install, my Adaptec 2930 board did not recognize the new Pioneer DVD. It came jumpered for a different id from my previous drive, and I have the controller board configured to only scan the ids that I'm using - in the hope, perhaps misguided, that that speeds the boot process.

What surprised me is that Windows nevertheless was able to use the drive. I'm not sure if the Adaptec scanning is solely for the purpose of identifying potential boot drives, but it seems weird.

In any event, I reconfigured the Adaptec board to scan the new ID number, and it now reports both drives properly during the boot sequence.

Gary