Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!elroy.jpl.nasa.gov!usc!jarthur!nntp-server.caltech.edu!gwoho From: gwoho@nntp-server.caltech.edu (g liu) Newsgroups: comp.sys.ibm.pc.hardware Subject: Re: lowlevel ide drive. Message-ID: <1991Feb18.080322.5078@nntp-server.caltech.edu> Date: 18 Feb 91 08:03:22 GMT References: <1991Feb17.064952.14315@nntp-server.caltech.edu> <{-=&&D+@rpi.edu> Organization: California Institute of Technology, Pasadena Lines: 47 In comp.sys.ibm.pc.hardware you write: >gwoho@nntp-server.caltech.edu (g liu) writes: >>people say that this should not need to be done and its already 1:1. >>it is not 1:1 on my drive. its 2:1. i would like to know how to adjust it >>so i can make it best for whatever os i use. >>it would be dumb if ide drives are stuck at 1:1 for a lot of people, because >>they run os that can not keep up. >The OS shouldn't make any difference to the interleave, and vice versa. As >I understand it, the real bottleneck on transferring data from the disk to >the computer is the bus. The processor itself is usually going to be >faster than any of that already. this depends on what machine you have. my drive has 34 sectors/track, spins at 60/sec so at 1:1, it sends about 1m/sec. my card wount do dma, so the 286 has to get the data itself. the 286 does a rep movs to get the data. that takes 4 cycles/byte. so, at 6mhz, the cpu is spending most of its time moving data. it has no time to do any processing to get ready to recieve the next sector by the time it comes around. some oss use more time than others, so 1:1 wont work for some oss. >>some people have reported destroying their ide drives via llformating. >>apparently their programs were not just pretending to llformat; they must >>really have been doing it. would one of those people email me a copy of >>the program? >Let me get this straight. You're ASKING someone to send you a copy of the >program which rendered their IDE drive USELESS, so you can try it too?! On >the face of it, it sounds insane. >What sort of data transfer rate are you getting? I mean, as tested by a >program like CheckIt or something. it messed up their drive--i dont think it will mess up mine. i believe they have to send the right information to the drive to get it to substitute the right blocks to make it work right. for example, to get my scsi drive to work well, i had to send it the following bytes: 4 16 0 0 2 0 0 0 0 4 0 0 0 129. i am willing to mess with the drive, sending it random codes to make it work. its not as hard as it may seem. >-- >Kevin Martin >sigma@rpi.edu