Index  | Recent Threads  | Unanswered Threads  | Who's Active  | Guidelines  | Search
 

Quick Go »
No member browsing this thread
Thread Status: Active
Total posts in this thread: 25
Posts: 25   Pages: 3   [ Previous Page | 1 2 3 | Next Page ]
[ Jump to Last Post ]
Post new Thread
Author
Previous Thread This topic has been viewed 3118 times and has 24 replies Next Thread
nanoprobe
Master Cruncher
Classified
Joined: Aug 29, 2008
Post Count: 2998
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: Consistently short granted credit... why?



My machines all overlcaim as well, but I blame it on the fact they all have 64 bit OS's and a 64 bit BOINC client.


^^^^^^^^^^^^^^^^What he said^^^^^^^^^^^^^^^^^^^^^^^^ crying
----------------------------------------
In 1969 I took an oath to defend and protect the U S Constitution against all enemies, both foreign and Domestic. There was no expiration date.


[Aug 16, 2010 8:58:02 PM]   Link   Report threatening or abusive post: please login first  Go to top 
anhhai
Veteran Cruncher
Joined: Mar 22, 2005
Post Count: 839
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: Consistently short granted credit... why?

trust me 64 bit OS and client doesn't make an ounce of different. I have both and they perform almost identical
----------------------------------------

[Aug 16, 2010 9:21:41 PM]   Link   Report threatening or abusive post: please login first  Go to top 
Former Member
Cruncher
Joined: May 22, 2018
Post Count: 0
Status: Offline
Reply to this Post  Reply with Quote 
Re: Consistently short granted credit... why?

Specific to HFCC (and FAAH), can offer 2 things to try and improve the closeness of claim and grant:

2. Cache up more than a day of work and start BOINC scheduled networking to connect only 1 hour per day or more/less depending on the daily throughput and result upload/download MB volume. Ethernet traffic and WIFI sucks considerable juice which affects the mini[calibration/reference]tests inside these work units during the beginning and end phase which when the network is active always coincides with uploading.

Exactly what am I doing here? I only have one option to control connection frequency, and it's not defined in hours per day:

  • Connect to network about every ____ days

How do I use that to control it according to what you described? I've actually had that set for 0.025 (days), because BOINC was in the habit of accumulating piles of completed work units, which caused ridiculous swings in my RAC and made it impossible to get a sense of general effectiveness. I am loathe to undo this and wind up having useless averages again.

As far as process priority, I already have a licensed version of Cacheman XP, which also has "sticky" priority settings.
[Aug 17, 2010 5:04:45 AM]   Link   Report threatening or abusive post: please login first  Go to top 
JmBoullier
Former Community Advisor
Normandy - France
Joined: Jan 26, 2007
Post Count: 3716
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: Consistently short granted credit... why?

Connect to network about every ____ days
This is not the parameter which was intended, this one is used for computing the cache size.

The parameter you would have to use is in the Basic Options section at the top:
Connect to the Internet only between: hh:mm and hh:mm
----------------------------------------
Team--> Decrypthon -->Statistics/Join -->Thread
[Aug 17, 2010 5:34:35 AM]   Link   Report threatening or abusive post: please login first  Go to top 
Sekerob
Ace Cruncher
Joined: Jul 24, 2005
Post Count: 20043
Status: Offline
Reply to this Post  Reply with Quote 
Re: Consistently short granted credit... why?

Actually I use the method described in this FAQ for the scheduled connecting i.e. doing this through local preferences rather than via the website device profiles as that allows daily variation:

Some sample Scenarios when to Crunch or Network
http://www.worldcommunitygrid.org/forums/wcg/viewthread_thread,20741

RAC/BSRAC is a sliding mean of the last 60 days or rather the average of the days that results were reported in that 60 day window, so it should not flux that much, but the logic is flawed if there is a big outage day and result reporting slips to the next day (and BOINCStats is not in sync with the WCG stats time keeping). At constant production it should not matter that much and at least I see it move only so slightly, more dependent on what gets OKayed on from prior pending validation status. On Sunday I had 34 in PV, and Tuesday morning it was 19... and that's with 1.5 devices.

Also if using a scheduled connect of an hour, most/all Ready to Report will be cleared during that 1 hour daily window. BOINC forces any out that have reached 24 hour after completion and when it does, it takes the newer along, since there will be several requests for work and these combine with Ready to Report clearing.
----------------------------------------
WCG Global & Research > Make Proposal Help: Start Here!
Please help to make the Forums an enjoyable experience for All!
[Aug 17, 2010 7:33:41 AM]   Link   Report threatening or abusive post: please login first  Go to top 
Former Member
Cruncher
Joined: May 22, 2018
Post Count: 0
Status: Offline
Reply to this Post  Reply with Quote 
Re: Consistently short granted credit... why?

I agree, dozens of results sitting and waiting "ready to report" is annoying, especially for those who run higher than default caches and run projects with highly variable WU runtimes, such as HCMD2. Or for people who do not have internet access 24/7.

Here's how you can get BOINC to do a manual update, at a time of your choosing: (Windows OS)

Open Notepad or any text editor and put the following line of code in it:

boinccmd --host localhost --passwd XXXX --project www.worldcommunitygrid.org update


-replace XXXX with the password found in gui_rpc_auth.cfg in your BOINC data directory.

-save this text file as "update.bat" in your /BOINC folder.

Open Windows task scheduler and create a new task which executes "update.bat" and set the schedule however you like. I have my machines set up in 2 different ways depending on need:

-for my farm which only has internet access from 0000-0600 local time: run update.bat daily at 0555.

-for the machines in my house which have 24/7 net access: run update.bat at 1755 which is 5 minutes before WCG runs it's end-of-day stats.

You can even use this to run the update command on remote machines on a network by modifying the contents of the update.bat file.
[Aug 18, 2010 2:51:33 AM]   Link   Report threatening or abusive post: please login first  Go to top 
Former Member
Cruncher
Joined: May 22, 2018
Post Count: 0
Status: Offline
Reply to this Post  Reply with Quote 
Re: Consistently short granted credit... why?

It seems like Sekerob and XS_fallwind are using two different means to achieve the same thing, the latter being the more geekish method I suppose. I've been using a cache of 3 days since my SETI@Home days; it was motivated by the legendary outages that project used to have, and I confess I have yet to see a similar outage with WCG. I still use the large cache anyway.

@Sekerob: Why enable the "Disconnect when done" setting, since clearly you're using broadband? I didn't think the setting was relevant in a true networked context, and I worried that it might even force an unnecessary renewal of the DHCP lease.
[Aug 18, 2010 3:36:16 AM]   Link   Report threatening or abusive post: please login first  Go to top 
Sekerob
Ace Cruncher
Joined: Jul 24, 2005
Post Count: 20043
Status: Offline
Reply to this Post  Reply with Quote 
Re: Consistently short granted credit... why?

The disconnect does not really matter. The machine from which I did this sampling is portable... sometimes connected via dial up modem when ADSL2+ is down for longer. The DHCP lease I've set in the router to 14 days with preferred IP's coupled to mac addresses (which you can do both for WIFI and NIC) so that devices always get the same, but if by fluke don't will still connect from a limited range of free IPs. The devices themselves are set to auto ip/dns, but still in 99.999% of the time get the same IP assigned.

Cron job is a solution, someone employing the not much known boinccmd tool. Slick, unattended, low taxing on the servers has it's just once a day, briefly before the midnight UTC. Long as that does not get too popular, so I'd set it to 30 minutes before noon and midnight UTC to give the validators a chance to get things sorted out. Just before midnight is a very busy segment on the servers.
----------------------------------------
WCG Global & Research > Make Proposal Help: Start Here!
Please help to make the Forums an enjoyable experience for All!
[Aug 18, 2010 6:16:09 AM]   Link   Report threatening or abusive post: please login first  Go to top 
Former Member
Cruncher
Joined: May 22, 2018
Post Count: 0
Status: Offline
Reply to this Post  Reply with Quote 
Re: Consistently short granted credit... why?

I'm an ignorant American who hasn't yet got up to speed with UTC. What values represent noon and midnight in UTC? I've known about boinccmd but never felt inspired to use it before.
[Aug 18, 2010 7:26:24 AM]   Link   Report threatening or abusive post: please login first  Go to top 
Former Member
Cruncher
Joined: May 22, 2018
Post Count: 0
Status: Offline
Reply to this Post  Reply with Quote 
Re: Consistently short granted credit... why?

UTC is Co-ordinated Universal Time, formerly known as GMT or Greenwich Mean Time. Time values are expressed the same as military time, 1200 for noon, 0000 for midnight. Conversion from UTC to local time for North America can be found here: http://www.dxing.com/utcgmt.htm

PS: forgot to mention, all time related settings in the BOINC manager and your My Grid page are in your local time. No need to convert to UTC.
----------------------------------------
[Edit 1 times, last edit by Former Member at Aug 18, 2010 10:06:26 AM]
[Aug 18, 2010 10:02:33 AM]   Link   Report threatening or abusive post: please login first  Go to top 
Posts: 25   Pages: 3   [ Previous Page | 1 2 3 | Next Page ]
[ Jump to Last Post ]
Post new Thread