For John the Ripper, @dr jimbob gave you the information: see the benchmarks page and use the
--test command-line flag to make your own measures.
For rcracki-mt, the situation is a bit different. This uses a rainbow table which is a specific kind of look-up table containing, in a size-optimized structure, a lot of precomputed password hashes. Thus, the bulk of the hashing occurs when the table is built (with some other software), not when it is used. There is some hashing at usage time, but less, and hashing is not the only parameter in cracking speed.
Indeed, a rainbow table can be characterized by the number N of password hashes it virtually contains (i.e. there are exactly N distinct passwords which the table can crack; it will always succeed for one of these N passwords, and always fail for all others), and by its "internal chain length" t. The chain length is chosen when the table is built. The average costs are:
- Table size: N/t chain ends.
- Attack cost: t lookups, t2 hashes to compute.
- Table building cost: about 1.7*N hashes, and a complete sorting step over the N/t chain ends.
A "chain end" is a sequence of bits of length a bit above log N, say a dozen bytes each. Depending on some technical details, you can save a factor of 2 in some places, which can matter in practice but does not change the big picture.
Rainbow tables are a variant of an older method with a clearer name: Hellman's Time/Memory Trade-Off. This points out that through the chain length chosen to build the table(s) (the t parameter), you save space (storage size is divided by t) but you increase usage cost (with a simple big table of precomputed hashes, you do one lookup and no hash; with the rainbow table, you do t lookups and t2 hashes for each attacked password hash). The trade-off is really between the available CPU for table building, the size of the hard disks, the available CPU at attack time, and the time taken for each lookup. Lookups are often the bottleneck at attack time: a mechanical hard disk will tolerate about one hundred accesses per second (these are not sequential at all). Of course, SSD offer vastly faster lookups, but are also quite more expensive per stored gigabyte, so the trade-off balance shifts.
Summary: for rainbow tables, "how many" passwords per second is the result of a combination of a several tunable parameters (chain length, but also number of tables and split between tables) and encompasses different hardware characteristics (CPU, disk size, disk technology...) for both the table building and the table usage. There is no simple answer; it really takes a lot of thinking and a lot of tuning with actual hardware -- and, of course, any actual performance result is subject to fast obsolescence due to shifting technologies.
It must be pointed out that rainbow tables are completely defeated by salts (as employed by any decent password hashing function). When salts are properly applied, only brute force with no precomputation can be used by attackers, and with no way to attack several password hashes in parallel; so you are back to John the Ripper.