Posts by JStateson

1) Message boards : GPUs : Card without extra power input (Message 93687)
Posted 1 day ago by Profile JStateson
Post:
An R9 270 pulls 180 watts at full load using a pair of 6 pin PCIe If the manufacturer followed specs then the draw through the slot is max of 75 so the pair of connectors maybe 50 each

AMD card are known for higher floating point precison feature and that can use power that might otherwise be available for gaming. NVidia skipped the FP64 performance in their gaming cards.


You might consider the following
RTX 2060 has only single 8 pin connector and max of 160 watts

GTX 1660 Ti has same 8 pin but draws only 120 watts
With 75 from motherboard only 45 need to be supplied by SATA power which should not be a problem. this assume you do not want to use any of the PCIe cables.

I don't recommend anything lower than the 1660ti as it is not much different from the R9 in performance although may be newer.

You mentioned the gtx 5010. the 5010m is a laptop chip I assume you meant 1050. If you are looking to ADD an additional board instead of replacing your R9 you might consider one of the inexpensive mining board like the ZOTAC P106-90 3G (75 watts total) that lack video support. Not clear what you want to do.

all stats came from TechPowerUp
2) Message boards : BOINC client : Misconfiguration or identification of required client sources in ".gitignore" (Message 93650)
Posted 2 days ago by Profile JStateson
Post:
Solved - sort of.

Should have started with the Linux one first, pushed it to the upstream then cloned the windows version.

However, if you start with the windows version then decide you want to clone the Linux you will need to remove or comment out the following files from .gitignore or you will be unable to build for Linux.
#pkginfo
#prototype
#client/scripts/boinc-client
#client/scripts/boinc-client.service

#py/Boinc/version.py
#py/setup.py


Probably just needs a warning in the build wiki to clone the windows from the Linux.
3) Message boards : Questions and problems : GPU dummy plug still needed? (Message 93642)
Posted 2 days ago by Profile JStateson
Post:
should be ok as long as you don't let it go to sleep or close the lid

At one time there was a program that kept laptops running even with the lid closed.


If you do buy an HDMI dummy plug be aware that some ebay'ers show 3 plugs in the adv but the fine print says you are getting only one.
4) Message boards : BOINC client : Misconfiguration or identification of required client sources in ".gitignore" (Message 93640)
Posted 2 days ago by Profile JStateson
Post:
Ran into a problem building both windows and Linux version of the boinc-master
Not going to submit this as an "issue" as maybe I didn't order the builds correctly. Maybe someone can decide if there is a problem or not
If so I will submit it as an issue unless it is already known

Background: Wanted to have single copy of Boinc source at my upstream and create working windows and Linux versions of same source.

Created private upstream "boinc-master" empty
Created local git repository on my windows system and downloaded the full "zip" from the boinc repository (thanks!)
Initialized and pushed the local repository to my upstream
On my Linux system I did a git clone of my upstream and attempted a build which failed

The Linux build failed because (among other missing items) the file "client\scripts\boinc_client.im was missing
I looked in .gitignore and sure enough that file was excluded with the comment "build by configure"
that means when I did my upstream "push" that file was not pushed and as a result did not show up in the clone.

I don't believe that file is created by "configure" and assume the comment in .gitignore is incorrect.

The order of building the client on Linux is to run the scripts
./_automake
./configure --disable-server --disable-manager


that "automake" script fails and reports (among other stuff)
configure.ac:1289: error: required file 'client/scripts/boinc-client.in' not found
configure.ac:1289: error: required file 'client/scripts/boinc-client.service.in' not found


Since "configure" is done after _automake then it is not possible for those files to be created by "configure" (unless there is a neat trick)

I believe those two files (there are others) need to be removed from .gitignore or a change to "_automake" to create them.

I suspect that the developers work from a single copy of the sources when finalizing both Linux and windows versions. I am trying to do the same thing and it is strange that a "windows push" excludes required Linux files.
5) Message boards : Projects : Some projects will not get tasks (Message 93633)
Posted 3 days ago by Profile JStateson
Post:

(not sure if the above will show or not as it does not in the preview).


Some sites require https and other require http
for images and urls

Not sure why but if the preview does not work with https then try http and vice-versa
6) Message boards : Questions and problems : Some projects get compensated by google? (Message 93627)
Posted 3 days ago by Profile JStateson
Post:
Out of 26 projects my main system is watching, 6 of them have what I assume is google tracking code.

I discovered this by using find /i "google-analytics" mas*.xml in the boinc data folder

The 6 projects are:

Cas
Nfs
Universe
Cosmology
Gpugrid
Milkyway

for example:

---------- MASTER_WWW.GPUGRID.NET.XML
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');

I assume they signed up for this and get some compensation


FWIW, According to https://www.similarweb.com/website/boinc.berkeley.edu SETI is the biggest traffic referral to Boinc at Berkeley,. My guess is they are looking for ET both at SETI and at Berkeley. They will definitely find some at Berkeley.

Maybe this tracking code was added by my computer and not the project?
7) Message boards : BOINC client : problem building linux client: binary code is 20x bigger than before (Message 93622)
Posted 4 days ago by Profile JStateson
Post:
Made some progress tracking down why debug was enabled

the " -g " is controlled by

ac_cv_prog_cc_g

if = yes then debug is on
if = no then off

that variable iis in the script "configure" which is created by _autosetup

In one folder "boinc" if I run autosetup I get that flag set to "yes" and get debug stuff "-g -O2"

in another folder "boinc-master" if I run autosetup I get that flag set to 'no" and all I get is -O3

using diff there is no difference between the two _autosetup
nor the two Makefile.in
nor the two Makefile.am
nor the two Makefile.incl
there is a difference between the final "Makefile" as the -g O2 is in one and the -O3 is in the other but that is expected due to that flag being set to "yes"

One folder came from going to GitHub and a download of a zip
the other folder came from
git clone https://github.com/BOINC/boinc boinc

Maybe that is how the difference came about, maybe not.
Not going to pursue this any further. as that strip command you suggested works fine
Going to "smashin crab" for late lunch as I have given up on smashing this bug.
8) Message boards : Questions and problems : Reporting timer? (Message 93613)
Posted 4 days ago by Profile JStateson
Post:
Great detective work. Interesting workaround. Wish the MW administrators would look at your code examples and see where they have the server software misconfigured. I think you have asked for the server configuration files from the project to examine. Richard could probably work out what they have done wrong.


Thanks Keith!

Going to restate my conclusion as it is too late to edit the previous post and it might be misleading.

The client properly recognizes and uses the 91 second RPC delay. No problem there. All requests to the project have a 91 second delay whether results are attached or not.

What I found was that the project requires at least one request to HAVE NO RESULTS ATTACHED . That time delay of 256 seconds before I allow results to be attached will cause at least one request (all these requests are for data) to be sent WITH NO RESULTS ATTACHED So, if I had actually used 91 seconds for my delay (instead of 256) the project would exhibit the same behavior and nothing would have been downloaded.
9) Message boards : BOINC client : problem building linux client: binary code is 20x bigger than before (Message 93610)
Posted 4 days ago by Profile JStateson
Post:

./configure CXX='g++ -no-pie' --disable-server --disable-manager


Best would be to use compiler flags to not use the debug symbols in the first place but you can strip the symbols out afterwards with the strip command.


the above flags had no effect on size
jstateson@jysdualxeon:~/boinc/client$ ls -l boinc
-rwxr-xr-x 2 root root 20073976 Nov  9 20:41 boinc



strip --strip-debug boinc



this worked!
jstateson@jysdualxeon:~/boinc/client$ sudo strip --strip-debug boinc
jstateson@jysdualxeon:~/boinc/client$ ls -l boinc
-rwxr-xr-x 2 root root 1187568 Nov  9 20:44 boinc
jstateson@jysdualxeon:~/boinc/client$


the grep I did only got a hits at
config.status:old_striplib='strip --strip-debug'
configure:  test -z "$old_striplib" && old_striplib="$STRIP --strip-debug"
libtool:old_striplib="strip --strip-debug"

and all 3 of those "hits" showed up in the old dev system and the new one. Also I don't know the significance of those "hits" FWIW.
10) Message boards : Questions and problems : Reporting timer? (Message 93607)
Posted 4 days ago by Profile JStateson
Post:

Milkyway has
<request_delay>91.000000</request_delay>
I'm more interested in

<min_sendwork_interval> N </min_sendwork_interval>
Minimum number of seconds between sending jobs to a given host. You can use this to limit the impact of faulty hosts.
I'm not yet certain that this is the one which emerges as <request_delay>, but I think it's a more plausible candidate.
Edit - candidacy confirmed (I think) by https://github.com/BOINC/boinc/blob/master/sched/sched_types.cpp#L784


I have been looking at this and found a code change to the client to correct for the deficiency, or more likely, improper setup at the Milkyway project. I am not proposing to change the client, rather want to know what is wrong at the project end that allows my change to cause the work flow to work properly.

The problem as stated (many times): A block of MW work units arrive with the scheduler reply which has that 91 second delay requirement. A number of work units are processed, usually takes a minute each, and, a minimum of 91 seconds later results can be returned. Unlike other projects I am familiar with, Milkyway does not download any new work when results are uploaded. No work is download until the last of the work units are uploaded and only after a 10 minute delay.

I looked in cs_scheduler.cpp at
// Write a scheduler request to a disk file,
// to be sent to a scheduling server
//
int CLIENT_STATE::make_scheduler_request(PROJECT* p) {


and noticed that results, if any, are attached to the scheduler request a the location
p->nresults_returned = 0;
		for (i = 0; i<results.size(); i++) {
			rp = results[i];
			if (rp->project == p && rp->ready_to_report) {
				p->nresults_returned++;
				rp->write(mf, true);
			}


On a hunch, I allowed the results to be attached only if 91 seconds had elapsed since the last actual upload of results. However, the 91 second value was not available as that variable was in scheduler_reply, not scheduler_request so I used a local constant that could be obtained from the cc_config file for testing purposes.

I made a linux version in addtion to win32 and win64 and put the source code here along with printouts of work flow.

Looking at those event messages (work flow) from the three different systems running milkyway, you can see that new data is downloaded concurrently with uploads as is the normal behavior of on other projects.

To restate my solution: The project only "honors" a request for work if no existing results are attached to the scheduler request for at least 91 seconds.
Perhaps this can be a clue to find the real problem.
11) Message boards : BOINC client : problem building linux client: binary code is 20x bigger than before (Message 93601)
Posted 5 days ago by Profile JStateson
Post:
It is big because it has debug stuff. I grep for "--strip-debug" but it was there so I am at a loss to why all the debug stuff was in the executable. my older project from 2 months ago was obtained the same way and has no debug stuff

stateson@jysdualxeon:~/boinc/client$ file boinc
boinc: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=753642cbdfe8381bf86e41d736eece30774dd318, with debug_info, not stripped


so how do I strip the debug from it?
12) Message boards : BOINC client : problem building linux client: binary code is 20x bigger than before (Message 93599)
Posted 5 days ago by Profile JStateson
Post:
I am not an expert on gcc compilers

I have two previous build of the linux boinc client and both builds were small:
jstateson@jyslinux1:~/Downloads/boinc-master/client$ ls -l boinc
-rwxrwxr-x 2 jstateson jstateson 1517832 Nov  1 01:22 boinc
jstateson@jyslinux1:~/Downloads/boinc-master/client$


I decided to use a better system and did a new install of git and the client
I followed the same procedure as here except that package gm4 was not found.

Used https://boinc.berkeley.edu/trac/wiki/SourceCodeGit to get the master.

unaccountably, the final executable was 20x bigger. I assume it is full of debugging stuff? Why is it that big? I want it reduced down to the smaller size but do not know enough about gcc or the make files to do that
jstateson@jysdualxeon:~/boinc$ cd client
jstateson@jysdualxeon:~/boinc/client$ ls -l boinc
-rwxr-xr-x 2 root root 20075752 Nov  9 08:00 boinc


The program runs ok but is way to big. Must have the proverbial kitchen sink in it.

[edit] using the old makefiles did not help. I copied the 4 "Makefile" from the other Linux system and "touched" version.h but still ended up with a huge executable
13) Message boards : Questions and problems : API for downloading and uploading, and offline (Message 93578)
Posted 7 days ago by Profile JStateson
Post:
The closest thing to an actual "API" are the commands you can send to the app (the client) using boniccmd.exe. If you want to roll your own code to interact with the client then the add on tools here might be useful and especially the c# code at GitHub here. I was told it can run under Linux but AFAICT there is no native C# compiler for Linux.
14) Message boards : Questions and problems : Reporting timer? (Message 93573)
Posted 7 days ago by Profile JStateson
Post:

What do you mean by "most discussion boards"? If you mean outside of BOINC, then I disagree. Most forums I've used, if you change your mind or make a mistake, you can delete it. I see no advantage of forcing people to leave it there.


There are no advertisements in any of the boinc or project websites and they are not selling any products. I am happy with that. Ford, Toyota communities are funded using advertisements AFAICT
Apple, Microsoft and big players have plenty of money for bells and whistles.

Not sure how stackoverflow gets funded. They have over 80 affiliated sites and have a lot of bells and whistles.

However, if the "right to be forgotten" gets extended to "the right to be erased" then you might get your wish to be able to delete your posts
15) Message boards : Questions and problems : Reporting timer? (Message 93562)
Posted 8 days ago by Profile JStateson
Post:
Well, this would be the place to look: https://boinc.berkeley.edu/trac/wiki/ProjectOptions

But I must say I've never heard anyone discussing the need for a project setting like that, nor remember seeing one when I've been looking through for something else.


There has been an ongoing problem at milkyway with 10-15 minute delays before getting data. A lot of discussion but one of the key points was the moderator, Tom, who posted that they knew about the problem and it was "some obscure boinc setting somethere"
https://milkyway.cs.rpi.edu/milkyway/forum_user_posts.php?userid=1351529

It looks like you just found those "obscure boinc settings"

the following looks interesting

<min_sendwork_interval> N </min_sendwork_interval>
Minimum number of seconds between sending jobs to a given host. You can use this to limit the impact of faulty hosts. 


I think the problem is that this value, probably about 160 seconds ??? is OK but the project starts counting from the last time the user uploaded results. They need to start counting from the time they last downloaded. That is just a guess. I did not see anything else in that scheduler configuration that would cause the count to start at the last upload. If they start the count from the last time the user asked for data then that is OK but only if data was actually sent to the user. None is and I think that is the problem.

Are these files available to examine? I assume they are on the server and hidden.

[EDIT]
Was looking at
<next_rpc_delay>x</next_rpc_delay>
In each scheduler reply, tell the clients to do another scheduler RPC after at most X seconds, regardless of whether they need work. This is useful, e.g., to ensure that in-progress jobs can be canceled in a bounded amount of time. 


I wonder if setting that value to be greater than the "min_sendwork_interval" would fix the problem? That should cause the client to wait minimum of 160 seconds (or whatever) before uploading results and attaching the "piggyback" work fetch request.

I asked Tom to send me a copy of the file.
16) Message boards : Questions and problems : Ryzen 2600 not 100% utilized, not thermal throttling (Message 93516)
Posted 10 days ago by Profile JStateson
Post:
Tools used to perform calculations on GPUs (OpenCL, CUDA) have a limitation of 4gb address space At startup, the boinc message box can show (NVidia) how much video memory is available and it is never more than 4 no matter how much ram is on the board. If you are running gpugrid and have 63c temp that is excellent.

I added an additional 1070 to my existing pair on my area51 system and had to retrofit a liquid cooling system (eVga hybrid) as it got to hot. my hottest board is 80c and that is close to thermal limit (83c) The other boards (not shown) are 73c and 55c with the 55 the water cooled eVga. The fan noise is pretty bad during the summer. Memory used on grfidcoin ranges from 700mb to 900mb with controller load 42. The GPU load moves a lot during computations and can swing from 90 down to 40 and then back up quickly.

17) Message boards : GPUs : Two projects on one GPU? (Message 93507)
Posted 10 days ago by Profile JStateson
Post:

A long time ago (I think on a Radeon HD 290) I used to run more than one (about 3) Milkyway tasks at once (just using the one client). I got a reasonable speed increase. But now I don't, the GPU is already running at about 95% anyway with just one task. Either Milkyway has changed, or this card is different.



not sure when but a few years ago milkyway started doubling up the number of work units each job has. looking in a result file one finds
<number_WUs> 4 </number_WUs>
so currently each job is 4 simple work units
18) Message boards : Questions and problems : Any recommendation on avoiding linux upgrades that break drivers (Message 93319)
Posted 19 days ago by Profile JStateson
Post:
This does not happen very often but when it does it can be a PITA to recover from.

Just rebooted an 18.04 system and had to reinstall NVidia drivers. Unlike the AMD ones the NVidia frequently survive an upgrade.

From googling the difference between update and upgrade it seems I need to avoid the upgrade. I think I know what happened: I put in an ftp server and did an update followed by an upgrade. I assume the problem was the upgrade. I can't find where I got the walkthrough for the ftp server but I suspect they did it and I just copied what they did and pasted it. The problem with searching for help on Linux is there are numerous OS changes and a walkthrough for xxx.23 does not work the same as when you are running a different version or kernel.

I also get notices occasionally of "updates waiting". I assume those are needed. Have also noticed the list of updates seem to grow quickly if I don't apply them.

I assume that if I stop doing "upgrade" I will not have to reinstall any NVidia or ATI drivers in the future. Is that correct?
19) Message boards : Server programs : bug in server: report to project or to boinc? (Message 93314)
Posted 19 days ago by Profile JStateson
Post:
I have been trying to debug why no work is downloaded from milkyway when completed results are uploaded.

AFAICT other projects download a few (or a bunch!) on every upload. Not milkyway, and that was the topic of that thread I listed.

From trial and error, I, and others, have observed that MW does not respond to an update unless about 160 seconds have elapsed since the last request for data and that request must be after all the data is uploaded (or lost)

Users consider this a bug in the server and that it is compounded by boinc waiting for about 15-20 minutes to elapse before asking a second time.

My guess was that Milkyway was considering the upload of "completed results" to be the start time of the "last request".

I got to looking the windows code since I can finally build the client in VS2013.
Looked at: schedule_op, cs_schedule and work_fetch

I noticed that the field "req_secs" was used by the client to report "not asking for tasks" That field was defined as number of seconds of data that the device wants.

Tried the following: Made a mod the client so that "req_secs" was always 0 when sent to the project. Added another client mod to the "piggyback" routine so that when I clicked on "update" the field req_secs was set to a big number of seconds. The idea being that every time data was uploaded to Milkyway there would be no "want more data" but when I manually did an update it would ask for data (req_secs > 0).

Anyway, it didn't work, nothing got downloaded. A previous mod I tried was also unsuccessful: I allowed 3 minutes of data to accumulated before allowing an upload. Again, nothing got downloaded.

I have decided there are other challenges more interesting. I do have my own solution to the MW problem: I set a rule in BoincTasks that waits 160 seconds after the last Milkyway tasks is completed and then issues an RPC update. Since BT itself only checks every couple of minutes there is a worst case of 5-6 minutes of idle time before additional stuff gets downloaded and executed as shown in picture below. Other users simply use a dos script on the local system and loop boinccmd.exe to issue an update every 160 seconds. While this works, I do have 6 GPUs that are idle for 7 minutes and that represents just over 42 work units. I used to let Einstein run with "0" resource but recently some of their task take an unusual amount of time to finish. My idle time of 6 minutes is livable. The 15 to 20 minute wait was unacceptable.

20) Message boards : Server programs : bug in server: report to project or to boinc? (Message 93312)
Posted 20 days ago by Profile JStateson
Post:
The server code is contained in the exact same BOINC/boinc repository at GitHub - you can also choose server_release/1/1.0 and server_release/1/1.2 branches if you want confirmed, stable, code.


Thanks, that helped me realize my problem. I did not know what to look for. After reading this guide I realized I had already downloaded the server code.

What got me confused in the first place was when I was tracking down a possible bug in the milkyway project. I wanted to start with the message last request too soon and see where the problem came from. I could not find that phrase when using VS2013 "find in entire solution". I found that phrase on my ubuntu system. There is probably a way to do it under windows 10 but not with win10 "find" as it is not recursive AFAICT.
jstateson@jyslinux1:~/Downloads/boinc-master/sched$ grep -r "last request too recent" .
./handle_request.cpp:                        "Not sending work - last request too recent: %f\n", diff
./handle_request.cpp:                        "Not sending work - last request too recent: %d sec", (int)diff


I do not know how to get that source code into VS2013. I did the following search find -i "handle_request" *.vcxproj and could find any reference to any (c++) project. Since it ends in cpp I would have thought I could bring up VS2013 and look through the code. I am pretty sure I know what is going on and could help the project out. The last info I read about the project looking at this was here and no answer has been given since.

I did not want to post what I think is wrong unless I can read through the server code and would like to use VS2003 for its GUI features.
I just did a "find /I "win32" in the "sched" folder and it appears that code is all Linux so I cant use vs2013 for debugging
I have a suspicion that it is not a bug but a way to reduce load on the database but that is a guess. If a real bug I think I know what has happened.


Next 20

Copyright © 2019 University of California. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.