RMA.NET

[Flatlander]

Is it worth me installing 0.7 over the top of 0.5?

btw I have not been using the screen saver.

[Flatlander]

About 52hrs on Athlon 3200+:

Sieve at 149.5bn 1 per minute
LLR at 211782 1 per 2.5 minutes

I strongly suspect this is slower than a manual sieve/llr.
LLR from 205000 to 211782 was taking 22-25hrs. (After seiving to about 180bn.)
Sieving to 150bn was taking 9-11hrs. (For a range half the size. But even if we sqr(2) * that time...) [edited 'double' to 'sqr(2) *']

Maybe RMA.net would benefit from:
Seive to 1 billion at the start.
Run first three LLRs and take the mean time.
Sieve to a large percentage of this time. (>90%)
Then start your algorithm.
This might save several hours at the beginning.

My RMA folder has 4 temporary files in it beginning with z or y. I assume these are left by LLR?

Regards
Chris

It's not completely nessesary, especially if the MS fix works fine.
The bug occured, with, or without screensaver on.
It should not have, but it it did. I fixed this for people that dont have, or dont want to get the MS patch.

I have found that RMA.NET is not slower, than manualy sieve/llr ing.
You won't be saving several hours.
In your case, set the timer for more than 30 minutes, to get a more acurate average. You are testing large candidates,(n=200000+) so not many tests are completed, at %1 CPU, during a 30 minute period.

You could however, pre-sieve the file close to where you want it, and then import the file, into RMA via the "Continue file" option. Thus saving 1% CPU during sieve time. Again you have to decide when to stop, by measuring the progress yourself.

Temp files (z, y, u) will be cleared, when a new file is started.

[Flatlander]

I see now, thanks.

Is a 6 hour timer sufficient for tests like mine? It's only enough time for 1 or 2 LLRs at 1% CPU.

Is a 6 hour timer sufficient for tests like mine? It's only enough time for 1 or 2 LLRs at 1% CPU.

That seems ok, so at least one test is completed.
I probably should mention this somewhere....

I must update the timer, so that a greater range can be chosen from.
By default, I will also create an auto-timer to help optimize the program.

In your case, set the timer for more than 30 minutes, to get a more acurate average. You are testing large candidates,(n=200000+) so not many tests are completed, at %1 CPU, during a 30 minute period.

I should clarify my statement, to avoid confusion.
Since RMA.NET does not know the iterations completed, it counts the current test, as a fully completed test. But does not eliminate it from the file.
This is why RMA.NET was favoring LLR, a little early at 30 miniutes.
So set the timer, so that at least one test is completed per loop.
This will be changed in the next version, along with the auto-timer addition.

[Flatlander]

Yes, auto-timer would be good.
Perhaps you could make it minimize as an icon too?
Is it possible to make it not kill LLRs/NewPGens outside of its own folder? I often test ks while searching for top 5000.

I am now running LLR on it's own because I chose a too-large range and it has been sieved passed the perceived sweet-spot.

I will try the newest RMA.NET on my other PC when it finishes its k in 7-10 days.

Thanks
Chris

It will take a couple of days to finish the auto timer.

I can minimize it to just an icon only.
I'll have to place it behind the taskbar, since .NET does not allow virtual keys to be sent to a hidden,or non-visible form. VS6 had this rule too, but in practice it worked just fine.

Yes it's possibe to kill LLR/NewPgen only inside their folder but:
A. Rare errors could possible cause hardware damage, via multi-LLRing.
B. The .NEt process component, does not always stop them, so I use a process list kill, in addition to prevent any RMA errors.
I'll have to think of a solution....


Glad you tried it out!
Thanks for your help.
Shane F.

[Flatlander]

Originally Posted by TTn

Yes it's possibe to kill LLR/NewPgen only inside their folder but:
A. Rare errors could possible cause hardware damage, via multi-LLRing.

How is this possible?

I read that a while back,...I think from Joss and another source.
I'll see if I can find the thread and/or source. If the problem was fixed, and only local to that version, then I'm still weary about taking any chances.
Someone may still use that version!
I dont have a EULA, for the software, or any disclaimers either.

If your asking about multi-LLRing, they just have to be in different folders to execute.

I can't find the thread, or my old backup CD for the time period.


Does anyone else remember, about the possible hardware issue with LLR, when running multiple instances?


And where in the world is JOSS!
I have some questions about P-1.