Bug?
The Time option in prime.txt doesn't work for me.
I try with Time=1-7/13:10-13:15 and the Prime95 start at 13:10 but it will not stop at 13:15. With Prime95 version 24.14 it works fine.

[QUOTE=Prime95;112154]I need a few folks to do [B]load testing on the new server.[/B] If you are interested, email or PM me. I'll PM those who have expressed interest with instructions. Load testers will be doing trial factoring of really big Mersennes to low limits or ECM on small Mersennes.

4) Run version 25.4. Follow the link in the dialog box to create a userid. Choose a work preference of either "Trial factoring to low limits" or "ECM on small Mersenne numbers".[/QUOTE]

[QUOTE=James Heinrich;113577]On a different note, I wonder if the communication could be optimized somewhat, perhaps by getting batches of work (eg 10 or 100 exponents at a time) -- I noticed it couldn't communicate fast enough to keep one core of an AM2 X2 @ 2.6GHz busy doing TF-to-low-limits, let alone two cores. Now granted, I should probably be doing something harder than TF to 56-bit with a somewhat-powerful CPU, but still...[/QUOTE]

As noted above, the testing of the server communications is what is being stressed. The more machines trying to tie things up is what George W. is looking for. Batch comm. would defeat the purpose.

I seem to have a problem with the userid switching randomly back and forth between "JamesHeinrich" and "admin_user_anon", and even "ANONYMOUS" -- they just flipflop back and forth... this is 30 seconds of results.txt:[code]UID: admin_user_anon/3600x2v254, M98657831 has a factor: 1269675969476191, AID: 65FFC9FD21DD3C3F8421C4BB8B2D1571
UID: admin_user_anon/3600x2v254, M98657831 has a factor: 503791873056937, AID: 65FFC9FD21DD3C3F8421C4BB8B2D1571
UID: JamesHeinrich/3600x2v254, M98657893 no factor to 2^56, Wd4: B2ED908B, AID: F6E9332B8AA3D3CD7FCF7853B4D77796
UID: JamesHeinrich/3600x2v254, M98657981 no factor to 2^56, Wd4: B2EE908B, AID: E2C3366B09DFA212D8BA6BF7AD3EC1A7
{7 more}
UID: admin_user_anon/3600x2v254, M98658557 no factor to 2^56, Wd4: B2EC9090, AID: 0108C5BAAE7E0C2EFD267C932EAF8388
UID: admin_user_anon/3600x2v254, M98658607 no factor to 2^56, Wd4: B301908B, AID: 06992A703D1F8B34A933186C6E69B76D
{15 more}
UID: JamesHeinrich/3600x2v254, M98659643 no factor to 2^56, Wd4: B2FB908F, AID: 3086DC20B6DA53B07CCCDE9EB447FF60
UID: JamesHeinrich/3600x2v254, M98659697 has a factor: 32372022460247, AID: EE8B090D25836B4D6F8B67ADDF056699
UID: JamesHeinrich/3600x2v254, M98659709 has a factor: 190215918953, AID: C1201B30DC238ED31912A7FA19E2CF2E
UID: JamesHeinrich/3600x2v254, M98659751 has a factor: 35072144655745343, AID: 24036D2A194E1A68FEC5080A7F4AEBF7
UID: admin_user_anon/3600x2v254, M98659819 no factor to 2^56, Wd4: B2FE908F, AID: 8EBEEF78836646A6A35EA829B2334ABD
UID: admin_user_anon/3600x2v254, M98659849 no factor to 2^56, Wd4: B2FF908C, AID: DCFBAEAAB2AF591EFAAA7BCA20CC6E38
UID: admin_user_anon/3600x2v254, M98659877 no factor to 2^56, Wd4: B2FE9092, AID: 16CE9E0128A55C6C788638A46EB1F252
UID: admin_user_anon/3600x2v254, M98659963 no factor to 2^56, Wd4: B2FD9090, AID: 6AC395C8D41527D6587146597E47901A
UID: ANONYMOUS/3600x2v254, M98660069 no factor to 2^56, Wd4: B2F4908D, AID: 59CFE3F7A47066015B47215FA054914A
UID: ANONYMOUS/3600x2v254, M98660137 has a factor: 8682092057, AID: FAC60DB13EF47EC6E116CBAE17195125
UID: JamesHeinrich/3600x2v254, M98660951 no factor to 2^56, Wd4: B3029090, AID: F5CA4F30948C94DFC4DF560303F14C0E
UID: JamesHeinrich/3600x2v254, M98660183 no factor to 2^56, Wd4: B2F29091, AID: DBFD98DD4F5F61030BD463041BDABCF0[/code]
Although by far the winner is "admin_user_anon". If I set a different userid it sortof sticks for a short time, but then always reverts itself to "admin_user_anon".

v5 server seems to have run out of exponents "trial factor to low limits"... I got up to M99999971 to 2^56, now I've reverted to M18799813 to 2^67

I'd really like to see Prime95 report the starting point of trial factoring in results.txt. I've asked about it before, and I've seen results files with it in (maybe it was a previous version of Prime95?), like this:[code]// current style:
UID: user/comp, M99999971 no factor to 2^56, ...

// my request:
UID: user/comp, M99999971 no factor from 2^32 to 2^56, ...[/code]
I don't know if this is useful to anyone else (I assume it at least can't hurt), but for my [url=http://mersenne-aries.sili.net]own stats tracking[/url] it's useful to know how much work was performed on a TF.

My previous report of randomized UserIDs seems to apply to the x64 build only (or perhaps only under Vista64), I don't seem to have the problem on the 32-bit version on WinXP.

Feature request: would it be possible to have a preferred worktype of "Whatever makes the most sense [i]out of these selected options[/i]", so that it would assign me (for example) either (TF to low limits) or (TF) or (ECM), whichever of those 3 (in this example) made the most sense at the time.

From what I can tell, if the configuration of the number of worker threads to use is decreased (for example from 2 to 1), the worktodo for the now-excess threads is not merged into the remaining threads' worktodo, although you do get a warning on startup that there's more sections than active threads. I think if the number of threads is decreased, the worktodo from the excess threads should be redistributed among the current thread(s). Conversely, when the number of threads is increased, it may make sense to first redistribute the current set of worktodo across all the now-available threads first, before fetching new worktodo, as the already-assigned work may possibly exceed the current get-work-for-X-days setting.

[QUOTE=James Heinrich;113846]v5 server seems to have run out of exponents "trial factor to low limits"... I got up to M99999971 to 2^56, now I've reverted to M18799813 to 2^67[/QUOTE]

I think it would be best to cease TF load testing until I get back from vacation and can talk to Scott to see what he has learned. This will also give me time to work on the problems reported here.

Do not do trial factoring on M18xxxxxx numbers - that is wasted work.

ECMers can continue on even though that is not placing a great load on the server.

[QUOTE=James Heinrich;113866]I'd really like to see Prime95 report the starting point of trial factoring in results.txt[/QUOTE]Hmm, this is interesting. This is two consecutive lines from results.txt, from when the server ran out of small TF work:[code]UID: user/comp, M99999971 no factor to 2^56, Wd4: BFDF997A, AID: B9271227CFFDA8BE4652CCA84412B777
UID: user/comp, M18798833 no factor from 2^66 to 2^67, Wd4: B47E7D22, AID: 20FCDFF61D2E6DA301CA54EA1833BE69[/code]The 2^56 exponent does not include the starting point, but the 2^67 exponent does. I'm not sure how far the small-TF exponents on the server had already been factored, but out of the 12131 factors I found the smallest were all around 27.5 bits and distributed fairly evenly from <2^28 through <2^56 bits (except, strangely, not a single one fell in the <2^29 range, and a disproportionate number fell in the <2^30 range (see attachment). So, can it be made that all TF results include the starting point, not just larger bitdepths, please?

[QUOTE=Bundu;113104]Every once in a while my v25.4 I get a windows vista message saying this program has stopped working properly and asks me to close. I have no idea what it is.
Could it be the memory leak that is causing the problem?[/QUOTE]If it's the same one I'm getting then yes -- the dialog looks very similar to the "this program has performed an illegal operation and has been terminated" dialog, but in fact it's Vista saying "I think this program is using too much memory, please close it". In my case, Prime95 (x64, 25.4.1.0, 4GB RAM, Vista64) was doing ECM in 2 threads overnight and decided to eat up 1.8GB at some point, although when I checked it was only using around 400MB. My memory settings are 1.5GB overnight and 512MB in daytime (although it's not quite yet "daytime" when I checked it).

I renamed prime.log to something else and restarted Prime95 and it immediately ate memory at about 15MB/s until it was at 1.0GB, then a few minutes later ate memory again until it was at 1.6GB. I believe this coincides with Stage2 ECM -- when I first restarted it was doing stage2 on one thread and stage1 on the next; the increase from 1GB to 2GB seems to be the same time thread2 switched to stage2. Is ECM supposed to use large quantities of RAM, like P-1? If so, would it be possible to introduce a system similar to what was put in for P-1, where only 1 thread would run stage2 at any given time?

Hi James, I think after reading the posts I noticed that the excessive memory use was down to an error in p95.

I have noticed that if you keep the memory settings at 500mb the program doesn't get terminated but still uses a fairly large pagefile (1-2gb on mine). I changed my settings back down below the 1gb it was set at on the 29/08 and it ran perfectly until i stopped it a day or so ago becuase we had run out of TF exponents to test and george advised that the ECM wasn't really load testing the server.

I won't pretend I understand it all but the nice thing about this project is I get to stand on the shoulders of a giant and reach mathmatical heights that would be out of my normal reach :flex:

I just figured I would spend my cycles on my old version because at least the stats don't get zeroed and I'm trying to break into the top 100 on the old TF stat list (at 115 at the moment) :-)