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).
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".
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.
RE: Just checking the
)
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
RE: Well, I was away from
)
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).
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 :-)
RE: Yes, I will reduce the
)
Don´t forget to put resource share at 0 (zero) at your E@H preferences :)
archae86 wrote:I need to run
)
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".
RE: Yes, I will reduce the
)
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.
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..
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.
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.
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).