Um.. your first Mac has deadlines to 26 May, your second Mac has deadlines to 17 May and your third Mac has deadlines to 20 May.
If you don't want to go past deadlines, edit your "connect to server" option back to something lower, like 0.1 days so it will only get one result, or stop work from other projects for a while.
My 450MHz P3 runs 2 projects and still returns Einstein units on time. Don't worry - BOINC won't let you go overdue unless YOU do something silly on purpose.
My 450MHz P3 runs 2 projects and still returns Einstein units on time. Don't worry - BOINC won't let you go overdue unless YOU do something silly on purpose.
Yours is about the slowest machine that can safely run completely unsupervised though. With a peak 650 credit WU size you're potentially looking at a little more than 13days to complete the largest sized WU possible.
My 450MHz P3 runs 2 projects and still returns Einstein units on time. Don't worry - BOINC won't let you go overdue unless YOU do something silly on purpose.
Yours is about the slowest machine that can safely run completely unsupervised though. With a peak 650 credit WU size you're potentially looking at a little more than 13days to complete the largest sized WU possible.
I'd love for someone to comment on my theory in regards to the initial benchmarking and someone pulling multiple units at one time. Sure, perhaps one of the units might make it, but if multiple units were downloaded at the same time here, both get only two weeks. If they are the same size and it takes 8 days for one, that means any host like that which grabbed two units because the benchmark-RDCF combination wasn't accurate enough yet, would be working on the second unit needlessly... Sure, it might only happen one time to a specific host (due to the RDCF update after the first result), but it is possible... MD's 450 took 540,727.83 seconds for a mere 330.64 credit unit. If you took what Akos posted (535.92) and assumed linearity:
Don't know if you guys saw it yet, but Bernd posted a PDF you can use to extrapolate runtime vs template frequency in the S5R2 thread.
The curve is not even close to linear, and has significant discontinuties. Since it looks like host speed selection is still not enabled there are regions at the high and low of the range where Katmai PIII's and older and most likely first generation Athlons and older could be/are in deadline trouble if they draw just one result and run 24/7.
Don't know if you guys saw it yet, but Bernd posted a PDF you can use to extrapolate runtime vs template frequency in the S5R2 thread.
I hadn't put on my thinking cap when I first looked at it (and apparently when I just now looked at it either), so it didn't make a lot of sense to me. Perhaps if I paid more attention (or someone made a "for dummies" version), I'd get it... I think I got the general idea that progress curve isn't linear, so I made a linear math equation for an example. Even if it was being generous, it still drove home a point that Matt's 450 wouldn't be able to handle multiple WU downloads of certain types and return all results in the 14-day limit...
Has anyone seen one of those yet? Largest I ever came across was 529.xx credits, and someone mentioned 544.xx, but nothing bigger...
Hi Annika!
I'm not sure those monster workunits have already been distributed to crunchers, they originate from the very high end of the frequency search range. The estimation was based on the graph that Bernd posted here
If you see a workunit h1_0FFF.nn_S5R2_* where FFF is > (ca.) 530, you will notice it takes a little bit longer to complete it.
Has anyone seen one of those yet? Largest I ever came across was 529.xx credits, and someone mentioned 544.xx, but nothing bigger...
Hi Annika!
I'm not sure those monster workunits have already been distributed to crunchers, they originate from the very high end of the frequency search range. The estimation was based on the graph that Bernd posted here
If you see a workunit h1_0FFF.nn_S5R2_* where FFF is > (ca.) 530, you will notice it takes a little bit longer to complete it.
CU BRM
OK. The graph is starting to make sense to me now... I wasn't sure if FFF was the frequency ("What's the frequency Kenneth?")... If you don't understand the quote, Google it... ;-)
So, I have 409s right now... According to that PDF, it estimates 16-17hr runtimes? Is that correct? If so, what is the baseline system? Also are these the current estimates or are they based on having MMX/SSE optimization?
Has anyone seen one of those yet? Largest I ever came across was 529.xx credits, and someone mentioned 544.xx, but nothing bigger...
Hi Annika!
I'm not sure those monster workunits have already been distributed to crunchers, they originate from the very high end of the frequency search range. The estimation was based on the graph that Bernd posted here
If you see a workunit h1_0FFF.nn_S5R2_* where FFF is > (ca.) 530, you will notice it takes a little bit longer to complete it.
CU BRM
OK. The graph is starting to make sense to me now... I wasn't sure if FFF was the frequency ("What's the frequency Kenneth?")... If you don't understand the quote, Google it... ;-)
So, I have 409s right now... According to that PDF, it estimates 16-17hr runtimes? Is that correct? If so, what is the baseline system? Also are these the current estimates or are they based on having MMX/SSE optimization?
According to Bernd the runtime estimation was based on an early version of unoptimized code. The abolute numbers are not relevant, but by comparing the estimated runtime to actual runtime from past results, you can scale the Y-axis to match your machine's performance.
The WU you've done before were 249ers, which is close to a discontinuity in the graph so it's difficult to say whether they fall into the 6th or 7th group of WUs. I think it's in the 7th. Those WU took your machine 93k sec to complete, or 25.8 h. The graph would indicate a runtime of ca 21 h on the reference machine so if you add approx 23% to the runtime estimation you see in the graph you should get a good idea about runtime on your AMD. For your current WUs this would mean 17*1.23 = almost 21 h. Does that agree to what boinc manager is telling you?
It also means that the longest WU ever in this run will take about 46 h to complete on your machine. But we might see some optimization, especially for AMD under Win, until then.
Could you make the deadlines longer please?
)
Um.. your first Mac has deadlines to 26 May, your second Mac has deadlines to 17 May and your third Mac has deadlines to 20 May.
If you don't want to go past deadlines, edit your "connect to server" option back to something lower, like 0.1 days so it will only get one result, or stop work from other projects for a while.
My 450MHz P3 runs 2 projects
)
My 450MHz P3 runs 2 projects and still returns Einstein units on time. Don't worry - BOINC won't let you go overdue unless YOU do something silly on purpose.
RE: My 450MHz P3 runs 2
)
Yours is about the slowest machine that can safely run completely unsupervised though. With a peak 650 credit WU size you're potentially looking at a little more than 13days to complete the largest sized WU possible.
Has anyone seen one of those
)
Has anyone seen one of those yet? Largest I ever came across was 529.xx credits, and someone mentioned 544.xx, but nothing bigger...
RE: RE: My 450MHz P3 runs
)
I'd love for someone to comment on my theory in regards to the initial benchmarking and someone pulling multiple units at one time. Sure, perhaps one of the units might make it, but if multiple units were downloaded at the same time here, both get only two weeks. If they are the same size and it takes 8 days for one, that means any host like that which grabbed two units because the benchmark-RDCF combination wasn't accurate enough yet, would be working on the second unit needlessly... Sure, it might only happen one time to a specific host (due to the RDCF update after the first result), but it is possible... MD's 450 took 540,727.83 seconds for a mere 330.64 credit unit. If you took what Akos posted (535.92) and assumed linearity:
535.92/330.64 * 540727.83 / 3600 / 24 ~= 10.144 days.
Don't know if you guys saw it
)
Don't know if you guys saw it yet, but Bernd posted a PDF you can use to extrapolate runtime vs template frequency in the S5R2 thread.
The curve is not even close to linear, and has significant discontinuties. Since it looks like host speed selection is still not enabled there are regions at the high and low of the range where Katmai PIII's and older and most likely first generation Athlons and older could be/are in deadline trouble if they draw just one result and run 24/7.
Alinator
RE: Don't know if you guys
)
I hadn't put on my thinking cap when I first looked at it (and apparently when I just now looked at it either), so it didn't make a lot of sense to me. Perhaps if I paid more attention (or someone made a "for dummies" version), I'd get it... I think I got the general idea that progress curve isn't linear, so I made a linear math equation for an example. Even if it was being generous, it still drove home a point that Matt's 450 wouldn't be able to handle multiple WU downloads of certain types and return all results in the 14-day limit...
RE: Has anyone seen one of
)
Hi Annika!
I'm not sure those monster workunits have already been distributed to crunchers, they originate from the very high end of the frequency search range. The estimation was based on the graph that Bernd posted here
If you see a workunit h1_0FFF.nn_S5R2_* where FFF is > (ca.) 530, you will notice it takes a little bit longer to complete it.
CU BRM
RE: RE: Has anyone seen
)
OK. The graph is starting to make sense to me now... I wasn't sure if FFF was the frequency ("What's the frequency Kenneth?")... If you don't understand the quote, Google it... ;-)
So, I have 409s right now... According to that PDF, it estimates 16-17hr runtimes? Is that correct? If so, what is the baseline system? Also are these the current estimates or are they based on having MMX/SSE optimization?
RE: RE: RE: Has anyone
)
According to Bernd the runtime estimation was based on an early version of unoptimized code. The abolute numbers are not relevant, but by comparing the estimated runtime to actual runtime from past results, you can scale the Y-axis to match your machine's performance.
The WU you've done before were 249ers, which is close to a discontinuity in the graph so it's difficult to say whether they fall into the 6th or 7th group of WUs. I think it's in the 7th. Those WU took your machine 93k sec to complete, or 25.8 h. The graph would indicate a runtime of ca 21 h on the reference machine so if you add approx 23% to the runtime estimation you see in the graph you should get a good idea about runtime on your AMD. For your current WUs this would mean 17*1.23 = almost 21 h. Does that agree to what boinc manager is telling you?
It also means that the longest WU ever in this run will take about 46 h to complete on your machine. But we might see some optimization, especially for AMD under Win, until then.
CU
BRM