With the latest subfield (#25) nearing completion, the algorithm moves into a new phase, where it is more efficient to not target the field discriminant. This required no change to the app, but due to WU timing issues, a small change was made to the WU generator (it is now breaking data up into finer pieces). This required a small change to the app interface. I also upgraded to the latest versions of the boinc and pari libraries. Some modifications were also made to the checkpointing and progress meter (finer resolution).

Why am I telling you all this? Because you will be getting a "new" bounded app. It has been thoroughly tested over the last several weeks, but please report anything out of the ordinary. Thanks!

Is there something changed in WU length? They are running now 12h+ and still not finished, before some seconds to 4h.

Is there something changed in WU length? They are running now 12h+ and still not finished, before some seconds to 4h.

Yes, the timings will change, due to the change in discriminant targeting. I ran 1000+ cases on my computer as a test. Ignoring the really fast ones (<10 sec), the average time was less than an hour. The worst case time was about 3 hours. This is on a 3.6 GHz core i7. You can scale these times according to your clock speed to give you an idea of what to expect for runtimes.

Note that I apply a pre-filter that weeds out all the WUs faster than 10 sec.

Good work, Eric! Sorry that I wasn´t updating the stats since nearly 50 days...-__-
I have some done work for my own research, but this should be done and started testing on my computer. ;)

Well; this looks good and 1 Mil./batch are much work.
But, are this the primitive ones? [You said you´ll an new app...]
Any informations about the gpu-app-programmer from Germany?

-
Aurel

Good work, Eric! Sorry that I wasn´t updating the stats since nearly 50 days...-__-
I have some done work for my own research, but this should be done and started testing on my computer. ;)

Well; this looks good and 1 Mil./batch are much work.
But, are this the primitive ones? [You said you´ll an new app...]
Any informations about the gpu-app-programmer from Germany?

-
Aurel

No, these are not the primitive fields. Just a small algorithmic change to the current search (imprimitive fields)

What's this about a gpu programmer from Germany?

Good work, Eric! Sorry that I wasn´t updating the stats since nearly 50 days...-__-
I have some done work for my own research, but this should be done and started testing on my computer. ;)

Well; this looks good and 1 Mil./batch are much work.
But, are this the primitive ones? [You said you´ll an new app...]
Any informations about the gpu-app-programmer from Germany?

-
Aurel

No, these are not the primitive fields. Just a small algorithmic change to the current search (imprimitive fields)

What's this about a gpu programmer from Germany?

Damn, just imprimitive. But, the number of WU´s going smaller, which is very good. :) ~850k at SF26.

Hello, I have a question:
Why this 2 tasks on same computer have identical credit?
1. task: 9088523: running 587,841.66 sec; 946,71 credit
2. task: 9088530: running 1,013,174.43 sec; 946,71 credit.
Thanks, Martin

---

Hello, I have a question:
Why this 2 tasks on same computer have identical credit?
1. task: 9088523: running 587,841.66 sec; 946,71 credit
2. task: 9088530: running 1,013,174.43 sec; 946,71 credit.
Thanks, Martin

That would be because, we use credit based on runtime, not credit new. When credit is based on run time, there is a maximum limit setting, which I believe ours is set to something like 2 days. So any task that takes more than 2 days is capped at the maximum. Both tasks you list above are way beyond this limit.

The tasks for this app were designed to take about 2 or 3 hours on a typical modern computer. There are occasional outliers, but even then the most I have ever seen is ~10 hours. Your computers are relatively fast, so I am not sure why your tasks took so long. Maybe you can answer that.

That would be because, we use credit based on runtime, not credit new. When credit is based on run time, there is a maximum limit setting, which I believe ours is set to something like 2 days. So any task that takes more than 2 days is capped at the maximum. Both tasks you list above are way beyond this limit.

The tasks for this app were designed to take about 2 or 3 hours on a typical modern computer. There are occasional outliers, but even then the most I have ever seen is ~10 hours. Your computers are relatively fast, so I am not sure why your tasks took so long. Maybe you can answer that.

I don´t know, why tasks need so much time...

Hello, I have a question:
Why this 2 tasks on same computer have identical credit?
1. task: 9088523: running 587,841.66 sec; 946,71 credit
2. task: 9088530: running 1,013,174.43 sec; 946,71 credit.
Thanks, Martin

That would be because, we use credit based on runtime, not credit new. When credit is based on run time, there is a maximum limit setting, which I believe ours is set to something like 2 days. So any task that takes more than 2 days is capped at the maximum. Both tasks you list above are way beyond this limit.

The tasks for this app were designed to take about 2 or 3 hours on a typical modern computer. There are occasional outliers, but even then the most I have ever seen is ~10 hours. Your computers are relatively fast, so I am not sure why your tasks took so long. Maybe you can answer that.

I have had a couple that have run past 20-22 hours, although these have been an exception.
However I currently have one that is 7.3% done after 19 hours with an estimated 49 hours still to go (this is on a Windows 32 bit system).
I also have one at 5.2% after 14 hours with an estimated 37 hours still to go (this is on a Linux 64 bit system).

So a few out there are really long runners, though the majority are a under few hours.

Conan

---

I will look into those tasks to see if there's something I can change for future work generation.

Eric I have had to abort those two tasks as they would of taken over 400 hours to run and I am going away so could not monitor them.

The Windows work unit I aborted at 51 hours 10.386% done and 123 hours still to go, see Work Unit 8455991
The Linux work unit I aborted at 40.52 hours 9.394% done and 101 hours still to go, see Work Unit 8456120

Something wrong with those two work units.

Conan

---

Eric I have had to abort those two tasks as they would of taken over 400 hours to run and I am going away so could not monitor them.

The Windows work unit I aborted at 51 hours 10.386% done and 123 hours still to go, see Work Unit 8455991
The Linux work unit I aborted at 40.52 hours 9.394% done and 101 hours still to go, see Work Unit 8456120

Something wrong with those two work units.

Conan

Ok. Sorry about that. I will look into those 2 WUs to see what went wrong.

It looks like I need to adjust one of my thresholds. The current threshold was set for the previous subfield and it now looks like each subfield will need it's own value.

I think the worst of these cases could be as high as 5 or 6 days. I estimate there may be 30 or 40 of these. If you get one of these you can either abort it or let it complete. In either case, please let me know which WU had the problem. I will either delete the WU, or if you let it complete, I will manually grant you credit in order to get around the credit cap.

Martin: Going back to your original post about the long WUs, I will manually grant you credit for those that were capped.

Thanks for that credit and I have som longer tasks, and I let them running to the end.
Martin

I also forgot to mention, I temporarily increased the cap to 100 hours. I don't want to increase it much beyond that due to the "cheaters", the details of which I would rather not get into.

What means this:

Memory Leaks Detected!!!

Memory Statistics:
0 bytes in 0 Free Blocks.
5823 bytes in 12 Normal Blocks.
832 bytes in 15 CRT Blocks.
0 bytes in 0 Ignore Blocks.
0 bytes in 0 Client Blocks.
Largest number used: 300774052 bytes.
Total allocations: 327199723 bytes.

Dumping objects ->
{1042} normal block at 0x0222A348, 8 bytes long.
 Data: <@       > 40 E4 1C 00 14 00 00 00 
{1028} normal block at 0x02228ED0, 1024 bytes long.
 Data: <7.77496438739212> 37 2E 37 37 34 39 36 34 33 38 37 33 39 32 31 32 
{1026} normal block at 0x144138F8, 1024 bytes long.
 Data: <-9.7749643873921> 2D 39 2E 37 37 34 39 36 34 33 38 37 33 39 32 31 
c:\users\eric\documents\nf_project\visual studio 2008\projects\getboundeddecics\src\searchroutines.cpp(106) : {986} normal block at 0x0222CC98, 4 bytes long.
 Data: <    > F3 FF FF FF 
c:\users\eric\documents\nf_project\visual studio 2008\projects\getboundeddecics\src\searchroutines.cpp(104) : {985} normal block at 0x143F1B88, 4 bytes long.
 Data: <1   > 31 00 00 00 
{983} normal block at 0x143F1758, 1024 bytes long.
 Data: <y^2 - 77        > 79 5E 32 20 2D 20 37 37 00 CD CD CD CD CD CD CD 
{975} normal block at 0x02229F00, 1024 bytes long.
 Data: <  ?   ?   ?   ? > 88 1B 3F 14 09 12 3F 14 0B 12 3F 14 0A 12 3F 14 
{910} normal block at 0x143F0CC0, 1024 bytes long.
 Data: <120000000000.000> 31 32 30 30 30 30 30 30 30 30 30 30 2E 30 30 30 
{908} normal block at 0x143F0A10, 540 bytes long.
 Data: <                > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
c:\users\eric\documents\visual studio 2010\projects\boinc src\boinc_api.cpp(245) : {864} normal block at 0x02221630, 4 bytes long.
 Data: <    > 00 00 09 00 
c:\users\eric\documents\visual studio 2010\projects\boinc src\parse.cpp(153) : {603} normal block at 0x02221578, 139 bytes long.
 Data: <<project_prefere> 3C 70 72 6F 6A 65 63 74 5F 70 72 65 66 65 72 65 
{75} normal block at 0x02221500, 4 bytes long.
 Data: < 6" > E0 36 22 02 
{71} normal block at 0x02221480, 8 bytes long.
 Data: <0       > 30 F0 C5 00 00 00 00 00 
{70} normal block at 0x02221960, 8 bytes long.
 Data: <        > 1C F0 C5 00 00 00 00 00 
{69} normal block at 0x02221928, 8 bytes long.
 Data: <        > B0 B3 C5 00 00 00 00 00 
Object dump complete.

http://numberfields.asu.edu/NumberFields/result.php?resultid=9274362

I wouldn't worry about it. For some reason, the windows app always spits that out. All allocated memory in the app is deallocated before the program ends. It's possible the pari library is forgetting to deallocate something. Whatever the cause, when the program ends the memory is released anyways, so it's nothing to be concerned about.

Hi Eric,

I might have caught two of those long runners at once! Both just passed the 60 hour mark with one being at 53% and the other at 28%.

Nothing unusual noticed so far, except for taking such long time, so I'll try to complete them.

Just to give you notice that I might break the 100 hour cap on Friday...

Dennis

Hi Eric,

I might have caught two of those long runners at once! Both just passed the 60 hour mark with one being at 53% and the other at 28%.

Nothing unusual noticed so far, except for taking such long time, so I'll try to complete them.

Just to give you notice that I might break the 100 hour cap on Friday...

Dennis

hmmm. There really shouldn't be any of those long ones left. I wonder if this is related to this post:
http://numberfields.asu.edu/NumberFields/forum_thread.php?id=217&postid=1194#1194

Let me know if you break the cap and I will grant you manual credit.