I think, in the new 5.10.20 version, BOINC wait 24 hours...

BOINC will wait 24 hours before reporting, if there's no other reason to connect earlier, like asking for more work...

Asking for more work will happen just like before, every time amont of cached work drops below cache-setting. The only difference is:

"cache-size" = "connect every N days" + "Maintain enough work for an additional N days".

In 5.10.20 work will be reported at the first of:

1) More work is needed (a work fetch is generated).
2) 24 hours before deadline.
3) Connect interval (Connect every X) before deadline.
4) 24 hours after completion of a task.
5) A manual connection.

Batching things reduces the load on the database server.

I'll stay where I'm at, Boinc can keep 5.10.20, I've got enough trouble now as It is.

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

Hello,

because cache was empty I updated to 5.10.20.
But because of no work available I Have to wait for new WUs. No problem so far.

But after a minute or so this appeared in the "Download Tab":
under conection speed the following is shown:
"43397236619010381" followed by a huge number (near 100) of zeros followed by the normal ",00 KBps"

In the message tab is written:... temporarely down ... and system connect...

This error is coming new in that BOINC version, never seen it before..

[EDIT]
I've forgotten: it is a dual core and iti s only shown for one core. The other is all right...
[/EDIT]

Greetings
Bernd

---

Bernd, ignore it. It was reported (by myself and others), but not fixed prior to release. It's harmless.

tony

Thx Toni,

I've ignored it since I wrote the message.
But I could not ignore that the scheduler assigned 26 WUs, and there is still no download ... (more than five houres)


Does this problem has an easy solution, other to reset BOINC ??


Greetings
Bernd

---

Resetting boinc will just get you more stuck downloads to replace the ones lost in the reset. I too have wus stuck in download. I'm not sure what you're cache is set to, but I've found the higher the setting the more likely that one will actually connect on one of it's many retry efforts. it's a numbers thing, especially since each retry is at a different time. I've found a cache of 2 days more than sufficient to keep working without running dry, but that was over the weekend. Also, that's if you already have work. If you're dry, try 3 days. I don't know what they're changing that might affect my previous recommendation.

Thx Toni,

I've ignored it since I wrote the message.
But I could not ignore that the scheduler assigned 26 WUs, and there is still no download ... (more than five houres)


Does this problem has an easy solution, other to reset BOINC ??


Greetings
Bernd

Try ipconfig/flushdns.

On Vista it is more difficult to do than on XP. Google ipconfig/flushdns vista or ipconfig vista for more information.

---

Sir Arthur C Clarke 1917-2008

Thx Toni,

I've ignored it since I wrote the message.
But I could not ignore that the scheduler assigned 26 WUs, and there is still no download ... (more than five houres)


Does this problem has an easy solution, other to reset BOINC ??


Greetings
Bernd

Try ipconfig/flushdns.

On Vista it is more difficult to do than on XP. Google ipconfig/flushdns vista or ipconfig vista for more information.

Alternatively, try buying Berkeley a bigger, better and faster workunit file store.

The problem's at their end, not yours.

People have to learn to distinguish between a global (and yes, I do mean global - worldwide) problem, and a problem which affects you, yourself, personally, and only you.

If it's personal, try flushdns.
If it's global, express your support for the harassed staff at Berkeley with sympathy or cash, according to your means.

Ok I've tried every hint, exept buying Berkeley a bigger.....
... no progress...

I think, because my other project (Spinhenge) downloads as good as every time, it is a problem of Berkeley...


So, don't worry, be waiting...


Greetings
Bernd

---

Thx Toni,

I've ignored it since I wrote the message.
But I could not ignore that the scheduler assigned 26 WUs, and there is still no download ... (more than five houres)


Does this problem has an easy solution, other to reset BOINC ??


Greetings
Bernd

Try ipconfig/flushdns.

On Vista it is more difficult to do than on XP. Google ipconfig/flushdns vista or ipconfig vista for more information.

Alternatively, try buying Berkeley a bigger, better and faster workunit file store.

The problem's at their end, not yours.

People have to learn to distinguish between a global (and yes, I do mean global - worldwide) problem, and a problem which affects you, yourself, personally, and only you.

If it's personal, try flushdns.
If it's global, express your support for the harassed staff at Berkeley with sympathy or cash, according to your means.

I did the ipconfig/flushdns on my vista machine several days back, vista was not very happy with me for doing that.

My computer virtually locked up, a few things worked but I had that vista 'working' circle that wouldn't go away and I couldn't get most things to do anything.
I finally had to do what windows doesn't like, pull the power plug, lol, and reboot. After that, everything was back to normal.

No more ipconfig/flushdns for me on the vista machine.

---

I'm testing the new '24 hours' feature since two days... My cache is decreasing and BOINC don't ask for new work... Only reports every 24 hours after complete next WU before last connect... I have set the preferences 0 days to connect and 10 days of extra work...

I send you more news tomorrow after connecting, but this appears BOINC new version don´t request new work until the cache is empty...

Well... The mistery was solved...

I was crunching several wild WU's that increased my 'Result duration correction factor'...

That makes the 'time to complete' of the rest of WU's in my cache are increased too and BOINC thinks than I have enoug work...

Nothing about the 5.10.20 version...

---

Logan.

BOINC FAQ Service (Ahora, también disponible en Español/Now available in Spanish)

Yep, the clinkers have that unfortunate effect if you don't catch them in time and get rid of them. All the versions that support RDCF are susceptible to this.

OTOH, BOINC will bring the time metrics back into line eventually if you leave it alone.

The quick way is to keep track of what they are 'normally', and then edit them in client_state when they get whacked in cases like this.

Alinator

Yep, the clinkers have that unfortunate effect if you don't catch them in time and get rid of them. All the versions that support RDCF are susceptible to this.

OTOH, BOINC will bring the time metrics back into line eventually if you leave it alone.

The quick way is to keep track of what they are 'normally', and then edit them in client_state when they get whacked in cases like this.

Alinator

I see it... Good idea...

Done...!

Thanks a lot Alinator...!!! That looks better...!

---

Logan.

BOINC FAQ Service (Ahora, también disponible en Español/Now available in Spanish)

I think I see an advantage of 5.10.20 over 5.10.13 which is strong for me:

It appears that a long-standing bug (or at least limitation) which gave large amounts of overfetching on hosts with strongly skewed resource allocations has been fixed.

It appeared that in the past, no account was made of resource allocation in deciding how much work to request for a host whose work for a particular project had declined to zero, or even just appreciably below the request threshold. Thus hosts for which I have an 8 or 9% SETI resource allocation would request far more than appropriate when work became available after a server drought, or when fetch was allowed again after a temporary abeyance to address a short-term long-term mismatch. This was "selfish" after a drought, and would kick me into EDF much sooner than my chosen queue length would predict.

This was quite annoying, and I adopted some otherwise counter-productive practices to compensate, including shorter queue lengths than I'd otherwise like, and a habit of micromanaging away short-term long-term imbalances by direct client_state.xml editing.

Anyway, assuming I've got this about right, my thanks to the developers for the fix, and I offer this possible reason to other users to upgrade.

---

5.10.20 running good on 2 of my rigs.

For Windows only. This time, the Linux development is lagging behind with no stable 5.10.x available.

---

i have a weird issue regarding this boinc version... after running several hours, more than a day maybe...it is very unpredictable, the boinc manager suddenly receives a red stop sign, and there are no more details in the projects, tasks tabs (they vanish somehow)... after i exit boinc and open it again all is back to normal...the problem is that if i leave it for a few days, i don't know if will crunch all the time or not.... the problem appeared only in this version...OS is xp pro 32 and the cpu is e4300 oc'd to 3.0...anyone else encountered the same problem?....hmmm...it says something that the boinc manager is not connected to something....weird

5.10.20 running good on 2 of my rigs.

For Windows only. This time, the Linux development is lagging behind with no stable 5.10.x available.

I have been running 5.10.8 on Linux (Slackware) for several months now. It's still listed as a development version but I've had no problems with it at all.

---

Jim

Some people plan their life out and look back at the wealth they've had.
Others live life day by day and look back at the wealth of experiences and enjoyment they've had.

I have been running 5.10.8 on Linux (Slackware) for several months now. It's still listed as a development version but I've had no problems with it at all.

Is your Slackware 32-bit or 64-bit? I have tried 64-bit version on my 64-bit Fedora Core and experienced boinc aborts with nothing in the logs: just boinc process dies. I usually start boinc on Linux with flags "-daemon -allow_remote_gui_rpc".

Also, I can't run 5.10 64-bit on RHEL since it requires newer glibc libraries (GRRR RHEL4 is not even 3 years old and boinc already doesn't support it). I went back to 32-bit 5.8 boinc on those 64-bit machines and I use app_info.xml to run 64-bit Seti apps on these computers.

---

I have been running 5.10.8 on Linux (Slackware) for several months now. It's still listed as a development version but I've had no problems with it at all.

Is your Slackware 32-bit or 64-bit? I have tried 64-bit version on my 64-bit Fedora Core and experienced boinc aborts with nothing in the logs: just boinc process dies. I usually start boinc on Linux with flags "-daemon -allow_remote_gui_rpc".

Also, I can't run 5.10 64-bit on RHEL since it requires newer glibc libraries (GRRR RHEL4 is not even 3 years old and boinc already doesn't support it). I went back to 32-bit 5.8 boinc on those 64-bit machines and I use app_info.xml to run 64-bit Seti apps on these computers.

Sorry, I should have mentioned that it's just 32 bit. Since my wife and I are both trying to survive on just one disability income I can't afford a fast 64 bit multicore machine. I have a 1.3ghz Celeron which is the fastest machine I've been able to scrape together, but it does a fair job at crunching and most everything else I throw at it except for some of the newest games, etc.

---

Jim

Some people plan their life out and look back at the wealth they've had.
Others live life day by day and look back at the wealth of experiences and enjoyment they've had.

I had to go to 5.10.20 in order to get wu's. But I also noticed that now my RAC is improving slightly on this computer. I am using 2.4.

---

I have been running 5.10.8 on Linux (Slackware) for several months now. It's still listed as a development version but I've had no problems with it at all.

Is your Slackware 32-bit or 64-bit? I have tried 64-bit version on my 64-bit Fedora Core and experienced boinc aborts with nothing in the logs: just boinc process dies. I usually start boinc on Linux with flags "-daemon -allow_remote_gui_rpc".

Also, I can't run 5.10 64-bit on RHEL since it requires newer glibc libraries (GRRR RHEL4 is not even 3 years old and boinc already doesn't support it). I went back to 32-bit 5.8 boinc on those 64-bit machines and I use app_info.xml to run 64-bit Seti apps on these computers.

Sorry, I should have mentioned that it's just 32 bit. Since my wife and I are both trying to survive on just one disability income I can't afford a fast 64 bit multicore machine. I have a 1.3ghz Celeron which is the fastest machine I've been able to scrape together, but it does a fair job at crunching and most everything else I throw at it except for some of the newest games, etc.

I sympathize with You Jim-R, As It sounds even harder than living alone on an SSI check in an expensive state in an area where It gets super hot(Yet It's cheaper than the rest of the state, Barely that is.) and I have to upgrade the windows from single pane to low-e dual pane and doing the conversion to dual pane windows is going to be costly to Me($2,673 if bought one at a time vs $2,209 if bought all at once, There are 4 wide windows[$417ea] & 3 narrow ones[$335ea]), I have to also add Silver window film[about $500] and Four window awnings[$400 or $100 ea], But worthwhile in the end.

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's