DS-14x121 runtimes

Message boards : Number crunching : DS-14x121 runtimes
Message board moderation

To post messages, you must log in.

AuthorMessage
Richard Haselgrove

Send message
Joined: 28 Oct 11
Posts: 128
Credit: 106,945,342
RAC: 30,537
Message 445 - Posted: 28 Feb 2012, 23:49:52 UTC

Since we're talking again, I presume you've noticed that the DS-14x121 batch of standard decic search tasks seem to be running - uniformly - for a very long time: three or even four days seems par for the course.

Because BOINC didn't know this in advance, I have one machine running four tasks which have already passed their deadline (I'll keep them going), but also has five unstarted tasks which will pass deadline in the next half hour.

Under those circumstances, BOINC aborts the tasks automatically, but reports them so the the website says "aborted by user". Not Guilty, m'lud!

Presumably these tasks will be re-issued with the 'hurry up' deadline of five days - that's going to be mighty tight. It might be a good idea to relax the resend timings (grace period) until this particular batch has worked its way through the system.
ID: 445 · 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: 926
Credit: 97,222,922
RAC: 55,173
Message 446 - Posted: 29 Feb 2012, 1:22:52 UTC - in response to Message 445.  

Since we're talking again, I presume you've noticed that the DS-14x121 batch of standard decic search tasks seem to be running - uniformly - for a very long time: three or even four days seems par for the course.

Because BOINC didn't know this in advance, I have one machine running four tasks which have already passed their deadline (I'll keep them going), but also has five unstarted tasks which will pass deadline in the next half hour.

Under those circumstances, BOINC aborts the tasks automatically, but reports them so the the website says "aborted by user". Not Guilty, m'lud!

Presumably these tasks will be re-issued with the 'hurry up' deadline of five days - that's going to be mighty tight. It might be a good idea to relax the resend timings (grace period) until this particular batch has worked its way through the system.


Yes, I apologize for the long running WUs.

I first noticed this about 3 weeks ago during offline testing. I eventually came up with a fix, but not in time for this dataset. I am currently testing my fix, and so far it looks like it will work. The problem is that the looping variable is a "congruence vector" and WUs can not be made any smaller than 1 vector. The work around was to increase the modulus, so for example, 1 mod 32 could be split into 2 congruences: 1 mod 64, and 33 mod 62. In this way, I turn 1 congruence into 2, giving twice as many WUs that run in half the time. And I can repeat the splitting process until run times are in the 2 to 3 hour range. [As a side note, the congruences are actually for prime ideals (not prime integers) but the concept is the same.]

I will modify the grace period as you suggest when I get home tonight. Thanks for the suggestion!

Eric

ID: 446 · 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: 926
Credit: 97,222,922
RAC: 55,173
Message 447 - Posted: 29 Feb 2012, 6:28:04 UTC - in response to Message 446.  

I increased the "reliable_reduced_delay_bound" to .95, so its almost the original 7 days. The "report_grace_period" is currently set to 96. That would be an additional 4 days, assumming the units on that are hours (the boinc wiki doesn't specify the units). I think that should be sufficient.

The average run time of all WUs returned so far is 52 hours. The average on my hosts is 39 hours, but mine are relatively new core i7s and core i5s. The max is 150+ hours.
ID: 447 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile _MaRiO[PL]

Send message
Joined: 16 Nov 11
Posts: 1
Credit: 1,000,405
RAC: 0
Message 448 - Posted: 29 Feb 2012, 11:20:17 UTC

Q6600 @ 2,4
411,671.91 - - 329,345.00 - - 2,940.13 - - Get Decic Fields v1.02

Q8200 @ 2,8
165,342.85 - - 141,366.40 - - 3,363.42 - - Get Decic Fields v1.02
ID: 448 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Conan
Avatar

Send message
Joined: 3 Sep 11
Posts: 26
Credit: 2,370,588
RAC: 0
Message 548 - Posted: 18 Mar 2012, 0:49:36 UTC
Last modified: 18 Mar 2012, 0:50:25 UTC

The work units have varying run times and on average 64 bit seems a bit faster than 32 bit even with slower clock speeds.

AMD Phenom X4 @3.2 GHz :-
Shortest = 33.739 Hours, Longest = 61.524 Hours, Ave = 41.503 Hours
running Fedora 64 bit Linux

AMD Phenom X6 @3.3 GHz :-
Shortest = 34.977 Hours, Longest = 57.872 Hours, Ave = 47.812 Hours
running Fedora 64 bit Linux

AMD Phenom X4 @3.4 GHz :-
Shortest = 45.189 Hours, Longest = 89.966 Hours, Ave = 60.603 Hours
running Windows XP 32 bit

AMD Phenom X6 @3.5 Ghz :-
Shortest = 46.970 Hours, Longest = 86.867 Hours, Ave = 56.402 Hours
running Windows XP 32 bit

These figures will change as I have a few very much longer work units on my Linux machines at the moment which may even out the run times a bit.

Conan
ID: 548 · 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: 926
Credit: 97,222,922
RAC: 55,173
Message 551 - Posted: 18 Mar 2012, 18:48:28 UTC - in response to Message 548.  

Thanks for the timing analysis!

The difference between 32bit and 64bit could also be from different compilers (gnu for linux vs. visual studio for Windows). There also seems to be a difference between AMD and Intel, even at the same clock speed.
ID: 551 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
frankhagen

Send message
Joined: 19 Aug 11
Posts: 76
Credit: 2,002,860
RAC: 0
Message 552 - Posted: 18 Mar 2012, 19:31:29 UTC - in response to Message 551.  

The difference between 32bit and 64bit could also be from different compilers (gnu for linux vs. visual studio for Windows). There also seems to be a difference between AMD and Intel, even at the same clock speed.


you can not compare them using clock-speed. and you need to know which compiler is used and with which optimization options.

special builds for processor features are often a lot faster.

which versions of GCC and VS are you using?
ID: 552 · 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: 926
Credit: 97,222,922
RAC: 55,173
Message 554 - Posted: 18 Mar 2012, 23:27:49 UTC - in response to Message 552.  

The difference between 32bit and 64bit could also be from different compilers (gnu for linux vs. visual studio for Windows). There also seems to be a difference between AMD and Intel, even at the same clock speed.


you can not compare them using clock-speed. and you need to know which compiler is used and with which optimization options.

special builds for processor features are often a lot faster.

which versions of GCC and VS are you using?


Version 4.6.0 of gcc and for the windows compiler: Visual C++ 2010 express

I use -O3 optimization with the gcc compiler. With VS I use the "optimize for speed" option and also the "whole program optimization" option. So I agree it is hard to compare the linux version with the windows version.

I didn't think gcc used any special processor features to give an Intel CPU any advantage over the comparable AMD CPU. I know the intel compiler takes advantage of such features.
ID: 554 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
frankhagen

Send message
Joined: 19 Aug 11
Posts: 76
Credit: 2,002,860
RAC: 0
Message 559 - Posted: 19 Mar 2012, 13:47:44 UTC - in response to Message 554.  
Last modified: 19 Mar 2012, 13:48:28 UTC

I use -O3 optimization with the gcc compiler. With VS I use the "optimize for speed" option and also the "whole program optimization" option.


that way you get code which will run on any X86 (or AMD64) compatible machine. even those old ones that rarely exist anymore.
for AMD64 this (at least) enables the use of SSE-2 instructions, so they definitely will run faster than their 32-bit pendants. but every newer feature is simply left out.


I didn't think gcc used any special processor features to give an Intel CPU any advantage over the comparable AMD CPU.


right, not by default. to achieve that you have to use platform-specific compiler options - but that's exactly what MPIR supports with GCC. they even include special assembler code for several processor types.
ID: 559 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Matthias Lehmkuhl

Send message
Joined: 10 Jan 12
Posts: 8
Credit: 1,037,499
RAC: 0
Message 578 - Posted: 23 Mar 2012, 9:53:14 UTC

Hi Eric,
can you extend the deadline for this result?
It's running since 3 Days, and now at 79%. I have to shut down the machine for 3 Days during a power outage over the weekend.
http://numberfields.asu.edu/NumberFields/result.php?resultid=887424
Regular deadline is 24 Mar 2012 | 2:21:10 UTC
Time to go 19 hours.
Thanks.
Matthias
ID: 578 · 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: 926
Credit: 97,222,922
RAC: 55,173
Message 584 - Posted: 24 Mar 2012, 6:02:44 UTC - in response to Message 578.  

Hi Eric,
can you extend the deadline for this result?
It's running since 3 Days, and now at 79%. I have to shut down the machine for 3 Days during a power outage over the weekend.
http://numberfields.asu.edu/NumberFields/result.php?resultid=887424
Regular deadline is 24 Mar 2012 | 2:21:10 UTC
Time to go 19 hours.
Thanks.


Sorry, once it's been issued I can't change the deadline. But you should be safe with the new grace period and receive credit for it. If not, let me know.
ID: 584 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote

Message boards : Number crunching : DS-14x121 runtimes


Main page · Your account · Message boards


Copyright © 2019 Arizona State University