Posts by Dr Grey

1) Message boards : Number crunching : My Computer Builds And Other Projects (Message 1841999)
Posted 13 Jan 2017 by Profile Dr Grey
Post:
OK. Well those CT scanners can be pretty compute intensive. It might be an opportunity to see some high end hardware in action and maybe mention the benefits of distributed computing to the radiographer...
2) Message boards : Number crunching : Panic Mode On (104) Server Problems? (Message 1841642)
Posted 12 Jan 2017 by Profile Dr Grey
Post:
Now it's 31.5/sec returned in the last hour with a creation rate of 36.7/sec. They are fighting a valiant battle.
Noticing also that the average turnaround time has dropped to 30.5 hours from 33 earlier so the shorter queues are showing.
3) Message boards : Number crunching : Panic Mode On (104) Server Problems? (Message 1841608)
Posted 12 Jan 2017 by Profile Dr Grey
Post:
So generating a surplus of 4/sec which is enough to fill a 100 wu cache every 25 seconds. That's fast. But with 162,000 active hosts, it will take a while to get ahead of the pack.

As long as it continues to produce work at that rate. Sometimes it's faster, but at other times (like the most recent update) it's slower.
Only 26/sec. Nowhere near faster enough.


It's interesting though, that the average turnaround time is as high as 33 hours. With a lot of people struggling with low queues you'd expect it to be much lower. That suggests that the bulk of machines don't run anywhere near dry during the outage so the deficit is probably not all that bad.
4) Message boards : Number crunching : Panic Mode On (104) Server Problems? (Message 1841606)
Posted 12 Jan 2017 by Profile Dr Grey
Post:
The splitting rate shown is an instantaneous figure, compared to the long (hour?) sample used to generate the return rate. As I type the splitting rate is over 35/sec, so should be "more than capable" of keeping up with the demand (based on the results returned), which is just over 31/sec.


So generating a surplus of 4/sec which is enough to fill a 100 wu cache every 25 seconds. That's fast. But with 162,000 active hosts, it will take a while to get ahead of the pack.
5) Message boards : Number crunching : Panic Mode On (104) Server Problems? (Message 1841599)
Posted 12 Jan 2017 by Profile Dr Grey
Post:
Well, this has been interesting. My Windows 10 machine has a full cache of work. My Windows 7 machines have zero GPU work. Looks like the outrage is going to cause at least a 3-4 day lack of GPU work for my fast machines.


Current result creation rate: 30.4548/sec
Results received in last hour: 110,406. 110,406 / 3600 = 30.668 / sec

So it looks like the splitters can't keep up.
6) Message boards : Number crunching : Looking for used laptops (Message 1841230)
Posted 10 Jan 2017 by Profile Dr Grey
Post:
The SATA-to-Molex cables are to power the card through the PCIe x16 connector, like the MB would if it were plugged directly to the MB. The male SATA connecter gets plugged into one of the SATA female plugs on the power supply's SATA connector cables. Spread them out on as many SATA cables as possible, they draw up to 75 watts each.


According to this site the power rating for SATA would be borderline at best.
7) Message boards : Number crunching : Looking for used laptops (Message 1841221)
Posted 10 Jan 2017 by Profile Dr Grey
Post:
Can you tell me what is the use of a 'SATA 15pin Male to MOLEX 4pin power cable' ?
Where do you connect the SATA 15pin Male ?


You could plug it into one of these . And then you'd probably want to accessorise that with one of these.

It's the same as a SATA power connector on an HDD. The female connector comes from the PSU - just be careful of the power draw.
8) Message boards : Number crunching : My Computer Builds And Other Projects (Message 1841048)
Posted 9 Jan 2017 by Profile Dr Grey
Post:
I've got to say that I'd enjoyed this build thread too - best of luck with the tests.
9) Message boards : Number crunching : Driver Restart History? (Message 1840390)
Posted 6 Jan 2017 by Profile Dr Grey
Post:
Reliability monitor is a good place to start in windows. If windows caught the event it might tell you in there.
10) Message boards : Number crunching : Open Beta test: SoG for NVidia, Lunatics v0.45 - Beta6 (RC again) (Message 1839154)
Posted 31 Dec 2016 by Profile Dr Grey
Post:
I've no idea who this Dr Grey is, but what I do know is that I would back Jason and Raistmer aganst his technical ability any day. Have a look at his team name.


Thanks for the vote of confidence for my technical ability. For the record I have none, but I don't see any harm in challenging the status quo and offering up ideas that are worth discussing. Do you?
11) Message boards : Number crunching : Open Beta test: SoG for NVidia, Lunatics v0.45 - Beta6 (RC again) (Message 1839117)
Posted 31 Dec 2016 by Profile Dr Grey
Post:
This imply assumption that maintenance time directly depends on database size.
And that database size directly (or largely enough) depends on mean deadline time.
Second assumption looks very unjustified for the reasons listed earlier. First assumption requires some proofs too.
And third assumption is that if deadline shrinkage will take place it will automatically lead to number of tasks per host limit rise. Hardly...


Not sure all those implications directly follow but nevertheless I've taken a look at my older pendings and can prove I am wrong... 80 % of the pendings are less than 2 weeks old. 12 % are older than 4 weeks and 6 % are older than 6 weeks with the oldest being about 8 weeks old.
Current deadlines appear to be about 7.5 weeks although some appear to be 3 weeks and I'm not sure why that is. All my pendings occur just beyond 1, 7.5 week deadline, suggesting that workunits requiring more than one resend are extremely rare, and when resends happen they turnaround on average in a couple of days. According to these figures anyway, trying to reclaim space by reducing deadlines from 7.5 to 4 weeks will gain only about 12 % space. That would be just 90 workunits based on my pendings and probably not worth it.
12) Message boards : Number crunching : Open Beta test: SoG for NVidia, Lunatics v0.45 - Beta6 (RC again) (Message 1839108)
Posted 31 Dec 2016 by Profile Dr Grey
Post:
The current deadlines for completion will continue to grow to be further away from the time taken for the bulk of canonical results to be achieved.

1) Deadlines will not grow. They will remain the same.
2) So what? Why this bother? Did you ever observe new version roll up where BOINC mis-predict estimated time to completion? With shorter deadline % of killed tasks will be even higher. So, all this just to make credit accounted faster for those over-competitive ones who can't just leave host as it is and spend time on optimization instead of credit rise watching? It will accounted eventually - that's all what matter.

Regarding real time processing: we do only pre-process. Final processing is Nebula. And it requires data movement into Atlas. This SETI search isn't real-time one by design. Its sensitivity comes from data accumulation over few observations spanned by years. Real-time processing just self-imposed goal, not really required for this kind of search. Would be good to complete search faster, but cutting some processing power will not make it faster, it will make it slower. Particular result mean validation time isn't matter. There are millions of such results.


1) As average turnaround shrinks and deadlines remain the same, the time between them grows.
2) Why bother optimising the process? To decrease entries from slow to verify workunits. From my understanding this would enable a greater cache size to be allowed without impacting the database size.

If older, unverified workunits sitting in the database that would otherwise be reduced by shortening the deadlines have little impact on the backend system then I have little to argue about. But it would be interesting to know what proportion that would be. I could do that by looking at my own cache I guess. I'll go and make a coffee and see if I can make some figures.

On your last point though, the potential computational benefit to be gained I agree, is minimal. It would arise from those very high end machines that run dry during an outage. Looking at Petri's record breaker, his turnaround average is 0.16 days. A little under 4 hours. That means he's probably running dry half way into an 8 hour outage, about once a week. Or around 2.5 % of the time. Everyone else will be less than this. However, it could be argued that enabling a larger cache to ensure that 2.5 % performance gain from Petri, at the expense of our slower tail, would be better for the computational output of the project - as that 2.5% could be substantially larger than the tail output. But that would put us at odds with an egalitarian ideal.
13) Message boards : Number crunching : Open Beta test: SoG for NVidia, Lunatics v0.45 - Beta6 (RC again) (Message 1839096)
Posted 31 Dec 2016 by Profile Dr Grey
Post:


As soon as we adopt the intentions of the technology vendors at present, then more than 95% of our hardware compute capacity is immediately defunct. It would be nice if we could all have shiny new Kaby Lakes and GTX 1080s, but it's not realistically going to happen... especially when the gains represent poor return for the money. They need to do a lot better before we can say goodbye to stuff that works.


Nevertheless, time moves on. Looking back over the last few years SETI compute power increases by 5-10% each year. 1080s are soon to be old hat with the 1080Ti arriving soon, AMD's RyZen will hopefully perk up the CPU market pushing Intel towards adopting 10 nm quicker and I'm reading that we're hopeful for even better SETI apps in the near future. Older devices will continue to be retired and all this will all impact the average turnaround time, making analysis ever closer from near time to real time. The current deadlines for completion will continue to grow to be further away from the time taken for the bulk of canonical results to be achieved.
14) Message boards : Number crunching : Open Beta test: SoG for NVidia, Lunatics v0.45 - Beta6 (RC again) (Message 1839083)
Posted 31 Dec 2016 by Profile Dr Grey
Post:
Consider ARM6 phone crunching only when charging.
http://setiathome.berkeley.edu/host_app_versions.php?hostid=7435236
Среднее время обработки 25.85 days

That is, ~4 weeks. No need to touch deadlines.
If "97%" complete "just in one-two days" then fine, those tasks will be validated and deleted from BOINC database faster. They even not need to be kept week, just those 2 days.
But other still have chance to participate.

P.S. What need to be touched instead is quota system that fails to catch hyper-fast broken GPU hosts. That can produce thousands of broken results per day - amount that slow crunchers will not accumulate through whole year!


I cannot see the benefit to the project of catering for such low processing capability devices. Do they generate publicity or revenue? Even my Raspberry Pi, with a RAC of 87.46 (!) still has a turnaround of 2.74 days. That is about 1/500 of what my PC produces. The only reason I keep it connected is because it makes me happy that way - a bit like keeping a hamster with a wheel.
Is it right to keep the database inflated just to enable folks to keep their pet devices warm? What is the real benefit here? I agree on your last point.
15) Message boards : Number crunching : Open Beta test: SoG for NVidia, Lunatics v0.45 - Beta6 (RC again) (Message 1839032)
Posted 31 Dec 2016 by Profile Dr Grey
Post:
It would make good sense if the workunit deadlines were cut if the aim is to keep the database small.

True, however the project also wants to make use of the widest possible range of hardware, so the longer deadlines are necessary for the much, much slower crunchers out there.


I have heard this said in the past and it is a laudable aim, but allowing 6 weeks when 99% are probably being returned inside of 7 days is a substantial commitment towards outreach and could be considered unwarranted, especially if it is impacting the performance of the project.
16) Message boards : Number crunching : Open Beta test: SoG for NVidia, Lunatics v0.45 - Beta6 (RC again) (Message 1839024)
Posted 31 Dec 2016 by Profile Dr Grey
Post:
Inconclusives have never been a worry of mine, as long as they turn valid at some point and do not become invalid.

The problem with Inconclusives is the load on the database. The more Inconclusives there are, the larger the database becomes to keep track of all the work that is out there.
The project needs more crunchers to crunch the increasing amount of Greenbank work, yet they already have limits on the amount of work people can cache in order to reduce the strain on the database. The more Inconclusives, the greater the strain. Couple that with more crunchers and you've got a recipe for the whole thing crashing and burning repeatedly on a scale we've previously not seen.


It would make good sense if the workunit deadlines were cut if the aim is to keep the database small. Average turnaround is currently standing at less than two days, so three sigma being less than a week would give most of the workunits a good chance of being returned in that time. So, if you could cut the deadline to half what it is now and double the cache size - we'd have fewer workunits waiting around for validation from non-returners and healthier caches for the faster machines to stop them running dry and the operation would be all the more snappier... and happier.
I've just clicked through to see my oldest validation pending and it was sent out on the 28th Oct having timed out on my wingman. Actually, that's interesting. How do you get 2512 tasks in progress?
17) Message boards : Number crunching : GPU Wars 2016:  Pascal vs Polaris (Message 1835902)
Posted 14 Dec 2016 by Profile Dr Grey
Post:
Hopefully that will be putting some price pressure on the 1080 Ti launch
18) Message boards : Number crunching : Found a workaround for uncontrollable GTX 1080 downclocking / throttling (Message 1835360)
Posted 11 Dec 2016 by Profile Dr Grey
Post:
Since getting my EVGA GTX 1080 FTW I have had trouble getting it to sit reliably at a set overclock. Neither MSI's Afterburner or EVGA's Precision tools would work in enabling a constant overclock when running SETI. The card always had a tendency to downclock to 1721 MHz, occasionally bumping up to whatever overclock I had set it to without any apparent cause but always coming back down again, spending the majority of time at the lower clockspeed. I could sit and watch it on GPU-Z and there didn't seem to be any correlation of these jumps with BOINC activity - it wasn't happening with WU's starting and finishing. It's not temperature related as the card would be sitting in the low 70 C range if the overclock was being met, dropping to low 60s C at the downclock. It would also drop the voltage as it downclocked.
It looks like Nvidia's GPU Boost has been deciding that not much was going on, despite GPU-Z saying the GPU load was 98-99 %, and dropping the card into a lower power draw state. Changing 'power management mode' under Nvidia control panel/manage 3D settings to 'Prefer maximum performance' had no effect. All very frustrating and Googling the issue found a number of threads out there where other folks are encountering this with no solution being found.
I was considering seeing if changing the thread priorities would have an effect but I hadn't figured out how to do that yet, but anyway I might have found a way to force GPU Boost to stop the card from being so lazy.
In Nvidia control panel there's the 'Adjust Image Settings with Preview' menu item with the preview window showing a rotating Nvidia logo. Last night I was finding that just opening that setting pushes the card into its high power state. When I closed the panel the card would drop down to 1721 MHz again. You can even pause the animation and minimise it and the card will remain at full power. So I left it in that state over night, finding this morning that the card will sit at full power regardless of whether the panel is open or not - which is a bit weird. Whether this condition will survive a reboot or not I don't know, but I thought I'd put this out there in case anyone else is having this issue and wants to try it.
19) Message boards : Number crunching : You have to love early Xmas and B'day presents (even if you have to pay for them yourself). (Message 1834441)
Posted 6 Dec 2016 by Profile Dr Grey
Post:
I guess a lot of folks will be getting their upgrades for Christmas. The 1060s and 1070s look like really good value for a two or more generations upgrade.
20) Message boards : Number crunching : GPU Wars 2016:  Pascal vs Polaris (Message 1833135)
Posted 29 Nov 2016 by Profile Dr Grey
Post:
It is worth checking that Windows has been fully updated as nVidia can refuse to install on a non-updated system


Next 20


 
©2018 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.