If they're re-enabling networking for the first time, they will have to upload all the result files first, before they can report the results. They will have allowed enough time for that, and since they're active at the console anyway, they can work through the 11 'update' retries while the files are uploading.
If they can't manage that, I'm afraid you'll have to mark it down as one of the hazards in the gameplay. And it'll all be a useful stress-test for the new server farm.
OK, apparently yesterday I missed the "Permanent" flag in the "Redirect". With it configured now, the redirection indeed seems to work without error (and without the client noticing). So all should be fine now.
IIRC the master file with the schedulers list is fetched periodically anyway. Does anyone know whether this is true, and if so, what the period is? Once a week?
I've just sacrificed on of my PCs to test how reporting finished tasks will work and re-enabled the 12 days interrupted network connection with Einstein before challenge start. In my case a new master file was downloaded immediately, and the results were also reported immediately. I suppose that due to the many unsuccessful connection attempts before an internal flag was set do fetch a new master file immediately with the first successful connection.
And as I'm very graceful to the projects servers and upload my finished result files immediately but only withheld reporting them as finished during the bunkering period before challenge start, I hope the small timeframe of forty minutes between challenge start and tasks deadline will be no issue for me :)
Is anyone besides me noticing the message boards running slow since the project came up yesterday? I figured it was just traffic overload in the first few hours, but it's been the better part of a day now and it's still slow.
[edit]
But at least it's not giving gibberish and all kinds of script errors like Seti's boards do every time Dr. A. messes with the code.
David
Miserable old git
Patiently waiting for the asteroid with my name on it.
Is anyone besides me noticing the message boards running slow since the project came up yesterday? I figured it was just traffic overload in the first few hours, but it's been the better part of a day now and it's still slow.
Yes, as viewed here in Albuquerque, NM, USA, Einstein message board pages since the restart are rather slow to display start displaying, and even after a page starts to display, remaining material appears at a very slow rate. I also continue to notice "already read" notation errors intermittently.
Is anyone besides me noticing the message boards running slow since the project came up yesterday? I figured it was just traffic overload in the first few hours, but it's been the better part of a day now and it's still slow.
Yes, as viewed here in Albuquerque, NM, USA, Einstein message board pages since the restart are rather slow to display start displaying, and even after a page starts to display, remaining material appears at a very slow rate. I also continue to notice "already read" notation errors intermittently.
The same slow page loading behaviour here in the UK, very noticably different from before the move. I also see the Drupal pages loading slowly at Albert, although Oliver commented that they seemed to load at normal speed when loaded from within the MPI campus - suggesting that it isn't a simple server problem, but perhaps something in the external routing.
However I don't see much we can urgently do about that.
Migrating the DB back to UWM doesn't sound very useful, until we have a reliable DB structure set up there, ETA: a couple of months.
Having the web server and pages moved to AEI (i.e. closer to the DB) involves a couple of technical and administrative issues, where I'm not sure yet that all of these can be overcome at all. At least this would require us to get a single ssl certificate for different hostnames/domains under administration of at least three different organizations. ETA: several weeks in best case.
We're currently looking into optimizing the BOINC web code for less I/O with the DB, which might be the fastest option we have. ETA: unknown, success unknown.
If they're re-enabling
)
If they're re-enabling networking for the first time, they will have to upload all the result files first, before they can report the results. They will have allowed enough time for that, and since they're active at the console anyway, they can work through the 11 'update' retries while the files are uploading.
If they can't manage that, I'm afraid you'll have to mark it down as one of the hazards in the gameplay. And it'll all be a useful stress-test for the new server farm.
OK, apparently yesterday I
)
OK, apparently yesterday I missed the "Permanent" flag in the "Redirect". With it configured now, the redirection indeed seems to work without error (and without the client noticing). So all should be fine now.
IIRC the master file with the schedulers list is fetched periodically anyway. Does anyone know whether this is true, and if so, what the period is? Once a week?
BM
BM
I've just sacrificed on of my
)
I've just sacrificed on of my PCs to test how reporting finished tasks will work and re-enabled the 12 days interrupted network connection with Einstein before challenge start. In my case a new master file was downloaded immediately, and the results were also reported immediately. I suppose that due to the many unsuccessful connection attempts before an internal flag was set do fetch a new master file immediately with the first successful connection.
And as I'm very graceful to the projects servers and upload my finished result files immediately but only withheld reporting them as finished during the bunkering period before challenge start, I hope the small timeframe of forty minutes between challenge start and tasks deadline will be no issue for me :)
Love, Michi
Is anyone besides me noticing
)
Is anyone besides me noticing the message boards running slow since the project came up yesterday? I figured it was just traffic overload in the first few hours, but it's been the better part of a day now and it's still slow.
[edit]
But at least it's not giving gibberish and all kinds of script errors like Seti's boards do every time Dr. A. messes with the code.
David
Miserable old git
Patiently waiting for the asteroid with my name on it.
RE: Is anyone besides me
)
Yes, as viewed here in Albuquerque, NM, USA, Einstein message board pages since the restart are rather slow to display start displaying, and even after a page starts to display, remaining material appears at a very slow rate. I also continue to notice "already read" notation errors intermittently.
RE: RE: Is anyone besides
)
The same slow page loading behaviour here in the UK, very noticably different from before the move. I also see the Drupal pages loading slowly at Albert, although Oliver commented that they seemed to load at normal speed when loaded from within the MPI campus - suggesting that it isn't a simple server problem, but perhaps something in the external routing.
Load time of this thread from
)
Load time of this thread from south germany:
clearly something wrong with the webservice configuration
Indeed the forum pages are
)
Indeed the forum pages are slow to respond.
However I don't see much we can urgently do about that.
Migrating the DB back to UWM doesn't sound very useful, until we have a reliable DB structure set up there, ETA: a couple of months.
Having the web server and pages moved to AEI (i.e. closer to the DB) involves a couple of technical and administrative issues, where I'm not sure yet that all of these can be overcome at all. At least this would require us to get a single ssl certificate for different hostnames/domains under administration of at least three different organizations. ETA: several weeks in best case.
We're currently looking into optimizing the BOINC web code for less I/O with the DB, which might be the fastest option we have. ETA: unknown, success unknown.
BM
BM
Bernd, "Good Things Take
)
Bernd, "Good Things Take Time". Do it right and make E@H the Fastest and the Best.
Jesse
It seems that you use a
)
It seems that you use a tunnel from uwm to aei. It is possible to give that link higher priority and/or more bandwith?
Imo more promising than changing the webcode.