ZZZ again

**Thor** · 09-26-2005, 07:43 AM

Here they are again!

ZZZ ZZZ ZZZ ZZZ all over the place...

Greets Thor

EDIT: Seems like it was only a longer hick-up altough it latet at least 30min...

**vaughan** · 09-30-2005, 11:56 AM

ZZZ again

**AMDave** · 10-06-2005, 09:39 AM

and again

**rcoulter** · 10-08-2005, 08:48 PM

Time to boot the server again.

**AMDave** · 10-08-2005, 10:45 PM

...and awaaaay we go again

Thanks fellas.

**graeme** · 10-09-2005, 12:16 AM

np, thanks for the notes.

**rcoulter** · 10-11-2005, 07:48 AM

It would appear that the ZZZZ's are back.

**and_ped10** · 10-11-2005, 07:58 AM

Should be fixed by now.

Andreas

**rcoulter** · 10-12-2005, 07:39 PM

Back in full force. Need a restart.

Randy

**and_ped10** · 10-13-2005, 04:59 AM

Thank you for the info,

The server have been reatarted by now

Cheers,
Andreas

**rcoulter** · 10-23-2005, 09:09 AM

Sunday Morning and time for a reboot.

Randy

**and_ped10** · 10-23-2005, 11:08 AM

Has been done by now ;-)

**AMDave** · 10-30-2005, 01:34 AM

here's a twist.
No ZZZs, everything is going including the stats database.

however, the stats updates have been in "trickle" mode now for several hours for some reason.

The stats update service till seems to be running but is only showing 1 or 2 wu's here and there.

Perhaps the results cache is building and building without being processed or the results are being processed and the stats update is running in some broken form.

At least we are all still crunching.
I hope the project is getting the benefit of the results.
Don't know. No way to tell at the moment.

**AMDave** · 10-30-2005, 04:45 AM

I've been watching the stats recover.

It seems the project is processing the current wu's, but those wu's that were missing from the stats earlier seem to have stayed missing.

Oh well. we're back on track now anyway.

**and_ped10** · 10-30-2005, 06:23 AM

Hi,

The behavior you are seeing is due to the system being in a troublesome state.

When the system is in troublesome states allmost all calculations done by the clients are discarded by the server. The reason is that there is a set of criterions that the results, from the clients, have to fullfill, an example is that the new state should be connected to the current state.

Eventhough the calculations are discarded the work done is nessesary, as the it is impossible on forehand to tell which calculations will give good or bad results.

Because the statistics are based on good searches a drop will show up when the system is in a troublesome state.

Take care,
Andreas

**AMDave** · 10-31-2005, 03:49 AM

Thanks Andreas.

I think I understand.

Although the clients may find "Good Pref."(s) they may not fit the current state of the model as they move towards a lesser "high" point than the optimum solution, (ie the clients climb a lower peak that is not the summit)

My understanding is that this happens from time to time with the Monte Carlo method.

Would that be a fair analogy ?

Just to clarify, during the slow period my clients were finding "Good prefs." Does this mean that they were not deemed good by the model on the server even though they were deemed good by the client?

**and_ped10** · 10-31-2005, 10:43 AM

Originally posted by AMDave
Thanks Andreas.

I think I understand.

Although the clients may find "Good Pref."(s) they may not fit the current state of the model as they move towards a lesser "high" point than the optimum solution, (ie the clients climb a lower peak that is not the summit)

When you get the output from the client "Good Pref", the client have always found a summit. The "Good Pref" indicates that the client have calculated the eigenfrequncy of the lowest eigenmode at the lowest summit point (saddle point), and that the obtained value was reasonable.

My understanding is that this happens from time to time with the Monte Carlo method.

Would that be a fair analogy ?

The characterestic of Monte Carlo algorithms is that they rely on a random number. In the algorithm used in EON code the random number decides which state shifts that happens from a table of possible state shifts. It is the work of achieving the table of states that is done by the clients.

When the server make its pick in the table it depents on the random number and two values that are unique for all the different state shifts. The two values are:
(I) the energy barrier the system has to overcome to make the shift happen (larger value less likely)
(II) the prefactor that decibe how often the system would try to make the transition (larger value more likely). It is this value that is calculated when the client output 'Good Pref'.

Just to clarify, during the slow period my clients were finding "Good prefs." Does this mean that they were not deemed good by the model on the server even though they were deemed good by the client?

Yes. An example of this could be that the client have found a saddle point, when it is analyzed it shows up that it is not connected to the original state. The client got lost during its search so to say. Keep in mind that the space defining the searchspace is more than 3000 dimensional so the is plenty of differnt ways to go!

Cheers
Andreas

**AMDave** · 11-01-2005, 04:51 AM

Wow.
That was a great reply.
Thank you for taking the time to respond in such detail.
This is a real insight to how the decision-model works in relation to the the work done by the client.

Thanks again Andreas.

**AMDave** · 11-06-2005, 03:59 PM

back on topic...

21 minutes of ZZZ so far (at time of post)

**and_ped10** · 11-06-2005, 06:05 PM

The server has been restarted by now. Hopefully it will stay stable;-)

Cheers andreas

**rcoulter** · 11-23-2005, 10:10 PM

Time for a reboot.

Randy

**and_ped10** · 11-24-2005, 04:56 AM

The server is back on track now.

Cheers
Andreas

**AMDave** · 11-26-2005, 09:06 PM

Hi andreas.
Happy thanksgiving to you too.

I notice that the clients are crunching away but the stats are not showing any increments in the results.

Is this a "troublesome" state in the model at the moment, or has the SQL server got a problem ?

**graeme** · 11-26-2005, 10:06 PM

Thanks for pointing this out. The stats are running now, and should be up to date, and reflect all work done.

**Gunslinger** · 11-27-2005, 07:16 AM

Originally posted by graeme
Thanks for pointing this out. The stats are running now, and should be up to date, and reflect all work done.

I don't think all work has been credited - I would have expected to see well over 5000 units credited on my account to catch up the last 4 days, but only a couple of thousand have turned up...

**rcoulter** · 11-30-2005, 07:25 PM

The server needs restarting

Randy

**and_ped10** · 12-01-2005, 04:44 AM

The server seems to be running steadly now.

Cheers Andreas

**rcoulter** · 12-07-2005, 08:09 AM

Time to reboot.

Randy

**and_ped10** · 12-07-2005, 12:08 PM

Done ;-)

**Thor** · 12-07-2005, 05:45 PM

I still see quite some ZZZ's

Are the wu's so small at the moment? They just fly past!

Greets Thor

**and_ped10** · 12-08-2005, 04:52 AM

The server collects and process results as it should at the moment

**Silverthorne** · 12-09-2005, 11:49 PM

Anyone else seeing lots of ZZZ's?

**Thor** · 12-10-2005, 07:09 AM

Not right now, bu the stats file for Bok's stats doesn't seem to be updating...

Maybe someone can fix this so that the stats will kick in again?

Thanks!

Thor

Edit: Noe I also start to see some ZZZ's

**rcoulter** · 12-10-2005, 08:03 AM

Andreas

The server is getting almost continuous ZZZ's, with short work units and the stats server has been down for the last 8 or 9 hours.

Randy

**AMDave** · 12-10-2005, 08:15 AM

yep.
pages and pages and pages of zzz
all afternoon and evening (UTC+10

) in fact
occasionally interspersed with a work unit here and there

I also notice that the stats file has not refreshed for several hours now, or rather it may have been, but the stats server has not updated any results for several hours, so the stats file has not changed at all.

I also notice that the average ping times has blown out. Me thinks there may be something else afoot

None-the-less, the stats server could cop a good kick about now

ps andreas / graeme - tricky question - is there anywhere on the server that a script calls itself which also has an "includes" of an environment settings file that may append a file path to the path. If it calls itself enough times the file path gets too long and things start to fall over because some things cannot be found. I have tested this reproduceably on a Solaris box. Just wondering. Still trying to dig up some reason for the server's cyclic instability that is apparent from our end.

[ed]
hmm. nothing wrong with the internet
http://www.internettrafficreport.com/main.htm
[ed/]

**and_ped10** · 12-10-2005, 08:16 AM

Hi guys,

The simulation has reached a very troublesome state. That is the reason why you are getting small work units and see lots of ZZZs.

I have tried to tweak the simulation in order to get out of the troublesome state. Hope that it is working a little better now ;-)

Cheers Andreas

**AMDave** · 12-10-2005, 08:44 AM

I see WUs on all clients

cheers

still no stats updates on the eOn site tho

**AMDave** · 12-10-2005, 09:24 AM

andreas

is there any way to script the detection of a troublesome state and perform the tweak you just did ?

**graeme** · 12-10-2005, 09:32 AM

I was the cause of the problem. There was some error with mysql last night which prevented the addition of new groups. I restarted mysql, which solved the problem, but forgot to remove our lock files which prevents multiple scripts from updating the stats at the same time.

**Thor** · 12-10-2005, 10:06 AM

So tis time not the server but graeme needed a kick

Thanks for repairing it and keeping us posted

Greets Thor

Thread: ZZZ again

Thread Tools

Rate This Thread

Display

and again

The ZZZ are back

restart

ZZZ's again

And the ZZZ's are back

The ZZZ's are here again

strange stats updates

back on topic ZZZ

Server is down

Server reboot,

Server status

Server is down

Server problems

Posting Permissions