[QUOTE=Madpoo;380156]I can see that there are times when the disk subsystem really starts to get overwhelmed... [/QUOTE]The system seems to be out picking daisies when returning the [i]Top Producers >> Totals Overall[/i].

I think it is supposed to return the Top 500 ("/report_top_500/"). Instead it returns all 4500+.

[QUOTE]In summary, better things are coming. :smile:[/QUOTE]

That's very good to hear. Thanks for all your efforts and contributions.

[QUOTE=M29;380179]The system seems to be out picking daisies when returning the [i]Top Producers >> Totals Overall[/i].

I think it is supposed to return the Top 500 ("/report_top_500/"). Instead it returns all 4500+.[/QUOTE]

Oh, weird. You're right. That's more than 500.

That's one of the reports that gets generated hourly, but the server right now does not do any gzip compression, so that large > 1MB of data gets sent to the client via the scenic route.

I did test out switching the current server to use the built in PHP compression and that works, but I wasn't entirely sure if the v4/v5 API communications will work okay if the client gets gzipped data back from it's requests.

On the replacement server I avoided that by just using built in IIS compression for the main site and have it disabled for all of the API related calls. It might work anyway... the clients are probably using whatever built-in HTTP for it's OS which *should* be able to decompress any gzipped responses but I'm not going to test all of them just for that, and those calls don't normally return much data.

Suffice to say, when doing a webpagetest.org check of that page on the current server it can take 10-20 seconds. On the test server it was taking 1-2 seconds tops. 1+ MB of data compressed down to 150KB or so.

I guess if that report was fixed to just generate the top 500 and not the larger set, it wouldn't take as long anyway.

Another fun stat is how long it takes the server to run the SQL tasks that generate those hourly stats. On the current server it could take anywhere from 3 minutes to as much as 20 minutes, just depending on how much disk thrashing was going on, but on average I think I saw it taking 4-5 minutes. The test server is consistently doing it in 35-40 *seconds*.

That's not to say the final server replacement will do exactly the same, since we're testing this all on a virtual machine right now since that was easier for me to get going, but it is a close match to the physical box itself.

[QUOTE=Madpoo;380203]...when doing a webpagetest.org check of that page on the current server it can take 10-20 seconds.[/QUOTE]

If you're curious, here's the webpagetest I did on the current server for that page:
[URL="http://www.webpagetest.org/result/140805_E3_3QR/"]http://www.webpagetest.org/result/140805_E3_3QR/[/URL]

The site seems to be more responsive and uploading manual results was faster than the past two weeks, did you guys do anything?

[QUOTE=VictordeHolland;380249]The site seems to be more responsive and uploading manual results was faster than the past two weeks, did you guys do anything?[/QUOTE]

Nope, you were just lucky.

The site does seem happier with 5GB of free disk space. Madpoo is out of town this week so there won't be any work on the new server til he gets back.

The manual submitting if the results has been a little troublesome with the many cgi timeouts.

A few weeks ago, I tried to change the upper target exponents in trial factoring up to a value like 2^73 or 2^74 in my assignments.

While I submitted hundreds of results before, now I I just have a few results to submit every time.

Is it an idea to be followed by others?

Don't change the pledged factoring level. Or, if you do, then report all the bitlevels at once, when they are finished. Or even better, if you need "higher bitlevels" to factor, go to GPU72.

If you manually reserve TF work, then change the bitlevels, this will result almost always in [U]duplication of work[/U]. As you TF, lower bitlevels will be finished faster, PrimeNet has no way to know that you are doing higher bitlevels too, so it will assign them to other users, which will duplicate your work. Or you their. The server can't "guess your mind" to know that you intend to factor higher, unless you don't "pledge" so (reserving the right work).

Don't factor higher than you pledge for! This is a bad practice.

It's one of the unfortunate aspects of having multiple servers handing out assignments. GPU72.com is an invaluable addition to our [STRIKE]empire[/STRIKE] resources but I think it does cause a bit of confusion.

On the other hand, Primenet should not be assigning stuff "owned" by GPU72.

[QUOTE=LaurV;380268]Don't change the pledged factoring level. Or, if you do, then report all the bitlevels at once, when they are finished. Or even better, if you need "higher bitlevels" to factor, go to GPU72.

If you manually reserve TF work, then change the bitlevels, this will result almost always in [U]duplication of work[/U]. As you TF, lower bitlevels will be finished faster, PrimeNet has no way to know that you are doing higher bitlevels too, so it will assign them to other users, which will duplicate your work. Or you their. The server can't "guess your mind" to know that you intend to factor higher, unless you don't "pledge" so (reserving the right work).

Don't factor higher than you pledge for! This is a bad practice.[/QUOTE]


One exponent to test is only assigned for one test at a time. It can clearly be seen under the menu "Work Distribution". Get an assignment, and the number of available assignments drop correspondingly. Submit results and the number of available will be recalculated at the hourly run.

And yes, the deliver at once option must be set in the ini file to avoid conflicts.

[QUOTE=TheMawn;380272]It's one of the unfortunate aspects of having multiple servers handing out assignments. GPU72.com is an invaluable addition to our [STRIKE]empire[/STRIKE] resources but I think it does cause a bit of confusion.

On the other hand, Primenet should not be assigning stuff "owned" by GPU72.[/QUOTE]

Is GPU72 getting exponent assignments through the Primenet API at all, or do you mean Primenet isn't currently storing info on factoring above certain bit depths which GPU72 might be re-doing in some cases?

I can never afford (or at least justify the purchase to the wife) a fancy GPU so I haven't actually looked at the project, but it does sound nice to have such a powerful system doing fun stuff like that even if you're not a gamer.