Bruce, just what exactly is the key in the registry that you are talking about with regard to TCP timestamp setting? I haven't yet searched the forum for the thread you are referring to. I still don't have full caches on my Win 7 machines. Only about 50 CPU tasks and about 150 GPU tasks. Still see a majority of "no work available" messages every 5 minutes.

Once again my cache had run down, but not as much as in past days. Changed my application settings to Yes, Yes, Yes, hit Update & on the next work request it filled up.

This is on my Win10 system.
I'd be surprised if the TCP settings have any effect- i'm having no issues in contacting the Scheduler and getting a response. I'm just having issues with it allocating work even though I haven't hit the server side limits & I haven't reached my full cache settings.

I wouldn't think that TCP setttings would have anything to do with it either.
If the scheduler request is successfully made and answered without error, I don't see how the transmission rate or manner would affect how the scheduler processes the request.
I believe the old comms problem was affecting the ability to make contact with the servers in the first place.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Bruce, just what exactly is the key in the registry that you are talking about with regard to TCP timestamp setting? I haven't yet searched the forum for the thread you are referring to. I still don't have full caches on my Win 7 machines. Only about 50 CPU tasks and about 150 GPU tasks. Still see a majority of "no work available" messages every 5 minutes.

Hi Kieth

If you search the forum you can find the way to manually edit the registry, but I use this program to do it
TCP Optimizer v. 3.08.

They have a newer version that should work with Win10 TCP Optimizer 4.

It might have been a fluke that it started working when I made the change, I don't know.
Try it. If it works, then great, if not, then we will have to keep looking for what will work.
Good luck.

---

Bruce

Thanks Bruce, I searched the forum for threads and came upon the one regarding RFC1323, timestamps and TCP Optimizer. I looked in the registry in the location mentioned in the thread and I didn't have any entries for TCP RFC1323. I downloaded the TCP Optimizer 4 mentioned and ran it and rebooted. Nothing really has changed, still am getting only 4 tasks at a time when requested. That rate is not fast enough to keep up with the task retirement. Before all this started with the inability to get work, after the outage, I consistently would get 41-46 tasks per request after the servers recognized my download request in the queue. That is not the case with the Win 7 machines. Only get a maximum of 4 tasks per request now. The Win 10 machine got the usual 41-46 tasks per slug after the project came back yesterday and quickly refilled its quota.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

FYI, update. Finally back to full quota of 100/200 CPU/GPU tasks; 4 tasks downloaded at a time on my Windows 7 machines. So, it looks like it will take me 20 hours or so after the project comes back online to get my quota now. Wish I understood what has changed with regard to my Win 7 machines and the project servers.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Where does one scrounge up an old 6.10.58 BOINC installer for Windows 7 64 bit? The BOINC All Versions page Download page only has 7.6 series BOINC platforms for Windows 7 64 bit.

You can find it here Boinc Installer.
It has all the old versions of BOINC.

The last time I went there the 6.10.58 Win versions d/l were corrupted, but the 6.10.60's were fine.

I just tried 6.13.12 and that seems to have installed. Now to see if the problem is fixed.

After 6.10.60 things went downhill.

No luck with any 6.XXX branch of BOINC. Seems to ignore cc_config.xml flags and also ignore my app_config.xml. I just backleveled to 7.4.42 and at least that installed. Will see whether I can get any work.

Yes you must go back to old school ways to get the most out of these versions.

Cheers.

Where does one scrounge up an old 6.10.58 BOINC installer for Windows 7 64 bit? The BOINC All Versions page Download page only has 7.6 series BOINC platforms for Windows 7 64 bit.

You can find it here Boinc Installer.
It has all the old versions of BOINC.

The last time I went there the 6.10.58 Win versions d/l were corrupted, but the 6.10.60's were fine.

I just tried 6.13.12 and that seems to have installed. Now to see if the problem is fixed.

After 6.10.60 things went downhill.

No luck with any 6.XXX branch of BOINC. Seems to ignore cc_config.xml flags and also ignore my app_config.xml. I just backleveled to 7.4.42 and at least that installed. Will see whether I can get any work.

Yes you must go back to old school ways to get the most out of these versions.

Cheers.

Yes, that is what I found, Both 6.10.57 and 6.10.58 were corrupted. 6.10.60 doesn't even exist anymore in the directory. I gave up on going back to the 6 series. I have gotten used to and need the features of the 7 series now. I'm back to 7.6.33 to have all machines at the same level.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I use 7.6.33 with the manager from 6.10.48. I don't need a notices tab and I use the messages tab enough that having to open Event Log is simply annoying.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Ah shoot, again...

19/01/2017 00:40:59 | SETI@home | Requesting new tasks for AMD/ATI GPU
19/01/2017 00:40:59 | SETI@home | [sched_op] CPU work request: 0.00 seconds; 0.00 devices
19/01/2017 00:40:59 | SETI@home | [sched_op] AMD/ATI GPU work request: 180.00 seconds; 1.00 devices
19/01/2017 00:41:01 | SETI@home | [file_xfer] http op done; retval 0 (Success)
19/01/2017 00:41:01 | SETI@home | [file_xfer] parsing upload response: <data_server_reply>    <status>0</status>    <file_size>0</file_size></data_server_reply>
19/01/2017 00:41:01 | SETI@home | [file_xfer] parsing status: 0
19/01/2017 00:41:01 | SETI@home | [fxd] starting upload, upload_offset 0
19/01/2017 00:41:03 | SETI@home | Scheduler request completed: got 0 new tasks
19/01/2017 00:41:03 | SETI@home | [sched_op] Server version 707
19/01/2017 00:41:03 | SETI@home | No tasks sent
19/01/2017 00:41:03 | SETI@home | No tasks are available for AstroPulse v7
19/01/2017 00:41:03 | SETI@home | Tasks for CPU are available, but your preferences are set to not accept them
19/01/2017 00:41:03 | SETI@home | Tasks for NVIDIA GPU are available, but your preferences are set to not accept them
19/01/2017 00:41:03 | SETI@home | Tasks for Intel GPU are available, but your preferences are set to not accept them
19/01/2017 00:41:03 | SETI@home | Project requested delay of 303 seconds
19/01/2017 00:41:03 | SETI@home | [sched_op] Deferring communication for 00:05:03

(Before anyone asks, that's with Yes, Yes and Yes. I never changed that setting.)

---

I use 7.6.33 with the manager from 6.10.48. I don't need a notices tab and I use the messages tab enough that having to open Event Log is simply annoying.

The showstopper for me is the lack of app_config with the older manager.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I use 7.6.33 with the manager from 6.10.48. I don't need a notices tab and I use the messages tab enough that having to open Event Log is simply annoying.

The showstopper for me is the lack of app_config with the older manager.

Ah, I use notepad for that.

It is odd that some users with the issue are having luck toggling their web preferences back and forth. While others with the same settings, and haven't touched their preferences in months, are not having any issues.
My SETI@home prefs are either Yes, Yes, No or No, Yes, No and look to have been that way since at least April of last year.
Are the only hosts effected those that have or did have "accept work from other applications" set to Yes before the issue effecting that setting occurred?

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Are the only hosts effected those that have or did have "accept work from other applications" set to Yes before the issue effecting that setting occurred?

In "Home" mode (normal), I'm set yes, yes, yes
In "School" mode (AP splitters running), I'm set yes,no,no to make room in the caches in case I get lucky.
I've got a thing set in Firefox to make it a single keystroke to swap all crunchers between modes.
7.6.22 here, 4xWin10, 1xWin7

---

(Before anyone asks, that's with Yes, Yes and Yes. I never changed that setting.)

Try No, Yes, No for a few Scheduler requests and see what happens. If no joy, change it back.
Sometimes changing it from one to the other works for me, other times I have to change it (give it a few Scheduler requests to see it's made no difference) and then change it back again & the work starts flowing.
It's not making a whole lot of sense.

---

Grant
Darwin NT

I've always had it Yes for all applications and Yes to accept other work. Never had an issue getting work before all this started. I have toggled both ways endless times with several work requests on each setting. Seems to make no difference at all which way it is set. Still get only 3 or 4 tasks per request when I do get work.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I've always had it Yes for all applications and Yes to accept other work.

I've always been No, Yes, No.
Not much point saying Yes to work I can't do?

Never had an issue getting work before all this started.

Likewise.

I have toggled both ways endless times with several work requests on each setting. Seems to make no difference at all which way it is set. Still get only 3 or 4 tasks per request when I do get work.

The whole thing is too weird.
One setting will work for 10-18 hours, then the work comes in dribs and drabs (if at all). Change the settings and then it tops up in a couple of requests, then continues to replace WUs as they are reported (or I have to change the settings back to what they were, then things are OK). Then after 10-18 hours work comes in dribs & drabs & it's time to change the settings & fill the cache up again. Rinse and repeat.
Really weird (and frustrating).

---

Grant
Darwin NT

I feel your pain, folks, but I really have no more thoughts on what the problem could be for some of you.

I am on old world Boinc, yes yes yes, Win 7 on one rig, XP pro64bit on 2, and XP pro on the other 5.

And I currently still have my full cache of 2600 tasks across 8 rigs.....................
State: All (12438) · In progress (2600) · Validation pending (4981) · Validation inconclusive (125) · Valid (4732) · Invalid (0) · Error (0)
I do drop maybe as much as 10 below max, but in a few requests I am right back up to full cache.

Are we hitting the limits of the 100 task per scoop that the scheduler is working with? Having over 101k results returned per hour instead of the 80k or 90k we had before the current Aerecibo AND Guppi shorties?
That could be part of the problem? But why does it not hit MY crunchers?

What seems to be inexplicable is the randomness of it.

There seems to be no hard link to preference settings, OS, or Boinc version.
When somebody is having trouble with one of them, somebody else is doing just fine with the same.

Are the kitties just lucky? Dunno.
I CAN tell you it ain't because 'I am living right'....LOL.

EDIT:
OK, I just figured it out..............
The clue was when I used the word 'randomness'.
'Credit New' is now in charge of the scheduler.................LOL.
Meow.

---

"Time is simply the mechanism that keeps everything from happening all at once."

The clue was when I used the word 'randomness'.
'Credit New' is now in charge of the scheduler.................LOL.

You're not just whistling Dixie Kittyman (though you may think you were). The estimate components of CreditNew have driven work issue since inception, and those prediction/estimate components are precisely where the design faults are.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

The clue was when I used the word 'randomness'.
'Credit New' is now in charge of the scheduler.................LOL.

You're not just whistling Dixie Kittyman (though you may think you were). The estimate components of CreditNew have driven work issue since inception, and those prediction/estimate components are precisely where the design faults are.

. . That is for sure and in spades. On my C2D machine I am crunching on one (slow) CPU core that takes almost 3 hours to process Arecibo VLAR tasks, I normally have about 30 to 40 units cached (manager is set to 3 days of work and Guppis normally take around 2 hours). When the flood of Arecibo VLARs hit recently for some reason the Schedulers decided that Arecibo VLARs only take 30 mins to process on this rig and so decided to send me about 80 of them despite the tasks already cached for the CPU. I was not amused :(

Stephen

:(

BOINC has gone loopy for sure. CreditNew likely to blame. I have one machine that is in High Priority mode on MilkyWay GPU work now. Deadlines are 10 days out with all GPU work on all 3 machines with the same deadline. MW tasks take under 6 minutes to complete. All machines have the same server imposed hard limit of 160 tasks on board. The work is requested 1 task at a time as 1 task is retired. The other two machines are crunching all projects normally. WTF?

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

The clue was when I used the word 'randomness'.
'Credit New' is now in charge of the scheduler.................LOL.

You're not just whistling Dixie Kittyman (though you may think you were). The estimate components of CreditNew have driven work issue since inception, and those prediction/estimate components are precisely where the design faults are.

Yeah, Jason.
I was making a funny when I posted that.
But I can see that your point is correct.
Especially when backed up by a couple of confirming posts.
Fact is sometimes stranger than fiction.
Especially when it comes to the vagaries of Boinc.

---

"Time is simply the mechanism that keeps everything from happening all at once."

I REALLY hate to post this because it falls too much into the randomness idea BUT:

after the last outage it took about an hour for 2 of my computers to fill the caches ... the other 2 were still getting "no work available".

The 2 computers with full caches had 2 GPU's in each of them ... the 2 without any WU' had 1 GPU each (all are Nvidia).

Just for fun I moved 1 GPU to the other computer, (giving it 2 GPU's) and started it up ... 3 updates and It had 200 WU's!!!

I moved the GPU back to where it was before and watched for 30 min's and NO WU's were downloaded ... so I went to bed. Next A.M the queue was full ... (and I had 100 extra WU to crunch ... - Sorry)

I HAVE TO BELIEVE THIS HAS NOTHING TO DO WITH THIS DISCUSSION ... BUT ... JUST SAYING randomness is a funny thing!.

Ed F