...I hope the reason for the slowness of the AMD/Linux combo can be identified quickly.
Indeed, but it's not just AMD/Linux, my Intel/Linux box is also showing a loss in performance of about 5% (incomplete WU's). It looks like crunch times for XP and Linux on my host are now about even, with Linux maybe still being a bit faster.
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
...Intel/Linux box is also showing a loss in performance of about 5% ...
Yes, same as my PIIIs. Because of things like extra debugging code and other testing related things that my be causing a small performance hit, I'm basically ignoring those small <5% slowdowns. A 20%+ hit is a different kettle of fish :).
I'm moving a few Williamette/Northwood early P4s (running Windows) to the beta app to see how they go. I should have done them instead of the laptop earlier in the week.
...Intel/Linux box is also showing a loss in performance of about 5% ...
Yes, same as my PIIIs. Because of things like extra debugging code and other testing related things that my be causing a small performance hit, I'm basically ignoring those small <5% slowdowns. A 20%+ hit is a different kettle of fish :).
I'm moving a few Williamette/Northwood early P4s (running Windows) to the beta app to see how they go. I should have done them instead of the laptop earlier in the week.
[Linux beta app]Good point, the 5% loss could very well be attributed to the increase in debugging code. The 20% loss on your hosts sounds more like a problem with the math, maybe (I'm no little to nothing about coding and CPU extensions) SSE is not being properly utilized?[/Linux beta app]
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
There is one interesting consequence of doing what I have just posted.
Quote:
16/07/2007 8:28:57 PM||file projects/einstein.phys.uwm.edu/einstein_S5R2_4.17_windows_intelx86.exe not found
16/07/2007 8:28:57 PM||file projects/einstein.phys.uwm.edu/einstein_S5R2_4.17_windows_intelx86.pdb not found
In fact, when I look in the project folder *all* previous executables seem to have disappeared. Even the 4.24 app is gone so it looks like there's no going back :).
Well, the BOINC client is rather eager to delete files that he thinks are no longer needed. I thought that the file entries at the beginning of the app_info.xml should prevent the older App versions from being deleted (and just issue the warning you mentioned if they have already been deleted earlier), but apparently that's not the case; in fact it looks like it has the opposite effect.
I've now gone to the trouble of comparing your app_info.xml with the one I used at the time of the 4.17 -> 4.24 transition and I can confirm that creating those file entries at the beginning (as you mention) does seem to lead to the deletion of the earlier executables, including 4.24. I've just started transferring more boxes to the beta app but this time using my own app_info.xml which only has the one executable (4.28) listed between the tags. The second half of the file which says that results for 4.17, 4.24 or 4.28 can all be crunched by 4.28 is exactly the same as yours.
So I now get no warning messages about missing executables and no deletion of those old versions. For my purposes, with potentially a large number of boxes that could be switched to the beta app, I don't want the bandwidth penalty (ie having to redownload 4.24 many times) if I decide to go back to the previous version for any reason :).
EDIT: Sorry for misleading people by posting something without fully checking first. In the above paragraph I said that there was no deletion of the old executables. I assumed this without checking because there were no warnings of missing executables. However all the previous executables, including 4.24, did get deleted. This clearing of old exes must be a new feature in newer versions of BOINC as I didn't see this when using 5.4.x previously.
On a related note, I'll bring up another aspect of changing the science app that affects people with numbers of computers on a LAN. I know this should be discussed on a BOINC forum rather than here but I'll see what reaction I get here before I frame my post over there.
When the science app changes, all LAN machines download their own personal copy from central command :). This is a waste of bandwidth if each individual machine could have a preference setting that simply said "Check a LAN server first to see if the new app is there. If it is, grab the local copy. If not, download a copy from Central Command and also put a copy on the local server.
I realise that I can deploy the new app with a simple script anyway. The disadvantage of that is that you have to know that there is a new app in the first place and you have to be quick off the mark or the machines will download and beat you to it :). It would be nice if it were fully automatic.
On a related note, I'll bring up another aspect of changing the science app that affects people with numbers of computers on a LAN. I know this should be discussed on a BOINC forum rather than here but I'll see what reaction I get here before I frame my post over there.
When the science app changes, all LAN machines download their own personal copy from central command :). This is a waste of bandwidth if each individual machine could have a preference setting that simply said "Check a LAN server first to see if the new app is there. If it is, grab the local copy. If not, download a copy from Central Command and also put a copy on the local server.
I realise that I can deploy the new app with a simple script anyway. The disadvantage of that is that you have to know that there is a new app in the first place and you have to be quick off the mark or the machines will download and beat you to it :). It would be nice if it were fully automatic.
If I had a rather big LAN so that this becomes an issue, I'd go for a caching http-proxy, maybe, just for the BOINC clients. Would have the same effect without much administration work.
I realise that I can deploy the new app with a simple script anyway. The disadvantage of that is that you have to know that there is a new app in the first place and you have to be quick off the mark or the machines will download and beat you to it :). It would be nice if it were fully automatic.
We distribute the files (data files and Apps, too IIRC) with a list of sites where these files are availble, i.e. our download mirrors. The order of the list you get, however, depends on the timezone your machine is set to, so it should list the nearest server first.
In principle we could issue a first line referring to, say, a local download mirrot the client would then look at first (say einstein-download.local). If you have a local DNS server or proxy you could point it to a local mirror for your LAN. But I'm not sure this wouldn't cause security or bandwith issues. I'll probably need to think about it.
This is my first result using v4.28. It is a hybrid that was crunched about 15% by v4.24 and about 85% by v4.28. There were no problems making the transition. And, since the DB has already deleted my previous results, I can't compare processing times. However, my "gut feeling" says there wasn't much difference.
Looking at the stderr_txt, I was surprised by where the line "Start of BOINC application 'projects/einstein.phys.uwm.edu/einstein_S5R2_4.28_windows_intelx86.exe'." appears amongst the "string of numbers". That is, I was expecting the line to be inserted at a point that was (more or less) proportional to the amount of time crunched by each application. But, that is definitely not the case.
RE: ...I hope the reason
)
Indeed, but it's not just AMD/Linux, my Intel/Linux box is also showing a loss in performance of about 5% (incomplete WU's). It looks like crunch times for XP and Linux on my host are now about even, with Linux maybe still being a bit faster.
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
RE: ...Intel/Linux box is
)
Yes, same as my PIIIs. Because of things like extra debugging code and other testing related things that my be causing a small performance hit, I'm basically ignoring those small <5% slowdowns. A 20%+ hit is a different kettle of fish :).
I'm moving a few Williamette/Northwood early P4s (running Windows) to the beta app to see how they go. I should have done them instead of the laptop earlier in the week.
Cheers,
Gary.
RE: RE: ...Intel/Linux
)
[Linux beta app]Good point, the 5% loss could very well be attributed to the increase in debugging code. The 20% loss on your hosts sounds more like a problem with the math, maybe (I'm no little to nothing about coding and CPU extensions) SSE is not being properly utilized?[/Linux beta app]
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
RE: RE: There is one
)
I've now gone to the trouble of comparing your app_info.xml with the one I used at the time of the 4.17 -> 4.24 transition and I can confirm that creating those file entries at the beginning (as you mention) does seem to lead to the deletion of the earlier executables, including 4.24. I've just started transferring more boxes to the beta app but this time using my own app_info.xml which only has the one executable (4.28) listed between the tags. The second half of the file which says that results for 4.17, 4.24 or 4.28 can all be crunched by 4.28 is exactly the same as yours.
So I now get no warning messages about missing executables and no deletion of those old versions. For my purposes, with potentially a large number of boxes that could be switched to the beta app, I don't want the bandwidth penalty (ie having to redownload 4.24 many times) if I decide to go back to the previous version for any reason :).
EDIT: Sorry for misleading people by posting something without fully checking first. In the above paragraph I said that there was no deletion of the old executables. I assumed this without checking because there were no warnings of missing executables. However all the previous executables, including 4.24, did get deleted. This clearing of old exes must be a new feature in newer versions of BOINC as I didn't see this when using 5.4.x previously.
Cheers,
Gary.
On a related note, I'll bring
)
On a related note, I'll bring up another aspect of changing the science app that affects people with numbers of computers on a LAN. I know this should be discussed on a BOINC forum rather than here but I'll see what reaction I get here before I frame my post over there.
When the science app changes, all LAN machines download their own personal copy from central command :). This is a waste of bandwidth if each individual machine could have a preference setting that simply said "Check a LAN server first to see if the new app is there. If it is, grab the local copy. If not, download a copy from Central Command and also put a copy on the local server.
I realise that I can deploy the new app with a simple script anyway. The disadvantage of that is that you have to know that there is a new app in the first place and you have to be quick off the mark or the machines will download and beat you to it :). It would be nice if it were fully automatic.
Cheers,
Gary.
RE: On a related note, I'll
)
If I had a rather big LAN so that this becomes an issue, I'd go for a caching http-proxy, maybe, just for the BOINC clients. Would have the same effect without much administration work.
CU
H-BE
RE: I realise that I can
)
We distribute the files (data files and Apps, too IIRC) with a list of sites where these files are availble, i.e. our download mirrors. The order of the list you get, however, depends on the timezone your machine is set to, so it should list the nearest server first.
In principle we could issue a first line referring to, say, a local download mirrot the client would then look at first (say einstein-download.local). If you have a local DNS server or proxy you could point it to a local mirror for your LAN. But I'm not sure this wouldn't cause security or bandwith issues. I'll probably need to think about it.
BM
BM
This is my first result using
)
This is my first result using v4.28. It is a hybrid that was crunched about 15% by v4.24 and about 85% by v4.28. There were no problems making the transition. And, since the DB has already deleted my previous results, I can't compare processing times. However, my "gut feeling" says there wasn't much difference.
Looking at the stderr_txt, I was surprised by where the line "Start of BOINC application 'projects/einstein.phys.uwm.edu/einstein_S5R2_4.28_windows_intelx86.exe'." appears amongst the "string of numbers". That is, I was expecting the line to be inserted at a point that was (more or less) proportional to the amount of time crunched by each application. But, that is definitely not the case.
Please try out the new Beta
)
Please try out the new Beta 4.30.
BM
BM
Seams to work but very slow
)
Seams to work but very slow on AMD\\Windows, 87% after 20 hours, seams that Einstein is an Intel aplication.