buggy worker.pl (SERIOUS and HARMFUL bugs!!)
 

just to :bump: it again:

The buggy worker script makes it IMPOSSIBLE for windows users to collect points. Additionally, when during "testing ecm binary" the ecm job is killed in the windows task manager (thus making the script believe that the test is passed) and then running the script is HARMFUL, because of a bug (maybe windows only??) which causes the script to report jobs done whithout actually running the ecm-curves. :nuke: (consider: a c135 where the DB says that it has got 400 @ 25e4, 1200@1e6, 2500 @ 3e6 and 4000@11e6 would be considered ready for GNFS - but when the curves have not been actually done (because of the aforementioned bug), an easy p25 factor might be waiting around the corner...)

Two more suggestions:
1.) Please announce it when a new version of the worker.pl script is released (so that one doesn't have to download and check if the file has been changed - again and again - and no, I haven't downloaded again)
2.) Please add a version number to the script to make it easier for a user to check if he has an up-to-date version.

[QUOTE=Mini-Geek;186764]Anyone know how to write the script for Windows so that it actually works right? (wouldn't have to work on Linux as well, there could be separate versions)[/QUOTE]

Not sure how it will work for others, but I've managed to get a version of this working on my windows box. I'm running Windows XP Pro and am using ActiveState Perl 5.10. I'm including the modified version of the perl script below. The script required several changes that are windows-centric (so don't try to use this script in Linux). However, some changes may be useful in the Linux version too. (I'll leave it to Syd to decide that)

In order to run this:
Put the worker_windows.pl in its own folder
Put in the binaries you want in there (ecm.exe, msieve.exe, or both)
Open up a command prompt (may work in msys, not tested though)
cd to the directory of the worker_windows.pl script
Type in "perl worker_windows.pl" at the command prompt (without the quotes)

Hopefully that should work for anyone wanting to run this on windows. Also, if you've already run another version of the script, I think you should go ahead and delete the existing config.pl file and let this script recreate it for you. There may be problems from the linux version that will prevent this from running correctly. I've also added a version number of 1.01 to this.

P.S. I couldn't upload a .pl file here, so after downloading this file, rename the extension from .txt to .pl and it should work fine.

P.P.S. One thing to note is that sometimes the output in the command window will stop updating. Looking into task manager, you will see that new jobs are still coming in and finishing, but once the command window stops updating, you won't be able to see your progress anymore until you restart the script. I'm not sure what is causing this. I'd like to echo what Syd says on his site: "The worker script is buggy! Try it but dont expect it to work." :)

workers idle
 

I was able to clear up a lot of sieve (small factorizations) and a few ECM over the past few days. Unfortunately, there seems to be more troubles with the server handing out work. I can not longer get ECM work though there is still tons in the queue.

So I'm going off-line for a day or so.

RichD.
PPC (Mac G4 867)

I've got ActiveState perl 5.10.0 and your script seems to work. (the tests checked out okay, but I still haven't gotten an assignment from the DB after 14 minutes with plenty in the queue)

same here: still 'No suited work in queue"!

worker_windows.pl seems to work for me too, but same here: 'No suited work in queue"!

its not windows
i was getting that this morning and yesterday evening

Almost every aliquot sequence i submit results in a DB error.

I have about 80.000 new lines to submit in the 900K-1M range but am hesitant as I don't feel like checking en repairing every single sequence (sometimes more than once).

Clearly the DB was not properly Beta tested before the new release was put in.

My suggestion at this point: Restore it to its prior version. From what I could tell, that version worked well other than the occassional squared line bug on Aliquot sequences and some other minor stuff. Sure, it needed some tweaks for the minor stuff and to properly allocate the workers but I could always tell what was being done, it was being done in a reasonable time frame, it was a lot of fun to play with, and it got me very interesting in factoring. That is not the case now.

As much flack as I might get for suggesting this, I'm going to anyway: I think it would be best if all work done since the new release was put in is completely removed from the DB. In other words: An all out restore back to 2 weeks ago or shortly before it was updated to its new version. A tremendous number of errors are coming out. Math and especially factoring is very exacting. I am now strongly calling into question any and all work that the DB has done since the new version was put in.

To make it not quite so bad, I would suggest that factors submitted to the DB (not actually calculated by the DB) be fed back in after the DB is restored to this specific point in time when we are all confident that it was mostly correct...that time would probably be right before the new version was put in.


Gary

bumps in the road
 

This is just a pet project by a single individual. Some think this is a global production data base. Or is it??

Maybe we should have a dedicated support staff. How about a committee to elect a Board of Directors. And have it diverse such that each member is from a different country.

Of course, this is complete sarcasm. The point is, what started as a small individual project has mushroomed beyond anyone's expectations. Now, expectations are high for a 100% on-line/uptime availability.

Syd has done a remarkable job. He probably has more pressing needs at his *real* job. I think we are just going through growing pains.

My two cents,
RichD.

[QUOTE=RichD;187261]This is just a pet project by a single individual. Some think this is a global production data base. Or is it??

Maybe we should have a dedicated support staff. How about a committee to elect a Board of Directors. And have it diverse such that each member is from a different country.

Of course, this is complete sarcasm. The point is, what started as a small individual project has mushroomed beyond anyone's expectations. Now, expectations are high for a 100% on-line/uptime availability.

Syd has done a remarkable job. He probably has more pressing needs at his *real* job. I think we are just going through growing pains.

My two cents,
RichD.[/QUOTE]

I concur.