unforum

[chimera245]

Excellent news Sk1zz.

Are you happy with me taking your code and incorporating it (with further testing) into the client code line?

I should be able to work on this quite quickly now as RL is clearing up - perhaps starting tomorrow night?

[jazzychad]

Assault Benchmarks?

[chimera245]

I did some benchmarking early on in the piece with the 13th Labour client (GuiN has done the Web Site/Marketting but it's lil ole me that did all the development stuff), but really abandoned it as unreliable.

While the throttle is a guide to performance - it is a vague one. The setup of your OS (and what else is running), the processor type you use (AMD runs faster in most situations but does not respond to throttle), and the OS you use (Rosetta == Very Bad) make much more difference.

I think the top numbers I got were just under 9 minutes on a hyperthreaded Intel PIV 3.2Ghz with an environment where basically it was all Windows had to worry about.

[Skizz]

chimera245:
Go ahead - that's why I made the code public. For your information, the Worker.cpp/.h is the file containing the threaded decryption code. Decrypt.cpp/.h contains the UI and thread control - this file will need to be updated to run as a client. You'll probably want to cache pending work units so the decryption doesn't wait on server comunication (i.e. get WUs, dispatch WUs, get next WUs, wait, dispatch new WUs, send result, get next WUs, wait, etc...). At the moment it only stores the keys that produced valid output, not the output/plain text (memory access is so slow).

It did occur to me that the communication with the server will become the bottleneck in this application. But that's another problem

Dranioth:
People have been reporting Work Unit times as quick as 9 minutes on a 3GHz PC. My 3GHz Dual Core PC using this fast client can average a Work Unit every 10-15 seconds. Although it uses all the available CPUs reported by the OS, I don't think a hyperthreaded CPU will gain much advantage over a single core PC. Obviously, doing any foreground work will slow down the decryption - the fast client runs at idle priority which means other applications will get the CPU in preference to the client. If you look at the task manager you'll see the system's idle process is 90% or more most of the time so you shouldn't see any difference in normal day-to-day usage when running the fast client. Laptop users will notice their batteries drain quicker though.

Remember to disable the screen saver if you plan to leave any client running when you're not around!

Skizz

[Skizz]

Just out of interest, would it be possible to submit CPU details to the server (with user permission, of course). I'm just wondering if it's worth doing a 64bit version of the client (i.e. anyone using an AMD64 CPU) as this would again provide a step up in speed due to the single instruction 64 bit rotate (as opposed to the hoops the client currently jumps through) and the extra registers.

Skizz

[mac_monkey]

Well without much knowings of the internal workings of chimera's client, or the correctness of skizz's client It would be excellent if the two can be combined to produce a faster client, if not though-i think everyone's still donea great job with this!

Keep up the work guys!

[Fuseunderground]

Thanks to the 1.03 version (well done again Chimera245)
we have been able to monitor how many units were processed,
registered to our own e-mail address.

I calculated the percentage of the total processed units that I have done.
I was happy to see that this was reducing day by day,
because this meant there were more and more units being processed elsewhere,
[as I have a fairly constant flow of units through 2 (occasionally 3) PC's].

Recently, my percentage of the total has been increasing,
which implies people were running it have stopped or reduced their processing, which is disappointing.

I'm sure there are many of you out there that have processed lots more units than me,
Which means that others are doing even less, but obviously every little helps.

I guess I started typing this to simply share my observations,
But I think now that we need more ways to encourage many more of the ~10,000 active PXC players to participate.

One way could be a leaderboard on the 13th labour website,
(There's nothing like a leaderboard to encourage participation – ask Mind Candy )
Perhaps one board for people running one client,
and one for people with multiple clients (to encourage/not discourage the 'little guy')
This would obviously serve no real purpose, but would help people visualize how much they can affect the task.

Also is it possible to add the number of active unique users (e-mail addresses) to the client as well, as the number of active clients on it's own make it look like there's more people participating than there is (so some people may think 'they have enough help already….')

Anyway those are my thoughts for the day, feel free to ignore them.

Rich

[arnezami]

[Skizz]

The two slowest parts of the code are the key mixing loop (lots of memory read/writes) and the 64 bit integer rotations (conditional branches). As for the relative speeds of the two pipes, I couldn't really say without something like Intel's VTune, which I don't have as it's rather pricey and I'm not working for anyone who's got it (but there is a trial version available which I may download). I would hazzard a guess that the integer pipeline is quicker as the integer unit can dispatch up to two instructions per cycle whereas the SSE can only dispatch one.

The biggest speed up would be to use a 64bit CPU (e.g. AMD-64 / PowerPC G5) as this would eliminate the conditional jumps as well as free up registers.

What's interesting about this algorithm is its unsuitability for SIMD (although I use the SIMD parts I only use them as SISD).

I think Von's clue implies that the encrypted text was created using rccrypt, thus the assumptions about the decryption algorithm are well founded. The only possible option as far as I can see is the xor'ing of blocks together (the -p option I think). This is this only option rccrypt has which isn't specified by the card.

Skizz

[arnezami]

[jazzychad]

Skizz,
What are you using to compile your source code? I've tried running the binary on my machine (win2k), but it fails... I also tried compiling using Visual C++ v6 (old, i know...), but it throws a bunch of errors. Any pointers (haha, pun not intended) on how to compile? I'd really like to play around with this, too.

Thanks.

[chimera245]

[jazzychad]

Yes, but I would hate for the answer to be something like:

<!-- You solved me -->

and miss it solely because we used an alphanumeric set...

Are you looking for decrypted text that is entirely ascii-text? or are you considering ones that at least contain ascii-text?

[chimera245]

Hi,

The alphabet is for the 8 character key not the solution.

For a solution, we are including all values <= '~' I.e. from 0 to 126 - I am excluding DEL (127) and all higher - but this includes all the early crap too.

If the 8 character key happens to be

!@#$%^&*

instead of

8ugg3rM3

we will miss it - but we can cross that bridge at the end if necessary. It is not hard to come up with the work units/processing to go through the remaining combos. I just (and others in this and previous threads) have not thought that this would be necessary.

[Skizz]

jazzychad:
I used MS Visual Studio 2003 to compile it (but it ought work with 2005 express which is free). V6 probably complained about the assembler code. It probably failed on your PC because your CPU doesn't support the SSE2 extension the program uses. It really should check the CPUID I guess.

Skizz