After "downgrading" to 4.27 I get the following messages in my logfile:
You don't happen to have those bad tags in your 4.27 app_info.xml file do you by any chance?
No, I suspended all WUs, switched to "no network" and allowed the 64Bit app just 2 of them, so the remaining are still branded for 4.27. I installed the original app_info.xml and even modified it to direct any 4.28 WU(which I don't have) to 4.27. :-(
I had made a backup of my BOINC folder, so the last I can do is to restore the folder when all WUs are finished, kill the WUs of the backup und hope for new work.
But I would rather understand what is going on!
I never really got this WU, but it's already over with no reply!?
There must be a bad daemon around here...
ok, I know the reason why. ;-)
Is it possible that the server cancelled the task before the client had begun crunching it because the original wingman finally did submit something after all?
After "downgrading" to 4.27 I get the following messages in my logfile:
You don't happen to have those bad tags in your 4.27 app_info.xml file do you by any chance?
I don't believe it! That was the reason!
I'm a bit tired, so I first didn't understand what you meant. :(
Should have taken the files from the backup instead from the package.
Is it possible that the server cancelled the task before the client had begun crunching it because the original wingman finally did submit something after all?
CU
Bikeman
YES! :-)
Still a feature of the server I didn't know.
After "downgrading" to 4.27 I get the following messages in my logfile:
2008-02-11 09:51:50 [Einstein@Home] Sending scheduler request: To fetch work
2008-02-11 09:51:50 [Einstein@Home] Requesting 360288 seconds of new work
2008-02-11 09:52:00 [Einstein@Home] Scheduler RPC succeeded [server version 601]
2008-02-11 09:52:00 [Einstein@Home] Message from server: Resent lost result h1_0858.75_S5R3__447_S5R3b_0
2008-02-11 09:52:00 [Einstein@Home] Message from server: Resent lost result h1_0763.30_S5R2__140_S5R3a_2
2008-02-11 09:52:00 [Einstein@Home] Message from server: Resent lost result h1_0858.75_S5R3__446_S5R3b_0
2008-02-11 09:52:00 [Einstein@Home] Message from server: Resent lost result h1_0858.75_S5R3__445_S5R3b_0
2008-02-11 09:52:00 [Einstein@Home] Message from server: Resent lost result h1_0858.75_S5R3__444_S5R3b_0
2008-02-11 09:52:00 [Einstein@Home] Message from server: Resent lost result h1_0858.75_S5R3__443_S5R3b_0
2008-02-11 09:52:00 [Einstein@Home] [error] No app version for result: x86_64-pc-linux-gnu -1
2008-02-11 09:52:00 [Einstein@Home] [error] No app version for result: x86_64-pc-linux-gnu -1
2008-02-11 09:52:00 [Einstein@Home] [error] No app version for result: x86_64-pc-linux-gnu -1
2008-02-11 09:52:00 [Einstein@Home] [error] No app version for result: x86_64-pc-linux-gnu -1
2008-02-11 09:52:00 [Einstein@Home] [error] No app version for result: x86_64-pc-linux-gnu -1
2008-02-11 09:52:00 [Einstein@Home] [error] No app version for result: x86_64-pc-linux-gnu -1
2008-02-11 09:52:00 [Einstein@Home] Deferring communication for 6 min 28 sec
2008-02-11 09:52:00 [Einstein@Home] Reason: no work from project
This has happened a couple of times already.
cu,
Michael
I had the same after downgrading to 4.21 with these WU1 and WU2. Both WU's was crunched completly within 12hours but i forget to report them and both units gone to /dev/null.
But no problem, Einstein resent both tasks and i could crunch again in 10hours... Not bad for an E6320 ;-)
After "downgrading" to 4.27 I get the following messages in my logfile:
You don't happen to have those bad tags in your 4.27 app_info.xml file do you by any chance?
I don't believe it! That was the reason!
I'm a bit tired, so I first didn't understand what you meant. :(
I'm sorry, I was a bit lazy and didn't go search out the actual messages when the bad tag problem first came up. I should have at least put the full problem line
windows_intelx86
into my reply as that might have been more of a prompt to you. The word "windows" as part of a platform description in a Linux app_info file, well .... :).
After "downgrading" to 4.27 I get the following messages in my logfile:
....
I had the same after downgrading to 4.21 with these WU1 and WU2. Both WU's was crunched completly within 12hours but i forget to report them and both units gone to /dev/null.
But no problem, Einstein resent both tasks and i could crunch again in 10hours... Not bad for an E6320 ;-)
The outcome (ie tasks being resent) might have been similar but the cause (ie what caused your work to be thrown away) would have been rather different since there were no bad tags before version 4.27.
In your case, I'm guessing that when you reverted to 4.21, you didn't add an entry to your app_info.xml for 4.21 which allowed any later versions than 4.21 to be crunched by that earlier version. Even if you don't appear to have later version work in your cache it's still a good idea to just put in a couple of lines which says that it's OK for 4.xx work to be crunched by 4.21 and that would have allowed your 'ready to report' tasks to have been reported and not discarded.
When you think about it, downgrading can be quite tricky.
You seem to have been downgrading from 4.28 where you had that quite slow result. I notice that you were using 4.27 immediately before the 4.28 result. Any particular reason for going back to 4.21 rather than 4.27?
.....
The outcome (ie tasks being resent) might have been similar but the cause (ie what caused your work to be thrown away) would have been rather different since there were no bad tags before version 4.27.
In your case, I'm guessing that when you reverted to 4.21, you didn't add an entry to your app_info.xml for 4.21 which allowed any later versions than 4.21 to be crunched by that earlier version. Even if you don't appear to have later version work in your cache it's still a good idea to just put in a couple of lines which says that it's OK for 4.xx work to be crunched by 4.21 and that would have allowed your 'ready to report' tasks to have been reported and not discarded.
When you think about it, downgrading can be quite tricky.
You seem to have been downgrading from 4.28 where you had that quite slow result. I notice that you were using 4.27 immediately before the 4.28 result. Any particular reason for going back to 4.21 rather than 4.27?
Yes i forgot to write something in the app_info.xml but no problem work was resent from einstein-server.
4.27/4.28 are only for testing my linux-distro to be compatible with it and the possebility to crunch in 64bit-mode.
4.21 had in my configuration with socks5-proxy no further problems with lost network-access and runs like hell, too.
RE: After "downgrading" to
)
You don't happen to have those bad tags in your 4.27 app_info.xml file do you by any chance?
Cheers,
Gary.
RE: RE: After
)
No, I suspended all WUs, switched to "no network" and allowed the 64Bit app just 2 of them, so the remaining are still branded for 4.27. I installed the original app_info.xml and even modified it to direct any 4.28 WU(which I don't have) to 4.27. :-(
I had made a backup of my BOINC folder, so the last I can do is to restore the folder when all WUs are finished, kill the WUs of the backup und hope for new work.
But I would rather understand what is going on!
cu,
Michael
This is even
)
This is even better:
http://einsteinathome.org/workunit/36729166
I never really got this WU, but it's already over with no reply!?
There must be a bad daemon around here...
ok, I know the reason why. ;-)
RE: This is even
)
Is it possible that the server cancelled the task before the client had begun crunching it because the original wingman finally did submit something after all?
CU
Bikeman
RE: RE: After
)
I don't believe it! That was the reason!
I'm a bit tired, so I first didn't understand what you meant. :(
Should have taken the files from the backup instead from the package.
Thanks,
Michael
RE: Is it possible that the
)
YES! :-)
Still a feature of the server I didn't know.
cu,
Michael
RE: After "downgrading" to
)
I had the same after downgrading to 4.21 with these WU1 and WU2. Both WU's was crunched completly within 12hours but i forget to report them and both units gone to /dev/null.
But no problem, Einstein resent both tasks and i could crunch again in 10hours... Not bad for an E6320 ;-)
RE: RE: RE: After
)
I'm sorry, I was a bit lazy and didn't go search out the actual messages when the bad tag problem first came up. I should have at least put the full problem line
windows_intelx86into my reply as that might have been more of a prompt to you. The word "windows" as part of a platform description in a Linux app_info file, well .... :).I'm glad you sorted it out :).
Cheers,
Gary.
RE: RE: After
)
The outcome (ie tasks being resent) might have been similar but the cause (ie what caused your work to be thrown away) would have been rather different since there were no bad tags before version 4.27.
In your case, I'm guessing that when you reverted to 4.21, you didn't add an entry to your app_info.xml for 4.21 which allowed any later versions than 4.21 to be crunched by that earlier version. Even if you don't appear to have later version work in your cache it's still a good idea to just put in a couple of lines which says that it's OK for 4.xx work to be crunched by 4.21 and that would have allowed your 'ready to report' tasks to have been reported and not discarded.
When you think about it, downgrading can be quite tricky.
You seem to have been downgrading from 4.28 where you had that quite slow result. I notice that you were using 4.27 immediately before the 4.28 result. Any particular reason for going back to 4.21 rather than 4.27?
Cheers,
Gary.
RE: ..... The outcome (ie
)
Yes i forgot to write something in the app_info.xml but no problem work was resent from einstein-server.
4.27/4.28 are only for testing my linux-distro to be compatible with it and the possebility to crunch in 64bit-mode.
4.21 had in my configuration with socks5-proxy no further problems with lost network-access and runs like hell, too.