Posts by Woof
log in
1) Message boards : Number crunching : Output file size (and plans for the future) (Message 896)
Posted 10 Feb 2017 by Woof
BTW I think running out of work is worse than having to big of an output file.


You have to think about the scale of things though.

Let's go with a user with 100 cores to offer(since I have around that many and that's how I did the math since it was easy),and each WU only takes 30 minutes and makes that 6MB output file.

That's 1.2GB to upload every hour. ~29GB every day. ~864GB per month.

For someone with a lot more compute power that could really scale out. It looks like you have ~500 cores,and while I'm sure that's spread out across projects if you only ran this project and those Vv WUs you would end up using terabytes of upload per month....and I'm pretty sure your ISP would be giving you a call at that point.


Not to mention what it would be like to the computer at the other end of that. The server status shows ~13K tasks underway,so imagining that as the core count of all end users,scale that out. That's terabytes of transfer PER DAY.
2) Message boards : Number crunching : Unknown error number (0xffffffffc000001d) (Message 854)
Posted 6 Feb 2017 by Woof

Strange. I suspect that my app uses some rarely used AVX instruction, which is not recognized by your CPU


Looking at that host's specs,he's on Win7 but it doesn't declare SP1,which is required for AVX support.
3) Message boards : Number crunching : Optimization (Message 810)
Posted 25 Jan 2017 by Woof
Going from the 0.10 AVX version on my dual E5-2620 machine it used to average around 8-10K CPU seconds,with the newer app that is cut to around 5-6K secs.

Interestingly if I lower the number of tasks running at once to something like 4-6 at a time instead of using all 24 cores at a time it drops down to nearly 3-4K seconds.

I wonder if this is related to boost clocks or memory related. I've run into some weirdness with things that are memory bound when running on dual socket motherboards because it may get memory allocated in the wrong space,and while the links between CPUs are quick nowadays,it's still a performance penalty.


Anyways,simply amazing work!




Main page · Your account · Message boards


Copyright © 2019 CNR-TN & UniTN