PDA

View Full Version : Loyalty Packets



PCZ
09-22-2003, 03:27 PM
Could somebody please explain the significance of the Loyalty packets.

LinearB
09-23-2003, 02:58 AM
My understanding is:-

Every time you upload work you get a loyalty packet, You can set the frequency yourself so for me on dialup I've got a fairly low loyalty score as I normally only upload 2 or 3 times a day. If your a broadband user with an update set for every ten minutes your going to score quite highly.

michaelgarvie
09-23-2003, 09:09 AM
I've now replaced this biased stat by one that counts the number of days each island has sent more than one packet.
Cheers,
Miguel

Angus
09-24-2003, 12:11 AM
so?

What does that mean?

If I don't connect for a week, but the PCs have been crunching away madly, I get penalized or somehow branded as less 'loyal' ?

What's the point of it?

IronBits
09-24-2003, 12:29 AM
Angus, take your meds... you said your wouldn't run it because it's Java based...
What difference does it make to you?
Stop phewying on everyone's parade...
if you can't find something good to say, then bite your tongue... :weggy:

Angus
09-24-2003, 01:22 AM
:moon: :moon: :moon: :moon: :moon:

I believe I am still entitled to express my opinion.

ER- Didn't you say the same thing about Java clients?

IronBits
09-24-2003, 01:37 AM
No. I said I don't like java based clients...
and because I am not running this client,
I don't have a right to share my opinion on this project,
nor do I have any constructive criticism to offer,
thus I offer my silence...
:mouserun:

prokaryote
09-24-2003, 03:20 AM
Originally posted by Angus
so?

What does that mean?

If I don't connect for a week, but the PCs have been crunching away madly, I get penalized or somehow branded as less 'loyal' ?

What's the point of it?

Hi Angus,

I'd have to agree with you .... if this were the only measure involved ... which of course is what I believe that you're saying since I'm sure that you've taken the time to peruse the project's stats page and know about, the stats that measure the number of circuits analyzed, how many best solutions were found, the fastest island on average based upon the number of circuits analyzed and the length of active participation, the luckiest island based upon the number of best solutions found and the number of circuits analyzed; all of this done for both teams and individual islands on a total, daily and concurrent basis.

Luckily Miguel has considered this and it's not considered by itself (as I assume that you know and are just pointing out the futility of using daily activity as the sole means of statistical rank) and is just another single facet of a body of collected statistical information that tries to give an overall impression of where one stands with respect to others. So, based upon my assumptions, I'm in complete agreement with you. :)

prok

Angus
09-24-2003, 03:32 AM
Exactly.

All the other metrics make some sort of sense, once you get past the admittedly slightly weird 'island' terminology.

prokaryote
09-24-2003, 05:24 AM
I think that the "island" terminology is more of an analogy. The genetic algorithm seeks to evolve in isolation for X number of generations then the fittest individuals from nearby evolution sites are mixed with those fittest individuals on the local island and evolution is then again continued in isolation.

One way to think about it is as if each CPU's individuals were evolving on an island with no contact with other individuals on different islands (like Darwin's Gallapegos islands) until by some accident of nature nearby islands were connected or somehow the populations were allowed to migrate the short distances and mix.

Genetic algorithms, depending upon how they are designed, can get "stuck in a rut". One way around this is to allow some "ruts" to develope and then mix them up. This way the various locally optimal solutions can be combined and new schemas can be investigated. Doing it this way takes away the onus of having to have near perfect mutation, crossover and other evolutionary programming parameters from the get go and allows more generic settings. This is especially useful if one doesn't know what the optimal solution is supposed to look like.

Of course, one doesn't necessarily have to be limited to mixing individuals from those islands nearby (unless the assignment of an islands location to the 2d map is random, in which case it doesn't matter). The important part is to evolve in isolation for a period and then mix in fit individuals from other populations (lather, rinse, repeat as the cliche goes).

Hope that this helps.

prok

michaelgarvie
09-25-2003, 10:24 AM
Firstly I think its perfectly OK for someone who's not running the client of this project to say whatever they want.



So about loyalty stat (active days) I wanted to give credit to people who've been runnning it for ages but don't have as fast a PC as others. I think Prok gave a great answer as to why islands makes sense from an evolutionary biology point of view. And if you don't believe him, ask Peter Young from York Uni: http://www.newscientist.com/news/news.jsp?id=ns99994012


Secondly, I find interesting what objections people have towards java clients. We could discuss this here on in another thread if you prefer. But bring it on!



Miguel

HisMastersVoice
09-25-2003, 01:47 PM
imho java performs not that good on linux machines, so i prefer c or better asm coded clients.

take a look at the muon project from stephen brooks he develops the windows version of his client
and let do the porting to cpu optimized linux/solaris clients by a selected people.

and there is a good speedup between the i686 optimized vs. the athlon-xp optimzed version.
so it is a good idea to think of a non java client because the optimized client gets more out of the energy
we spend to the projects of all you crazy scientists :)

Angus
09-26-2003, 02:18 AM
Well, in general Java based DC clients are much slower than compiled C(anything) or ASM or whatever , that are optimized for each family of processor.

Here is an example of the Java silliness - Ubero Forum (http://www.free-dc.org/forum/showthread.php?s=&threadid=164) - it starts the 'which Java is faster for this processor and OS this week' thing. Having been sucked into that once, and having to wipe a machine clean to recover from the multiple overlays of JREs, I wouldn't go there again.

In case you hadn't noticed, DC folks are very stats driven - the client needs to be as fast as it can be to accumulate stats as fast as possible. The Java clients don't stand a chance.

My opinion, and I haven't tried running it yet.

And what's with the weird GUI thing? Can ANYONE explain that circuit diagram?

HisMastersVoice
09-26-2003, 03:05 AM
i dont care much about stats, my machine is power on 27/7 so why dont
support small projects who would never got the money or equipment for their
projects.
so my first rules for participating or not is

1. never support a project which tries to make money out of it
2. did the project make sense for me

another thing to think about is how much "effect" we can get out of a client
for the energy it uses to calculate the results.an optimzed client is far more
ecological than a slow java client.

on the european side of the atlantic saving energy is an important thing. there are
maybe other opinions on the other side of the atlantic :).

btw

regards to all countries who respect the kyoto protocol.

ps.

hey miguel why don't you just ask the still growing community to help you out with a
c or asm client when you cant do one by yourself ? i bet there are people who participate
who will try to help you.

michaelgarvie
09-26-2003, 07:00 AM
Firstly:
90% of the time, 1% of the code is being executed. I agree that porting this 1% of the code would give a speedup but in my case I have profiled the code and this is as optimal as it could be in Java. Being optimistic, porting this to C would give make it 30% faster.
However, the time I could recoded thousands of lines of code into C I have spent thinking hard about the genetic operators I'm using, the encoding. This leads to a greater efficiency than a 30% improvement when itcomes to a Genetic Algorithm you can get some serious advantages by chossing the right operators/mapping,etc..
Secondly, this has given me time to think about WHAT is being done. Sincerely, what is ecological about spending billions of CPU cycles in a brute force YES/NO search for a key which some people alredy know in the first place and which will shed no light on any issue whatsoever?? The Distributed.NET client may be as optimised as hell but you're still making your PC try out millions of different keys giving out a "NO" answer every time. Don't get me wrong, I used to check my Distributed stats every day at one point, but I think it was a combination of not knowing there were other projects and the lottery-folly of thinking I'd get some cash for free.
I mean, you could be the fastest runner in the world, but if you're going to run into a wall all day long that talent is wasted.
Cheers,
Miguel

HisMastersVoice
09-26-2003, 08:10 AM
so then we have to life with the java client.

and yes i agree with your statement to the dc project

i never calculate a single cycle for dc or seti or any other stuff like that.

the idea with the c or the optimized client was an idea. when your say
it makes not much sense to port the code to c it is ok.

IronBits
09-26-2003, 09:43 AM
I just don't like Java anything, sorry.

I like stats, but that's not the reason I participate in various projects.
However, it has been known as the main reason I add more boxen. ;)
:tempted:

Stephen_B
10-10-2003, 03:18 PM
A bit late to this conversation, but, speaking as someone who implemented a genetic algorithm in python (in 180 lines, no less), I can see how java can be a very productive choice.

Of course, the ability to import highly optimized libraries written in fortran/C doesn't hurt either.