Rather you took it easy, got it well and truly sorted out rather than trying to sort it out in a hurry, then have a repetition in a couple of days time..
hmm maybe problem is somethink like this... even if server doesnt had wus, mine client told me this: </p><p>5.10.2016 12:28:44 | Einstein@Home | Scheduler request completed: got 0 new tasks<br />5.10.2016 12:28:44 | Einstein@Home | No work sent<br />5.10.2016 12:28:44 | Einstein@Home | see scheduler log messages on https://einsteinathome.org/host/9******/log</p><p>
and important part of mine log from einstein is here
</p><p> </p><pre>2016-10-05 10:29:26.4398 [PID=4705 ] [version] Checking plan class 'FGRPOLD'
2016-10-05 10:29:26.4398 [PID=4705 ] [version] WU#257208783 too new</pre><pre>
interesting part is that I dont had any wus, and I even reset project (mine client but this will be server problem latest branch of wus is 2569*****
One of my machines got some freshly made BRP4G work such as this one.
The task was sent to my machine about an hour ago, but shows a creation time about six hours before that. This does not seem to be any sort of general availability, as the server status page continues to report a steady drop of tasks in progress.
Perhaps the full pipeline will come alive pretty soon. Yes, I'd prefer that the project people work on the problems rather than giving us more frequent reports.
hmm maybe problem is somethink like this... even if server doesnt had wus, mine client told me this: </p><p>5.10.2016 12:28:44 | Einstein@Home | Scheduler request completed: got 0 new tasks<br />5.10.2016 12:28:44 | Einstein@Home | No work sent<br />5.10.2016 12:28:44 | Einstein@Home | see scheduler log messages on https://einsteinathome.org/host/9******/log</p><p>
and important part of mine log from einstein is here
</p><p> </p><pre>2016-10-05 10:29:26.4398 [PID=4705 ] [version] Checking plan class 'FGRPOLD'
2016-10-05 10:29:26.4398 [PID=4705 ] [version] WU#257208783 too new</pre><pre>
interesting part is that I dont had any wus, and I even reset project (mine client but this will be server problem latest branch of wus is 2569*****
That part of the log has nothing to do with the shortage of BRP4G work and there's absolutely nothing wrong in it, the scheduler checks for available tasks for the plan class "FGRPOLD" and finds a FGRP workunit, but that unit is to new to be run by the app for the "FGRPOLD" plan class so the scheduler writes that in the log, then it continues on to check other available plan classes which would have shown if more lines from the log was included.
The project released new FGRP apps recently that is incompatible with the old apps, the tasks would not validate, so had to separate the old from the new.
The work shortage has been explained by Oliver and is due to the need to pre-process the data in house before sending it to us volunteers and that pre-processing had to be shut down during the weekend, Oliver is now working on getting up and running again. See this message for the announcement. As to why it's taking time I can only guess but my guess is that this is normally handled by Bernd and he is on vacation right now, I'm sure Oliver is doing his best to get it going as fast as possible.
As to why it's taking time I can only guess but my guess is that this is normally handled by Bernd and he is on vacation right now
Nope, that's not even the point here. We (as the E@H team) still depend on others to provide data we can feed to our pipeline. Those colleagues and teams currently struggle with infrastructural changes, system management bugs and staff shortages. It's really a number of things coming together this time that make it really hard (and somewhat frustrating) to make progress. Having staff shortages in our own team doesn't affect the lack of BRP4G data but doesn't help in getting other work done like keeping FGRP running, preparing new GW-analysis runs (previously scheduled for this week) and, alas, improving our website.
Just be patient, BRP4G production already started again but still needs to be ramped up to full speed.
Thank you Oliver for the update on the current problems!
I do apologize if you took offense at my comment, i hope you didn't, it was never my intention to imply that you might be less able to handle the situation.
I hope the launch of the new GW-run goes smoothly and keep up the good work!
Just a few minutes before I posted this I happened to notice that one of my systems had downloaded some BRP4G work. A check of the server status page showed both that the BRP4G work generator showed running status and even that there was a tiny inventory (10) of unsent work as of 18:55 UTC. With a little Update button mashing, all four of my GPU systems have work for the first time in days.
Oliver's cautious words suggest we may well not have yet ascended to the high plains of continuous availability, but this is encouraging.
By the 19:05 UTC server status snapshot, the BRP4G generator was again "Not Running" and the task inventory back to zero, so quite likely the pipeline upstream of that point can still be limiting.
The work shortage has been explained by Oliver and is due to the need to pre-process the data in house before sending it to us volunteers and that pre-processing had to be shut down during the weekend, Oliver is now working on getting up and running again. See this message for the announcement.
and found myself (persistently) in the Swedish language part of the website, with an embedded .../sv/... in the url. That isn't how Drupal translation is supposed to work, surely?
Suppose it's because I forgot to edit out the .../sv/... part of the link before I posted it. If this is the way things are going to work it's not going to be the last time I'll make that mistake...
Edit: And since I'm no longer able to edit that post I can't fix it. If a mod would like to correct it feel free to do so!
Hi Oliver, Rather you took
)
Hi Oliver,
Rather you took it easy, got it well and truly sorted out rather than trying to sort it out in a hurry, then have a repetition in a couple of days time..
In any event I'm sure you will get it sorted out.
Regards,
Cliff,
Been there, Done that, Still no damm T Shirt.
hmm maybe problem is
)
hmm maybe problem is somethink like this... even if server doesnt had wus, mine client told me this:
</p><p>5.10.2016 12:28:44 | Einstein@Home | Scheduler request completed: got 0 new tasks<br />5.10.2016 12:28:44 | Einstein@Home | No work sent<br />5.10.2016 12:28:44 | Einstein@Home | see scheduler log messages on https://einsteinathome.org/host/9******/log</p><p>and important part of mine log from einstein is here
One of my machines got some
)
One of my machines got some freshly made BRP4G work such as this one.
The task was sent to my machine about an hour ago, but shows a creation time about six hours before that. This does not seem to be any sort of general availability, as the server status page continues to report a steady drop of tasks in progress.
Perhaps the full pipeline will come alive pretty soon. Yes, I'd prefer that the project people work on the problems rather than giving us more frequent reports.
Digi wrote:hmm maybe problem
)
That part of the log has nothing to do with the shortage of BRP4G work and there's absolutely nothing wrong in it, the scheduler checks for available tasks for the plan class "FGRPOLD" and finds a FGRP workunit, but that unit is to new to be run by the app for the "FGRPOLD" plan class so the scheduler writes that in the log, then it continues on to check other available plan classes which would have shown if more lines from the log was included.
The project released new FGRP apps recently that is incompatible with the old apps, the tasks would not validate, so had to separate the old from the new.
The work shortage has been explained by Oliver and is due to the need to pre-process the data in house before sending it to us volunteers and that pre-processing had to be shut down during the weekend, Oliver is now working on getting up and running again. See this message for the announcement.
As to why it's taking time I can only guess but my guess is that this is normally handled by Bernd and he is on vacation right now, I'm sure Oliver is doing his best to get it going as fast as possible.
Quote:As to why it's taking
)
Nope, that's not even the point here. We (as the E@H team) still depend on others to provide data we can feed to our pipeline. Those colleagues and teams currently struggle with infrastructural changes, system management bugs and staff shortages. It's really a number of things coming together this time that make it really hard (and somewhat frustrating) to make progress. Having staff shortages in our own team doesn't affect the lack of BRP4G data but doesn't help in getting other work done like keeping FGRP running, preparing new GW-analysis runs (previously scheduled for this week) and, alas, improving our website.
Just be patient, BRP4G production already started again but still needs to be ramped up to full speed.
Oliver
Einstein@Home Project
Thank you Oliver for the
)
Thank you Oliver for the update on the current problems!
I do apologize if you took offense at my comment, i hope you didn't, it was never my intention to imply that you might be less able to handle the situation.
I hope the launch of the new GW-run goes smoothly and keep up the good work!
Just a few minutes before I
)
Just a few minutes before I posted this I happened to notice that one of my systems had downloaded some BRP4G work. A check of the server status page showed both that the BRP4G work generator showed running status and even that there was a tiny inventory (10) of unsent work as of 18:55 UTC. With a little Update button mashing, all four of my GPU systems have work for the first time in days.
Oliver's cautious words suggest we may well not have yet ascended to the high plains of continuous availability, but this is encouraging.
By the 19:05 UTC server status snapshot, the BRP4G generator was again "Not Running" and the task inventory back to zero, so quite likely the pipeline upstream of that point can still be limiting.
Holmis wrote:I do apologize
)
No worries, you didn't, to the contrary
Thanks,
Oliver
Einstein@Home Project
I just followed the link in
)
I just followed the link in this message
and found myself (persistently) in the Swedish language part of the website, with an embedded .../sv/... in the url. That isn't how Drupal translation is supposed to work, surely?
Suppose it's because I forgot
)
Suppose it's because I forgot to edit out the .../sv/... part of the link before I posted it.
If this is the way things are going to work it's not going to be the last time I'll make that mistake...
Edit: And since I'm no longer able to edit that post I can't fix it. If a mod would like to correct it feel free to do so!