Message boards :
Number crunching :
DS-14x121 runtimes
Message board moderation
Author | Message |
---|---|
Send message Joined: 28 Oct 11 Posts: 179 Credit: 220,376,862 RAC: 128,125 |
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. |
Send message Joined: 8 Jul 11 Posts: 1318 Credit: 403,722,178 RAC: 288,032 |
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. 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 |
Send message Joined: 8 Jul 11 Posts: 1318 Credit: 403,722,178 RAC: 288,032 |
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. |
Send message Joined: 16 Nov 11 Posts: 1 Credit: 1,000,405 RAC: 0 |
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 |
Send message Joined: 3 Sep 11 Posts: 30 Credit: 7,701,817 RAC: 3,703 |
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 |
Send message Joined: 8 Jul 11 Posts: 1318 Credit: 403,722,178 RAC: 288,032 |
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. |
Send message Joined: 19 Aug 11 Posts: 76 Credit: 2,002,860 RAC: 0 |
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? |
Send message Joined: 8 Jul 11 Posts: 1318 Credit: 403,722,178 RAC: 288,032 |
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. 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. |
Send message Joined: 19 Aug 11 Posts: 76 Credit: 2,002,860 RAC: 0 |
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. |
Send message Joined: 10 Jan 12 Posts: 8 Credit: 2,141,406 RAC: 3,303 |
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 |
Send message Joined: 8 Jul 11 Posts: 1318 Credit: 403,722,178 RAC: 288,032 |
Hi Eric, 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. |