By now, both SETI and us users (all -- not just gasbuddy) should be painfully aware that massive downloading of WU's and uploading of results is mainly a hardware problem. The volume of network traffic is overloading Seti@H BOINC's servers and storage capacity.

I think they should run a script reseting all users to no more than 1 days work and lock them there until they are ready to try their latest and greatest solution or hardware upgrade. They can then restore everyone's prefrences and let us try and break the system again.

Frankly, I do not see the sense in caching WU's at all. Downloading more than a days work at a time, while great when the system is "up 'n' down"; will cause individual and group rankings to jump around in quantum leaps and bounds as large chunks of work are
processed and returned.

--Pete

Pete,
The one thing I like about having a WU cache, is that alot of people do not get the time everyday to monitor their computers activities. Especially with the past long "Down Time". I do not think that I agree with the "1 Day cache", I would rather see 5 days of work to do, until the system is running smooth.

I agree that when Boinc is back up and running smooth, you will see a big change in the credit that is initially given but after a few days of up time this should smooth out as everybody returns WU's on a consistant basis.

As for uploading complete WU's,I have my network settings disabled so that I can choose when I attempt to upload.I try to do this when I believe the server is at a low point. Now a days that is hard to determine, so I am sitting here with around 140 units waiting to be uploaded. I know in time they will be uploaded, I just follow the other threads and look for posts from Boinc Dev team as to progress.

Warm Regards

so I am sitting here with around 140 units waiting to be uploaded
==========

So no wonder I can't get any Credit ... @%^&%$#@% ... ;)

Poorboy,
How many are you sitting on, 600 or 700. It is not because I want to, it is just that its seems for the last couple of days, it keeps "deferring Communication". Do you have an "always On" connection.I am on dial up and have one phone line.At one time I had been uploading 2 or three times a day, it just seems during their recent problems, I check the Home Page and then the message boards to see the status first.

Warm Regards,

Rocky

:-) Rocky

>
> Frankly, I do not see the sense in caching WU's at all. Downloading more than
> a days work at a time, while great when the system is "up 'n' down"; will
> cause individual and group rankings to jump around in quantum leaps and bounds
> as large chunks of work are
> processed and returned.
>

If you've not got a permanent connection, having more than 1 day cached makes perfect sence. If relying on dial-up, wouldn't dream of using less than 2-day-min-cache, and many haven't got another option, and since atleast here phone-bill is paid by the second it's important to minimize the online-time.

Even with permanent connection, long-time-seti-users knows Berkeley often has small or longer outages, so will rely on a weeks cache. Of course, then more projects is running stable can attack to more projects to make sure wouldn't run idle. Connecting to CPDN should ensure you'll have work in most cases. ;)

In "classic", some users has offline-farms that example is re-filled once a week, while others can be away for weeks/months and turns off internet-access but let their home-farm crunch away, others just saves up for a surprise-dump to pass another cruncher or more team-organized to surprise another team, while still others is team-hoppers only staying a week or so before jumping to the next team. In BOINC team-hopping doesn't move the "credit", while 14-day-deadline makes sure everyone will dump atleast every 14-day. So overall the credit-flow will be more constant once BOINC is fully up and running. Probably not the daily flow, but this has never been a good indicator since even DC-only-boxes has daily variation in #wu-crunched due to AR.

> How many are you sitting on, 600 or 700.

it's not a question of number.

>alot of people do not get the time everyday to monitor their computers

exacty it is.

yes we are still with seti@boinc, but for my part, I would apreciate,
having less work for us user.

Asking respectful: how many times did you clicked on the "retry now" or "update" knob?

Ok, when scheduler is down, he is down, but when scheduler running
asking one more time, how many "clicks" are you doing? to update?

we all know, the boinc-client will retry itelf but after long long delayes.

Wow many time we see in the messages of the boincclient, scheduler not..
clicking "retry.. or update" give us a better "chance" to up or download
I know it's not the best way, but also clicking to "retry now" on the client

really wondering if the new hardware can help..

friendly ric

Ingleside, I fully agree. And with that 14 day deadline, I am sure that there are many that will lose some of their WU's because of the downtime, especially those with slower computers.

Warm Regards,

Rocky

Current scenario ;

Suppose there is 10 users. they are all crunching 10 WU per day
and their caches is set to 10 days of work.

Each user connect once every 10 days to upload and download.
the probability that they all connect the same day is 10 to 1.
Their connections been made randomly and because we have no way
to now when they will connect we have to spread out the connection
equaly on a 10 days period.

Day 1 user 1 connect and transfer 200 units
Day 2 user 2 connect and transfer 200 units
Day 3 user 3 connect and transfer 200 units
Day 3 user 4 connect and transfer 200 units
Day 5 user 5 connect and transfer 200 units
etc...

At the and of the 10 days period the server had tranfered total 2000 WU

Proposed scenario ;

Each users caches is set to one day.

Day one all users connect and transfer total of 200 units
Day two all users connect and transfer total of 200 units
etc...

At the and of the 10 days period the server had tranfered total 2000 WU

Same thing !

Best regards
Marc

Friendly Ric,
I try not to use the update buttons or the retry buttons. At least in my case, when I am online for a period of time doing other things, Boinc tries to upload at it's time frames. It usually comes back saying "Backing off from 1 minute to 3 hours. I let it run it's course, and if they do not upload in the time that I am online, I disable the network connection and wait until next time online. When the uploads do transmit, I will then go to the projects page and hit "Update". Lately it has been saying "Deferring Communication" It says usually 1 minute at first. Before the recent "Down Time", very rarley would it "report work" the first time, but after the initial Deferrment the schedualer responded. Before the recent Down Time, whenever the Schedualer responed successfully I would start getting new WU's. Sometimes 2, sometimes 25.
I try to follow the message boards for messages about the server, but I have seen other posts that say that you can force uploads. I just thought this was why many people could not get through, because of the "force feeding".Am I doing it wrong?

Very Sincerely,

Rocky

Warm Regards

Among all the reasons why SETI is switching to boing is the following one

Quote

"BOINC has a more flexible data architecture than SETI@home Classic. Data can be transferred to and from multiple servers, and can remain resident on PC disks. In the future, we'll use these capabilities to search for ET signals in a much larger radio frequency range."

It's them who decided to give us the possibility to set our caches preferences
it's for them to make shure that it works. Not us !

> Current scenario ;
>
> Suppose there is 10 users. they are all crunching 10 WU per day
> and their caches is set to 10 days of work.
>
> Each user connect once every 10 days to upload and download.

Impossible, if not every user has atlest 2 machines, since every machine can at most get assigned 50 "results"/day, counted from midnight Berkeley-time, 07:00 UTC.

> the probability that they all connect the same day is 10 to 1.
> Their connections been made randomly and because we have no way
> to now when they will connect we have to spread out the connection
> equaly on a 10 days period.
>
> Day 1 user 1 connect and transfer 200 units

200??? didn't you say 10wu/day & 10-day-cache? Of course depends on min/max-setting, but this will in that case either be 10 /day starting day2 or 100 at day 11...

> Day 2 user 2 connect and transfer 200 units
> Day 3 user 3 connect and transfer 200 units
> Day 3 user 4 connect and transfer 200 units
> Day 5 user 5 connect and transfer 200 units
> etc...
>
> At the and of the 10 days period the server had tranfered total 2000 WU

Uhm, 10 users with 10-day-cache & 10 wu/day is 1000 wu. ;)

>
> Proposed scenario ;
>
> Each users caches is set to one day.
>
> Day one all users connect and transfer total of 200 units
> Day two all users connect and transfer total of 200 units
> etc...
>
> At the and of the 10 days period the server had tranfered total 2000 WU
>
> Same thing !
>

It's a couple of problems here:
1; currently some 6x-expected-wu is being recycled again, this screws up the units downloaded.
2; many dialup-users is screwed if can't download more than 1 days work, both due to #1 but also in case of "fast" wu or crashes.
3; it's not certain connecting 10 times getting 10 wu/time is easier on the I/O-limited database than connecting 5 times getting 20 wu/time...

Anyway, then everything works as it should, a fairly normal setting of 7-10 days cache will give this schenario for someone with one machine crunching 10 wu/day:

Day1; 3 connects gives 50 new wu, crunches 10. Rest 40.
day2; 2 connects gives 40 new wu, returns 10 results, crunches 10, rest 70
day3; 1 connects gives 20 new wu, returns 10 results, crunches 10, rest 80
day4; no connects since already 7-day-cache, crunches 10, rest 70.
day5; 1 connects gives 20 new wu, returns 20 results, crunches 10, rest 80
day6; no connects since already 7-day-cache, crunches 10, rest 70.
day7; 1 connects gives 20 new wu, returns 20 results, crunches 10, rest 80
day8; no connects since already 7-day-cache, crunches 10, rest 70.
day9; 1 connects gives 20 new wu, returns 20 results, crunches 10, rest 80
day10; no connects since already 7-day-cache, crunches 10, rest 70.

Ok, day1 will keep asking every hour for more work so you'll really return 10 results this day. Did a little simplification with only asking at start of day. ;)
AFAIK the client doesn't re-ask for more work even didn't reach max-#-cache-days if over min-#-cache-days, but can be mistaken at this point. But will not re-ask later on atleast before drops down below min-#-cache-days.
Also v4 is maybe a little different and will maybe fill up to max-#-cache-days even if v3 isn't doing it...

Poorboy,
How many are you sitting on, 600 or 700
==========

Well actually right now I'm only sitting on as you call it 25 WU's ready to Upload, but that is no fault of mine, I simply haven't been able to upload them. I upload any finished WU's as soon as I can, I don't sit on them for 10 days and the upload them. And I was just kidding about not being able to get any Credits because of you holding that many. Didn't you see the Wink Smiley at the end of the Post...

I have cable so I'm always connected but right now I'm like you and have the Internet connection disabled because theres no point in the GUI to keep trying to upload when it's not going to happen. I just try on one PC every now and then to see if they are accepting uploads. If not then I just disable the connection again.

Right now it doesn't really matter because Credit isn't being Granted anyway so if your holding them for what ever reason it's no big deal right now. But when they are granting credit I see no reason to hold that many at once because the people are waiting for their credits and people that hold a huge amount of Finished WU's are simply keeping some people from getting those credits until they are ready to turn them in.

I don't keep the Finished ones on my computers any longer than I have to, not only for the above reason but also for the reason of what if some thing happens to your computer and you lose all those finished WU's. Now they have to be sent out again after the deadline and that could have been avoided by sending them in in a timely manner instead of holding on to them...

The problem with this logic is SETI will have MILLIONS of users!
Random or not it's their bandwidth and server capibilities we have to depend upon.

--Pete

> Current scenario ;
>
> Suppose there is 10 users. they are all crunching 10 WU per day
> and their caches is set to 10 days of work.
>
> Each user connect once every 10 days to upload and download.
> the probability that they all connect the same day is 10 to 1.
> Their connections been made randomly and because we have no way
> to now when they will connect we have to spread out the connection
> equaly on a 10 days period.
>
> Day 1 user 1 connect and transfer 200 units
> Day 2 user 2 connect and transfer 200 units
> Day 3 user 3 connect and transfer 200 units
> Day 3 user 4 connect and transfer 200 units
> Day 5 user 5 connect and transfer 200 units
> etc...
>
> At the and of the 10 days period the server had tranfered total 2000 WU
>
> Proposed scenario ;
>
> Each users caches is set to one day.
>
> Day one all users connect and transfer total of 200 units
> Day two all users connect and transfer total of 200 units
> etc...
>
> At the and of the 10 days period the server had tranfered total 2000 WU
>
> Same thing !
>
> Best regards
> Marc
>
>
>
>
>
>

on a dial up line, there is an other situation, a lot of people are on dial up, other people are using a permanent connection to the web.


> doing it wrong?

I'm not able to classify, if I'am wrong myself or not, therefore much less able to classify others..
it's not my way. I do just accept..and having fun.

it's just a fact, many users have more than one little friend crunching,
as more you have of them, as more the "mess" plays.


frequently seeing delaying of 1 2 4 6 or more HOURS. This even when 24/7 "pluged" to the net. many user "reporting" this also.

spoken from my experience, letting all clients running themself as the project was "designed", they where not able to UPLOAD/report all WU's. Download yes.
When we can't upload, this belongs other users, waiting for hard worket credit.
It takes time to "help" the uploads.


I'am an old man, needing much sleep. since the project started, I missed a bit
all my hopes are in the future. on the seti1 days, a old pentium 120 laptop was doing himself and faithful, what I have to do now myself... (yes It's not fair to compare this way)

perhaps wrong but seti@boinc or not seti@boinc, "computers" are build to serve the human, not the other way

This application on the actual release, could be more usrfriendly (my opinion).

Overloading SETI's Servers
several days offlined, the server(s) are going online, we user are doing our upload togeher. if there is one or more escaped Wu, we are going there like ducks, receiving their dayly bread.

sometimes berkeley gots in just a few hours, the work, the "backlog" of serveral day. in those case, we all together, without knowing it, are hammering the hardware-system(s)and software components, each of us, creates a small part of the load.

we will se.

most of the time friendly

ric



// offtopic
@petit soleil
your are right, concering the cpu temp, running a history based mesure tool, saw the same. The increase of temp fittes exactly to the start/end phase of
a wu

> Impossible, if not every user has atlest 2 machines, since every machine can
> at most get assigned 50 "results"/day, counted from midnight Berkeley-time,
> 07:00 UTC.

Forget about the 50 limit. It's not the point. I am talking about maths.
If you prefer do the same calculation with number that would not exceed 50
The facts I want to show would be the same.

> 200??? didn't you say 10wu/day & 10-day-cache? With 200 you needs atleast
> 4 machines.

I wrote "transfer" witch include both download and upload.
10 X 10 UPLOAD = 100 10 X 10 DOWNLOAD = 100
100 + 100 = 200 TOTAL TRANSFER


> Uhm, 10 users with 10-day-cache & 10 wu/day is 1000 wu. ;)

Again 10 X 10 X 10 UPLOAD = 1000 10 X 10 X 10 DOWNLOAD = 1000
1000 + 1000 = 2000 TOTAL TRANSFER


> 3; it's not certain connecting 10 times getting 10 wu/time is easier on the
> I/O-limited database than connecting 5 times getting 20 wu/time...

That's exactly what I have tried to demonstrate !

> Anyway, then everything works as it should, a fairly normal setting of 7-10
> days cache will give this schenario for someone with one machine crunching 10
> wu/day:
>
> Day1; 3 connects gives 50 new wu, crunches 10. Rest 40.
> day2; 2 connects gives 40 new wu, returns 10 results, crunches 10, rest 70
> day3; 1 connects gives 20 new wu, returns 10 results, crunches 10, rest 80
> day4; no connects since already 7-day-cache, crunches 10, rest 70.
> day5; 1 connects gives 20 new wu, returns 20 results, crunches 10, rest 80
> day6; no connects since already 7-day-cache, crunches 10, rest 70.
> day7; 1 connects gives 20 new wu, returns 20 results, crunches 10, rest 80
> day8; no connects since already 7-day-cache, crunches 10, rest 70.
> day9; 1 connects gives 20 new wu, returns 20 results, crunches 10, rest 80
> day10; no connects since already 7-day-cache, crunches 10, rest 70.

You don't seem to understand my point. Your example here is correct but
with a small cache there would just be more connection but with smaller
file size transfer. supose it works like classic. You finish one, you upload and download one. This makes a total of 10 connection minimum for one user
with one machine crunching 10 WU per day. In your example you take into account connection problems it would also occur with small caches !

The point is no matter how you set your cache at the end of this 10 days
period the total number of connection, download and upload, Units report
is EXACTLY THE SAME.

Tell me what is the difference between

10 USERS CONNECTING ONE TIME PER DAY AND DOWNLOADING 10 WU
10 X 1 X 10 = 100

AND

10 USERS CONNECTING TEN TIMES AND DOWNLOADING ONE WU
10 X 10 X 1 = 100

It's as simple as 1+1=2

There is a mathematical law that apply here that would confirm what I am
saying. I click Post reply and I go get it in my engeneering books.

> Tell me what is the difference between
>
> 10 USERS CONNECTING ONE TIME PER DAY AND DOWNLOADING 10 WU
> 10 X 1 X 10 = 100
>
> AND
>
> 10 USERS CONNECTING TEN TIMES AND DOWNLOADING ONE WU
> 10 X 10 X 1 = 100
>
> It's as simple as 1+1=2
>
> There is a mathematical law that apply here that would confirm what I am
> saying. I click Post reply and I go get it in my engeneering books.
>

Over time, yes the resultant work is the same. But, my hypothsis is SETI's hardware can cope with a continuous, gentle steady stream of incomming results better than large clusters of incomming data. It's a question of throughput at their end, not ours.

--Pete

> Over time, yes the resultant work is the same. But, my hypothsis is SETI's
> hardware can cope with a continuous, gentle steady stream of incomming results
> better than large clusters of incomming data. It's a question of throughput
> at their end, not ours.
>
> --Pete

Once again small caches would not be smoother on the server. As all
connections are completely random. There could very be a point where
10000 client with small cache are trying to connect at the same time
asking for one WU. The same way you could have 1 users alone on the
bandwith asking for 20 WU. the connections are random and unpredictable.

Best regards
Marc

This is embarassing. Why is everyone arguing and bickering about stupid things like how many workunits they have waiting to upload and how much cache people have? Petit Soleil - I agree with you, Berkeley gave us the ability to set caches, it's up to them to make sure it works right, not us. Berkeley knows the power of this supercomputer that they have at their fingertips and I'm sure they are eager to get everything ready to take as much advantage of that power as they are able. But it's complicated to use this "supercomputer" and takes some time and effort to perfect things.

Besides that, we are all here for the same reason, to HELP the people at Berkeley analyze recorded signals from space in hopes of finding "little green men." Bickering amongst ourselves and moaning about how things are going right now does not help anyone with anything. It does not help get units, it does not help upload units, it does not help the hardware problems which everyone should have known from the beginning if they didn't.

Like I've said so many times, all we can do is let BOINC do it's thing when it is able, let UCB know of any bugs we find, and help fellow users with any real problems that they have. There is no need for anyone try to "defend" oneself here. So while they get things working, why don't we sit back, relax a little, and not be so jumpy about such small meaningless matters (that includes the 6x length workunits that would just simply go away if people actually let them process instead of worrying not having as many workunits to process because of them).

And that is my two cents worth.

Chris

> And that is my two cents worth.
>
> Chris

Very well said
Marc

(snipping some things, hopefully not too much...)

>
> I wrote "transfer" witch include both download and upload.

Granted, you did wrote transfer here, but uploading results has never been a bottleneck in seti since a wu is roughly 350KB while a result is roughly 5KB. Since the problem now is the database it's maybe different...

>
> > Uhm, 10 users with 10-day-cache & 10 wu/day is 1000 wu. ;)
>
> Again 10 X 10 X 10 UPLOAD = 1000 10 X 10 X 10 DOWNLOAD = 1000
> 1000 + 1000 = 2000 TOTAL TRANSFER

Here you can't say anything, since I specifically wrote "wu", while you wrote "At the and of the 10 days period the server had tranfered total 2000 WU"
You are NEVER returning a wu back to the seti-servers, but a result. Confusedly BOINC also calls the "thing" you get assigned for download for "result", but you also downloads a wu to accompany this "result". ;)

>
> The point is no matter how you set your cache at the end of this 10 days
> period the total number of connection, download and upload, Units report
> is EXACTLY THE SAME.

If you look more closely on my example you see the #wu downloaded is not the same but 170. ;) Also, different cache-settings will dictate how often you're reporting work / asking for more, therefore the #connections to RPC will be different. The actual number of file download/upload will over time average out regardless of cache-settings, but due to exponential backoff if can't connect isn't a major problem before the 100 MBit-internet-link is swamped, and at this point it's swamped regardless of 1 connection or 100 connections.

>
> Tell me what is the difference between

Since this is DC the important difference is...

>
> 10 USERS CONNECTING ONE TIME PER DAY AND DOWNLOADING 10 WU
> 10 X 1 X 10 = 100

In most cases all can connect once per day so 100 wu is downloaded.

>
> AND
>
> 10 USERS CONNECTING TEN TIMES AND DOWNLOADING ONE WU
> 10 X 10 X 1 = 100

Many users is using dial-up so can't connect 10 times a day. Around here, every phone-call is paid by the second. Also, connecting at day is much more expensive than evenings/nights. Of course, you'll maybe also want to use the phone for other things, so can't let BOINC dial-out at will.
Therefore, not knowing how many uses dial-up can only take a guess but let's say half of them is dial-up, and the dial-up-users only connects once a day.

So in this example you get only 55 wu/day.

>
> It's as simple as 1+1=2

This isn't math, it's DC, and 55 wu/day != 100 wu/day. ;)


If you looks on the documentation one of the main points of the scheduling-server is "Make as few scheduler RPCs as possible." Also, the points of caching is:
1; "The core client downloads enough work to keep its host busy for a user-specifiable amount of time. This can be used to decrease the frequency of connections or to allow the host to keep working during project downtime."
2; "This scheme allows computers that are sporadically connected (because they're portable or have modem-based connections) to avoid becoming idle due to lack of work. If the host is frequently disconnected from the Internet, the min should be at least as long as the typical period of disconnection. The larger the difference between min and max, the less often the BOINC client will connect to the Internet."

edit... O, it wasn't your idea to limit the cache to 1 day. :o
Oh well, hopefully has shown that limiting the cache to only 1 day isn't a good idea. :)