Hello.
Some of us (including me), when encounter this error sometimes need to do workaround (deleting work/, queue.dat, unitlist.txt, even machinedependent.dat) so it won't get the same (bad?) WU again. Now, if the machine that's doing the WU is headless (without monitor), and leave running without user intervention for quite a while, there's a possibility this machine will run the same (bad?) WU over and over again. Means waste of power.
Here's my suggestion.
- When client A encounter this error (or any other error that hinting bad WU) at some checkpoint, the client report this WU to the server.
- The server mark the WU.
- client A get different WU.
- The server send the marked WU to other client. Say client B and C.
- If client B and C report the same error at the same checkpoint, most likely the WU is a bad WU.
- Else, if either client B or C send the completed WU, there's possibility client A machine is not very stable.
This way, client A won't waste its resources to do the same WU over and over again. And it provides a good way to test whether a WU is a bad one.
Just my 2 cent
Suggestion for handling ERROR 0x0
Moderators: Site Moderators, FAHC Science Team
Suggestion for handling ERROR 0x0
Last edited by amuro.ID on Wed May 05, 2010 1:41 pm, edited 1 time in total.
-
- Site Moderator
- Posts: 6986
- Joined: Wed Dec 23, 2009 9:33 am
- Hardware configuration: V7.6.21 -> Multi-purpose 24/7
Windows 10 64-bit
CPU:2/3/4/6 -> Intel i7-6700K
GPU:1 -> Nvidia GTX 1080 Ti
§
Retired:
2x Nvidia GTX 1070
Nvidia GTX 675M
Nvidia GTX 660 Ti
Nvidia GTX 650 SC
Nvidia GTX 260 896 MB SOC
Nvidia 9600GT 1 GB OC
Nvidia 9500M GS
Nvidia 8800GTS 320 MB
Intel Core i7-860
Intel Core i7-3840QM
Intel i3-3240
Intel Core 2 Duo E8200
Intel Core 2 Duo E6550
Intel Core 2 Duo T8300
Intel Pentium E5500
Intel Pentium E5400 - Location: Land Of The Long White Cloud
- Contact:
Re: Suggestion for handling ERROR 0x0
I guess that it requires some modification in the server codes. Right now, if your system is 100% stable (you ran multiple WUs without any error) and out of the blue, you get EUE or other errors, you report it in the forum and if there are multiple people that complains then the admin/mod marks the WU as bad. I guess that the bad WUs are out in the open unless they are taken down by the admin/mod. Hopefully, an automated system might be planed in the future.
ETA:
Now ↞ Very Soon ↔ Soon ↔ Soon-ish ↔ Not Soon ↠ End Of Time
Welcome To The F@H Support Forum Ӂ Troubleshooting Bad WUs Ӂ Troubleshooting Server Connectivity Issues
Now ↞ Very Soon ↔ Soon ↔ Soon-ish ↔ Not Soon ↠ End Of Time
Welcome To The F@H Support Forum Ӂ Troubleshooting Bad WUs Ӂ Troubleshooting Server Connectivity Issues
Re: Suggestion for handling ERROR 0x0
Yes true. Modification on the server and client code. So the client can send the needed information about ERROR 0x0.
Regarding reporting the error, the donor can only report it IF he/she notice it. It doesn't solve the problem if the client running on headless Machine or if the machine is being left out for a while. Say, if the donor not touching his/her PC for days.
And, i am guessing there are sysadmin out there running F@H at non-busy/non-critical server. Or even on dozens/hundreds workstations on some company. Say, the sysadmin run it on dozens of windows XP machine as a service. Imagine the time (and hassle) he/she need it just for finding whether any of that machine is doing bad WU over and over again.
Regarding reporting the error, the donor can only report it IF he/she notice it. It doesn't solve the problem if the client running on headless Machine or if the machine is being left out for a while. Say, if the donor not touching his/her PC for days.
And, i am guessing there are sysadmin out there running F@H at non-busy/non-critical server. Or even on dozens/hundreds workstations on some company. Say, the sysadmin run it on dozens of windows XP machine as a service. Imagine the time (and hassle) he/she need it just for finding whether any of that machine is doing bad WU over and over again.