Has the validation error problem been quietly resolved during the day today? My last validation error occured this morning, actually about 9 hours ago.

Are you still seeing the error occur??

Are you psychic?? I was just thinking the same thing!!

My latest run on the boxes I am monitoring has shown no Validation errors during the last 12 hours.

F.

---

Has the validation error problem been quietly resolved during the day today?

I wish I could say it was resolved, but I can't promise it will stay fixed. Nothing is ever as simple as it seems. But we're trying.....

---

@SETIEric@qoto.org (Mastodon)

Has the validation error problem been quietly resolved during the day today?

I wish I could say it was resolved, but I can't promise it will stay fixed. Nothing is ever as simple as it seems. But we're trying.....

Thanks Eric for taking the time to look into the problem, especially on a Weekend.

Has the validation error problem been quietly resolved during the day today?

I wish I could say it was resolved, but I can't promise it will stay fixed. Nothing is ever as simple as it seems. But we're trying.....

Thanks Eric for taking the time to look into the problem, especially on a Weekend.

I second that. Thank you Eric from taking time away from your weekend.

---

Has the validation error problem been quietly resolved during the day today?

I wish I could say it was resolved, but I can't promise it will stay fixed. Nothing is ever as simple as it seems. But we're trying.....

Thank you very much for stopping in Eric!

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

The kitties just turned the network on and they are kinda bummed....after 7 rigs reported the work done since this morning, I still managed to snag about 12 validation errors between them.
The problem is not fixed yet.

Will turn the network back off and try another batch tomorrow morning.

This has been another message from the kitty warning network.......

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

For what its worth, On the two old machines that I run, I seem to have skipped getting any Validate Errors so far this time (touch wood). During past rashes, of the validate errors, they were fairly susceptable so maybe there is a clue there somewhere, a difference in client, app or settings maybe (besides being old machines). Then again maybe just good luck this time :D

Jason

[Oh I did mobilise a few base ships, but they never managed to locate any trouble, let alone fire off any shots ... ]

---

"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.

Looking through my task list across all computers here on SETI, I don't see any validate errors either (I may have had some which have subsequently been purged, but since they tend to hang around for the re-issue, I would have expected to have seen some if they were as common for all hosts as people have been saying). I'm running BOINC v5.10.13 with a connect interval of 0.01 days (just under 15 minutes), so that's the usual interval between upload and report.

However, I did get a validate error on Beta overnight. Here's the log:

03/11/2007 22:31:05|SETI@home Beta Test|Computation for task 03mr07aa.5457.5798.3.9.6_2 finished
03/11/2007 22:31:05|SETI@home Beta Test|Starting 03mr07aa.28548.3753.4.9.124_2
03/11/2007 22:31:05|SETI@home Beta Test|Starting task 03mr07aa.28548.3753.4.9.124_2 using setiathome_enhanced version 527
03/11/2007 22:31:08|SETI@home Beta Test|[file_xfer] Started upload of file 03mr07aa.5457.5798.3.9.6_2_0
03/11/2007 22:31:16|SETI@home Beta Test|[file_xfer] Finished upload of file 03mr07aa.5457.5798.3.9.6_2_0
03/11/2007 22:31:16|SETI@home Beta Test|[file_xfer] Throughput 8054 bytes/sec
03/11/2007 22:31:29|SETI@home Beta Test|Sending scheduler request: To fetch work
03/11/2007 22:31:29|SETI@home Beta Test|Requesting 4308 seconds of new work, and reporting 1 completed tasks
03/11/2007 22:31:44|SETI@home Beta Test|Scheduler RPC succeeded [server version 509]

So the work request happened to trigger a report just 13 seconds after the upload finished: more evidence that the 'Return Results Immediately' clients are most at risk in the current batch?

Hey dummy - check my stats - I think I have a right to complain

First off, "dummy" is grounds for starting a flame war. Saying "bye" is not. Just because one has a right to complain, doesn't mean one can't do so in a more constructive manner.

And for someone that is a "moderator" you sure know how to start an unneeded flame war!

By telling you "bye"? Heaven forbid! If you recognize an "unneeded" flame war, why respond in such a way that will further it by calling me a "dummy"? It's amazing that this Moderator tag gets me put up on such a pedestal that I cannot respond in kind to people, but it's perfectly OK for them to be jerks about it. It's a two-way street, regardless of the Moderator tag.

---

Hey dummy - check my stats - I think I have a right to complain

First off, "dummy" is grounds for starting a flame war. Saying "bye" is not. Just because one has a right to complain, doesn't mean one can't do so in a more constructive manner.

And for someone that is a "moderator" you sure know how to start an unneeded flame war!

By telling you "bye"? Heaven forbid! If you recognize an "unneeded" flame war, why respond in such a way that will further it by calling me a "dummy"? It's amazing that this Moderator tag gets me put up on such a pedestal that I cannot respond in kind to people, but it's perfectly OK for them to be jerks about it. It's a two-way street, regardless of the Moderator tag.

Ozz, don't worry about it. Looking at his posting history (under this and previous user names), you're not the first, and probably won't be the last, user to feel the non-constructive side of his personality.

His computers are hidden, so we can't analyse exactly what went wrong. But looking at his team affiliation, and his posting history, I think we can guess. BOINC v5.9.0 (Crunch3r) with RRI, anybody?

It never ceases to amaze me how some of the most competitive spirits here can spend enormous amounts of time, mental energy, electrical energy and equipment purchase cost (Kevin posted, while he was still Kevin, that he didn't have the use of any company or school computers: all those hidden hosts had been purchased with his own money): yet still have no idea how to work with BOINC, rather than against it. Maybe Kevin and others could apply some of the philosophy of Jiu-Jitsu to their competitiveness?

Ozz, don't worry about it. Looking at his posting history (under this and previous user names), you're not the first, and probably won't be the last, user to feel the non-constructive side of his personality.

Yeah. I think you're right.

---

So the work request happened to trigger a report just 13 seconds after the upload finished: more evidence that the 'Return Results Immediately' clients are most at risk in the current batch?

I agree Richard. The event that seems to be triggering the validation problem is reporting a completed WU within a very short interval from the upload of it. And taking that into account, any RRI client is going to increase the chances of that happening.
However....it is still a problem that has to be overcome, and I think Eric's response recognizes that. Because even a stock client with reporting based on connect interval stands the chance of hitting the bug with the last WU or two uploaded just before the reporting threshold is reached.
Hopefully this will be towards the top of Eric's to do list this coming week. I hope he can get it sorted.

EDIT....
And hopefully in the meantime Eric can run his magic script periodically and restore some of the credits currently being lost due to the error.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Ozz, as a forum moderator you come across the thoughts of various different characters - Some are understanding,funny and kind - Some are the extreme opposite.
So, as Richard statet above : Don`t let it ruin your day !

Regards
Kurt

---

I say,,,"let it ruin your day"..that way even a mediocre day tomorrow will seem like a good day. LOLOLOL

Well, just reported last night's work, and the validator errors still abound. I know the RRI aspect of the client I am using makes it worse, but the root cause is still there.
I am wondering if some of the recent server configuration changes are contributing to this problem, because I had not been getting all these validation errors until just recently.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Taking a look at the computers of most of the people that are seeing this Validate error, nearly all are using BOINC v 5.10.13 or Crunch3r's 5.9.0. AFAIK these are the only versions that allow reporting immediately.

Therefore I would recommend that we all, as I also use 5.10.13 but have not had these errors, but then my CI setting is 0.01, check that the CI is not 0.000 or RRI.

With 5.10.xx the settings made in your account here may not be having any effect because you have a "global_prefs_override.xml" file, if so to change settings you need to use Advanced/Preferences in BOINC Manager.

Andy

P.S. This problem of 5.10.13 CI 0.000 was brought up in Aborted, Canceled by Server, happening A LOT !!! Posted on 31 Jul 2007.

I use 5.10.13 on all my boxes, but my CI is 0.1 - just under 2.5 hours. I haven't looked through all my boxes yet, but I see at least one validate error from this morning.

-Dave

[edit] From 4 Nov 2007 7:47:40 UTC to be exact...

[edit 2] Found a total of 4 new (today) validate errors, posted in the validate thread.

---

I just checked all my boxes. I have not received any more validation errors in more than 24 hours. All my boxes are using Boinc 5.10.13 version and chicken optimized applications. I have the CI set at 0.0006944 (60 seconds) plus the cache set for 5 days.

If your still using crunch3r's 5.9.0 version of Boinc I would say now is a good time to upgrade Boinc. This is of course just my opinion.

[edit] I do NOT use a global_preferences_override file. [/edit]

I use 5.10.13 on all my boxes, but my CI is 0.1 - just under 2.5 hours. I haven't looked through all my boxes yet, but I see at least one validate error from this morning. [edit] From 4 Nov 2007 7:47:40 UTC to be exact...

Dave,

It would be interesting if you were to look at your message log for this morning, and see if that particular upload/report pair respected your 0.1 day connect interval, or whether - like my Beta log earlier - a work fetch request meant that your result was actually reported much quicker than normal.
_____________

Does anyone remember this little graph I posted last week?


(direct link)

- the one that showed that BOINC v5.9.0 for Windows was the single most used version of BOINC, at least in the 8-hour period I captured data for?

I've been thinking about that. How come it's so widely used? The official download site (calbe.dw70.de) is not exactly obvious, it's not listed on the Other sources of BOINC client software page, and a Google search for 'optimized BOINC client' doesn't bring it up in at least the first half-dozen pages. So it's obscure, yet the most popular version on the planet. How come?

I think it's to do with teams. I don't think it's a coincidence that the team recruiting slogan on the download site matches the team that KevinT is a member of. I guess (and it is only a guess) that at least one team has been promoting - heavily promoting - a client which is deprecated by the project developers. In which case, I don't have much sympathy: I think any complaints should be directed at the team promoters.

I truly, honestly don't believe that the project developers would deliberately introduce validate errors in an attempt to eliminate RRI clients (they could just block that version, as I believe some other projects have already done). But I'm almost tempted to start an urban myth.......

Back to serious matters. It's interesting that my Google search still brings up the Truxoft client as the #1 hit. One of the good features of that client, which I used for over a year, was that each of the optimisation features could be controlled by a configuration file setting - you could use RRI, or you could turn it off. I think it's a major drawback that Crunch3r doesn't do configuration: if you use his clients, you get all the features - CPU Affinity, RRI, and (IIRC) inflated benchmarks - whether you want them all or not. I see from the 'Who?' thread that Crunch3r has made a new version with delayed reporting available (I hope he remembered all about the GPL). This is not the version on the public download page (those files are still datestamped January 2007) - I think it would be a good idea if Crunch3r made the delayed-reporting version his recommended download.

Dave,

It would be interesting if you were to look at your message log for this morning, and see if that particular upload/report pair respected your 0.1 day connect interval, or whether - like my Beta log earlier - a work fetch request meant that your result was actually reported much quicker than normal.

Here's from around that time, one of the validate errors in question was 11fe07ac.23804.13569.6.6.70

11/4/2007 5:04:48 AM|SETI@home|Sending scheduler request: To fetch work
11/4/2007 5:04:48 AM|SETI@home|Requesting 55 seconds of new work, and reporting 2 completed tasks
11/4/2007 5:04:53 AM|SETI@home|Scheduler RPC succeeded [server version 511]
11/4/2007 5:04:53 AM|SETI@home|Deferring communication for 11 sec
11/4/2007 5:04:53 AM|SETI@home|Reason: requested by project
11/4/2007 5:04:55 AM|SETI@home|[file_xfer] Started download of file 14fe07ab.30369.17250.10.6.206
11/4/2007 5:05:00 AM|SETI@home|[file_xfer] Finished download of file 14fe07ab.30369.17250.10.6.206
11/4/2007 5:05:00 AM|SETI@home|[file_xfer] Throughput 150782 bytes/sec
11/4/2007 5:20:10 AM|SETI@home|Sending scheduler request: To fetch work
11/4/2007 5:20:10 AM|SETI@home|Requesting 64 seconds of new work
11/4/2007 5:20:15 AM|SETI@home|Scheduler RPC succeeded [server version 511]
11/4/2007 5:20:15 AM|SETI@home|Deferring communication for 11 sec
11/4/2007 5:20:15 AM|SETI@home|Reason: requested by project
11/4/2007 5:20:17 AM|SETI@home|[file_xfer] Started download of file 14fe07ab.20423.9479.12.6.222
11/4/2007 5:20:22 AM|SETI@home|[file_xfer] Finished download of file 14fe07ab.20423.9479.12.6.222
11/4/2007 5:20:22 AM|SETI@home|[file_xfer] Throughput 160317 bytes/sec
11/4/2007 5:23:52 AM|SETI@home|Computation for task 11fe07ac.23804.13569.6.6.70_0 finished
11/4/2007 5:23:52 AM|SETI@home|Starting 11fe07ac.23924.91123.9.6.75_0
11/4/2007 5:23:52 AM|SETI@home|Starting task 11fe07ac.23924.91123.9.6.75_0 using setiathome_enhanced version 528
11/4/2007 5:23:54 AM|SETI@home|[file_xfer] Started upload of file 11fe07ac.23804.13569.6.6.70_0_0
11/4/2007 5:23:58 AM|SETI@home|[file_xfer] Finished upload of file 11fe07ac.23804.13569.6.6.70_0_0
11/4/2007 5:23:58 AM|SETI@home|[file_xfer] Throughput 26347 bytes/sec
11/4/2007 5:23:58 AM|SETI@home|Computation for task 11fe07ac.23924.91123.9.6.75_0 finished
11/4/2007 5:23:58 AM|SETI@home|Starting 11fe07ac.23839.92350.7.6.107_1
11/4/2007 5:23:58 AM|SETI@home|Starting task 11fe07ac.23839.92350.7.6.107_1 using setiathome_enhanced version 528
11/4/2007 5:24:00 AM|SETI@home|[file_xfer] Started upload of file 11fe07ac.23924.91123.9.6.75_0_0
11/4/2007 5:24:01 AM|SETI@home|Sending scheduler request: To fetch work
11/4/2007 5:24:01 AM|SETI@home|Requesting 2550 seconds of new work, and reporting 1 completed tasks
11/4/2007 5:24:04 AM|SETI@home|[file_xfer] Finished upload of file 11fe07ac.23924.91123.9.6.75_0_0
11/4/2007 5:24:04 AM|SETI@home|[file_xfer] Throughput 23244 bytes/sec
11/4/2007 5:24:06 AM|SETI@home|Scheduler RPC succeeded [server version 511]
11/4/2007 5:24:06 AM|SETI@home|Deferring communication for 11 sec
11/4/2007 5:24:06 AM|SETI@home|Reason: requested by project

-Dave

---