This is a transient problem that occurs when the DB queries the page makes take longer than the PHP timeout. The pages ends up incomplete in the cache.
This is a problem not introduced by the web update, we'll work on improving the server status page soon anyway.
On the list of computers under my account there is a column on the right labelled "last contact". This seems to have a link, but when I click on it it tried to open http://einstein.phys.uwm.edu/sched_logs/2010-06-09_10/2010-06-09_10:44.txt which isn't found. There is a similar link on the computers detail page.
On Seti and GPUgrid this column isn't a link but just a date/time, that is you can't click on it.
The RSS feed for the news on the home page seems to be as of the 31st (last item is the running out of space). I'm not sure if is meant to update automatically or not.
The "last contact" link is a speciality of Einstein@home. It used to show the scheduler log of the last contact of the machine. This feature has been disabled due to the high I/O load it caused on the server. We're working on a replacement.
The project preferences page is suffering from a translation bug which also afflicted CPDN when they updated their web code last week. Seems like it's probably in the shared translation files.
This is the same (second) iten on the Einstein preference page, in German and then in English:
Quote:
Ausführung auf Grafikkarte anhalten wenn der Computer benutzt wird?
Unterstützt ab Version 6.7 aufwärts ja
Hm. I fixed the German translation file (locally) as much as I could, should be better now. But I'm not familiar enough with the other languages, and with the translation service in general to fix this in BOINC.
At me ist works fine, as far I can see now.
But I was hoping the page "All Tasks for "user"" become further improved, so that one can sort the lines in regard to the different collums, as it can be done in BOINC Statistics. Until now they are fixed sorted in regard to the Wokunit ID. That would be helpful for my own statistics.
For the "Server Status Page" I like to suggest, to sort the fields in the second collumn by actuallity. At now the "S5GC1 search progress" should become the top field, and "Previous searches" the lowest one.
Bernd, thank you for correcting the errors in the German translation of the Computing and Project preferences of members' accounts.
CPDN upgraded its Boinc version last week and has the same problem with three items in the German translation. I have listed your changes and asked Milo to change the same items for CPDN using your translations.
I've also posted on the boinc_loc email list to say that the Boinc generic German translation file needs to be updated by a volunteer.
But I was hoping the page "All Tasks for "user"" become further improved, so that one can sort the lines in regard to the different collums, as it can be done in BOINC Statistics.
Well, we had enough to do bringing the web code up to date with current BOINC. We don't have much time to drive the development on the web code further that what BOINC currently offers.
There's one feature I added, though, that's currently hidden. If you add "&show_hosts=1" to the URL of the "Tasks" page, you'll see the hostids (with links), too. For me and probably others with a lot of hosts it's useful to see where e.g. the client errors do happen, but there might be a good reason why this is not BOINC standard. So for now I leave it that way.
Up to the Jul 27th one could calculate the "Fraction completet" by (Time pocessed)/(Total survey observation time). But yesterday morning it jumped up to nearly dubble that value, from 23.74% to 47.20%. What´s the new reference?
There are two more breaks concerning "Average data taking rate" and "Percentage of data taking rate". "Progress rate today" is ok. I hope to find time later today to discribe this, as it is a bit more complicated.
until recently we used an imprecise estimate of how much work was done for the ABP search. For this I pulled the information of how much telescope time was used for the survey with the Arecibo telescope from an official website. I compared this to the amount of observation time equivalent the Einstein@Home clients had already processed. Dividing the latter by the first gave then an estimate of how much was processed.
This however did not take into account how much of the total telescope time was spent in observing mode. The telescope has to slew from sky position to sky position and there's also calibration time at the beginning of the observation.
The new reference now fixes that. We now have a complete list of all observations done that qualify for processing by Einstein@Home. Each sky position pointing with Arecibo yields a set of seven "beams" (because the receiver / radio camera has seven feed horns: it's a seven-pixel camera). Now, the number of beams processed is compared to the total number of beams available. Accordingly the stats in the table for the daily amount of work done are computed in "beams/day".
"Average data taking rate" is now also in beams per day; it's computed by dividing the number of beams collected in total by the stretch of time over which they were acquired. And since the old estimate didn't take into account slew/calibration time, the "Percentage of data taking rate" also goes up.
Hallo Benjamin!
Thanks for your answer!
My question is: Is it possible to link the data published until yesterday morning with the data since yesterday midday?
Yesterday(UTC)____________9:40______ ________12:45
Average data taking rate ____44,13[min/day] ______48,80[beams/day]
Progress rate today ________41,78[min/day] ______65,36[beams/day]
( The data for ABPS become once a day in the morning updated. Unfortunately there is no timestamp, from when the date are taken.)
If you take (Progress rate today) 65,36/41,78 = 1,5644[beams/min]. This is very accurate the value one can derive from the data published until yesterday morning: 1,5645[beams/min] = 38,350[sec/beam]. Is this just luck ???
The factor for "Average data taking rate" is clearly smaller 48,80/44,13 = 1,1058[beams/min]. This explains, why the "Percentage of data taking rate" jumped from 94,67% up to 133,93%.
Are this factors further and/or backward valid?
If you take (Progress rate today) 65,36/41,78 = 1,5644[beams/min]. This is very accurate the value one can derive from the data published until yesterday morning: 1,5645[beams/min] = 38,350[sec/beam]. Is this just luck ???
Nope, this is related. One beam is 268.5 seconds long.
Quote:
The factor for "Average data taking rate" is clearly smaller 48,80/44,13 = 1,1058[beams/min]. This explains, why the "Percentage of data taking rate" jumped from 94,67% up to 133,93%.
Are this factors further and/or backward valid?
For data taking rate there are some other factors that have to be taken into account, so there's no backwards compatibility here. But our webpage's history is exact all the way back. I will update the webpage soon to show the progress on the anti-center search correctly.
I've updated our progress page. This now also includes the progress from the search on "anti-center" data. These are pointings with the Arecibo telescope that aim away from the Galactic center in contrast to all the observations we've processed so far. Therefore, there's also a new set of plots showing the sky region covered by the anti-center search and our progress in color code.
While I was updating the page I've also made all the numbers on the progress table based on the number of beams processed, getting rid of all time equivalents. One Arecibo pointing consists of seven beams (the seven feed horns of the receiver / radio camera). Each grey point in the sky maps is one pointing (a set of these seven beams).
Comments
The server status page lots
)
The server status page lots its layout/formatting and is showing data in a single column of tables.
The 'Community - Languages'
)
The 'Community - Languages' link is broken:
"../languages/compiled/" is not a directory. Please consult the documentation for correctly setting up the translation system.
Welcome To Team China!
This is a transient problem
)
This is a transient problem that occurs when the DB queries the page makes take longer than the PHP timeout. The pages ends up incomplete in the cache.
This is a problem not introduced by the web update, we'll work on improving the server status page soon anyway.
BM
BM
RE: "../languages/compiled/
)
The directory was missing. I crated it. Could you try again?
BM
BM
RE: RE: "../languages/com
)
The link works (now), but there's only one entry to select:
Use browser language setting
and there's a "foo" line beneath "Language selection".
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
I ran
)
I ran "update_translations.php". Does this work now?
BM
BM
Not sure if it's a bug or
)
Not sure if it's a bug or not; but comment links typically indicate the number of comments people have made.
RE: Does this work
)
Yep, it not only shows the list, it even switches languages ;-) (at least with IE6)
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
RE: Not sure if it's a bug
)
Is there any other BOINC project which does show this?
BM
BM
On the list of computers
)
On the list of computers under my account there is a column on the right labelled "last contact". This seems to have a link, but when I click on it it tried to open http://einstein.phys.uwm.edu/sched_logs/2010-06-09_10/2010-06-09_10:44.txt which isn't found. There is a similar link on the computers detail page.
On Seti and GPUgrid this column isn't a link but just a date/time, that is you can't click on it.
The RSS feed for the news on the home page seems to be as of the 31st (last item is the running out of space). I'm not sure if is meant to update automatically or not.
Thanks for the server s/w update.
BOINC blog
The "last contact" link is a
)
The "last contact" link is a speciality of Einstein@home. It used to show the scheduler log of the last contact of the machine. This feature has been disabled due to the high I/O load it caused on the server. We're working on a replacement.
BM
BM
The project preferences page
)
The project preferences page is suffering from a translation bug which also afflicted CPDN when they updated their web code last week. Seems like it's probably in the shared translation files.
This is the same (second) iten on the Einstein preference page, in German and then in English:
Hm. I fixed the German
)
Hm. I fixed the German translation file (locally) as much as I could, should be better now. But I'm not familiar enough with the other languages, and with the translation service in general to fix this in BOINC.
BM
BM
I'm ready to translate
)
I'm ready to translate anything into Russian. One of my specialities is a translator of technical papers. So, I'm ready help :)
At me ist works fine, as far
)
At me ist works fine, as far I can see now.
But I was hoping the page "All Tasks for "user"" become further improved, so that one can sort the lines in regard to the different collums, as it can be done in BOINC Statistics. Until now they are fixed sorted in regard to the Wokunit ID. That would be helpful for my own statistics.
For the "Server Status Page" I like to suggest, to sort the fields in the second collumn by actuallity. At now the "S5GC1 search progress" should become the top field, and "Previous searches" the lowest one.
Kind regards
Martin
Most of the BOINC projects
)
Most of the BOINC projects which have updated their web pages recently have a standard page footer:
[pre]Home | My Account | Message Boards[/pre]
which is a useful expansion on the "Return to Einstein@Home main page" which we've inherited here.
Where did the top
)
Where did the top participants link go?
Thanks.
Jon
RE: Where did the top
)
It's under Statistics, which is on the front page.
Bernd, thank you for
)
Bernd, thank you for correcting the errors in the German translation of the Computing and Project preferences of members' accounts.
CPDN upgraded its Boinc version last week and has the same problem with three items in the German translation. I have listed your changes and asked Milo to change the same items for CPDN using your translations.
I've also posted on the boinc_loc email list to say that the Boinc generic German translation file needs to be updated by a volunteer.
RE: But I was hoping the
)
Well, we had enough to do bringing the web code up to date with current BOINC. We don't have much time to drive the development on the web code further that what BOINC currently offers.
There's one feature I added, though, that's currently hidden. If you add "&show_hosts=1" to the URL of the "Tasks" page, you'll see the hostids (with links), too. For me and probably others with a lot of hosts it's useful to see where e.g. the client errors do happen, but there might be a good reason why this is not BOINC standard. So for now I leave it that way.
BM
BM
What I miss and what I find
)
What I miss and what I find very useful at other projects is the direct links for "Home | My Account | Message Boards" at the bottom of each page.
(Some have "Home | Project | My Account | Message Boards", but they use a Drupal front).
Like this? BM
)
Like this?
BM
BM
RE: Like
)
That's the one! Thumbs up!
RE: Like this? BM yeah
)
yeah ... but ...
hmmm ... the translation is funny ;-)
RE: Like this? That's
)
That's the spirit. Thanks Bernd. :-)
Conc.: ABPS Search Progress
)
Conc.: ABPS Search Progress Page
Up to the Jul 27th one could calculate the "Fraction completet" by (Time pocessed)/(Total survey observation time). But yesterday morning it jumped up to nearly dubble that value, from 23.74% to 47.20%. What´s the new reference?
There are two more breaks concerning "Average data taking rate" and "Percentage of data taking rate". "Progress rate today" is ok. I hope to find time later today to discribe this, as it is a bit more complicated.
Martin
Hi Martin, until recently
)
Hi Martin,
until recently we used an imprecise estimate of how much work was done for the ABP search. For this I pulled the information of how much telescope time was used for the survey with the Arecibo telescope from an official website. I compared this to the amount of observation time equivalent the Einstein@Home clients had already processed. Dividing the latter by the first gave then an estimate of how much was processed.
This however did not take into account how much of the total telescope time was spent in observing mode. The telescope has to slew from sky position to sky position and there's also calibration time at the beginning of the observation.
The new reference now fixes that. We now have a complete list of all observations done that qualify for processing by Einstein@Home. Each sky position pointing with Arecibo yields a set of seven "beams" (because the receiver / radio camera has seven feed horns: it's a seven-pixel camera). Now, the number of beams processed is compared to the total number of beams available. Accordingly the stats in the table for the daily amount of work done are computed in "beams/day".
"Average data taking rate" is now also in beams per day; it's computed by dividing the number of beams collected in total by the stretch of time over which they were acquired. And since the old estimate didn't take into account slew/calibration time, the "Percentage of data taking rate" also goes up.
Hope that helps,
Ben
Einstein@Home Project
Hallo Benjamin! Thanks for
)
Hallo Benjamin!
Thanks for your answer!
My question is: Is it possible to link the data published until yesterday morning with the data since yesterday midday?
Yesterday(UTC)____________9:40______ ________12:45
Average data taking rate ____44,13[min/day] ______48,80[beams/day]
Progress rate today ________41,78[min/day] ______65,36[beams/day]
( The data for ABPS become once a day in the morning updated. Unfortunately there is no timestamp, from when the date are taken.)
If you take (Progress rate today) 65,36/41,78 = 1,5644[beams/min]. This is very accurate the value one can derive from the data published until yesterday morning: 1,5645[beams/min] = 38,350[sec/beam]. Is this just luck ???
The factor for "Average data taking rate" is clearly smaller 48,80/44,13 = 1,1058[beams/min]. This explains, why the "Percentage of data taking rate" jumped from 94,67% up to 133,93%.
Are this factors further and/or backward valid?
Martin
RE: If you take (Progress
)
Nope, this is related. One beam is 268.5 seconds long.
For data taking rate there are some other factors that have to be taken into account, so there's no backwards compatibility here. But our webpage's history is exact all the way back. I will update the webpage soon to show the progress on the anti-center search correctly.
Cheers, Ben
Einstein@Home Project
Hi all, I've updated our
)
Hi all,
I've updated our progress page. This now also includes the progress from the search on "anti-center" data. These are pointings with the Arecibo telescope that aim away from the Galactic center in contrast to all the observations we've processed so far. Therefore, there's also a new set of plots showing the sky region covered by the anti-center search and our progress in color code.
While I was updating the page I've also made all the numbers on the progress table based on the number of beams processed, getting rid of all time equivalents. One Arecibo pointing consists of seven beams (the seven feed horns of the receiver / radio camera). Each grey point in the sky maps is one pointing (a set of these seven beams).
Hope you like it & happy crunching!
Benjamin
Einstein@Home Project