civileme wrote: > James wrote: > >> I think the 33mhz bus is the root cause of a lot of problems. Video has >> improved not because of faster cpu's but because so much of what used to >> travel on the buss is now done on the card. My hdd may be able to read >> faster than ever before but it sure doesn't help when even at 66mhz it >> exceeded buss speed. Your box performs at the slowest speed on the chain >> and if that's 33mhz .... that's the choke point.. course all this is >> IMHO but I think I'm in the ballpark. >> >> James >> > > Actually, we are talking about data rates very differently.... > > From/To the attached electronics and disk, the data is _pure serial_ > > Under any one head there iare > 258048 bits of usable data in a rotation... And this rotation occurs > in 1/7200th of a second or about .139 ms, so if an entire track is > read, we have > > about 1.86 GBITS/s (that's Gigabits/sec using 10^9) or 1.73Gbits/sec > (using 2^30) > > Now the controller is capable of passing data at what? How is that > rated? Is it bytes/sec, words/sec. bits/sec, or just a clock rate > that is advertised? The advertising is usually careful NOT to say. > In fact it appears to be a clock rate. > > Now we have to look at the pcide bus The AT Attachment with Packet > Interface Revision 6 Draft says there are 16 data bits. What does > that mean in raw bit rate? > > Hmmm lessee, there are many sorts of messages crossing that bus, not > all of them data, and to every 512 bytes there is appended a 57-byte > CRC packet so let's agree to knock off about 10% for necessary cruft > to preserve data integrity--it's a little higher than that but so what? > > 133MHz (ATAPI-6) less 14Mhz is 119MHzx16bits =1.9GBITS/sec or > 1.77Gbits/sec > > WHOA!!!! Until we have 10000rpm disks for IDE it looks like we can > transfer data a little faster than it can spin on or off the disk.... > > But that's OK we can build up the data for a burst in an onboard > buffer or seven so that many tasks can be happening apparently > simultaneously > > Now the PCI bus is 32 and the extended PCI bus is 64 bits wide.... > > Hmmm the IDE channel is only 16 bits wide so to use the PCI bus to > capacity, we need 4 times the clock rate or 4x33 or 132. > > Sheesh, seems we are at the max that can work with an essentially > unbuffered transfer from memory to disk... but of course the > buffering is already there for the next of the components that > advertises a speed increase. > > Now look as the fractional nanosecond values of signals for spooling > data and recall that once a cylinder boundary is reached (at 63K for > single-platter two head disks) we have to talk about stepping the > heads, and now we are talking milliseconds, a 10^6 order of magnitude > change in data rate. That is why a buffer on the disk electronics is > a great idea. > > The disk is the slowest component. RAID0, RAID4 or RAID5 can make a > real difference in the apparent performance of disk transfers by > making stepping a less frequent event (with the right chunk size > defined, of course.). > > Civileme > > > > > > >------------------------------------------------------------------------ > >Want to buy your Pack or Services from MandrakeSoft? >Go to http://www.mandrakestore.com > ACKS divide the disk rate by 60 :-/ That is rpm not rps. So the disk interface is at least 60 times as fast as the disk!!!
Civileme
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
