Dunno if this has any bearing on the problem, E@H host log shows:-
2015-03-30 23:13:10.8910 [PID=26795] [HOST#11672980] Sending [RESULT#491220483 PM0013_02461_118_1] (est. dur. 13507.10 seconds, delay 1209600, deadline 1428966790)
2015-03-30 23:13:10.8940 [PID=26795] Only one Beta app version result per WU (#214770549, re#5)
2015-03-30 23:13:10.8952 [PID=26795] Only one Beta app version result per WU (#214770401, re#6)
2015-03-30 23:13:10.8964 [PID=26795] Only one Beta app version result per WU (#214770402, re#7)
2015-03-30 23:13:10.8980 [PID=26795] Only one Beta app version result per WU (#214770548, re#8)
Why only 1 result per WU if a quorum is required to validate the WU?
Or of course that may have nothing to do with it at all, just the HTTP errors
2015-03-30 23:13:10.8980 [PID=26795] Only one Beta app version result per WU (#214770548, re#8)
Why only 1 result per WU if a quorum is required to validate the WU?
If they send out two beta app tasks per quorum they run the risk that faulty beta results might still agree with each other and so get through the validator checks.
2015-03-30 23:13:10.8980 [PID=26795] Only one Beta app version result per WU (#214770548, re#8)
Why only 1 result per WU if a quorum is required to validate the WU?
If they send out two beta app tasks per quorum they run the risk that faulty beta results might still agree with each other and so get through the validator checks.
Hi Gary,
Soz, I'm still confused:-/ Cos every WU I have has a wingman as well as me..
to me that implies at least 2 iterations of that task..
Now and then I get a WU with a _4 at the end so its been sent to more than 2 clients..
So if E@H only sends out 1 beta WU at a time, how does that fit in?
Not questioning your statement, just can't see how things are working:-(
... to me that implies at least 2 iterations of that task..
Absolutely, but only one of them can be sent to a beta test host.
The log snippet you posted is simply showing the scheduler machinations in trying to select a suitable task to send to your (beta enabled) host. It reported several potential candidate tasks but rejected each of them because one of the pair making up each quorum had already already been sent to a beta-enabled host. Eventually it would have found a suitable task - perhaps one that hadn't been sent to anyone else yet.
Quote:
Now and then I get a WU with a _4 at the end so its been sent to more than 2 clients..
A WU (when first issued) consists of two identical tasks, sent to two separate hosts, the only difference being that one has the suffix '_0' and the other '_1'. If either or both of those 'primary' tasks fail for whatever reason, the scheduler will send out replacement copies (resends) with incrementing suffixes such as '_2' or '_3' or '_4', etc, up to the limit of 20 tasks per quorum. So an _4 task simply means that at least 3 earlier copies of the task must have already failed. This is general operating procedure and nothing to do with beta tests. For beta tests, primary tasks and resends are sent out in the normal way with the exception that a quorum can contain just one copy of the task which is assigned to a beta test host - hence the above scheduler machinations to enforce this rule.
Quote:
So if E@H only sends out 1 beta WU at a time, how does that fit in?
The project doesn't send out beta WUs. It sends out WUs that contain two duplicate tasks. Those tasks could both be crunched by hosts running the standard app, or they could be crunched by 1 standard app host and 1 beta test host. They can't both be crunched by beta test hosts.
Much obliged:-) Gotit now.. it was the word 'result' that got to me, as I saw it a result is what you get when a WU has completed and sends that info to the server. Had it said only 1 'task' per beta client it would have made more sense to me:-)
BTW seems some forum options are slowing to the point of uselessness:-/
Like Quote, leaves one with a box containing only the info part, nothing of any quoted text or space to reply..
Maybe the u/l gremlins are invading other areas:-/
2015-03-30 23:13:10.8980 [PID=26795] Only one Beta app version result per WU (#214770548, re#8)
Why only 1 result per WU if a quorum is required to validate the WU?
If they send out two beta app tasks per quorum they run the risk that faulty beta results might still agree with each other and so get through the validator checks.
Hi Gary,
Soz, I'm still confused:-/ Cos every WU I have has a wingman as well as me..
to me that implies at least 2 iterations of that task..
Now and then I get a WU with a _4 at the end so its been sent to more than 2 clients..
So if E@H only sends out 1 beta WU at a time, how does that fit in?
Not questioning your statement, just can't see how things are working:-(
Regards,
I think he's getting at the possibility that if there's a coding bug in the beta code (there is a reason it would be beta); there would be a possibility that two computers could crunch that task perfectly, if you will (aka without error from the computer's end). As such, both computers would arrive at a similar result. But if the bug is in the code itself (reason it would be tested), the result could still be bad. This wouldn't be due to an issue with the computer, but rather due to the instructions the computers were given to execute having a bug in it. Until the code is known/reliable, one can't guarantee it will always produce good results. That's why it's tested, and then they can look at the tests, to make sure that the results check out. This check wouldn't be the same as simply making sure the computers produce a similar result, but would necessitate that the result is valid based on a known quantity of what it should be. AKA, giving a test unit, they have an idea what result they want to see, independent of getting the result back, and if it doesn't match, can then look for a logic error in the code to see why it doesn't match.
There's a saying wrt computers, garbage in, garbage out. If the code has a bug in it, the computer can execute that as it should, but because the code has a problem, it won't give the desired result...
As to the issue we're seeing here, uploads are still problematic. I'm actually starting to wonder if we broke the server during the team challenge, and it had trouble keeping up with the stress that got put on it. Well the challenge is over, hopefully the remaining tasks can upload sometime soon.
I think he's getting at the possibility that if there's a coding bug in the beta code (there is a reason it would be beta); there would be a possibility that two computers could crunch that task perfectly, if you will (aka without error from the computer's end). As such, both computers would arrive at a similar result. But if the bug is in the code itself....
If the above was directed at me, nope, what got to me wasn't a bug in any code, it was terminology. In my view 'result' is just that, the output file generated when a WU has been processed to a conclusion. NOT a 'task' to be sent to a client..
Quote:
As to the issue we're seeing here, uploads are still problematic. I'm actually starting to wonder if we broke the server during the team challenge, and it had trouble keeping up with the stress that got put on it. Well the challenge is over, hopefully the remaining tasks can upload sometime soon.
Hi Magic, Dunno if this
)
Hi Magic,
Dunno if this has any bearing on the problem, E@H host log shows:-
2015-03-30 23:13:10.8910 [PID=26795] [HOST#11672980] Sending [RESULT#491220483 PM0013_02461_118_1] (est. dur. 13507.10 seconds, delay 1209600, deadline 1428966790)
2015-03-30 23:13:10.8940 [PID=26795] Only one Beta app version result per WU (#214770549, re#5)
2015-03-30 23:13:10.8952 [PID=26795] Only one Beta app version result per WU (#214770401, re#6)
2015-03-30 23:13:10.8964 [PID=26795] Only one Beta app version result per WU (#214770402, re#7)
2015-03-30 23:13:10.8980 [PID=26795] Only one Beta app version result per WU (#214770548, re#8)
Why only 1 result per WU if a quorum is required to validate the WU?
Or of course that may have nothing to do with it at all, just the HTTP errors
Regards,
Cliff,
Been there, Done that, Still no damm T Shirt.
RE: 2015-03-30
)
If they send out two beta app tasks per quorum they run the risk that faulty beta results might still agree with each other and so get through the validator checks.
Cheers,
Gary.
RE: RE: 2015-03-30
)
Hi Gary,
Soz, I'm still confused:-/ Cos every WU I have has a wingman as well as me..
to me that implies at least 2 iterations of that task..
Now and then I get a WU with a _4 at the end so its been sent to more than 2 clients..
So if E@H only sends out 1 beta WU at a time, how does that fit in?
Not questioning your statement, just can't see how things are working:-(
Regards,
Cliff,
Been there, Done that, Still no damm T Shirt.
RE: ... to me that implies
)
Absolutely, but only one of them can be sent to a beta test host.
The log snippet you posted is simply showing the scheduler machinations in trying to select a suitable task to send to your (beta enabled) host. It reported several potential candidate tasks but rejected each of them because one of the pair making up each quorum had already already been sent to a beta-enabled host. Eventually it would have found a suitable task - perhaps one that hadn't been sent to anyone else yet.
A WU (when first issued) consists of two identical tasks, sent to two separate hosts, the only difference being that one has the suffix '_0' and the other '_1'. If either or both of those 'primary' tasks fail for whatever reason, the scheduler will send out replacement copies (resends) with incrementing suffixes such as '_2' or '_3' or '_4', etc, up to the limit of 20 tasks per quorum. So an _4 task simply means that at least 3 earlier copies of the task must have already failed. This is general operating procedure and nothing to do with beta tests. For beta tests, primary tasks and resends are sent out in the normal way with the exception that a quorum can contain just one copy of the task which is assigned to a beta test host - hence the above scheduler machinations to enforce this rule.
The project doesn't send out beta WUs. It sends out WUs that contain two duplicate tasks. Those tasks could both be crunched by hosts running the standard app, or they could be crunched by 1 standard app host and 1 beta test host. They can't both be crunched by beta test hosts.
Cheers,
Gary.
Hi Gary, Much obliged:-)
)
Hi Gary,
Much obliged:-) Gotit now.. it was the word 'result' that got to me, as I saw it a result is what you get when a WU has completed and sends that info to the server. Had it said only 1 'task' per beta client it would have made more sense to me:-)
BTW seems some forum options are slowing to the point of uselessness:-/
Like Quote, leaves one with a box containing only the info part, nothing of any quoted text or space to reply..
Maybe the u/l gremlins are invading other areas:-/
Regards,
Cliff
Cliff,
Been there, Done that, Still no damm T Shirt.
I got some new tasks on one
)
I got some new tasks on one host but tried to get more for my fastest one and only got no new tasks too many uploads in progress
RE: RE: RE: 2015-03-30
)
I think he's getting at the possibility that if there's a coding bug in the beta code (there is a reason it would be beta); there would be a possibility that two computers could crunch that task perfectly, if you will (aka without error from the computer's end). As such, both computers would arrive at a similar result. But if the bug is in the code itself (reason it would be tested), the result could still be bad. This wouldn't be due to an issue with the computer, but rather due to the instructions the computers were given to execute having a bug in it. Until the code is known/reliable, one can't guarantee it will always produce good results. That's why it's tested, and then they can look at the tests, to make sure that the results check out. This check wouldn't be the same as simply making sure the computers produce a similar result, but would necessitate that the result is valid based on a known quantity of what it should be. AKA, giving a test unit, they have an idea what result they want to see, independent of getting the result back, and if it doesn't match, can then look for a logic error in the code to see why it doesn't match.
There's a saying wrt computers, garbage in, garbage out. If the code has a bug in it, the computer can execute that as it should, but because the code has a problem, it won't give the desired result...
As to the issue we're seeing here, uploads are still problematic. I'm actually starting to wonder if we broke the server during the team challenge, and it had trouble keeping up with the stress that got put on it. Well the challenge is over, hopefully the remaining tasks can upload sometime soon.
Grrrrrrrrrrrr, so now we know
)
Grrrrrrrrrrrr, so now we know whom to blame for E@H servers dropping like flies:-)
Regards,
Cliff
Cliff,
Been there, Done that, Still no damm T Shirt.
RE: I think he's getting
)
If the above was directed at me, nope, what got to me wasn't a bug in any code, it was terminology. In my view 'result' is just that, the output file generated when a WU has been processed to a conclusion. NOT a 'task' to be sent to a client..
You have a separate reply to the above:-)
Regards,
Cliff
Cliff,
Been there, Done that, Still no damm T Shirt.
The upload problem is still
)
The upload problem is still going on.
I hope people at the office will see this thread.