MagicButton questions

[Mystwalker]

I have two questions about the MagicButton - I'm not sure if anyone except Jean-Luc can help me, though. :(

1) Let's say a user visits a page with MagicButton and produces 2 GigaMD5, unfortunately without new DP. Was this CPU time a waste or is the "last" (resp. a recent) non-DP saved?

2) <Already solved...>

Therefore, another question: :p
3) Is there a performance gain when trying to use different "cores" for the MagicButton? The Java VM should conceal most of the architecture of the host system and optimize the ByteCode for it, but maybe different implementations can increase the speed a little.
Of course, the MagicButton only provides ~1% of the overall DP points, thus I guess a small performance increase is not that high priorized...

[Mystwalker]

Generalizing 1) to the standard Client:

It seems like the current status is saved to md5_save.xml - but only once a DP is found.
Especially for slower systems, wouldn't it be better to regularly save the current MD5 checksum so there is no (or next to no) loss when closing the Client?

[Guilherme]

Originally posted by Mystwalker
I have two questions about the MagicButton - I'm not sure if anyone except Jean-Luc can help me, though. :(

1) Let's say a user visits a page with MagicButton and produces 2 GigaMD5, unfortunately without new DP. Was this CPU time a waste or is the "last" (resp. a recent) non-DP saved?

I have this same question, for the Win32 client. If the client produces some GigaMD5s, and the user quits the client, the GigaMD5s produced are lost, or the client, on the next run, restart from where it has stopped, using the GigaMD5s previously produced?

[jlcooke]

Originally posted by Mystwalker
I have two questions about the MagicButton - I'm not sure if anyone except Jean-Luc can help me, though. :(

1) Let's say a user visits a page with MagicButton and produces 2 GigaMD5, unfortunately without new DP. Was this CPU time a waste or is the "last" (resp. a recent) non-DP saved?

2) <Already solved...>

Therefore, another question: :p
3) Is there a performance gain when trying to use different "cores" for the MagicButton? The Java VM should conceal most of the architecture of the host system and optimize the ByteCode for it, but maybe different implementations can increase the speed a little.
Of course, the MagicButton only provides ~1% of the overall DP points, thus I guess a small performance increase is not that high priorized...

0) To be clear - the MagicButton is written in Pure 100% Java. The cores in the downloaded client are written in optimized Assembly. So it's apple's and oranges.

1) The MagicButton saves the current state to a browser cookie once every 5 seconds. So if the user leaves the page, they next page they goto will continue working from the previous saved state. Average lost work - 2.5sec.

2) :)

3) see my answer to 0). There is only 1 core in the MagticButton. Ironiclly, it's almost as fast a ASNIC - the Sun JIT really surprised me there.

The magicbutton could be the biggest contributor of work is it were on sites like Slasahdot, ThinkGeek, SourceForge, CNN, etc. But right now, it's only one personal websites. :(

[jlcooke]

Originally posted by Mystwalker
Generalizing 1) to the standard Client:

It seems like the current status is saved to md5_save.xml - but only once a DP is found.
Especially for slower systems, wouldn't it be better to regularly save the current MD5 checksum so there is no (or next to no) loss when closing the Client?

To people who let the client run for days on end, the overhead of file I/O is un acceptable. So the menalty of losing work for those to restart many times (the less you restart, the less effort you lose) I am investigating a way to detecting a "kill" signal and saving the current state.

[Mystwalker]

Originally posted by jlcooke
To people who let the client run for days on end, the overhead of file I/O is un acceptable. So the menalty of losing work for those to restart many times (the less you restart, the less effort you lose)

Maybe an option "When save progress state?" with values like "every [x] minutes" and "whenever a DP is found" (like it is currently the case) would be a good interim solution.

Given a client with 6 paths running at 7.5 MegaMD5/s (which is more or less my second instance), I lose - according to my calculations - almost half an hour whenever I close it (assuming I ran it long enough to get nearly a random distribution)...

[jlcooke]

Originally posted by Mystwalker
Maybe an option "When save progress state?" with values like "every [x] minutes" and "whenever a DP is found" (like it is currently the case) would be a good interim solution.

Given a client with 6 paths running at 7.5 MegaMD5/s (which is more or less my second instance), I lose - according to my calculations - almost half an hour whenever I close it (assuming I ran it long enough to get nearly a random distribution)...

Humm. 1 DP every 2^32. 7.5 MegaMD5/sec. 572.6623 sec per DP. 9.5 min. Average lost time - about 5mins. Is this still ok for you?

[Mystwalker]

Originally posted by jlcooke
Humm. 1 DP every 2^32. 7.5 MegaMD5/sec. 572.6623 sec per DP. 9.5 min. Average lost time - about 5mins. Is this still ok for you?

Well, AFAIK you have to spread the 7.5 MegaMD5/s over all six paths - thus the time lost is six times a big, isn't it?

[jlcooke]

Originally posted by Mystwalker
Well, AFAIK you have to spread the 7.5 MegaMD5/s over all six paths - thus the time lost is six times a big, isn't it?

7.5MegaMD5/sec is accross all 6 paths, but that doesn't change the statistical expectation of 1 dp in every 2^32 md5s

[Mystwalker]

Right, but I'm statistically losing 0.5 DPs for every path - thus 3.0 DPs...

[jlcooke]

Originally posted by Mystwalker
Right, but I'm statistically losing 0.5 DPs for every path - thus 3.0 DPs...

If you watch your md5_send.xml file... you'll see it get written to once every 9min or so. 'nuf said. ;)

[Mystwalker]

Originally posted by jlcooke
If you watch your md5_send.xml file... you'll see it get written to once every 9min or so. 'nuf said. ;)

Ah, after some investigation, I know what you mean:

Whenever a DP is found, the current MD5 hash of all paths is written to the md5_save.xml. That way, I really only lose approx. 4.5 minutes, which is quite acceptable. :thumbs: Thanks for pointing that out.:cheers:

edit: I just saw that I already had this knowledge in my 2nd posting of this thread :bang:

Only problem I can see now are slow machines with above-average DP distances on all paths:
The PC I'm currently on is a P3/800 of the university. It uses a 3 paths Core and had to run ~40 minutes before finding the first DP (distance: 6.26 GigaMD5). Assuming I always log on only for half an hour, there would be no progress at all, right?

[jlcooke]

Originally posted by Mystwalker
Ah, after some investigation, I know what you mean:

Whenever a DP is found, the current MD5 hash of all paths is written to the md5_save.xml. That way, I really only lose approx. 4.5 minutes, which is quite acceptable. :thumbs: Thanks for pointing that out.:cheers:

edit: I just saw that I already had this knowledge in my 2nd posting of this thread :bang:

Only problem I can see now are slow machines with above-average DP distances on all paths:
The PC I'm currently on is a P3/800 of the university. It uses a 3 paths Core and had to run ~40 minutes before finding the first DP (distance: 6.26 GigaMD5). Assuming I always log on only for half an hour, there would be no progress at all, right?

Statistically, you should expect to need 4.295 GigaMD5 for each DP. So yes, if the md5crk client stopped and started each time, you would see little/no progress. That's why you shoujld run it as a windows service (Win2k/WinXP) so it will run no matter who is logged in.

[Mystwalker]

Originally posted by jlcooke
That's why you shoujld run it as a windows service (Win2k/WinXP) so it will run no matter who is logged in.

I'd love to, but I don't have admin rights on the university computers. :(
And locking computers is not liked by my fellow students. ;)

An idea recently came to my mind:
How about a button, which - when pressed - writes the current progress into the md5_save.xml?
I'm not sure if this degrates performance though, as your GUI currently is output-only...

Note:
I hope that I don't annoy you with my questions/suggestions. I just want to get some insight into the projects I'm participating in (technical side included), try to help improve it and to evaluate the options I have. And I really like your project + the client! :thumbs:

[Digital Parasite]

Mystwalker, my md5GUI has a "Stop" button on it which will ask the client the quit and save its current state. Is that what you are worried about, having to quit from the client and it not saving the latest progress it has made?

This should work with the 1.0.7 client which has not been released yet.

[jlcooke]

Originally posted by Mystwalker
I hope that I don't annoy you with my questions/suggestions. I just want to get some insight into the projects I'm participating in (technical side included), try to help improve it and to evaluate the options I have. And I really like your project + the client! :thumbs:

Never. Keep them coming. I will answer just about any question that is thrown at me.

[Mystwalker]

Originally posted by Digital Parasite
Mystwalker, my md5GUI has a "Stop" button on it which will ask the client the quit and save its current state. Is that what you are worried about, having to quit from the client and it not saving the latest progress it has made?

This should work with the 1.0.7 client which has not been released yet.

That's exactly my concern. I can hardly wait for that version. :)


Originally posted by jlcooke
Never. Keep them coming. I will answer just about any question that is thrown at me.

Good to hear. :cheers:

[[GP]GP500]

if i put this on our teampage, are the points found too be added too our team-score.

[Mystwalker]

Originally posted by [GP]GP500
if i put this on our teampage, are the points found too be added too our team-score.

The website has to be registered to one member. Each DP found through the website will be counted to him (and via him to the team he's in).