[QUOTE=Madpoo;399177]... (Javascript...sorry LaurV) ...[/QUOTE]Are we really so alike that we get confused with each other? :richard-n-ernst:

[QUOTE=retina;399181]Are we really so alike that we get confused with each other? :richard-n-ernst:[/QUOTE]

Umm... I meant Retina. Who could forget you? You wonderful, FF 3.x rocking, Javascript hatin' prime hunter!

[QUOTE=Madpoo;399177]I'm looking a little closer at the manual assignment page now that I have the time.
[/QUOTE]

I mocked up a few design-only changes to the manual assignment page:
[URL="http://www.mersenne.org/manual_assignment/default.mock.php"]http://www.mersenne.org/manual_assignment/default.mock.php[/URL]

First, I added some text just to warn that requesting a lot of work will take a while, and ideally keep it under 50.

Besides that, I changed the input fields to "number" type. It does some input verification too, but with the "number" input fields you can set min/max values.

Since the cores (I renamed to "workers") is limited to 12, that's a hard maximum for that field. If you try to submit with more than 12 there you get a browser warning.

For the # of assignments per worker, I did set a max on that input field of "50". I think that's a healthy enough # for a single worker thread to request at once... isn't it? Of course the way it is now it could still request up to 12 x 50 at once.

I'd have to research what the options are for showing some kind of running total of assignments based on the current values of input fields. I think it would end up being Javascript though. Which is fine for everyone but Retina (I got it right that time). And he'll just have to do the math in his head. :)

Better yet would be showing the total assignments you're asking for and then multiply by 300 ms to give the user some idea of what to expect.

Anyway, the mockup is just a work in process... I'm open to suggestions. I've yet to dig into the assignment part itself and maybe 300ms per assignment generation is just what we're going to deal with. No biggie, if so I think we can make it work just fine.

[QUOTE=Madpoo;399177]Looking at the code that does the assignment itself might be something I can check out. I don't know how much is done in PHP and how much gets passed to SQL, but there could be some room for tweaking or optimizations.[/QUOTE]

I don't know what the schema and indexes are, but it seems to me that it should be possible to hand out assignments much faster than 300 ms each. I know basically nothing about MSSQL, but I'm pretty handy at tuning MySQL. My hunches for the slow performance are slow disk commits (not using SSD or battery-backed disk controller), not having an index that sufficiently filters the results, sorting the results in memory instead of using an index, performing a round trip to the database for every assignment instead of one batch, or a combination of those.

[QUOTE=Madpoo;399186]keep it under 50.[/QUOTE]

There can be a vast difference in effort for an individual assignment.
Attempts to limit number of assignments without regard to work type and region parameters will be quite misleading and unnecessarily alarmist.
For example, using PrimeNet for courteous assignment of TF work in some regions to the extent of 2222 units would not be unreasonable.
Been there, done that, and all completed in a timely fashion.
I'm sure that much more extreme number of units examples can be constructed.

PS: I wasn't stuttering, but rather emphasising that a 100k brick of work can exceed 2000 units.

[QUOTE=snme2pm1;399191]Attempts to limit number of assignments without regard to work type and region parameters will be quite misleading [/QUOTE]
It is the number of assignments per request. You can always make additional requests.

[QUOTE=Madpoo;399186]I think it would end up being Javascript though. Which is fine for everyone but Retina (I got it right that time). And he'll just have to do the math in his head. :)[/QUOTE]As long as the submission is similar to [u]<form method="post" action="[normal (non-JS) link here]">[/u] then it will be fine. But you will still need to program the server to the same limits as the JS because you can't trust all clients to always play nicely.

[QUOTE=axn;399194]It is the number of assignments per request. You can always make additional requests.[/QUOTE]

Many in our country are aware of the quote from the recently departed ex Prime Minister, Malcolm Fraser, "life wasn't meant to be easy".
But I submit that life doesn't need to made unreasonably difficulty either.
If the PrimeNet manual assignment agent is altered to only provide a tiny number of units, than I would have seriously diminished reason to utilise it.

[QUOTE=retina;399181]Are we really so alike that we get confused with each other? :richard-n-ernst:[/QUOTE]
Haha! However I should use the other emoticon: :beer:

@Madpoo: you should try to search for "do a barrel roll" in google, (without quotes).

[QUOTE=LaurV;399198]Haha! However I should use the other emoticon: :beer:[/QUOTE]Tag team :bump2:

:fight:

[QUOTE=Madpoo;399186]I mocked up a few design-only changes to the manual assignment page[/QUOTE]You could change the <form> method from "get" to "post" for immediate effect, which on the plus side gives the user a warning if they try to refresh to the page, but on the downside would cripple your ability to do what you did in perusing the logs to see what requests for assignments were made when. You could of course add additional internal logging at the (start of) the generate-assignments code, but that's more work to replicate what's currently captured in the httpd logs.

You should put in a server-side check to prevent malicious people from bypassing your client-form limits. Easily done: change the one line in the code:[code]// was:
//$found_assignments++;

// change to:
if ($found_assignments++ > (12*50)) {
break;
}[/code]Of course, putting the magic numbers into constants/variables in the code makes it easier to maintain.