Posts by jason_gee


log in
1) Message boards : Number crunching : Average Credit Decreasing? (Message 1784149)
Posted 1 day ago by Profile jason_gee
So, all this being said, would installing the 64 bit version of Windows possibly clear up some of the issues?


*Possibly*, on a lot of provisos: if it is one of the later (I think Cedar Mill) P4 models that can do 64 bit, currently it is notably paging the HDD when trying to load the 950 up, and there is actually any CPU headroom apparent.
2) Message boards : Number crunching : Building a 32 thread xeon system doesn't need to cost a lot (Message 1784040)
Posted 1 day ago by Profile jason_gee
Oh, and a little OT, but Jason, could you head over to this thread and check out my post here and comment there on your thoughts of what might be going on? It seems a little weird, with such a large difference in systems that they would be so close in RAC. Thanks!


Done!
3) Message boards : Number crunching : Average Credit Decreasing? (Message 1784039)
Posted 1 day ago by Profile jason_gee
Interestingly the slower you crunch, the higher the 'award' with this strange 'system'. I can easily recognize this, cause i have two different GPUs, the GT 640 being nearly three times faster than the GT 430. On similar WUs the GT 430 always get more credit, only topped by the CPU (Core2Quad), which again earns more credit for a similar WU. I think "borked" is way too friendly for this behavior...

Absolutely true it appears. In this example, I have 2 machines, a Genuine Intel(R) Atom(TM) CPU 330 @ 1.60GHz [Family 6 Model 28 Stepping 2] (4 processors) and a Genuine Intel(R) Pentium(R) 4 CPU 3.80GHz [Family 15 Model 4 Stepping 10] (2 processors) and have recently been keeping an eye on them, and wondering what might be going on. They are both configured to only run GPU tasks, as the Atom would pretty much choke on anything CPU, it really wouldn't be worth it.

As the P4 3.8 proc is unfortunately fairly pitiful as well, I decided to set that up as a GPU only cruncher too. Now to be honest, the Atom just sits upstairs happily crunching away with no one bothering it at all, and the P4 is used by my daughter for web based games and such, maybe 1 hour each day of the week and on one of those days for a total of probably 2-3 hours, where crunching is suspended because it really effects the usability of the system if it is enabled.

So because of that, it's not an _exact_ apples to apples comparison, but pretty dang close I'd say, and the difference in RAC (or should I say lack of significant difference) is pretty surprising. And actually, the Atom is (and has been for a while) running higher (6,304 ) than the P4 (5,765), and it only has a GTX260 in it, whereas the P4 has a GTX950, which is 5 generations newer then the 260, and both the 260 and the 950 are pretty much the lower end of their respective spectrums when they were new.

Just thought I'd toss that out there as an interesting comparison.


This comparison may be obscured a bit, because first the hyperthreaded p4 will likely be underfeeding the 950. That'd be partly due to hyperthreading sharing resources with everything else the system needs to do, partly because the 950 would be natively 64 bit while the OS is 32 bit on the host, and depending on what tasks you're running, because the GPU has 2GiB VRAM, you could run into paging issues with presumably the Max RAM installed.

In the Atom + 260's case, I believe the 260 will be being fed more than adequately, having more cores, likely no system RAM pressure (2 Gig offset partially only by the 895MiB VRAM)

If it were me, and physical/driver/power/thermal considerations allowed, I would swap those GPUs. (Mostly would depend if they made an XP driver for the 950 I suppose) [Would probably have to consider more RAM in the Atom machine though, depending what the OS+driver does having 2GiB VRAM to map into the physical space, and how many tasks you'd want to run at a time on it]
4) Message boards : Number crunching : Building a 32 thread xeon system doesn't need to cost a lot (Message 1783985)
Posted 1 day ago by Profile jason_gee
The Quadro's work, though that model won't be breaking any records, with only 64 Cuda cores and compute capability 1.1 (pre-Fermi). Most likely either Cuda 2.3 or 3.2 will be the best choice for Cuda MB application, and you'd need to be careful with drivers since Pre-Fermi was moved to an end-of-life branch, and might need to try a few to see which will support OpenCL on this device.

(If looking to change, a 750ti would cream that GPU for less noise and power)
5) Message boards : Number crunching : V8 CUDA for Linux? (Message 1783779)
Posted 2 days ago by Profile jason_gee
...So seems to me we have some technological convergence going on between Windows and Linux :)

So Jason, in your opinion, is this a good thing or a bad thing? Are they 'dumbing down' (for lack of a better way of describing it) Linux which might reduce it's performance and implied (to me) advantages over Windows? Or is it good in that it allows programmers to work with more of a single skill set? Or something completely different?


It's hard (speaking as a computer scientist). The *NIX model as has been has some 30+years behind it (many more if you count BCPL, predecessor to C etc). At the same time, I believe *NIX dropped the ball with threading and scalability, which is becoming a thing finally.

These are things that M$ did before *NIX, but then the commodore Amiga had preemptive multitasking before either of them anyway (despite that the Amiga was based on a SunStation)... So It comes down to precious developers protecting their turf and being precious.

In this case I think the CPU scaling stall was ineveitable, and the only choice was multithreaded everything. For what we have now it's just M$ that recognised it first, and embraced it early (~2005);
6) Message boards : Number crunching : Average Credit Decreasing? (Message 1783758)
Posted 2 days ago by Profile jason_gee
Has anybody already made any estimates about crunching rate (not credit) in these last (dis)creditnew years?


For here, you can guesstimate total crunched only goes up by Moore's Law (transferred to GPU from CPU in recent years, as CPU more or less stalled)

You can roughly approximate how much credit has dropped for the same #operations by getting a raw cobblestones for a given task, by APR*cobblestone_scale*elapsed_time_seconds, which will approximate what credit would be pre-creditnew downscaling.

cobblestone_scale is 200/86400e9
7) Message boards : Number crunching : Average Credit Decreasing? (Message 1783743)
Posted 2 days ago by Profile jason_gee
Sorry, but I've sat through this thread reading all the reproach people have about the credit system and how David doesn't want to change anything, but then apparently neither does anyone here or else someone would've gone that track already.


I think alot of that animosity comes from the lack of acknowledgement that what users see is real, apparently isn't being worked on (An understandable and natural consequence of the transferral/change/budget-cuts, and low priority placed on Credit, ignoring that it's tied into critical estimates)

From one of those developers' (doing nothing) perspectives, I know exactly where the design flaws in CreditNew lie, and they are non-trivial. This is more than a simple code patch.

IMO, what has to happen is for things to break, and that's what you're witnessing.
8) Message boards : Number crunching : V8 CUDA for Linux? (Message 1783674)
Posted 3 days ago by Profile jason_gee
Oh okay understand now.


looking around at more changes, it looks like the meaning of that may have changed not all that long ago as well, as a lot seems to be pointing to virtualisation and the memory management as having had major overhauls.
9) Message boards : Number crunching : V8 CUDA for Linux? (Message 1783655)
Posted 3 days ago by Profile jason_gee
Afternoon

Okay I have had no further error from the 2 MINT 17.3 machines.

Another thing I have noted is that the virtual memory size for some of these units are 20gb, any clues as to why is that, compared to the Windows version running 117.6mb

Regards


I'd say the virtual size just represents the address space visible to the process, rather than any physical figure (certainly there are no allocations anything near that large). Most likely the Windows figure represents committed memory.
10) Message boards : Number crunching : V8 CUDA for Linux? (Message 1783642)
Posted 3 days ago by Profile jason_gee
Skimming 4.x Kernel changelogs, looks like multiple queue block layers (software and hardware level) were added to better support NVM(e) storage and scaling to multiple cores (spreading IO/driver load). That means functionally the same race conditions now exist as on Windows (with different semantics/buffer-structure/delays), as the symptoms and apparent workaround suggested.

Most likely different applications running at reduced priority, will trigger this particular finished-file-present-too-long issue, depending on system contention and different kinds of devices.

Down the road before recommending Boinc/api fixes, will probably have to attempt to replicate here using a newer Kernel and/or devices.
In the meantime I'd suggest the no_priority_change workaround should help in the majority of cases where it occurs on Linux. Probably a more complete fix to allow running at idle priorities (as intended) will involve more than one of the following:

- restoring normal priority for exit [very brief]
- writing the finish file last (instead of before boinc diagnostics shutdown) [not a complete fix, but minimises risk]
- making the client a bit less fussy about finished files.
[As per Juha's suggestions, probably should care less about them, if at all, e.g. for slot management]

So seems to me we have some technological convergence going on between Windows and Linux :)
11) Message boards : Number crunching : V8 CUDA for Linux? (Message 1783608)
Posted 3 days ago by Profile jason_gee
Greetings All

Nil lockups or errors since yesterday afternoon.

Regards


Was that with the no_priority_change flag set ? or just left as it was ?
12) Message boards : Number crunching : V8 CUDA for Linux? (Message 1783433)
Posted 4 days ago by Profile jason_gee
Stock Boincapi and the client don't cope extraordinarily well with buffered IO and threading. You can try renicing to a more normal process priority (which may help).

Hmmm, that could help. I'm using the <no_priority_change>1</no_priority_change> on my Ubuntu 16.04 machine, and I'm not getting those Errors. I ran the cuda42 App for a while but switched to the "Special" App after seeing how hard the credits are falling again. tazzduke is getting that Error on both of his Ubuntu 16.04 machines.


OK, after this Cuda 8 testing is done, will do a little research to see what might have changed in the Linux Kernel and/or C Libraries. My money's on that it's the threading/IO, and that could mean a lot of problems on the horizon for Boinc.
13) Message boards : Number crunching : V8 CUDA for Linux? (Message 1783430)
Posted 4 days ago by Profile jason_gee
So, what's up with all the "finish file present too long" Errors?
https://setiathome.berkeley.edu/results.php?hostid=7974150&state=6


Probably implies that Linux *may* have moved to buffered IO/Multithreaded-C-Runtimes, which would probably make sense with more mobile targets these days wanting to offload to a dedicated IO sentinel core. (Lazy IO as has been normal in Windows since ~2005, as a desktop optimisation.)

Stock Boincapi and the client don't cope extraordinarily well with buffered IO and threading. You can try renicing to a more normal process priority (which may help).

As you would be using some standard boincapi as my Linux builds do, for a more permanent code fix, If updating your boincapi used in the build doesn't help (Rom switched at least some file IO to commit mode), then until the client is made less fussy, you probably need to shift the finished file creation from where it is in boinc_finish() (or whatever) into boinc_exit() as last call before exit().

At least those are the workaround/messy conclusions we reached on Windows. If similar symptoms are manifesting on Linux, and the workarounds are similar, then it points at proper fixes (for Boinc)

[If you need it, Can post a patch for current api after Cuda8 testing is over with]
14) Message boards : Number crunching : Average Credit Decreasing? (Message 1783217)
Posted 4 days ago by Profile jason_gee
Interestingly the slower you crunch, the higher the 'award' with this strange 'system'. I can easily recognize this, cause i have two different GPUs, the GT 640 being nearly three times faster than the GT 430. On similar WUs the GT 430 always get more credit, only topped by the CPU (Core2Quad), which again earns more credit for a similar WU. I think "borked" is way too friendly for this behavior...


Yep, that's right. This was discovered during controlled tests on Albert, which had tasks that process identically at the time. If you crunch less efficiently (i.e. take longer and generate more heat) you end up on the high side of the claim. [i.e. process much slower than the expected ~5%+/- of peak_flops (GPU)]

Higher credit will happen when you crunch as slowly as possible (claiming lots of operations), and are paired with a blazingly efficient wingman [crunches at higher % of his peak_flops].

Importantly the average claim on the quorum is scaled back to a reference application anyway, in our project case making it a gross underclaim because of no compensation for that being SIMD enabled.

Crunching slower at some point will lead to overall lower credit, but the loophole is you have enough memory these days to pile on tasks [to run slowly in parallel].

It's just a matter of time until we start adding scaling/throttle controls into the various apps for other reasons (mainly safety and usability control), but in the meantime you can pile on the instances and downclock the GPU after Boinc starts, then you'll consistently claim high. In an extreme case you would use as many instances of the lowest performing application as will fit. [Will always be working toward reduced memory, Ram and Vram, modes to support more devices]

A problem can come with that if you are paired with someone doing the same (intentionally or unintentionally), but I think even if everyone that reads this did it, still enough host-owners never visit the forums that this low effective claim pairing would remain rare.
15) Message boards : Number crunching : Average Credit Decreasing? (Message 1783198)
Posted 4 days ago by Profile jason_gee
I wonder how on earth anyone at Berkerley could say that there isn't an issue with the credit system and not want to understand why it is behaving in the manner that it is.

It is obvious that creditnew is not reflecting thru put so the real question I have is what is it supposed to show?


It's supposed to first dial in (adaptively converge) elapsed time estimates for sending the right amount of work to hosts, and then on client side hooks into the scheduling of tasks and projects.

Once validations occur, it then awards by the cobblestone scale for tasks, in theory RAC then directly indicative of successful throughput, yes (just a different scale). The elapsed times then go back into the first step to dial in estimates.

As an adaptive control system, it has some notable & classic engineering instabilities, that make each stage pretty fragile under anything but rare idealised (non existent) conditions. The rub is that it 'sortof works' as described, but not quite meeting the expectations of users. In that respect it's a proof-of-concept mechanism, rather than a complete system that should be in deployment. The reason for that is there are no health/quality-control indicators built in (other than user complaints) that would make refinement easier. Also semantically and structurally the code uses its own 'standards' that in some areas obscure what the elements actually are, making replacement of the pieces with 'better/more-standard' implementations harder than it should be.
16) Message boards : Number crunching : Lunatics Help (Message 1783097)
Posted 5 days ago by Profile jason_gee
Should I use Cuda50 on my GT610?

And do I need to run my cache down before switching?


Yours also seems to be Fermi Class (compute capability 2.1) therefore same suggestion, probably 4.2 or 5, and splitting hairs to tell the difference

Switchover rerunning the installer *should* be trouble free in that simple case, though if worried about it, running the cache down first costs nothing.
17) Message boards : Number crunching : Lunatics Help (Message 1783094)
Posted 5 days ago by Profile jason_gee
Are you folks saying I should use Cuda50 on my GT430?


4.2 or 5 will work well, I'd guess probably 4.2 for that GPU, but probably you'd be splitting hairs to prove that on this GPU.
18) Message boards : Number crunching : GPU Wars 2016: NVIDIA Pascal details (Message 1783092)
Posted 5 days ago by Profile jason_gee
Yeah Windows driver latencies are pretty atrocious compared to the Linux ones (In My experience), so the threshold of whether to run single or multiples definitely lies in a different place.
19) Message boards : Number crunching : Windows 10 - Yea or Nay? (Message 1782970)
Posted 5 days ago by Profile jason_gee
Yeah, M$ has gone way to the financial dark side without Gates and Allen, but latest earnings report and outlook appears to indicate a similar path for Apple without Jobs and the Great and Powerful Woz(meant with the utmost respect).


Yeah, Have to say, wacky as those guys were, they're choirboys compared to whoever devised this Sh@tstorm
20) Message boards : Number crunching : Windows 10 - Yea or Nay? (Message 1782954)
Posted 5 days ago by Profile jason_gee
Yeah, 'Old Bill' is so desperately in need of cash he needs to spam people by phone WAR Diallers, ROFL

The Phone companies are so outdated, vulnerable and corrupt, their own employees can voluntarily or by duress give databases to criminal gangs. Same with the banks. (not to mention pissed off sacked employees).

If you work at such a place, take a walk and look for a real job.

When this comes to a crunch, mark my words, it will once again be Narcissists preying on the weak to prop up their insane addictions.


Next 20

Copyright © 2016 University of California