ECM users - version 30.9-30.13 (see post#316)

[Madpoo]

Originally Posted by Mark Rose

Browsers dropped support for ftp over a year ago.

And yet, we still get hits to the FTP links for some of those old files. Not a lot...

Unfortunately, unlike hits to an http link which has the "referrer" field, the only way to know where those FTP links are coming from is do a Google search, and even then it's not like there's anything we can do about it. I think the last time I did any kind of effort like that, when we were seeing a bunch of dead-link hits to some Primenet web page or another, I did contact a couple sites to let them know (and there are also some 301 redirects I put in place).

I don't think I'd bother doing that with FTP links unless it was some well known thing, but honestly we don't get a lot of FTP hits anyway. Not enough to worry about, like a few dozen a month compared to tens of thousands for the HTTP links. We stopped listing the FTP download link on the Primenet download page years ago, and that helped quite a bit since people were copy/pasting that.

For now, I've at least created subdirectories on that download page ( GIMPS downloads ) for v16 through v30, and then at least for the newer ones, I did like James' site and have the minor versions in subfolders below that.

I grabbed some counts of how many hits we get to each download over the past month so I may just take the XX most common of them and create redirects and then let the rest of them error out if someone's direct linking to it. And also, like I mentioned, it'd be nice to have a "most recent" link that we can update and always send you straight to whatever the latest official version is, and maybe a "test version" for the times when George puts out a beta version for people to try something (but if it breaks, that's on you)

[chalsall]

Originally Posted by Madpoo

And yet, we still get hits to the FTP links for some of those old files. Not a lot...

Thank you for your long-term outstanding work, Aaron.

Few appreciate what is involved with being the SysAdmin for a "Public Facing" server. It is non-trivial.

Ignoring the occasional hostile requests, zero days are extra fun.

[Madpoo]

Originally Posted by chalsall

Thank you for your long-term outstanding work, Aaron.

Few appreciate what is involved with being the SysAdmin for a "Public Facing" server. It is non-trivial.

Ignoring the occasional hostile requests, zero days are extra fun.

I think we (George, James and I) all have fun doing this. At least, I hope the others do as well... not like we're getting paid or anything. It just means that sometimes the requests will take a little longer to get to, or it might get downvoted since there's only so much time we can collectively spend on things.

A nice bonus is that I've probably learned more in the past 8-10 years about SQL from working on Primenet than I had in the previous 8-10 years just being a DBA as part of my other "regular job" tasks. Which translated into helping me out immensely in those other jobs, being more effective, so it's been like a rigorous training program in a way.

Meanwhile... does anyone have an account at the "overclock.net" forums? That's one place where they've posted new builds with direct FTP links over the years. Example:
Overclock.net - Prime95

I thought about signing up just so I could post an HTTPS link to the latest one and break that trend of FTP, but meh... maybe someone here already has one? Overclockers do love them some Prime95 action... it really does put your rig to the test like nothing else.

[LaurV]

Originally Posted by Madpoo

George hasn't built the executables for 30.10 apparently.

He did, but there is a good reason why it was not posted. We had some PM talk meantime, it seems to run OK for me, but not so for other people. It will come.

Related to the FTP, that is what I said, build a html wrapper, like James did. It is some work, but then you are more flexible to arrange the things to your liking.
Now, I know this sounds rude, and I don't want you to take it that way, I am not in the position to order anything to anybody. It is my way of "wishing" things. Of course we appreciate what you all are doing here, and we keep you all in some kind of awe (no joke!) otherwise we won't talk to you at all! But in my (est-European) culture, as well as in Thai (and most of Asia, and Latin America, etc, i.e. the most of the world, in fact), we go in the restaurant and say "give me a beer", or "quiero una cheveza", and that is not considered impolite, only you English-speaking brats say "I would like to have a beer please" If you come to my house and say that, I will reply "ok" and continue to mind my business, letting you to find the fridge by yourself. If you want ME to give you a beer, say so!

Joking apart, and as we are at wishing section, wishing you all to have a healthy and prosperous 2023 together with your families and friends. OTOW, have fun writing the wrong year for the next weeks...

[bur]

I've been running 30.9b3 for a few days now doing B1=3e6 ECM on M22xxx. Everything seems to work well, just now I got this crash after filling worktodo.add:

[Worker #7 Jan 21 06:36] PolyG built.  Time: 2.074 sec.
[Worker #1 Jan 21 06:36] PolyG built.  Time: 2.070 sec.
[Main thread Jan 21 06:36] Restarting all worker windows to process .add file.
[Worker #4 Jan 21 06:36] Worker stopped.
[Worker #5 Jan 21 06:36] Worker stopped.
[Worker #12 Jan 21 06:36] Worker stopped.
[Worker #10 Jan 21 06:36] Worker stopped.
[Worker #6 Jan 21 06:36] Worker stopped.
[Worker #3 Jan 21 06:36] Worker stopped.
[Worker #11 Jan 21 06:36] Worker stopped.
[Worker #2 Jan 21 06:36] Worker stopped.
[Worker #9 Jan 21 06:36] Worker stopped.
[Worker #8 Jan 21 06:36] Worker stopped.
[Worker #7 Jan 21 06:36] PolyH built.  Time: 0.948 sec.
[Worker #7 Jan 21 06:36] H(X) scaled.  Time: 0.276 sec.
[Worker #7 Jan 21 06:36] PolyF up.  Time: 0.034 sec.
[Worker #1 Jan 21 06:36] PolyH built.  Time: 0.934 sec.
Segmentation fault
$

After restarting mprime everything continued just fine.

[bur]

It happened again when I added lines to worktodo.add

Like before, not all 12 workers were successfully stopped. Again it's Worker #1, but that might be a coincidence?

[Worker #1 Jan 21 08:30] PolyH built.  Time: 0.972 sec.
[Worker #1 Jan 21 08:30] PolyG built.  Time: 2.036 sec.
[Main thread Jan 21 08:30] Restarting all worker windows to process .add file.
[Worker #12 Jan 21 08:30] Worker stopped.
[Worker #11 Jan 21 08:30] Worker stopped.
[Worker #8 Jan 21 08:30] Worker stopped.
[Worker #9 Jan 21 08:30] Worker stopped.
[Worker #7 Jan 21 08:30] Worker stopped.
[Worker #6 Jan 21 08:30] Worker stopped.
[Worker #4 Jan 21 08:30] Worker stopped.
[Worker #5 Jan 21 08:30] Worker stopped.
[Worker #10 Jan 21 08:30] Worker stopped.
[Worker #3 Jan 21 08:30] Worker stopped.
[Worker #2 Jan 21 08:30] Worker stopped.
[Worker #1 Jan 21 08:30] PolyH built.  Time: 0.922 sec.
Segmentation fault

[Rubiksmath]

Originally Posted by bur

It happened again when I added lines to worktodo.add

In my experience stopping workers during stage 2 is almost a guaranteed crash. Doesn't always happen but whenever I have to stop a worker in stage 2 I get nervous. It's not usually bad if it crashes I lose at most 30 min of computing time.

As an aside, if you wanted to use Mersenne.ca to look at T-level on the exponents you are running, submitting identical results from all your workers at the same time (as I presume you have been doing by looking at the recent results page but I could be wrong) causes Mersenne.ca to consider them duplicates and discard, thus displaying an incorrect T-level. Primenet seems to report the T-level more accurately though so it is good that has been added.

[Prime95]

Yes, save files in ECM stage 2 are not implemented yet

[bur]

Now it seems to happen consistently when attempting to ECM a larger exponent:

[Worker #4 Jan 22 07:14] Stage 1 complete. 25612650 transforms, 1 modular inverses. Total time: 2353.847 sec.
[Worker #4 Jan 22 07:14] Available memory is 12273MB.
[Worker #4 Jan 22 07:14] Switching to FMA3 FFT length 72K, Pass1=384, Pass2=192, clm=2
[Worker #4 Jan 22 07:14] Optimal B2 is 1562*B1 = 1562000000.  Actual B2 will be 1562145585.
[Worker #4 Jan 22 07:14] Estimated stage 2 vs. stage 1 runtime ratio: 0.341
[Worker #1 Jan 22 07:14] Restarting worker with new memory settings.
[Worker #9 Jan 22 07:14] M1281979 curve 1 stage 1 at prime 983911 [98.39%]. Time: 110.892 sec.
Segmentation fault

Re-tried two times, same result. I crashes when the first worker moves to Stage 2.

It's a Ryzen 9 3900x, 32 GB, Ubuntu 22.04.

As an aside, if you wanted to use Mersenne.ca to look at T-level on the exponents you are running, submitting identical results from all your workers at the same time (as I presume you have been doing by looking at the recent results page but I could be wrong) causes Mersenne.ca to consider them duplicates and discard, thus displaying an incorrect T-level.

I noticed the mersenne.ca t-level was often off, so I never used it. Since I submit the results in the "official" results.json.txt form, shouldn't mersenne.ca take them for what they mean?

[Prime95]

Originally Posted by bur

Now it seems to happen consistently when attempting to ECM a larger exponent:
It's a Ryzen 9 3900x, 32 GB, Ubuntu 22.04.

This may be the bug LaurV reported and is fixed in 30.10. I'll try to get a 30.10 mprime built for you

[Rubiksmath]

I sometimes had something similar, I don't know the exact circumstances but with some fiddling around with the memory each worker was allowed individually instead of having a max allocation for the whole set of workers fixed it for me. When I had a set amount of RAM available for all 4 workers to pool from when one worker started stage 2 it would restart all workers as the amount of available RAM had changed in some fashion (Prime95 would allocate ~50% of my RAM to the first worker, 25 to the second and the remainder to the third or something along those lines), and because the worker was still in stage 2 init it was a guaranteed crash. You can occasionally get away with restarting a worker in stage 2 but during stage 2 init it is a certain crash. Because Prime95 would restart all workers automatically whenever a worker got to stage 2 it was a guaranteed crash every time and it took a lot of trial and error to fix but I fixed it using the method described above. In local.txt there is a section where it has [Worker #1] [Worker #2] etc. and underneath each worker you just write Memory=5200 for example to have each worker use 5200 MB RAM max.