oh dear, is the server down again ?

[adream]

hi thee distyibuted people..

the server apeares to be down again, i have several clients that have hung while fetching new data

i assume it will be after the weekend before things are fixed... oh well



cheers

adream


:elephant: :elephant: :elephant:

[safemode]

indeed. the server seems to be going down often lately. What's the cause ? It's been down since yesterday at least.

[prokaryote]

Hi Miguel, noticed that you're online. I just tried to log on and it appears to be a no-go. Any ideas?

prok

[michaelgarvie]

There has been so much traffic over the weekend (more people joingin i guess) that the university computing service thought my server was infected and they blocked it at the firewall!! I hope all these new people keep trying to connect!!!

:swear:

[prokaryote]

Okay, thanks. I'll keep trying to connect up. Hope that you can set them straight about the project, etc. Good luck. :)

[michaelgarvie]

I certainly did!

[safemode]

looks like the clients either can't connect to the server to upload data it's done (possibly even download it) or the stats screen isn't getting updated. I hope it's not that university's network people screwing up again.

[michaelgarvie]

Yeah, only the outer ring (the last ones to register) of the topology had sent results. I'm restarting the server now hoping for the best.

By the way, even with this outer ring, the first dual rail error signal circuit was evolved. You can take a look at it working. Its the last one in the results page. The last two lines are the error lines and if they're different this signals no error, if they're equal this signals an error! See for yourself that it will signal an error before a behavioural failure happens due to a fault, given all inputs are fed in between fault arrivals.

The amazing this is it does it with even less resources than the normal one!! This is an incredible result. I think we might be talking about a lot than less than half of conventional overhead for this kind of task

[safemode]

unfortunately, for those servers that have been workin on the last circuit, their current work up all weekend is lost, because the server was restarted and then set with a new project within the time span of an hour. Or will the client update register the old work when it eventually grabs the new code? Normally we'd only lose at most an hour by default configuration but since the server wasn't listening all weekend, that's close to 72 hours lost on numerous islands.

at the time of me writing this, mine are still working on the old circuit.

[safemode]

oh well, 150,000 generations gone. time to crush the latest circuit.

[michaelgarvie]

No work was lost over the weekend because all new genotypes were submitted as soon as the server went up on monday. Last night about half of the clients seemed to be stuck and the other half were working fine and were enough to evolve a really good circuit which will shock the field!

[Bok]

Miguel,

most of my clients are, I believe, sitting idle :(

Luckily I have a backup project which kicks in.. I'm not at home to be able to stop/restart them.

Bok

[michaelgarvie]

Actually the current best circuit of the cluster comes from Bokwork3!! However quite a few of your non-work boxes don't seem to have registered. However it doesn't seem to be a server problem because there are loads of registered islands (http://www.cogs.susx.ac.uk/users/mmg20/dhe/statsTopology.php). Maybe restarting them when you get back? Maybe your internet connection dropped off?

Let me know if you can't sort this out.

[Bok]

I'll give it a go. Actually at the hotel tonight I'll boot into Knoppix and see if the wireless card works.... if it does I can ssh to my home network and then VNC to the windows boxes :)

The net connection is still up as I can ssh in anyway (but through windows :( )

Cool, that one of my machines got the best circuit currently!

Thanks for your help

Bok

[safemode]

I dont get how none of the work was lost. I had to manually restart my clients because they would connect to the server and still work on the old project even though the new project was well along it's way already. A manual restart means the work done is lost. There is no way in the clients to save the data that they've done when you restart them.

Team stats aren't being updated. btw.

Eventually with any luck i'll be able to pick up a magazine and read about all the conventional circuit engineers oogling this project's circuits and the relative quickness it created them.

[michaelgarvie]

Safemode,

1) If you look at the Daily statistcs you'll see all team stats going up. If you look at the total effort you'll actually that AMD_Users and Changelings_Crew have swapped places since yesterday. So why do you say that team stats aren't updating?

2) There is no need to manually reset your client. When connection is lost to the server (as when it is restarted) the following happens: Upon reconnection it downloads the server task and if:
a) It is the same as the previous one it will keep going and submit the results its been working on.
b) It is different then it will cancel the old task and start working on the new one.

However this happens every half hour if you are starting your client with the option -c 30. This is why you may have thought it was going on with the new one regardless. If you'd like a quicker response of your client to when the server comes back up you can change this to -c 5. This means upon disconnection from the server it will try to reconnect every 5 minutes.

3) Trust me, you will definitively read about this in the proceedings of the 10th International On-Line Testing Symposium 2004. And by the way, the paper you can find in the publication section (http://www.cogs.susx.ac.uk/users/mmg20/academic.htm#pubs) title 'Evolution of Self-Diagnosing Hardware) from the ICES 2003 won the best paper award for the whole conference as judged by senior acadmic peers in the field. This paper will also give you an insight into how the evolved circuits peform superior diagnosis than the conventional ones. So there has already been a lot of interest by engineers and NASA people into this work. I would like to refer you to a paper with overhead results for the same benchmark circuits used in this project using conventional techniques such as Berger codes. However you can't find them on the web unless you pay IEEE. If you have a library at hand I recommend you ask an interlibrary loan for the 6th IEEE International On-Line Testing Workshop. And the 7th, 8th and 9th as well.

4) I wish the results to the hard problems came as quickly as the ones to the simpler versions we're tackling now. The current run is already noticably taking a lot longer than the C17 one, right?

5) I am working on the code to generate the circuit diagram for the conventional voter system as well so you can compare both's principles of operation. However for large circuits it may not be that easy to appreciate.

[safemode]

the teamstats (the stats when you click your team name) wasn't updating at all but now it is. Seems like it took a day or so since the project was restarted. Anyways, I witnessed the clients connect to the server and continue working on the old circuit while the new circuit was on the stats page being worked on by others. IT was already over an hour when i first messaged about how the clients weekend work would be done now that the new circuit had been started but they were working on the old circuit and i waited another hour before restarting them or so and at the time, they were still working on the older circuit.


Anyways, it's no big deal, my 3 island team will be beating most of every other team soon again. The secret to that is simply not having any idle members, ever.


Will do with reading the publications. and yes, the new circuit is taking a long time. but it's 22 gates compared to 6 which was the last one we did. Are circuits evolved asexually or sexually between the first circuit it grabs off the net and possibly a mutated copy of it or what? Perhaps for large circuits the method of procreation isn't optimal. Much like how most multicellular complex organisms dont use asexual reproduction like most bacteria and simpler creatures.

Interraction is also something of interest to think about when talking about small circuits compared to large ones. We might get places faster by having mostly independent evolution with sports of significant interraction instead of interaction every half hour. With large circuits, few generations come between interaction on the default 30 minutes. THis leads to a very bland gene pool. I have my setup doing 60 minute interactions with 30 minute connects. But still, 60 minutes isn't even enough to allow close to a thousand generations on my fastest island. And yet, when we do interact, what decides who we interact with? 4 closest islands ? closest in what way? I'm fine with interacting with 4 islands ,but i'd like to interact with say a couple other groups of non-close islands before returning with my new genomes to evolve the next generation. Just ideas, maybe for a next generation type client that can take run-time input and what not.

[michaelgarvie]

Just to insist: what makes you think your client actually connected to the server?

About reproducion: there is sexual cross over as well as many kinds of mutation (asexual).

About migration: every time you interact you exchange individuals with one of your neighbours. You rotate, so one time its N, then W, then S and E and N again. The individual is selected from your population using the current selection method which is usually Rank Selection.

You're right about the operators may not be optimal anymore, but this is hard to tell. You're also right about the migration rate should be lower. I'll slow it down the next time I start the server. I can do this by setting the probability of a migration actually taking place. Currently its 1 (always) but I could set it to 0.1 for slower runs like this one.

Cheers,
Miguel

[safemode]

the reason why i say it connected was not only did longer than the set time for connecting occur, but I also saw a message that stated it connected on one of my machines, at which time it continued working on the old circuit. After i saw that i figured something must not be working right because it should have recieved the new circuit by then and so i restarted them both manually.


Yea, i definitely think it would be better if we slowed migration down considerably on larger circuits. Or, if at all possible, make the migration less widespread, like make it much more likely that when a migration occurs (slowed down already) that it only occurs between islands of the same group. Only rarely do the migrations occur between groups. Then once we reach the better than human island we can interbreed all the teams together again. I dont know, this is all very complicated. It's like setting up the breeding of a species like the dog so that you can create a miniature poodle from a wolf in the least number of generations without knowing what a poodle looks like. We'd have to test the different theories of how we should allow migration on a couple circuits to see which one performs better. Perhaps this can be tested on a small scale with a tiny network of say 10 -20 or so islands doing a small circuit that we already evolved. We have basically a running timeline of how the evolution took place using that plot picture. So we could measure the performance of the really tiny network using the different migration methods by seeing how long each method takes to reach certain landmarks on the graph.

Anyways, the idea that changing the migration method could be extremely helpful, it's just a matter of how we end up testing it. I believe we have a improvement ratio for that past multi-fualt project that was basically bottoming out like this one is. We can go back to either one of these with different methods of migration and see if the improvement ratio increases or not. It would probably have to be run for a couple days though for a good number of generations in each isolated island to pass to produce any variety.

We need more dedicated islands, most of the evolution of the circuit is carried by the few islands that are decently fast and churn dhe 24/7. Yes it's nice for the people who run the project sporatically to be interested, but to really contribute to the project, you need to be able to churn out generations at a decent rate, otherwise you're not contributing much variety to the gene pool and when you eventually do connect (if you're doing it sporadically offline) your generations are likely far too old to be of any use. This can be offset if migration is done on a team basis and as a team, migration could occur frequently. That would make that strain of circuit evolve much faster than it would if the migration among the team occured slowly, since the individuals in many teams are slow. The faster migration among a slow team would effectively make the team look like each island was contributing to the same circuit, ie, one really fast island. On faster teams, migration could proceed slowly among itself, and inter-team migration could occur rarely. This method of migration could weild the largest gains since the slower islands (sporadic ones too) would actually get to contribute to the improvement of the circuit instead of contributing useless generations because the faster islands are beating them so badly.

[prokaryote]

One thing to keep in mind is that GA's main benefit is the testing of schemas. A schema is a consecutive chunk of the genome that persists as individuals are selectively chosen due to fitness. Therefore, a poorly fitted individual can still contribute to the genome it's schema and thus is not of minimal value.

The number of cross-overs that occur during the generation of children will act as a limit to the size of the schemas that can be expected to persist through the generations.

If the mutation function of a GA is applied only to individual characters or digits within the genome, then the likelyhood of a new (and useful) schema being generated by mutation alone becomes rather small and populations tend to homogenize quickly.

One way to combat this is to have isolated populations evolve their own schemas which is why the interactive rate is important as has been mentioned. Perhaps it should be a function of generation as has also been mentioned.

Another way to combat this is to have mutations occure in say X consecutive digits of the genome, thus introducing mutated schemas.

This may be one reason why many organisms are diploid (or more), since when there are two copies of a chromosome, only one is usually expressed, leaving the other to accumulate mutations without harm to an individual.



Purely as a side note, the simpler creatures (prokaryotes) could easily be considered to be better fitted to the environment based upon biomass, niches occupied and longevity (billions of years versus an average species age of several millions of years) compared to more complex creatures. Also, many prokaryotes have a form of "sexual" reproduction where they may absorb or exchange genetic material from others. In this sense they could be considered more advanced since an individual can change its genetic make-up without having to wait to reproduce to see the results. :D ;)

[safemode]

Well, the way i look at it. You got a bunch of people evolving their schema circuit, but since they're slower, rather quickly the faster islands are evolving circuits that are closer to the goal than the ones who are slower, thus all the slower island's circuits aren't contributing much to advance the currently more fit circuit. They're always playing catch up because they're slower.

I understand the contribution these islands are having to their schema, but wouldn't their schema be relying on random mutation to advance it and help the total evolution of the circuit, since they can't hope to help the total evolution of the circuit via breeding. The method i was describing was to try and offset this slowness, by creating instead of teams with individual islands, teams with "one" island where all the individuals contribute. It's an homogenized local circuit to that team, it would basically get the reproduction power of the cumulative power of the team (slower islands join larger teams on avg anyway) and allow such islands to contribute not only in variety via different teams but by raw generation power which is so necessary in larger circuit evolution. I think some teams can benefit greatly from this method, while other teams can continue to work in the manner that they currently do. That way we can sort of bring all the "islands" up to the same sort of performance level so no group is outpacing the other by a significant amount, and thus the slower group's circuits aren't always playing evolutionary catch up.

[Stephen_B]

I haven't seen that having a faster processor necessarily means you have the best population (though in the long run it should have an impact). Maybe it's just _my_ faster processor is rarely in the top ten.

Actually that's not quite true. Often lots of people will be tied with the same best individual. Don't forget that you might benefit from a neighboring fast computer since islands share genetic material.

Having lots of islands, even if they are slower, is good for overall diversity, which you want if you are to avoid killing off potential solutions too early.

[prokaryote]

Originally posted by safemode
Well, the way i look at it. You got a bunch of people evolving their schema circuit, but since they're slower, rather quickly the faster islands are evolving circuits that are closer to the goal than the ones who are slower, thus all the slower island's circuits aren't contributing much to advance the currently more fit circuit. They're always playing catch up because they're slower.

Slower is slower, so I'd agree with you about that, it would take some islands longer to reach a "stabilized" or non-changing genetic plateau. Maybe that is how interaction could be triggered, through some sort of differentiator, that compares how fast the generations are changing and when they hit a flat point, interact.

I think that the point that you're raising is that you'd like to see all of the islands cruising along at about the same number of generations produced per unit of time, thus they'd all interact at about the same time. Though with regard to schema's this doesn't really matter as long as the project goes on long enough to allow a slow island to reach a plateau point and interact so that it's schema(s) can be tested.

I think that you may be missing the idea about what a schema is. A schema is not the entire circuit, it would be several gates and their interconnections out of the entire circuit. Thus, while an individual may have a poor overall fitness, they may have the best local grouping of gates and connections that would boost the fitness level of the "more advanced" individuals when they interact. These schemas would of course evolve via mutation, but by existing in isolation, it is allowed to evolve as an alternative instead of being obliterated in its early stages when mixed with more fit individuals right off the bat. Only later, when mixed with other fit individuals (through cross-over) would these schemas be allowed to "fight" amongst themselves and the best overall combination of schemas would be chosen and represented by the most fit individuals.

So overall, the fitness score does not tell the entire story, less fit individuals can contribute (via their encapsulated schemas) to the more fit individuals by contributing new schemas not tried by the more fit populations. Isolation allows these schemas to develop. Also, there may be more than one solution to a circuit problem. Just because we evolve a circuit with a score of 1,1,1,some parsimony > hand designed, doesn't mean it's the "best". GA's don't necessarily find the optimum when they hit a plateau. They are highly dependent upon their history contained within their genome. Thus the island approach allows many different histories to be tried.

[safemode]

no, you're not getting it. Slower islands dont produce enough generations before interaction to evolve optimized schemaz in circuits and if they dont interact at all for a very long time, they're likely working with a circuit that's completely unusable schemas due to them being evolved and optimized for a much more primitive version of the currently evolved circuits. To speed up the project you need to be able to process generations. If an island is slow to compute generations then they're still playing with something that's similar to what they started out with. They're stuck with primitive circuits while every fast island has moved beyond that. When they interact and grab the circuits that the fast circuits have created, they're still stuck there, not able to evolve that new circuit fast enough and basically come time for the next interaction they're working on a circuit similar to that one they grabbed last time. I dont care if by some genetic fluke they can create a grouping of gates that is really optimized, it would be a rare thing for a slow island to produce an optimized gate sequence compared to fast islands. I'm suggesting a method to significantly speeed the project up, all you've been saying is that there is some chance that slower circuits can contribute. I want to see the slower islands to contribute the same as the faster islands so the indidivual isolated populations are working in the same era rather than the slow ones working on what the fast ones did last time they connected and interacted, while allowing the slow islands to push that generation number up at the same rate as the fast ones.

once and for all. Eg.
you have a team of slow islands. Intsead of each slowly working on it's own which quickly homogenizes due to slow generations and relatively frequent interactions. They work on 1 circuit. frequent iinteractions keep the individual's circuits up to date with the rest of the team while every individual's work (generations) can actually contribute to the improvement of their single circuit. This single circuit woul d then evolve through the combined cumulative work of the team which is definitely different than the way it's done now. All that would need to be changed would be how interactions occur. You'd need to have two areas of interaction, a team interaction which can be set frequent for slow client teams and rarely for fast ones, and a inter-team interaction which can be set slow for large projects and fast for tiny ones. Team interaction would only occur within that island's team, and interteam interaction would allow islands to interact with some other island in some other team. That's all that would need to be changed for what i've been talking about. I think it makes perfect sense.

[michaelgarvie]

Nice look to Free-DC by the way! :cheers:

Back to serious stuff. Given that the cluster is so large I think the migration probability of 1/10 is too low. For eg. look at today, srr5a did 26 fitness improvements (about 95%) of them so was basically working on its own. Everyone else wasn't catching up quick enough. If more neighbours had been given the fitter individual they could have improved it themselves possibly quicker than srr5a did. Like everything in life, a balance has to be found.

About team grouping. Currently everyone is on the same topology, teams don't matter when it comes to your place on the grid. I'm not sure this kind of differential migration rate would be beneficial. Some teams may be so out of it that they're wasting time at fitness 0.2 when most others are at 0.8. I think the problem with your argument safemode is that a "slow" team would be still be a lot slower than a "fast" team if they have similar number of team members. So the difference bewteen slow and fast would be reinforced if you segregate them.

By keeping migration going between all means slower clients will catch up and still have a chance to improve on the latest circuit, which does happen. I have a dual Celeron 500 connected which has had its share of fitness improvements!

Also as proc mentioned, you could carry 90% of a winner genetic structure and not know it. So all islands are contributing at all times by exploring different areas of the landscape.

I'll set the migration rate to 0.5 the next time, see if this keeps a nice balance.

[safemode]

You could fool the stats though by having a much more frequent connect and interact time than most other people. Yea, he improved it 95% of the time, but how much of an improvement, and has other islands that are using a connect and interact time on the order of an hour or half an hour had time to connect and give their results. I was thinking that if i wanted to whore the stats board i could set my interact and connect time to like 5 minutes, then once i matched the top circuit, every tiny improvement i do would be a new best circuit so long as nobody else was doing the same thing beating me to it.

Right now we look like we're on a nice slope to the winning circuit. And what i was talking about was that only slower teams would use the faster team interaction, not the faster teams as well. The faster teams would have an extremely slow team interaction, since each island in a fast team is likely to be nearly as fast as an entire slow team. And as for your statement about all teams/islands are contributing regardless of speed, i think that's wrong. All islands have the possibility of contributing, they aren't necessarily contributing anything positive to the evolution of the circuit all the time, and i think in most cases, the slower islands aren't contributing much of anything unless they're interact and connect times are very low so as to always be building off of the best fit circuit. This method might actually be best for slow islands under the current interaction model, since they have litle hope in evolving an independent different circuit in any decent amount of time.

[safemode]

plus, srr5a is an extremely fast island. If he had his connect/interact time set even to say half an hour, it's the same as a normal speed island doing it every 5 minutes or so when they find a winning circuit.

Basically you gotta take control over the interact and connect time from the user if you wanna use the "knack" and "lucky" stats as any sort of indicator of performance because they can at least, from what i've seen, be manipulated either consciously or not.

Interactivity as a user tunable option is ok for being that way, but connect times can allow these particular stats to be misleading.

[prokaryote]

Originally posted by safemode
no, you're not getting it. Slower islands dont produce enough generations before interaction to evolve optimized schemaz in circuits and if they dont interact at all for a very long time, they're likely working with a circuit that's completely unusable schemas due to them being evolved and optimized for a much more primitive version of the currently evolved circuits. To speed up the project you need to be able to process generations. If an island is slow to compute generations then they're still playing with something that's similar to what they started out with. They're stuck with primitive circuits while every fast island has moved beyond that. When they interact and grab the circuits that the fast circuits have created, they're still stuck there, not able to evolve that new circuit fast enough and basically come time for the next interaction they're working on a circuit similar to that one they grabbed last time. I dont care if by some genetic fluke they can create a grouping of gates that is really optimized, it would be a rare thing for a slow island to produce an optimized gate sequence compared to fast islands.

Yes processing power is paramount, you can't generate individuals and generations without it. You can't speed up the project unless you have more flops thrown at it (as an upper asymtotic bound).

In a Genetic Algorithm variation is key. You have to have more variablity not less (as you get by combining islands into sub-groups thereby homogenizing the populations). More processors = more islands = more variability.

A primitive circuit (i.e., not seeing x number of generations) does not imply that it doesn't have a decent schema brewing. A slow island with little interaction could develop a schema that is totally nut busting (and yet the individuals will have crap for fitness scores) if only it was given to another individual from a different island that needs that component, but if the interaction rate, either within a team sub-group or with another neighbor island is too frequent, then due to the fitness selection criteria, that schema would not be allowed to develop, it would be overcome by fitter individuals who don't have that schema in their makeup and we'd never know it. In order for GA's to work nicely, you have got to have variety; either by huge initial random populations, by using isolation as a tool, or by messing around with mutation rates and injections of random individuals. Granted, a slow island may not have the most "best fit" individuals, but this says nothing about the value of its individual schemas and the contribution of its variety. Faster islands get to a homogenized state faster, it doesn't mean that they have more variety. Sure they process more generations and therefore produce more single point mutations, but when you reach a homogenized state, single point mutations are almost always not beneficial and add nothing to the variety of the genome, unlike near the begining when the individuals are different.

This is the BIG problem with GA's... how to avoid homogenization of the population too fast and to not allow schemas to develop (either for an island or for the whole population). GA's are about developing strings of schemas, not about steepest gradient searches and the like (which focus on an individual's fitness level) as there are many vastly more efficient methods for doing gradient searches. Many GA methods, generally dealing with dynamic mutation rates, have been tried in order to avoid the too early population homogenization issue, but they generally end up as hand-crafted approaches for each specific problem (in this case circuit).