![]() |
|
|
#12 |
|
P90 years forever!
Aug 2002
Yeehaw, FL
17·487 Posts |
Everything looks fine. Those look like acceptable P4 timings.
Is there any chance the server difficulties the last week have caused our problem? Some users report mprime reacts badly when the server is unavailable - losing plenty of CPU cycles. Try running mprime -m and set iterations between outputs at 100 or 1000. Then Test/Continue and see if iteration timings are OK (22 milliseconds). If so, does the the wall clock match up to your observed iteration timings? Does FreeBsd support a power-saving sleep mode? If so, disable it. That too can reduce throughput drastically. |
|
|
|
|
|
#13 |
|
Aug 2002
Termonfeckin, IE
24·173 Posts |
My mprime running 22.7 crashed earlier this week because of server troubles. So definitely the server caused problems. Another option is to turn on verbose and see what the iteration timings are. Say
mprime -d > log.txt That way you should find out how much time it's really taking. |
|
|
|
|
|
#14 |
|
Aug 2002
101 Posts |
Once it starts crunching the second exponent, things are better. Here is some indicators:
M8312093 completed P-1 at Aug 31 00:35:59 2002. At Aug 31 06:36:47 2002, it reported progress 987109/8312093. That is more than 1/10 of the work in 6 hours. Whole thing should be done in about 50 hours. Estimate is also 2 days. It said 5 days for the last exponent. We will see. We can enter my above bench mark as a data point for P4A 2.2G running DDR133. Sorry for the sticky mouse. |
|
|
|
|
|
#15 |
|
Aug 2002
Termonfeckin, IE
24×173 Posts |
Again, don't trust the completion estimate too much. It can be wrong for a variety of reasons. Loos at the actual iteration times by using the -d switch.
|
|
|
|
|
|
#16 |
|
Aug 2002
101 Posts |
The estimates were not so bad most of times. It said 5 days for my last double check and it did take 5 days. This time, it said 2 and took 2. It is a P4, verified! :D Now I can get it some serious work.
Thanks! |
|
|
|