I sent these bugs to George and Scott by email but am posting them here for reference and to ask people to see if they can duplicate them.

[QUOTE]While this behaviour may be good for the production server, did you intend to assign LL tests when I let Primenet decide my work preference? I got an LL test in the 46 million range. I can confirm that choosing worktype works from the server as I was able to change to ECM and TF and my computer got the desired work type.
Another small bug is that using Firefox on linux, I find that the pie chart and histogram in the performance stats is a bit screwy. I have not tested this on windows and using Konqueror I can't seem to log in at all but that is not a huge concern as there is probably a miniscule market share for Konqueror. Anyway, the title of both charts is cut off at the top as the title is vertically centered at the top pixel. Also, the y-axis on the histogram seems incorrect as the inverse ranks only go up to 5.
[/QUOTE]

Garo,

I'm working on TF, P-1, and LL assignments now. The 46,000,000 to 46,010,000 range does have live up-to-date data. I expect to open up the range for real testing in the near future. The main problem is that the get assignment queries work, but some of them do full table scans. I'm reworking the indexes and assignment algorithms now.

Load testing has found many bugs - several of which are very hard or impossible to reproduce and/or fix. Finding errors in the web forms is useful, just be aware that it is a work-in-progress.

And yes, first-time LL tests is the default work preference for fast machines.

[QUOTE=Prime95;118755]Please email the prime.txt, local.txt, and worktodo.txt files to me so that I can debug the problem.[/QUOTE]
I'm sorry -- what's the email address I should be sending to? You can contact me offline at hoopmanjh-at-hotmail-dot-com if you'd prefer.

Thanks!

Joe

Windows Scheduling
 

[quote=James Heinrich;118795]:bow: :grin:
Now it behaves as expected. Prime95 isn't [I]entirely[/I] without effect on the system, but much much closer.[/quote]

Windows always gives some time-slices to every thread to prevent communication errors like TCP-connection-time-outs. This behavior can be disabled with the [URL="http://msdn2.microsoft.com/en-us/library/ms686280.aspx"]SetThreadPriorityBoost[/URL] API and the [I]DisablePriorityBoost parameter set to TRUE [/I]for threads, that don't need it, like the workers of Prime95.

This should ideally be included (at least as an option) in Prime95. However, if you know the Thread-ID and have sufficient rights (e.g. by being the owner of a thread), this can also be done externally. If George decides to implement this, ThreadPriorityBoost should be temporarily enabled, when reading or writing save files, to better ensure their consistency and not keeping them open for too long.

Personally, I really don't need this feature. Prime95 behaves nicely enough for me, although I do stop it during large MPEG-encoding batches.

Generally Prime95 can be run as a service and it does so on NT-based Windows Versions older than Vista.

You can use a program like [URL="http://www.electrasoft.com/srvany/srvany.htm"]SRVANY[/URL] to do so on a Vista machine.

-Christoph

[quote=db597;118796]Sounds to me like it's the TLB bug. Maybe a BIOS update will fix it.[/quote]

Thanks, this could be the source of the error. I'm going to disable Level 3 Cache, to see if the problem disappears, if yes, it is most likely the TLB-bug

[quote] Personally, I really don't need this feature. Prime95 behaves nicely enough for me, although I do stop it during large MPEG-encoding batches.[/quote]You could try:
[quote]In rare cases, users have reported the program can interfere with the performance of some programs such as disk defragmenters and some games. You can pause prime95 automatically when these programs are running by adding this line to prime.ini:

PauseWhileRunning=prog1,prog2,prog3,etc

Note that prime95 will pause if the program name matches any part of the running program's file name. That is "foobar" will match "c:\foobar.exe", "C:\FOOBAR\name.exe", and even "C:\myfoobarprog.exe". By default, prime95 will check the list of running programs every 64 iterations, but not more frequently than every 10 seconds. You can adjust the time period with this prime.ini setting:

PauseCheckInterval=n

where n is the number of seconds between checking which programs are running.[/quote]

[QUOTE=Xyzzy;118812]You could try:[/QUOTE]That's why I asked (above) for: [QUOTE=James Heinrich;118749]Another option might be a [i]PauseWhileRunning[/i]-style configuration where Prime95 would suspend (at least part of) itself while said applications are running [i]and using more than <10>% CPUtime[/i] -- that way if you have Windows Media Encoder open, but not encoding, Prime95 runs full-throttle, but when encoding is actually going on, Prime95 suspends a (one or more) worker thread(s).[/QUOTE]

Somehow we missed that post.

:blush:

That is a good idea. We never thought about the program being open after the work is done. The one we use terminates after it is done.

[QUOTE="christoh"]This behavior can be disabled with the [URL="http://msdn2.microsoft.com/en-us/library/ms686280.aspx"]SetThreadPriorityBoost[/URL] API and the [I]DisablePriorityBoost parameter set to TRUE [/I]for threads, that don't need it, like the workers of Prime95.[/QUOTE]My past experience with this function showed that it has no effect on the running of threads. I had set one thread to idle priority (the same as P95 uses) and ran another thread at normal priority. I measured the amount of runtime that each thread received and found no significant difference when the parameter was set and when it was not.

But, I also remember that the amount of runtime the low priority thread received was very small (~ 0.1%) so I think the effect described in a previous post of the OS giving runtime to low priority threads is not as a result of the priority boost behaviour, but some other mechanism. I suspect that the other threads were calling a wait function (probably Sleep), this tends to mess with the OS scheduling amongst different priority threads.

As an illustration of this problem try using Sleep as a timer (i.e. Sleep for 100ms in a loop) and you can see how the time becomes more and more inaccurate as you add more and more lower priority non-Sleeping threads.

Expect outages / problems today getting assignments. I'm changing the definition of the available assignments table.

For some reason worker thread 1 has run out of assignments on Nov. 18th, see attatched zipped prime.log. (I have set debug=2).

Now empty worker thread 1 is set to ECM on small Mersennes, worker 2 is set to ECM on small Fermat numbers.