Posts by marmot
log in
1) Message boards : Number crunching : Estimated running time / size given by project vs reality ! (Message 4940)
Posted 10 hours ago by marmot
Other possibilities when over clocking, error correction in RAM slows the process down so over clocked system RAM or T3 cache could actually slow work down; step your FSB down 1 or 2 points and see if things speed up.

If running WU on 1 or 2 cores then the CPU can use burst mode to higher frequencies to get faster results. When all cores are in use then burst mode can't be used for all available wattage is in use and thermal limits are reached.
2) Message boards : Number crunching : Error while downloading (Message 4939)
Posted 10 hours ago by marmot
Getting some which aren't _a:

They range from _1 to _9 (heaviest amounts in _8 and _9 from random sampling)
Last one sent 15 Feb 2019, 7:33:14 UTC, first one 12 Feb 2019, 17:46:05 UTC.

180 WU in total.
Latest WU numbers,
35802096, 358066607, 358024256, 357986345.
Earliest WU numbers 357915583-86 (aborted by user and resent in the time period, so earlier data set was also effected).

Hope that helps you track down the problem.
3) Message boards : Number crunching : Slow scheduling (Message 4922)
Posted 4 days ago by marmot
Have all my other projects on 0 resource and they have filled the cores.

If I manually update SRBase then it checks for work (no "full cache" or "not highest priority project" errors) but when left on it's own it only requests work every 6 to 12 hours.

So all my machines but one older laptop missed out on the WU's today.

Any solution to the slow scheduler without idling cores (the machines heat the house and it's -10C outside)?
4) Message boards : Number crunching : Long 2 are a joke (Message 4915)
Posted 12 days ago by marmot


Just make the number the same as your <cmdline>-t4</cmdline> number.

Thanks, did that already.

The long1's were getting about 330 hours/day and that was what I expect from single thread, 1 per machine, but they are set to 3 threads and so it seemed like WUprop wasn't counting them correctly.

Some new long1-3 came down today and I'll try and get accurate accounting.
5) Message boards : Number crunching : Proposal to prevent days of lost CPU cycles on long WU's (Message 4914)
Posted 12 days ago by marmot
Forgot to add something.

If you make longs multi core by default (long1 = 8 core, long2= 4 core, long3 = 2 core) then limiting each client to 2 long1, 4 long 2 and 8 long3's would equally distribute the load and prevent the user aborts and management just before deadlines.

It might also encourage more to do longs.

Just another tactic seen at YAFU to deal with the 16 and 32 thread WU's. 2 per machine, maximum, ignoring the user default of 'unlimited'.
6) Message boards : Number crunching : Proposal to prevent days of lost CPU cycles on long WU's (Message 4909)
Posted 13 days ago by marmot
So over at YAFU some of the 32t WU's can go for 14 days.

The project developer, Yoyo, set up a dual deadline scenario.

The first deadline is the one the client shows and is the date by which the WU must be started.

The second deadline is the validation deadline which the WU needs to be completed by and is set at 7 days past the start deadline.

Not sure how YoYo implemented this but it's a great solution to this.

Looking through the long WU history I'm seeing 3 to 8 CPU days of wasted time on many WU's and a list of 5 to 15 attempts before the WU is completed.

What do you think?

(Personally, I like the long WU's and will do them all the time but aborting 300-500k second WU's tonight is making me nauseous.)
7) Message boards : Number crunching : Work available?? (Message 4908)
Posted 13 days ago by marmot
Sorry for the delay, I had a lot to do at work and Iam a little bit sick. I will come back to you as soon as possible.

Beat that pathogen into retreat.
8) Message boards : Number crunching : Long 2 are a joke (Message 4907)
Posted 13 days ago by marmot
Mine work using <cmdline>-t4</cmdline>

Wuprop only counts 1 thread though.

That REALLY sucks... I was going to increase thread count to 6 until noticing your comment and now really want to reduce it back to 1 and abort all long WU that don't have 6 days deadline.

One of my main goals it to complete 100,000 hours per work unit at WuProp.

Reduce hours counted by 1/3 on longs will mean it might be 4 years to reach 100,000 hours since WU here are intermittent and I shut down work in the summer to avoid contributing to global warming with A/C since our community still uses coal and natural gas fired power plants.

@Rebirther, why not triple the deadline on longs and then there will be much less wasted work, and a higher probability of work 24/7 instead of these long gaps of no WU's?
9) Message boards : Number crunching : Long 2 are a joke (Message 4906)
Posted 13 days ago by marmot
Given my longs 3 threads and still running up against deadlines on some of them.

Why does BOINC start a WU with only 12 hours left that took 3 days to run?

Guessing BOINC is ignorant and only the server here would have the data on average run times and would have to determine the WU couldn't complete and do the cancellation on it's end, right?

I had self abort 8+ longs per machine by using my own deadline calculations.

A longer deadline or more aggressive server cancellations would be appreciated so I can reduce my management time.
10) Message boards : Number crunching : SR-base overheat !? (Message 4900)
Posted 22 days ago by marmot

Hello ?
I will not move to artic or antartic because SR take so much !
Joke of course.

BBC had a story about a lady in Siberia heating her house with BtC mining computers.

My house is completely warmed by computers this winter except tomorrow when the temps are going to drop to 6F outside. I'll fire up the wood stove and burn the branches gathered from the lawn plus sawdust and old magazines (saving on the trash bill too).

Picked the right part of winter to run some SRBase!
11) Message boards : Number crunching : SR-base overheat !? (Message 4899)
Posted 22 days ago by marmot
If you are on Windows then Throttle Stop is a great general clock control and for BOINC there is TThrottle which analyzses PID's, has a database of known BOINC WU's and pauses them for a few cycles in order to keep the core temps at the setting you pick. Also, allows maximum and minimum CPU usage that works way better than the built in BOINC version. Also works for many GPU projects (not very well on Collatz).

Not sure if there are Linux versions available but probably for TThrottle at least.
12) Message boards : Number crunching : Why is this WU so time consuming? (Message 4218)
Posted 15 Feb 2018 by marmot
Maybe this work unit was actually that long as it verified the prime I found

40 · 1017215605 + 1
13) Message boards : Number crunching : Why is this WU so time consuming? (Message 4096)
Posted 11 Jan 2018 by marmot

16 credit SR Base 146,416.00 CPU seconds.

All the others were about 700-800 seconds
14) Message boards : Number crunching : WU with error in CPU time (Message 3771)
Posted 21 Aug 2017 by marmot
CPU time of over 3 million seconds completed in a day.

Some fishy smell here.

Main page · Your account · Message boards

Copyright © 2014-2019 BOINC Confederation / rebirther