Stability of network cards at 75MHz+

[dwight]

"Robert G. Brown" wrote:

> On Mon, 15 May 2000, dwight wrote:
>
> 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: ...

It was your original statement, about how one cannot OC UDMA,  that
I was objecting to. The subsequent FAQ doesn't support it either.

Again, there's a difference between shouldn't and can't.

> 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.

DIfferent manufacturers have different tolerences; I suspect it may
actually vary from batch to batch, but I don't think anyone keeps track.

> 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. ...

Yes, but this wasn't the original point; I was objecting to your blanket
statement, which I found to be erroneous, with all due respoect.

I also note that one of the FAQs that this is missing from is the
Beowulf FAQ; I can speak authoritatively here, as I've recently
reformatted the whole FAQ into HTML (which is extremely useful IMHO).
This will be more formally announced later this week, after I finish with a
few last suggestions from Kragan.


>  ... 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.

I thoroughly agree. And I'll add that I do not recommend or endorse OC'ing
for anyone.

> 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.

I have to disagree with this blanket statement too. I know of professionals
who OC; in fact, it's a reasonable bet that you are using technology that
was either developed or influenced by OC'ing. I'm speaking from first hand
experience here.

But then, these people tend to know exactly what they are doing, and why.

>
> 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.

Ah, I certainly do such an analysis. It's one of the reasons why I OC.
But then, I have more experience with it, and computers, than most people.
I also have fairly elaborate QA procedures which have stood up quite well.

As I've mentioned to you in private email, I view most of the COTS systems
the same way most on this list view OC'ing. It beats me how anyone can
use a computer without having done proper QA, OC'd or not.

I've worked with many of the computer manufacturers myself, and personally
know some of the people involved here. I prefer to put my faith in my own QA
rather than theirs, thank you very much.

But I grant that such efforts are indeed the exception and not the rule.

>
> 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.

Ok. So will I.

Best Regards,

    -dwight-


------------------------------------------------------

> The Beowulf Mailing list archives can now be searched by visiting:
>         http://www.supercomputer.org/Search/
> The Calendar of Events in supercomputering can be found at:
>         http://www.supercomputer.org/calendar/