Pyrit 0.2.3-dev (C) 2008, 2009 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3
The following cores seem available…
#1: ‘CUDA-Device #1 ‘GeForce 8600M GT”
#2: ‘Network-Core @192.168.56.3’
#3: ‘CPU-Core (x86)’
Rev103 that was just committed to svn includes support for clustering multiple machines over the local network. This feature was often requested as it allows to use hardware much more effectively.
How it works:
- Pyrit has a new command ‘serve‘ that starts a server on the current host. A server listens for connections on port 19935 (setup those firewalls…) and can use the local hardware to compute for other clients.
- Clients can use multiple servers and each server can support multiple clients simultaneously.
- This is not a distributed database! The clients transfer their workunits to the servers and the servers compute the results and send them back. Bandwidth is a problem: 10.000 PMKs/s require about 30kb/s from the client to the server and about 300kb/s from the server to the client. This makes internet-connections too slow for most of us…
How to use:
- Get Pyrit-0.2.3-dev from trunk
- On the servers, the machines with the fast hardware:
- Start Pyrit with ‘pyrit serve‘.
- The server uses all available (local!) hardware just like a pyrit-session would do…
- Kill it with ctr+c when you are done. Beware that clients which are still waiting for results from that server will die…
- On the client, the machine that hosts the database:
- Edit ‘~/.pyrit/hosts‘. Add one IP/hostname per line for every server you have.
- Check if the server is reachable by opening ‘http://%5BServer-IP%5D:19935/‘ in your web-browser.
- Run ‘pyrit list_cores‘. It should list the new Network-Cores.
- The servers do not have to be online when you start Pyrit. Inactive servers get ignored…
- Use Pyrit like you would normally do. All functions (benchmark/batchprocess/passthrough) use the servers transparently and without further interaction.
I think the implementation is already quite reasonable; however you should expect some rough edges like unhandled exceptions/crashes caused by network timeouts and such…