Hungry hosts could be a problem to Einstein?

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6534
Credit: 284700169
RAC: 113726

RE: Just checking the

Quote:
Just checking the project folder and I have about 2000 tasks remaining and quite a few are 8MB !


Ah. That's 16GB right there. You have a decent 'ranch' then :-)

Cheers, Mike.

I have made this letter longer than usual because I lack the time to make it shorter ...

... and my other CPU is a Ryzen 5950X :-) Blaise Pascal

juan BFP
juan BFP
Joined: 18 Nov 11
Posts: 839
Credit: 421443712
RAC: 0

RE: Well, I was away from

Quote:

Well, I was away from home and it just kept downloading thousands of 2MB tasks.
I got the emails from ISP, 50%
75% then today 100%. I had to buy an extra 5GB. Got 8 hosts on it now.
My cache was set to the max.

Reg

Set your cache to max 0.5(*) day and resourse share of 0 (in E@H defoult seting)

For now that would make no diference for SETI (100 WU per GPU/CPU max limit is active at least for few weeks as noticed)

If your cache is at max (10 days) and resource share is at 100 (normal defoult value) and the limit of E@H is realy 300 WU that would translate in 300*16MB (for an average WU) or about 4.8 GB per host! just for the cache...

That could be the reason of your big bandwith usage...

If you keep my sugested settings when your host runs out of SETI work it will DL only the number of units needed for 1/2 day crunchin E@H (in this host 2x670 runing 2WU on each at a time, about 32 WU (16 WU per GPU or about 256MB only).

So you will not need to buy any extra quota from comsat. And will keep your hosts feeded all the time.

Hope thats helps, and the calculations are right...returning to the beer drinking task.

(*) set your cache to match you GPU speed in WU processed in SETI, for example in one of my hosts:

1 WU each 8 minutes 2 at a time = about 15 per hour for the GPU of course
so with a 100 WU limit that will take about 6 1/2 hours to process. I set my cache to 0.5 a day (so it will receive the entire 100WU limit with a lot of tranquility).

lHj2ixL.jpg

 

Big Reg
Big Reg
Joined: 9 Dec 11
Posts: 7
Credit: 5440004
RAC: 0

Yes, I will reduce the cache

Yes, I will reduce the cache right down. My cup runneth over.
Not like usual dying of thirst.

At least I won't need any more work for >19 days :-)

juan BFP
juan BFP
Joined: 18 Nov 11
Posts: 839
Credit: 421443712
RAC: 0

RE: Yes, I will reduce the

Quote:

Yes, I will reduce the cache right down. My cup runneth over.
Not like usual dying of thirst.

At least I won't need any more work for >19 days :-)


Don´t forget to put resource share at 0 (zero) at your E@H preferences :)

lHj2ixL.jpg

 

archae86
archae86
Joined: 6 Dec 05
Posts: 3145
Credit: 7023174931
RAC: 1830249

archae86 wrote:I need to run

archae86 wrote:

I need to run out the door, but I posted on this topic a year ago in the thread I pointed to earlier.

Here is a link to the relevant point in that thread.


So, here I'll try to correct information in that year-old post of mine which was either wrong when posted or has changed since then. (names and total size of files)

I believe the current truth for BRP jobs is that each downloads 8 *.bin4 files, each of size 2,098,320 bytes. So the core requirement is a trifle over 16 Megabytes/WU, and the upload and other overhead is negligible in comparison

So my single GTX460 hosts, running only at factory overclock, generating a BRP (CUDA) RAC of about 36,000/day are each incurring data traffic of about 1.2 billion bytes/day at steady state. Comcast does not seem to be generating my monthly usage-to-date information today, so I can't double-check these numbers from that source.

Thus high end hosts, running multiple cards of appreciably faster GPUs, if you find your hosts able to keep them fed, could incur perhaps as much as 10 billion bytes/day at steady state.

Requesting many days of work right at the beginning, when the time duration estimate can be wildly wrong, might give a startup transient much, much higher than that, were it not for the daily quota. I believe the most recent update to work download daily quota limits was posted here by Bikeman. Simplified, the daily limit is 32 per CPU core and 160 per GPU. So Juan's host 6107577 as currently configured could download almost 13 billion bytes/day before hitting the daily quota while (slowly) building up a work cache. Consider someone who pays for their data usage who has several such hosts sharing an internet connection. To abuse an oft-cited claimed saying by the late U.S. Senator Everett Dirksen "a billion here, a billion there, and pretty soon you are talking real money".

Jord
Joined: 26 Jan 05
Posts: 2952
Credit: 5779100
RAC: 0

RE: Yes, I will reduce the

Quote:
Yes, I will reduce the cache right down. My cup runneth over.


You can also set BOINC on all your systems to stop downloading when they near the maximum bandwidth allocated to you by your ISP.

Use the "Transfer at most --- Mbytes every --- days
Enforced by version 6.10.46+
" for that.

soft spirit
soft spirit
Joined: 27 Oct 10
Posts: 113
Credit: 5880079
RAC: 0

well it looks like our little

well it looks like our little team crossed 1M/widgets per day 2 days ago.. and the pipe seems to be holding up nicely so far.

with the temperatures dropping, I may have to plug my old 590 card back in. Gotta love GPU heating.. well at least in the Winter..

juan BFP
juan BFP
Joined: 18 Nov 11
Posts: 839
Credit: 421443712
RAC: 0

A made a post in the SETI

A made a post in the SETI GPUUG thread explaining a configuration sugestion and bandwidth requeriment for crunching SETI and E@H without conflict. For those who participate there take a look.

lHj2ixL.jpg

 

msattler
msattler
Joined: 12 May 07
Posts: 459
Credit: 98140222
RAC: 0

My guess is that Big Reg

My guess is that Big Reg didn't have workshare set to 0%, so Einstein tried to fill his cache up to his Seti cache levels.

I have not changed my cache settings at all, but with the 0% workshare set, Boinc downloads a reasonable handful of Einstein at a time.

Khangollo
Khangollo
Joined: 17 Feb 11
Posts: 42
Credit: 928047659
RAC: 0

Argh,

Argh, 10-day-cachers...

Guys, you *don't need* more than 2 day cache for Einstein@Home (if you have 24/7 internets connection on your side).

MaU38.gif

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.