Version of BOINC 5.2.6 has no reaction on flag -return_results_immediately. Sometimes it works, sometimes not. Some computers needs to manual update for all results, some of them sends about 30% of results...

Is there anyone with the same problem?

---

Yes i have the same problem but it does not bother me much.

---

Scorpions - Wind Of Change

See thread Uploading results vs returning result .

---

Version of BOINC 5.2.6 has no reaction on flag -return_results_immediately. Sometimes it works, sometimes not. Some computers needs to manual update for all results, some of them sends about 30% of results...

Is there anyone with the same problem?

Have you tried just leaving it alone?

If your profile says "connect every 3 days" then your work will get reported every three days.

---

I (perhaps like the original posters) am curious why
the current version of boinc still accepts that switch
at startup, but then seems to ignore it. Indeed, if you
run the program with a truly bad switch, you get help
output that purports this switch to still be implemented:

C:\\Program Files\\BOINC>boinc -foofoo
Unknown option: -foofoo
Usage: boinc [options]
-help show options
-version show version info
-exit_when_idle Get/process/report work, then exit
-show_projects show attached projects
-return_results_immediately contact server when have results
-detach_project <URL> detach from a project
-reset_project <URL> reset (clear) a project
-attach_project <URL> <key> attach to a project
-update_prefs <URL> contact a project to update preferences
-run_cpu_benchmarks run the CPU benchmarks
-check_all_logins for idle detection, check remote logins
too -allow_remote_gui_rpc allow remote GUI RPC connections
-redirectio redirect stdout and stderr to log files
-dir <path> use given dir as BOINC home
-no_gui_rpc don't allow GUI RPC, don't make socket

Anyone with developer level insight who can say why the switch option
isn't just removed from the code and/or help?

Just wondering.

Dave

Have you tried just leaving it alone?

If your profile says "connect every 3 days" then your work will get reported every three days.

I don't mean to be rude, but you're completely incorrect...

When I leave and go to work, which means nobody is pressing the UPDATE button,
work gets reported after certain criteria are met. I haven't tried to figure
out all of the criteria, but I can tell you it updates sometimes between
work units (upload one, wait a bit, report it while the next unit is still
going, upload the next one, wait a bit, report it while the next unit is
still going, etc...) but then sometimes it will do something like
"upload, crunch, upload, crunch, upload, crunch, report, download, upload,
crunch, upload, report, download, etc..." (notice the lack of a true pattern?)

---

When your work cache falles below your cache setting, be it .2 days or 5 days, when it falles below that setting then Boinc will report any completed work units and download more work until the work cache is above the setting you have. It can take 10 to 14 days for Boinc to settle down and maintain your cache setting properly. My advice is leave it alone and it WILL work.

---

Boinc....Boinc....Boinc....Boinc....

I just checked out the source code and this option is indeed being parsed, but nowhere processed. It is inconvenient especially in case of a server, client or a connection dropout - if the result is not reported immediately after uploading, there is a good chance you lose it completely because the deadline comes before you can report it. In fact I do not understand why these two actions were separated at all. I do not see any good reason for not reporting the result immediately after uploading it. Well, maybe it is because of other projects like CPDN, where intermediate results are being uploaded before completing the entire unit.

Since the problem interests me too, I am looking at the source code and trying to figure out if I can add the reporting just after the uploading without messing it up. If I manage, I'll upload the modified version to my server and let you know.

---

trux
BOINC software
Freediving Team
Czech Republic

Version of BOINC 5.2.6 has no reaction on flag -return_results_immediately. Sometimes it works, sometimes not. Some computers needs to manual update for all results, some of them sends about 30% of results...

Is there anyone with the same problem?

Please see this thread in Einstein fora, it explains it all. It seems that something that existed up until 4.45 went away silently (it is parsed, but has no effect), and apparently there ARE some people out there who are using this flag, so I think the BOINC community needs to hear an official statement as to whether this flag is here to stay, i.e., it was omitted temporarily, or going to be obsolete.


Ertugrul.

Have you tried just leaving it alone?

If your profile says "connect every 3 days" then your work will get reported every three days.

I don't mean to be rude, but you're completely incorrect...

When I leave and go to work, which means nobody is pressing the UPDATE button,
work gets reported after certain criteria are met. I haven't tried to figure
out all of the criteria, but I can tell you it updates sometimes between
work units (upload one, wait a bit, report it while the next unit is still
going, upload the next one, wait a bit, report it while the next unit is
still going, etc...) but then sometimes it will do something like
"upload, crunch, upload, crunch, upload, crunch, report, download, upload,
crunch, upload, report, download, etc..." (notice the lack of a true pattern?)

Not to be rude, but the basic concept here is for BOINC to connect to the scheduler according to the "connect every 'x' days" setting.

As your post suggests, there are exceptions. BOINC will go off the normal schedule (connect early) if it runs short on work. It will connect early if a deadline is approaching.

It gets a little more complex if you crunch more than one project because BOINC will process one project in preference to another based on short and long term debts.

But, if you run one project and set "connect every 'x' days" to something like three, it will rarely see an exception, and it will connect every three days.

That applies only to reporting (to the scheduler).

Downloads will usually happen right after a connection to the scheduler (right after work is assigned). Uploads will tend to happen right after the WU is completed. This can vary a little during an outage, or network congestion, or when Cogent and another backbone go to war.

Please note that my statement about "every three days" used the word reported and not the word "upload" or the word "download."

---

Version of BOINC 5.2.6 has no reaction on flag -return_results_immediately. Sometimes it works, sometimes not. Some computers needs to manual update for all results, some of them sends about 30% of results...

Is there anyone with the same problem?

Please see this thread in Einstein fora, it explains it all. It seems that something that existed up until 4.45 went away silently (it is parsed, but has no effect), and apparently there ARE some people out there who are using this flag, so I think the BOINC community needs to hear an official statement as to whether this flag is here to stay, i.e., it was omitted temporarily, or going to be obsolete.


Ertugrul.

This is probably a good clue. I've seen the same statement in other posts, but tracking those down is left as an exercise to the reader.

The definitive answer is probably in the change logs, but I don't have the link handy.

---

Please note that my statement about "every three days" used the word reported and not the word "upload" or the word "download."

I see this is going to go around in circles...
Keep popping those "blue pills"...




Brian...who still thinks that there's a problem, but doesn't feel like trying
to convince someone who's mind is already made up...

---

Version of BOINC 5.2.6 has no reaction on flag -return_results_immediately. Sometimes it works, sometimes not. Some computers needs to manual update for all results, some of them sends about 30% of results...

Is there anyone with the same problem?

Please see this thread in Einstein fora, it explains it all. It seems that something that existed up until 4.45 went away silently (it is parsed, but has no effect), and apparently there ARE some people out there who are using this flag, so I think the BOINC community needs to hear an official statement as to whether this flag is here to stay, i.e., it was omitted temporarily, or going to be obsolete.


Ertugrul.

This flag was created for debugging, it was never intended for general use. If I remember correctly it was depreciated in late version 2.xx or early version 3.xx, certainly before public release. It just took a little while for it to actually get deleted.

---

BOINC WIKI

BOINCing since 2002/12/8

This flag was created for debugging, it was never intended for general use. If I remember correctly it was depreciated in late version 2.xx or early version 3.xx, certainly before public release. It just took a little while for it to actually get deleted.

Fine.

I'm using it all the time, for the same reasons posted by others.
I want to see what's currently going on in my boinc status page, and have
a 2 day cache at the same time.

You might call that "debugging" if you like. :o)


So I vote for putting the flag back in.

Regards Hans

---

But, if you run one project and set "connect every 'x' days" to something like three, it will rarely see an exception, and it will connect every three days.

The preference "connect every N days" is really a mis-naming, since it's not how often you're connecting, but how large cache you wants. Since there is only one cache-setting, it's also interpreted as how often you're connecting for the purpose of desiding if needs to switch to deadline-mode...


For someone running only one project and cache-setting 3 days, he'll crunch result-1, upload it, start crunching result-2, and somewhere while crunching result-2 asks for more work. Asking for more work also reports any uploaded results...


If you're not seeing this behaviour, is you by any chance still running v4.19? If so, please remember v4.19 and earlier clients asked for 2N the cache-setting, while later clients only asks for N.

In multi-project the behaviour is more random...

I do not always upload during #2, I have had 6-8 ready to reports sitting until it connected for new downloads.

I don't mind the current system that 5.2.x uses. I don't need to see it reported immediately. Once everything gets settled after about a week of normal crunching, your credits grow just as normal as ever. The program does not need to be micromanaged. It's meant as a set it, forget it type of program. I love to watch it, myself (been on BOINC for over a year). I just don't worry about the program, and let it work on it's own. It will do what it needs to, when it needs to.

I believe people are too much in a hurry in the world. What happened to the laid back days before e-mail, the web, etc.? You had to send a letter, wait for response. We just need to relax more. I like the credits that show me I am doing my work, but I know they will eventually come.

If you want to watch that your machines are doing their job, get BoincView or some other 3rd party software, where you can see that all your computers are happily crunching at a quick glance.

---

My movie https://vimeo.com/manage/videos/502242

Please note that my statement about "every three days" used the word reported and not the word "upload" or the word "download."

I see this is going to go around in circles...
Keep popping those "blue pills"...

Brian...who still thinks that there's a problem, but doesn't feel like trying
to convince someone who's mind is already made up...

If you don't want an argument, avoid the flame bait.

Phrases like "not to be rude, but you're completely wrong" or "keep taking those pills" do not belong in a technical discussion.

---

This flag was created for debugging, it was never intended for general use. If I remember correctly it was depreciated in late version 2.xx or early version 3.xx, certainly before public release. It just took a little while for it to actually get deleted.

Fine.

I'm using it all the time, for the same reasons posted by others.
I want to see what's currently going on in my boinc status page, and have
a 2 day cache at the same time.

You might call that "debugging" if you like. :o)


So I vote for putting the flag back in.

Regards Hans

Actually, I'd vote for a seperate cache-size setting. Allowing someone to set the cache to five days, and the scheduler interval to 1 gives some of the functionality without the excess load.

I'm not criticizing anyone, especially Hans Dorn -- his machines are just a good example.

A really fast cruncher (I didn't look at all of yours, Hans, but you've got at least one of these) does a work unit under an hour. You have 18 machines.

If we assume Hans' average one per hour, then that's roughly 430 scheduler ops per day, from just one user.

If instead each machine connects twice/day, that's 36 -- less than 10% of the load on the schedulers.

That means ten times more hosts without forcing SETI to buy a faster scheduler.

There are currently 512,304 hosts crunching SETI. If we assume 3 hours per WU on average, and all report immediately, that's 4 million hits on the scheduler per day -- 8 times what'd be if they all had "connect every 'x' days" at 1.

I know we see the constant argument here that "I own my computer, I should be able to control it absolutely!" but I think we have to remember that the work, and the infrastructure to feed us work belongs to SETI, and it really is good for all of us to let them optimize the communication between the BOINC client and BOINC servers.

---

Phrases like "not to be rude, but you're completely wrong" or "keep taking those pills" do not belong in a technical discussion.

How about like this:

you're completely wrong, not to be rude, keep taking those pills

HEHEHEHEHEHE

OK, I'll got back to the corner now....Maw

I do not always upload during #2, I have had 6-8 ready to reports sitting until it connected for new downloads.

In majority of instances you'll report one or two at once, but for various reasons you can also report more.


Example, you've just crunched through a bunch of VHAR taking 1h30m, and this means "To completion" has dropped to 1h30m. With a 5-day cache-setting this means 80 results cached.
If you suddenly gets a "normal" angle-range-result taking 2h, "To completion" also jumps to 2h, meaning you've now suddenly got 79 results cached, with expected cpu-time 6 days 14h.
6 days 14h > 5 days, so you can crunch 19 results before you again needs more work.