Modification to bounded app

Message boards : News : Modification to bounded app
Message board moderation

To post messages, you must log in.

1 · 2 · Next

AuthorMessage
Profile Eric Driver
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 8 Jul 11
Posts: 1318
Credit: 403,708,838
RAC: 288,154
Message 1123 - Posted: 29 Sep 2014, 16:52:29 UTC

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!
ID: 1123 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile rebirther
Avatar

Send message
Joined: 19 Aug 11
Posts: 4
Credit: 1,673,636
RAC: 0
Message 1124 - Posted: 30 Sep 2014, 16:38:24 UTC

Is there something changed in WU length? They are running now 12h+ and still not finished, before some seconds to 4h.
ID: 1124 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Eric Driver
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 8 Jul 11
Posts: 1318
Credit: 403,708,838
RAC: 288,154
Message 1125 - Posted: 30 Sep 2014, 20:25:48 UTC - in response to Message 1124.  

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.
ID: 1125 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Aurel
Avatar

Send message
Joined: 25 Feb 13
Posts: 216
Credit: 9,899,302
RAC: 0
Message 1126 - Posted: 1 Oct 2014, 16:25:26 UTC

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
ID: 1126 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Eric Driver
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 8 Jul 11
Posts: 1318
Credit: 403,708,838
RAC: 288,154
Message 1127 - Posted: 1 Oct 2014, 18:14:05 UTC - in response to Message 1126.  

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?
ID: 1127 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Aurel
Avatar

Send message
Joined: 25 Feb 13
Posts: 216
Credit: 9,899,302
RAC: 0
Message 1129 - Posted: 1 Oct 2014, 19:27:10 UTC - in response to Message 1127.  

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.
ID: 1129 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Martin Droppa

Send message
Joined: 12 Mar 12
Posts: 3
Credit: 2,000,994
RAC: 32
Message 1135 - Posted: 13 Oct 2014, 7:26:44 UTC
Last modified: 13 Oct 2014, 7:27:11 UTC

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
ID: 1135 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Eric Driver
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 8 Jul 11
Posts: 1318
Credit: 403,708,838
RAC: 288,154
Message 1136 - Posted: 13 Oct 2014, 16:58:59 UTC - in response to Message 1135.  

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.
ID: 1136 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Martin Droppa

Send message
Joined: 12 Mar 12
Posts: 3
Credit: 2,000,994
RAC: 32
Message 1137 - Posted: 13 Oct 2014, 21:34:01 UTC - in response to Message 1136.  


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...
ID: 1137 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Conan
Avatar

Send message
Joined: 3 Sep 11
Posts: 30
Credit: 7,701,817
RAC: 3,703
Message 1138 - Posted: 15 Oct 2014, 2:19:23 UTC - in response to Message 1136.  
Last modified: 15 Oct 2014, 2:24:09 UTC

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
ID: 1138 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Eric Driver
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 8 Jul 11
Posts: 1318
Credit: 403,708,838
RAC: 288,154
Message 1139 - Posted: 15 Oct 2014, 4:35:42 UTC - in response to Message 1138.  

I will look into those tasks to see if there's something I can change for future work generation.
ID: 1139 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Conan
Avatar

Send message
Joined: 3 Sep 11
Posts: 30
Credit: 7,701,817
RAC: 3,703
Message 1140 - Posted: 16 Oct 2014, 10:34:14 UTC

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
ID: 1140 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Eric Driver
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 8 Jul 11
Posts: 1318
Credit: 403,708,838
RAC: 288,154
Message 1141 - Posted: 16 Oct 2014, 15:14:29 UTC - in response to Message 1140.  

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.
ID: 1141 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Eric Driver
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 8 Jul 11
Posts: 1318
Credit: 403,708,838
RAC: 288,154
Message 1142 - Posted: 17 Oct 2014, 21:14:06 UTC - in response to Message 1141.  

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.
ID: 1142 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Martin Droppa

Send message
Joined: 12 Mar 12
Posts: 3
Credit: 2,000,994
RAC: 32
Message 1143 - Posted: 18 Oct 2014, 18:04:43 UTC - in response to Message 1142.  

Thanks for that credit and I have som longer tasks, and I let them running to the end.
Martin
ID: 1143 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Eric Driver
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 8 Jul 11
Posts: 1318
Credit: 403,708,838
RAC: 288,154
Message 1144 - Posted: 19 Oct 2014, 2:01:43 UTC - in response to Message 1143.  

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.
ID: 1144 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Aurel
Avatar

Send message
Joined: 25 Feb 13
Posts: 216
Credit: 9,899,302
RAC: 0
Message 1146 - Posted: 20 Oct 2014, 20:33:37 UTC

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
ID: 1146 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Eric Driver
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 8 Jul 11
Posts: 1318
Credit: 403,708,838
RAC: 288,154
Message 1147 - Posted: 20 Oct 2014, 23:44:41 UTC - in response to Message 1146.  

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.
ID: 1147 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Dennis-TW

Send message
Joined: 2 Dec 14
Posts: 3
Credit: 388,326
RAC: 0
Message 1196 - Posted: 17 Dec 2014, 13:19:02 UTC

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
ID: 1196 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Eric Driver
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 8 Jul 11
Posts: 1318
Credit: 403,708,838
RAC: 288,154
Message 1197 - Posted: 17 Dec 2014, 14:59:57 UTC - in response to Message 1196.  

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.
ID: 1197 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
1 · 2 · Next

Message boards : News : Modification to bounded app


Main page · Your account · Message boards


Copyright © 2024 Arizona State University