Mersenne Digest Sunday, 31 January 1999 Volume 01 : Number 503
----------------------------------------------------------------------
From: Leu Enterprises Unlimited <[EMAIL PROTECTED]>
Date: Fri, 29 Jan 1999 15:42:37 -0800 (PST)
Subject: RE: Mersenne: Problems with ATI graphics
Ditto on Aaron's excellent comments. I've added some of my own.
> From: "Aaron Blosser" <[EMAIL PROTECTED]>
> Date: Thu, 28 Jan 1999 14:33:52 -0600
> Subject: RE: Mersenne: Problems with ATI graphics
> ...
>
> > 2) I don't think heat is the problem. The problems start within 5-10
> > seconds of starting prime and stop as soon as prime is halted.
>
> Then we can say it's related with some certainty.
I've actually measured the heat put off by mprime. The above observations
are completely consistant with how the CPU heats up.
> > 3) The on-board ATI graphics chip is about 2 cm away from the Slot1,
> > directly underneath the CPU's big heat sink.
>
> That's *way* too close, I would think.
Good lord, yes. For most cards, they might be OK. But don't forget that
some video cards can put off a good deal of heat themselves.
> ...
> One good test would be to use any other program that uses the FPU alot and
> see if the flicker shows up. Can anyone think of another program that
> would? I suppose any benchmark that tests FLOPS should do the trick.
>
Another good test would be memtest86. I've put a copy of it up on
supercomputer.org's download section, for both Windows and Linux users.
It will generate about 2C more heat than mprime/prime95 running the
torture test. And this doesn't use the FPU.
To get the maximum amount of heat, use memtest86 in cache mode.
-dwight-
===============================================================
To learn how to build a supercomputer for under $10,000 visit
www.supercomputer.org
===============================================================
------------------------------
From: [EMAIL PROTECTED]
Date: Fri, 29 Jan 1999 17:20:06 -0800 (PST)
Subject: Re: Mersenne: Problems with ATI graphics
> 2) I don't think heat is the problem. The problems start within 5-10
> seconds of starting prime and stop as soon as prime is halted.
I never said anything about heat. I said electromagnetic radiation. It
emenates (sp?) from anything that is electrical. The more electricity,
themore emenations. It works the same way as a radio transmitter, and
unfortunately your graphics card appears to be the receiver so to speak...
> 3) The on-board ATI graphics chip is about 2 cm away from the Slot1,
> directly underneath the CPU's big heat sink.
Hmmm, sounds pretty suspicious to me. I would move it down a slot or
two...
> 4) The distributed.net client does not cause this behavior. My
> understanding is that it does not use either FPU or cache.
Huh? If you are LL testing you are using FPU and cache. I'm almost as sure
that applies if you are factoring as well.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: WWW: http://www.silverlink.net/poke : Boycott Microsot :
: E-Mail: [EMAIL PROTECTED] : http://www.vcnet.com/bms :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
From: "John R Pierce" <[EMAIL PROTECTED]>
Date: Fri, 29 Jan 1999 20:33:51 -0800
Subject: Re: Mersenne: Problems with ATI graphics
> > 3) The on-board ATI graphics chip is about 2 cm away from the Slot1,
> > directly underneath the CPU's big heat sink.
>
> Hmmm, sounds pretty suspicious to me. I would move it down a slot or
> two...
"ON-BOARD" ATI graphics. its a all-in-one motherboard. can't move it.
re: emf radiation, I heavily doubt that a CPU could radiate any significant
EMF thru a heatsink, which after all is a large mass of aluminum, presumably
grounded.
I'd be more likely to suspect power transients coming through the +5VDC.
> > 4) The distributed.net client does not cause this behavior. My
> > understanding is that it does not use either FPU or cache.
>
> Huh? If you are LL testing you are using FPU and cache. I'm almost as sure
> that applies if you are factoring as well.
he meant the distributed.net client does not use FPU or cache. In fact, it
does use some cache, but not nearly as heavily as the LL tests do. The
distributed.net client is that RC-5 encryption thing, its all integer math.
- -jrp
------------------------------
From: [EMAIL PROTECTED]
Date: Sat, 30 Jan 1999 00:14:42 -0600 (CST)
Subject: Mersenne: Factoring Fermat Numbers
Several months ago I downloaded fermat.exe from the Mersenne.org site
("zip file" at http://www.mersenne.org/fermat.htm). This program attempts
to find factors of Fermat numbers (F16 to F20) using ECM factoring.
I have run it occasionally, and it seems to work. (I have found some of
the known factors, but no new ones yet.)
More recently, I downloaded the source code from Perfectly Scientific
Inc (link is on the same page as above). I have compiled the source code
successfully, but the resulting program does not seem to be working, since I have
found none of the known factors with several runs of the program. (The output to
the screen looks the same as George's executable, except for not finding any
factors.) I even modified the line that says "seed = random number"
to say "seed = value", where "value" is a number that resulted in finding a factor
in the original executable. (Note: the original executable and my executable
are for Windows 95/NT.)
My first few compiles were with Watcom C. I then tried MS Visual C/C++,
using the command line that was suggested in the comments in the file fermat.c:
cl -O2 fermat.c fgiants.c giants.c
A couple of "test programs" are included with the Perf-Sci source files.
These programs use giants.c (but not fgiants.c). I tried these two (with
Watcom C) and they seem to work OK.
The comments at the top of each of the files used for "fermat.exe"
indicate that changes have been made since George's executable was created.
Perhaps Perf-Sci introduced a bug somewhere? Does anyone have any other ideas
about what the problem could be?
------------------------------
From: [EMAIL PROTECTED]
Date: Sat, 30 Jan 1999 00:23:19 -0600 (CST)
Subject: Mersenne: Factoring Fermat numbers
Sorry if this is a duplicate message. I am not sure if my previous attempt to
send this message got there or not.
Several months ago I downloaded fermat.exe from the Mersenne.org site
("zip file" at http://www.mersenne.org/fermat.htm). This program attempts
to find factors of Fermat numbers (F16 to F20) using ECM factoring.
I have run it occasionally, and it seems to work. (I have found some of
the known factors, but no new ones yet.)
More recently, I downloaded the source code from Perfectly Scientific
Inc (link is on the same page as above). I have compiled the source code
successfully, but the resulting program does not seem to be working, since I have
found none of the known factors with several runs of the program. (The output to
the screen looks the same as George's executable, except for not finding any
factors.) I even modified the line that says "seed = random number"
to say "seed = value", where "value" is a number that resulted in finding a factor
in the original executable. (Note: the original executable and my executable
are for Windows 95/NT.)
My first few compiles were with Watcom C. I then tried MS Visual C/C++,
using the command line that was suggested in the comments in the file fermat.c:
cl -O2 fermat.c fgiants.c giants.c
A couple of "test programs" are included with the Perf-Sci source files.
These programs use giants.c (but not fgiants.c). I tried these two (with
Watcom C) and they seem to work OK.
The comments at the top of each of the files used for "fermat.exe"
indicate that changes have been made since George's executable was created.
Perhaps Perf-Sci introduced a bug somewhere? Does anyone have any other ideas
about what the problem could be?
------------------------------
From: Alan Powell <[EMAIL PROTECTED]>
Date: Sat, 30 Jan 1999 10:19:02 -0500
Subject: Mersenne: Factoring Fermat Numbers
At 12:14 AM 1/30/99 -0600, [EMAIL PROTECTED] wrote:
> <snipped>
>More recently, I downloaded the source code from Perfectly Scientific
>Inc (link is on the same page as above). I have compiled the source code
>successfully, but the resulting program does not seem to be working, since
I have
>found none of the known factors with several runs of the program.
I have considerable experience with "fermat.c" and the Perfectly
Scientific Inc "giants" libraries. Suggest you try the following:
1. Place the four source files fermat.c, fgiants.c, giants.h and
giants.c in your project directory - say \MyProjects\FermatTest
2. In MS Visual C++ 5.0/6.0 create a new project using: File / New
/ Projects=Win32 Console Application / Project name=FermatTest
3. Compile the three source files fermat.c, fgiants.c and giants.c
adding them to the project FermatTest when prompted
4. Modify the main function in fermat.c as follows:
i) add a new case: case 12: B = 1000L; break;
ii) use a fixed seed: seed = xxx; (instead of psi_rand())
where xxx is 144, 485, 573, 632 or 959
5. Then do Build / Build FermatTest.exe (or F7)
6. The resultant executable FermatTest.exe should have compile cleanly
and when run from a DOS prompt using the syntax:
FermatTest.exe 12 > FermatTest.txt
should produce results similar to those shown below
The "magic" seeds above are five known test values that find the
factor 114689 in the First stage (carried forward to Second stage).
If not you have some kind of problem!!
If you have any other questions please contact me privately,
so we can discuss this off the Mersenne List.
Alan Powell
[EMAIL PROTECTED]
================================================================
F 1 2 [Xeon400]
Attacking F12 using ECM with DWT
B=1000 C=50000 Q=4096 nsh=544 stack=1088 fftlen=128
Commencing first stage pass=144 seed=144...
------------------------------
From: "Aaron Blosser" <[EMAIL PROTECTED]>
Date: Sat, 30 Jan 1999 11:06:32 -0700
Subject: RE: Mersenne: Problems with ATI graphics
> >Either way...EMF from the CPU definitely appears to be the culprit. One
> >possibility which I emailed the original person was to place some braided
> >copper between the CPU and video card, and tie that to a good ground.
> >That's not practical though. :-) We don't all have copper braiding lying
> >around.
>
> What would that do, effectively shield the video card with a Faraday cage?
> Anyways it looks like the EMF may be from the FPU. I'm sure there are
more elegant solutions, but that one would be pretty cheap.
Essentially. A grounded copper mesh is pretty good at picking up
multifrequencies, and since it's grounded, the signals tend to dissipate.
> >Remember those old hobby computers from back in the 70's that
> generated so
> >much EMF you could make a TV flicker from the other side of your
> house? Or
> >how you could place a radio nearby and run a program that
> generated so much
> >noise in such a way that you could actually try to play a tune? Oh, for
> >fun... (Okay, I'm not quite old enough to have used a hobby computer in
> >the 70's...but close, so close).
>
> I bet the FCC had a lot off about that...which is probably why modern
> computers come in a stainless steel box that's grounded through the 3rd
> wire on the power connection.
I don't know how upset they were back then. In those days they were
probably more lax as long as you weren't interfering with other peoples
stuff.
These days, the FCC has stricter guidelines, requiring a class B for any
prebuilt systems. Oddly, you can still build your own computer from parts
and not have to get it certified. For businesses, you need class A whether
its prebuilt or homebrew.
I will say though that for most computer parts nowadays, you can slap one
together yourself and it all fits together much better. Motherboards have a
lower power consumption, monitors are EMF shielded, and cases are either
heavy duty metal or lined plastic affairs. The ATX spec for motherboards
and cases actually contain language for EMF radiation, and there's a nice
metal thing that comes with an ATX case to fit around the ports that stick
out the back, limiting the radiation leakage there.
Good stuff.
The big problem is radiation inside the case. For the longest time, sound
cards would either pick up alot of stray noise, or generate a lot of stray
noise themselves. Then they got better when they started packing more stuff
onto one chip, avoiding all that noisy glue logic.
CPU's use less power and generate less noise/heat, but I still consider it
VERY unwise to put something like a graphics chip withing 2cm of the CPU.
You're just *asking* for trouble there. :-)
Aaron
------------------------------
From: "John R Pierce" <[EMAIL PROTECTED]>
Date: Sat, 30 Jan 1999 13:14:39 -0800
Subject: Re: Mersenne: Problems with ATI graphics
Paul Derbyshire comments...
> John Pierce wrote...
> >re: emf radiation, I heavily doubt that a CPU could radiate any
significant
> >EMF thru a heatsink, which after all is a large mass of aluminum,
presumably
> >grounded.
>
> Who said anything about "through the heat sink"?
> Fact is it isn't heat, since the vid problem shows up while the chip's
> still ice-cold to touch, and vanishes the instant prime95 stops without
> taking the time to wait for the fpu to cool down.
they specifically stated the ATI graphics chip was located half under the
CPU heat sink. Presumably, that would look something like this...
[bad ascii art alert]
||||
-------------------|||| <= Pentium-II SEC
-------------------||||
-------------------|*||
--heat sink--------|*|| <= * = P-II chip
-------------------|*||
-------------------|*||
-------------------|*||
-------------------||||
-------------------||||
||||
||||
===ATI SVGA CHIP=== ||||
=============motherboard===================
By EMF I meant electromagnetic interference, i.e. radio. Said heatsink
should act as a radio shield also and eliminate any inductive interference
with the ATI. Its my best guess that this effect is due to improperly
bypassed high frequency power supply transients.
- -jrp
------------------------------
End of Mersenne Digest V1 #503
******************************
