There are currently two problems with the LAT search that I'm aware of … and the second is a cross-platform validation problem between Macs and the other platforms.
Any news on that? I was quite excited this morning to see that my Mac had finally had a LAT result validated, but it turned out it had sided with another Mac against a Windows machine.
We are still tuning the validator, and I am working on a change to the application that should make it a little bit faster but with the side effect of narrowing down the differences between platforms.
Would it help to make sure that all copies of a particular workunit are sent only to computers with the same operating system?
In BOINC this concept is called "homogenous redundancy". A project can be configured to use this, but then this applies to all applications of the project.
Would it help to make sure that all copies of a particular workunit are sent only to computers with the same operating system?
Yes, it will help to reduce the number of validation errors. But this way it will produce different results on different machines that cannot be compared normally. And yet we don't know which OS produces wrong results. So, there is no other way than to find the reason of validation errors. But it needs some time to.
We are still tuning the validator, and I am working on a change to the application that should make it a little bit faster but with the side effect of narrowing down the differences between platforms.
BM
This should have been done now with the new app version 23 shipped today.
We are still tuning the validator, and I am working on a change to the application that should make it a little bit faster but with the side effect of narrowing down the differences between platforms.
BM
This should have been done now with the new app version 23 shipped today.
BM
I have had the 0.22 version running on a number of Linux hosts as well as on a single host running Win XP. The performance on Windows has been quite bad compared to that on Linux for the same hardware.
I have just finished converting all the above machines to the 0.23 version. The first results with the new version are now in and the linux hosts are showing a speedup of around 15% or so. The time on one quad core host has dropped from around 27K secs to less than 23K secs.
The improvement on Windows seems to be even better. That machine is a dual core and it was completing tasks in around 37K secs. It is now completing results in around 25K secs with the 0.23 version. Linux hosts of pretty much identical specs had been completing tasks in around 26K secs with the old version. One of these is on track to complete its first 0.23 result in around 22K secs so there is still an advantage for Linux, althought very much reduced from what it was.
Thanks very much for the very useful speedup. I hope you also get the desired result for validation improvement as well.
I suspect that most of your machines are powered by AMD CPUs? I did see larger speedups on our Intel machines here, as well as in the DB of the runtime averaged over all hosts.
Anyway, preparing for "production" we increased the deadline (10 days) and are ramping up the FGRP1 share of the project (i.e. sending out more FGRP work).
I'm only running Windows on Intel here, but I'd noticed that very significant speedup with 0.23 - I can pull out figures if it helps, but I'd guess you have plenty available.
I'm still seeing FGRP1 taking ~30% longer than S6Bucket on all machines (I'm running SSE2 minimum, mainly Core2 or above, so can take advantage of the optimisation).
The extended deadline is welcome - 0.22 took over two days on my elderly P4 server, pushing it into EDF. Perhaps you might consider the credit ratio as part of the tuning process.
Bikeman wrote:There are
)
Any news on that? I was quite excited this morning to see that my Mac had finally had a LAT result validated, but it turned out it had sided with another Mac against a Windows machine.
http://einsteinathome.org/workunit/103074788
NG
We are still tuning the
)
We are still tuning the validator, and I am working on a change to the application that should make it a little bit faster but with the side effect of narrowing down the differences between platforms.
BM
BM
Would it help to make sure
)
Would it help to make sure that all copies of a particular workunit are sent only to computers with the same operating system?
RE: Would it help to make
)
In BOINC this concept is called "homogenous redundancy". A project can be configured to use this, but then this applies to all applications of the project.
BM
BM
RE: Would it help to make
)
Yes, it will help to reduce the number of validation errors. But this way it will produce different results on different machines that cannot be compared normally. And yet we don't know which OS produces wrong results. So, there is no other way than to find the reason of validation errors. But it needs some time to.
RE: We are still tuning the
)
This should have been done now with the new app version 23 shipped today.
BM
BM
I validated a second gamma
)
I validated a second gamma ray unit on my Linux box against a Windows 7, using version 22. Another one is running on version 23
Tullio
RE: RE: We are still
)
I have had the 0.22 version running on a number of Linux hosts as well as on a single host running Win XP. The performance on Windows has been quite bad compared to that on Linux for the same hardware.
I have just finished converting all the above machines to the 0.23 version. The first results with the new version are now in and the linux hosts are showing a speedup of around 15% or so. The time on one quad core host has dropped from around 27K secs to less than 23K secs.
The improvement on Windows seems to be even better. That machine is a dual core and it was completing tasks in around 37K secs. It is now completing results in around 25K secs with the 0.23 version. Linux hosts of pretty much identical specs had been completing tasks in around 26K secs with the old version. One of these is on track to complete its first 0.23 result in around 22K secs so there is still an advantage for Linux, althought very much reduced from what it was.
Thanks very much for the very useful speedup. I hope you also get the desired result for validation improvement as well.
Cheers,
Gary.
Welcome back, Gary! I
)
Welcome back, Gary!
I suspect that most of your machines are powered by AMD CPUs? I did see larger speedups on our Intel machines here, as well as in the DB of the runtime averaged over all hosts.
Anyway, preparing for "production" we increased the deadline (10 days) and are ramping up the FGRP1 share of the project (i.e. sending out more FGRP work).
BM
BM
Indeed, welcome back,
)
Indeed, welcome back, Gary.
I'm only running Windows on Intel here, but I'd noticed that very significant speedup with 0.23 - I can pull out figures if it helps, but I'd guess you have plenty available.
I'm still seeing FGRP1 taking ~30% longer than S6Bucket on all machines (I'm running SSE2 minimum, mainly Core2 or above, so can take advantage of the optimisation).
The extended deadline is welcome - 0.22 took over two days on my elderly P4 server, pushing it into EDF. Perhaps you might consider the credit ratio as part of the tuning process.