Stability of network cards at 75MHz+

[Robert G. Brown]

On Mon, 15 May 2000, dwight wrote:

> I think you are referring to listarchives/beowulf/2000/05/0042.html?
> I do believe you *can* OC with UDMA enabled successfully; and I
> believe Mark's words were "all bets are off". Plus his other excellent
> comments were right on target, especially about the special cabling.
> 
> However, just because you can, doesn't necessarily mean that
> you *will* be able to. I think I've OC'd a hard disk or two this way;
> but have also had failures with others. The original posters' comment
> about having trouble OC'ing disks in general was quite correct.

Well, how can I argue?  Perhaps one can get lucky.  On the other hand,
perhaps it will only appear that you're lucky at first, and a few days
later you'll have a disk that is such a hash that no fsck can recover
it, which is pretty unlucky.  I can only quote the Ultra-DMA HOWTO/FAQ:

  9.2.  Are you overclocking?

  If you are, beware! Here is a quote from the udma-generic
  documentation:

  DON'T OVERCLOCK the PCI bus. 37.5MHz is the maximum supported speed
for the PCI bus. Some (supposedly compatible) UDMA drives will not even
take 37.5MHz, but should be OK at 33.3MHz.

  In any case, NEVER, NEVER set the PCI bus to 41.5MHz.

  The RECOMMENDED safe setting is 33MHz.

I seem to recall that this was a pretty hard limitation -- disks have to
synchronize a whole bunch of disparate activities -- platter speeds,
seek heads, buffers, and interfaces (allowing for speed of light type
delays caused by cable length and quality) and one of these was VERY
INTOLERANT of altering base clock rate of the system buses.

> A while back, storagereview.com ran a poll about OC'ing success
> per hard disk vendor and model. For all too many HD's, it was common
> to see a success rate of 40-60% or so. This makes it an expensive
> crap-shoot.

All this has been hashed over before, repeatedly.  It's in all the
various FAQs and HOWTOs and is a part of the unwritten (and sometimes
very explicitly written!) list etiquette.  The consensus is:  Overclock
all you want, but if you do don't waste the time of list-persons seeking
help to debug a "problem", at least not without setting your clocks
right back where they belong and going through a systematic hardware
debug cycle to see if you broke anything with your higher clock and
increased heat, and general stupidity.

If you post to e.g. the kernel list or the smp kernel list with some
bizarre problem and attract the attention of e.g. Alan Cox or Mark Hahn
or Linus himself and ten people spend four iterations of email trying to
analyze your reported problem and THEN it emerges that you're
overclocking the system in question (and that setting the clock back
"solves" the problem:-), they'll nuke you.  "Flame" is too tame a word.
And you'll deserve it -- their time is precious and they willingly spend
it answering all sorts of questions and solving all sorts of real
problems as it is.

IMHO (only, of course) OC'ing is for amateur computer users and games
persons.  Professionals value their time and the reliability of the work
that they do more than the transient, fleeting step ahead of Moore's Law
that one can obtain with OCing.  

NOBODY does a systematic analysis of the costs and the benefits -- they
simply decide on the basis of anecdotal evidence whether or not to do it
or not (Joey told me he overclocked his gaming system and it worked
fine, so I should be able to overclock my whole rack of beowulf nodes
and achieve equally trouble-free operation) and then get all religious
about it.  A lot of people seem to do it to get even with Intel for the
"Intel Conspiracy", where Intel deliberately downgrades a batch of CPUs
to keep the supply of high clock CPUs small and the price (and marginal
profits) high.

But this is likely VERY boring to list old-timers as they've heard it
and said it over and over again, so I'll stop now.

   rgb

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu