...
I set my write to disk option for 600 seconds. Looking in the main boinc directory, the client_state.xml and client_state_prev.xml are updating at an interval varying between 3 and 5 seconds. In the slots directories (HT so there are 2 instances running), each slot's Fstat.out.ckp file is updating at varying intervals of 2 to 4 seconds...
I'm running Intel P4 w/HT XP/SP2 3GHz and specified in preferences to update every 3 minutes. Have been running Albert WUs (8-hrs length)for some time. Client_State.xml and Prev..xml as well as chkp files in both einstein slots update every 3 minutes as specified. Lucky me.
...
I set my write to disk option for 600 seconds. Looking in the main boinc directory, the client_state.xml and client_state_prev.xml are updating at an interval varying between 3 and 5 seconds. In the slots directories (HT so there are 2 instances running), each slot's Fstat.out.ckp file is updating at varying intervals of 2 to 4 seconds...
I'm running Intel P4 w/HT XP/SP2 3GHz and specified in preferences to update every 3 minutes. Have been running Albert WUs (8-hrs length)for some time. Client_State.xml and Prev..xml as well as chkp files in both einstein slots update every 3 minutes as specified. Lucky me.
Yeah, it seems that it's specific to the linux version of albert. And may only be happening in certain linux kernels, though of the three people reporting it here the 2.4 and 2.6 kernels are represented.
Have same continuous 5 second disk access on all 3 Mandriva, 2005LE and 2006.0, systems when Albert is running. Have General Preferences set to 60 seconds for disk updating. Looking in boinc directory client_state_prev.xml and client_state.xml are modifed every minute. In slots/0 Fstat.out.ckp is shown as modified every minute and in projects the wu r1_1112.5__1343_s4r2a_0_0 is shown as being modified every minute. These are the only files I have seen being updated so far. Boinc is running in my home directory so don't think it necessary to look elsewhere.
Have same continuous 5 second disk access on all 3 Mandriva, 2005LE and 2006.0, systems when Albert is running. Have General Preferences set to 60 seconds for disk updating. Looking in boinc directory client_state_prev.xml and client_state.xml are modifed every minute. In slots/0 Fstat.out.ckp is shown as modified every minute and in projects the wu r1_1112.5__1343_s4r2a_0_0 is shown as being modified every minute. These are the only files I have seen being updated so far. Boinc is running in my home directory so don't think it necessary to look elsewhere.
As a follow up changed General Prefs to 300 sec for disk updating (taking a que from Bruce). Did an update and verified update in messages. Same files are being modified when Albert is running at one minte intervals except I now have a different wu r1_1112.5__1337s4r2a_1_0 and as before Fstat.out.ckp, client_state_prev.xml, and client_state.xml.
There's a new version of the Linux app being sent out now - but still no word from the staff...
I don't know what all the new app may address, but I just got some new work that uses it (albert 4.40) and the disk writes are now working at the proper time interval to match my preferences.
The problem with the Linux version of the albert application writing to disk more frequently than set by user preferences has been fixed. A new Linux version of the app (4.40) is now being distributed which fixes this.
For the technically-inclined, this was a nasty bug in the interface between the BOINC API library and the Einstein application. A API function called boinc_is_standalone() was returning a boolean value, but the API header file declared it to return an integer. It took a number of hours to track this down!
Hello!
I have been out of all boincing and internet for almost a week, had to change isp, and missed some deadlines on several projects! I just wonder is not these Albert wu's compatible with my beta application namely Einstein 0.18, which runs on host 4683? I have tried to reset the project , but no new workun it's came this way.
Is it planned to go back to "old" einstein wu's some time ; as far as I have read Albert's are here to stay!!
Ignore this thread just found out via this thread( http://einsteinathome.org/node/189383 ) I have to rename app_info.xml and restart boinc to get Alberts!!
no problems here downloading/crunching alberts. they take less time than the other WUs so i claim less credit.
BUT the computer I am paired with (well, it has been sent most of the alberts i have had) hasn't returned their alberts yet, so i must wait for credit.... grr
RE: For me it looks like
)
I have the same problem, initiated a thread about it in the Problems and Bug reports forum:
http://einsteinathome.org/node/190524
It bugs me quite a bit, hope someone has a solution.
Greetings, Mr Ragnar Schroder
RE: ... I set my write to
)
I'm running Intel P4 w/HT XP/SP2 3GHz and specified in preferences to update every 3 minutes. Have been running Albert WUs (8-hrs length)for some time. Client_State.xml and Prev..xml as well as chkp files in both einstein slots update every 3 minutes as specified. Lucky me.
RE: RE: ... I set my
)
Yeah, it seems that it's specific to the linux version of albert. And may only be happening in certain linux kernels, though of the three people reporting it here the 2.4 and 2.6 kernels are represented.
Have same continuous 5 second
)
Have same continuous 5 second disk access on all 3 Mandriva, 2005LE and 2006.0, systems when Albert is running. Have General Preferences set to 60 seconds for disk updating. Looking in boinc directory client_state_prev.xml and client_state.xml are modifed every minute. In slots/0 Fstat.out.ckp is shown as modified every minute and in projects the wu r1_1112.5__1343_s4r2a_0_0 is shown as being modified every minute. These are the only files I have seen being updated so far. Boinc is running in my home directory so don't think it necessary to look elsewhere.
RE: Have same continuous 5
)
As a follow up changed General Prefs to 300 sec for disk updating (taking a que from Bruce). Did an update and verified update in messages. Same files are being modified when Albert is running at one minte intervals except I now have a different wu r1_1112.5__1337s4r2a_1_0 and as before Fstat.out.ckp, client_state_prev.xml, and client_state.xml.
There's a new version of the
)
There's a new version of the Linux app being sent out now - but still no word from the staff...
RE: There's a new version
)
I don't know what all the new app may address, but I just got some new work that uses it (albert 4.40) and the disk writes are now working at the proper time interval to match my preferences.
The problem with the Linux
)
The problem with the Linux version of the albert application writing to disk more frequently than set by user preferences has been fixed. A new Linux version of the app (4.40) is now being distributed which fixes this.
For the technically-inclined, this was a nasty bug in the interface between the BOINC API library and the Einstein application. A API function called boinc_is_standalone() was returning a boolean value, but the API header file declared it to return an integer. It took a number of hours to track this down!
Director, Einstein@Home
Hello! I have been out of all
)
Hello!
I have been out of all boincing and internet for almost a week, had to change isp, and missed some deadlines on several projects! I just wonder is not these Albert wu's compatible with my beta application namely Einstein 0.18, which runs on host 4683? I have tried to reset the project , but no new workun it's came this way.
Is it planned to go back to "old" einstein wu's some time ; as far as I have read Albert's are here to stay!!
Ignore this thread just found out via this thread( http://einsteinathome.org/node/189383 ) I have to rename app_info.xml and restart boinc to get Alberts!!
With regards and keep up the good work !!
no problems here
)
no problems here downloading/crunching alberts. they take less time than the other WUs so i claim less credit.
BUT the computer I am paired with (well, it has been sent most of the alberts i have had) hasn't returned their alberts yet, so i must wait for credit.... grr
***
Nothing is impossible