David Anderson is well known for being very stubborn.

Obstinacy is a common description for I don't give a sh**.

You don't know David then, he's VERY VERY passionate about his 'baby' Boinc and will vehemently defend what he has done, yes that can cause people to think ill of him, I did for a long time, but he did what he did in the beginning with little help and we have Boinc with literally Millions of people who have used it to show for it. YES Boinc has been updated upteem thousand times since then BUT the absolute MAIN problem with Boinc is it's still 32 bit if they could get the funding to get back in and finish the 64bit version, no idea how far along it is, but that would make it alot better for most of us. After that the Server side needs updating, or before I don't know how that would work, so the Boinc Projects can FINALLY come into the 21st century!!

Maybe they're simply experiencing what you've said all along .. discovering that 30 year old easily broken, hard to manage code written in an era that was never designed to handle all the nuances of multi core cpu/gpu computations requiring a near full time IT manager, else going back to square 1 with an endless procession of new ill equipped admins inheriting code written before they were born trying band-aid solutions isn't exactly a recipe for continued smooth sailing.

No, it's time the whole Boinc setup should be nuked and started fresh, beginning with awarding credits that are consistent cross-project which as we know is a joke. Wow, I got 20,000 points in MilkyWay today (equal to 150 in WCG)! Obviously an exaggeration but you get the point. Doesn't stop the point whores from proudly extolling their production numbers in their signatures.

Word homie. Ya nailed it.

I dare you both to go onto the Github Boinc forum and request some changes. David Anderson is well known for being very stubborn.

If you can lay out your suggestion as it relates to the current version of Boinc and how to fix it, not the programming but some of the things are VERY interconnected making it a pain in the butt to change 'one little thing' then he might be more apt to listen to suggestions. But people who say 'why can't we have linear cpu core settings for projects within Boinc' have no idea of the programming that would take. ie on the Server side to change the credits we get from the 'Credit New' scheme they came up with to anything else involves changing the code in like 15 different places!! AND that needs to be done EVERY TIME a project upgrades the Server side version to a new one, that's one reason why some projects are running not very new versions on the Server side.

I looked in task manager and see that boincmgr.exe, boinc.exe and boinctray.exe are all marked as x64.
If boinc was 32bit it wouldn't work on macos catalina and later.

Maybe they're simply experiencing what you've said all along .. discovering that 30 year old easily broken, hard to manage code written in an era that was never designed to handle all the nuances of multi core cpu/gpu computations requiring a near full time IT manager, else going back to square 1 with an endless procession of new ill equipped admins inheriting code written before they were born trying band-aid solutions isn't exactly a recipe for continued smooth sailing.

No, it's time the whole Boinc setup should be nuked and started fresh, beginning with awarding credits that are consistent cross-project which as we know is a joke. Wow, I got 20,000 points in MilkyWay today (equal to 150 in WCG)! Obviously an exaggeration but you get the point. Doesn't stop the point whores from proudly extolling their production numbers in their signatures.

Word homie. Ya nailed it.

I dare you both to go onto the Github Boinc forum and request some changes. David Anderson is well known for being very stubborn.

Oh that would be funny. I could throw down my 8080 assembler bona fides running CP/M in 1978! Now that would clear the parking lot! And for those that are still left, I could hollar out "Hey! Where are you guys going?! I'll have you know I was the first one on my block to have 1K bytes of ram!"

How about my programming of an Olivetti Programma from 1966! A desk computer the size of half a desk which could only hold 132 instructions at a time and you had to feed in a new magnetic card for the next 132 instructions.

I looked in task manager and see that boincmgr.exe, boinc.exe and boinctray.exe are all marked as x64.
If boinc was 32bit it wouldn't work on macos catalina and later.

Actually you can tell there's still 32bit programming inside Boinc as the Server only sees a max of 4gb of memory on any gpu, yes SOME parts of Boinc are 64 bit but ALOT of the programming inside is still 32bit and the 64bit stuff was made to work with it.

I looked in task manager and see that boincmgr.exe, boinc.exe and boinctray.exe are all marked as x64.
If boinc was 32bit it wouldn't work on macos catalina and later.

Actually you can tell there's still 32bit programming inside Boinc as the Server only sees a max of 4gb of memory on any gpu, yes SOME parts of Boinc are 64 bit but ALOT of the programming inside is still 32bit and the 64bit stuff was made to work with it.

Then how are people making use of more than 4GB? It's required for GPUGrid for a start.

David Anderson is well known for being very stubborn.

Obstinacy is a common description for I don't give a sh**.

You don't know David then, he's VERY VERY passionate about his 'baby' Boinc and will vehemently defend what he has done, yes that can cause people to think ill of him, I did for a long time, but he did what he did in the beginning with little help and we have Boinc with literally Millions of people who have used it to show for it.

Indeed, but many others in there are fed up of him not releasing the new Boinc etc. Having said that, there was one thing I wanted changed where the programmer called Bladd something objected but David interrupted and said no Peter has a good idea so it got put in his queue he never gets round to. I think they only have one part time programmer and that's it. He spends so much time allocating himself things he never actually gets round to doing them.

Anyway I'm not currently in a good mood. I got a new card (different model to the others) and connected it to a machine with the other kind. Windows saw it, Boinc didn't (typical). I assumed this was because Windows hadn't put a compute enabled driver in, so I installed the latest driver for it. This corrupted the registry (what?!). So half my equipment ain't crunching for a bit.

I looked in task manager and see that boincmgr.exe, boinc.exe and boinctray.exe are all marked as x64.
If boinc was 32bit it wouldn't work on macos catalina and later.

Actually you can tell there's still 32bit programming inside Boinc as the Server only sees a max of 4gb of memory on any gpu, yes SOME parts of Boinc are 64 bit but ALOT of the programming inside is still 32bit and the 64bit stuff was made to work with it.

Then how are people making use of more than 4GB? It's required for GPUGrid for a start.

Because the kludge fix is to allow any number at4gb or above that to work, as i said it's just a 32bit number length problem not an actual gpu problem.

David Anderson is well known for being very stubborn.

Obstinacy is a common description for I don't give a sh**.

You don't know David then, he's VERY VERY passionate about his 'baby' Boinc and will vehemently defend what he has done, yes that can cause people to think ill of him, I did for a long time, but he did what he did in the beginning with little help and we have Boinc with literally Millions of people who have used it to show for it.

Indeed, but many others in there are fed up of him not releasing the new Boinc etc. Having said that, there was one thing I wanted changed where the programmer called Bladd something objected but David interrupted and said no Peter has a good idea so it got put in his queue he never gets round to. I think they only have one part time programmer and that's it. He spends so much time allocating himself things he never actually gets round to doing them.

Anyway I'm not currently in a good mood. I got a new card (different model to the others) and connected it to a machine with the other kind. Windows saw it, Boinc didn't (typical). I assumed this was because Windows hadn't put a compute enabled driver in, so I installed the latest driver for it. This corrupted the registry (what?!). So half my equipment ain't crunching for a bit.

I hope you can get back up really soon again!!

Then how are people making use of more than 4GB? It's required for GPUGrid for a start.

Because the kludge fix is to allow any number at4gb or above that to work, as i said it's just a 32bit number length problem not an actual gpu problem.

So what happens when a project's task needs 6GB to run? Can it just make two requests? Or once the thing's running, Boinc is nothing to do with it? I remember old photo editors had a big problem impossible to get round with a RAM limit for editing one photo. How come it's 4GB RAM and 2GB files?

I hope you can get back up really soon again!!

I have 4 (could be 5 if I change an NVME to an SSD) computers in the garage that I can plug GPUs into. I think the best way is if I keep like with like. I think 4 Tahitis on one machine, 1 Tahiti that doesn't like that machine on another machine, 1 Baffin on another machine, 1 6990 on another machine. A Fury and a Tahiti in the lounge for games etc.

Then how are people making use of more than 4GB? It's required for GPUGrid for a start.

Because the kludge fix is to allow any number at4gb or above that to work, as i said it's just a 32bit number length problem not an actual gpu problem.

So what happens when a project's task needs 6GB to run? Can it just make two requests? Or once the thing's running, Boinc is nothing to do with it? I remember old photo editors had a big problem impossible to get round with a RAM limit for editing one photo. How come it's 4GB RAM and 2GB files?

You are mixing applications and expecting the same results, photo shop editors are mostly 64bit programs, they left 32bit a long time ago, while Boinc can't detect anything above 4gb, so that's the cutoff for the projects using that as a thing to limit processing to a gpu. I'm assuming you mean the upload/download file and that size of the files is determined by each project and the amount of data they want back from each task. Universe for example has either 120k or 20k files that get uploaded after we finish a task.

I hope you can get back up really soon again!!

I have 4 (could be 5 if I change an NVME to an SSD) computers in the garage that I can plug GPUs into. I think the best way is if I keep like with like. I think 4 Tahitis on one machine, 1 Tahiti that doesn't like that machine on another machine, 1 Baffin on another machine, 1 6990 on another machine. A Fury and a Tahiti in the lounge for games etc.

I don't typically have multiple gpu's in one pc, it cuts back on the number of cpu cores I have crunching, a single gpu in each machine means more cpu cores and therefore more project choices to run Boinc.

'I'm not dicking with that crap code for days trying to make it work. I've already been down that road. I will not spend another minute of my time on BOINC.'

- 'Texstar', founder of PCLinuxOS in reply to a question as to why Boinc isn't found in the distro's repository

On my linux machine, I get similar results: all are 64-bit.
Red Hat Enterprise Linux release 8.6 (Ootpa)
This is a client machine, not a server.

[/usr/bin]$ file boinc*
boinc:        ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=4a444f877bad66d3e3c69815b610c2f44dec51c0, stripped
boinc_client: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=4a444f877bad66d3e3c69815b610c2f44dec51c0, stripped
boinccmd:     ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=004ad0d0739c3b4a05a6afd9e5f716f730d63226, stripped
boincmgr:     ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=30032e4e8cb1a106b666ce63ac8b11e722fccb82, stripped
boincscr:     ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=1b24af4798f6e15af7d5fd66681355a7005d82ad, stripped

[/usr/lib64]$ file ld-linux* ld-2.28*
ld-linux-x86-64.so.2: symbolic link to ld-2.28.so
ld-2.28.so:           ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=67aa0f1504abcfc4befb2b61a329a30a9984e0db, with debug_info, not stripped

[/usr/lib64]$ file *boinc*
libboinc_api.so.7:             symbolic link to libboinc_api.so.7.16.11
libboinc_api.so.7.16.11:       ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=b534348dcb43689c3eaacc94f317305a5be2a982, stripped
libboinc_graphics2.so.7:       symbolic link to libboinc_graphics2.so.7.16.11
libboinc_graphics2.so.7.16.11: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=900728d6af6e7c77e639e569d657326824973d4d, stripped
libboinc_opencl.so.7:          symbolic link to libboinc_opencl.so.7.16.11
libboinc_opencl.so.7.16.11:    ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=011ba4e89c630388ff1694e4cc56db3d55b53fe7, stripped

---

Then how are people making use of more than 4GB? It's required for GPUGrid for a start.

Because the kludge fix is to allow any number at4gb or above that to work, as i said it's just a 32bit number length problem not an actual gpu problem.

So what happens when a project's task needs 6GB to run? Can it just make two requests? Or once the thing's running, Boinc is nothing to do with it? I remember old photo editors had a big problem impossible to get round with a RAM limit for editing one photo. How come it's 4GB RAM and 2GB files?

You are mixing applications and expecting the same results, photo shop editors are mostly 64bit programs, they left 32bit a long time ago, while Boinc can't detect anything above 4gb, so that's the cutoff for the projects using that as a thing to limit processing to a gpu. I'm assuming you mean the upload/download file and that size of the files is determined by each project and the amount of data they want back from each task. Universe for example has either 120k or 20k files that get uploaded after we finish a task.

No I'm referring to older Photoshop programs that couldn't handle over 2GB files. Not sure why it's 2GB a lot and not 4GB.

Anyway people are I think making use of more than 4GB in GPUs for one task, in GPUgrid?

I hope you can get back up really soon again!!

I have 4 (could be 5 if I change an NVME to an SSD) computers in the garage that I can plug GPUs into. I think the best way is if I keep like with like. I think 4 Tahitis on one machine, 1 Tahiti that doesn't like that machine on another machine, 1 Baffin on another machine, 1 6990 on another machine. A Fury and a Tahiti in the lounge for games etc.

I don't typically have multiple gpu's in one pc, it cuts back on the number of cpu cores I have crunching, a single gpu in each machine means more cpu cores and therefore more project choices to run Boinc.

No it doesn't. If I stick 6 GPUs in one PC leaving the other 5 without one, or stick one GPU in each, I end up using the same number of CPU cores. and it's easier to have them all together as they use the same queue.

'I'm not dicking with that crap code for days trying to make it work. I've already been down that road. I will not spend another minute of my time on BOINC.'

- 'Texstar', founder of PCLinuxOS in reply to a question as to why Boinc isn't found in the distro's repository

ROTFPMSL!

On my linux machine, I get similar results: all are 64-bit.
Red Hat Enterprise Linux release 8.6 (Ootpa)
This is a client machine, not a server.

[/usr/bin]$ file boinc*
boinc:        ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=4a444f877bad66d3e3c69815b610c2f44dec51c0, stripped
boinc_client: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=4a444f877bad66d3e3c69815b610c2f44dec51c0, stripped
boinccmd:     ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=004ad0d0739c3b4a05a6afd9e5f716f730d63226, stripped
boincmgr:     ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=30032e4e8cb1a106b666ce63ac8b11e722fccb82, stripped
boincscr:     ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=1b24af4798f6e15af7d5fd66681355a7005d82ad, stripped

[/usr/lib64]$ file ld-linux* ld-2.28*
ld-linux-x86-64.so.2: symbolic link to ld-2.28.so
ld-2.28.so:           ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=67aa0f1504abcfc4befb2b61a329a30a9984e0db, with debug_info, not stripped

[/usr/lib64]$ file *boinc*
libboinc_api.so.7:             symbolic link to libboinc_api.so.7.16.11
libboinc_api.so.7.16.11:       ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=b534348dcb43689c3eaacc94f317305a5be2a982, stripped
libboinc_graphics2.so.7:       symbolic link to libboinc_graphics2.so.7.16.11
libboinc_graphics2.so.7.16.11: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=900728d6af6e7c77e639e569d657326824973d4d, stripped
libboinc_opencl.so.7:          symbolic link to libboinc_opencl.so.7.16.11
libboinc_opencl.so.7.16.11:    ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=011ba4e89c630388ff1694e4cc56db3d55b53fe7, stripped

Everybody has already acknowledged that parts of Boinc are in fact 64bit but parts of it are not as well.