numeric 1-12

charSetLen = 10
bFpoint = 10,000
keySpace = 1111111111110 = 2^40.02
stepSpeed = 0.5*10^9

config1
4 perfect tables, 99.9%
tableWorkFactor1 = 12.78300
chainLen1 = 7453
chainCount1 = 1905720291
expectedUniqueChains1 = 257825920
non-perfectTableSize1 = 28.398 GiB
non-perfectTableSetSize1 = 113.592 GiB
perfectTableSize1 = 3.841 GiB
perfectTableSetSize1 = 15.36 GiB
p&iTableSize1 = 2.095 GiB
p&iTableSetSize1 = 8.379 GiB
p/non-p = 0.1353
p&i/p = 0.546
p&i/non-p = 0.0737
tableGenerationTime = 7.89 h
tableSetGenerationTime = 31.56 h

config2
5 perfect tables, 99.9%
tableWorkFactor = 4.48860
chainLen = 6667
chainCount = 748062596
expectedUniqueChains = 230577503
non-perfectTableSize = 11.147 GiB
non-perfectTableSetSize = 55.735 GiB
perfectTableSize = 3.436 GiB
perfectTableSetSize = 17.18 GiB
p&iTableSize = 1.892 GiB
p&iTableSetSize = 9.459 GiB
p/non-p = 0.30824
p&i/p = 0.5507
p&i/non-p = 0.1694
tableGenerationTime = 2.77 h
tableSetGenerationTime = 13.85 h

config3
6 perfect tables, 99.9%
tableWorkFactor = 2.72220
chainLen = 6085
chainCount = 497069296
expectedUniqueChains = 210524458
non-perfectTableSize = 7.407 GiB
non-perfectTableSetSize = 44.442 GiB
perfectTableSize = 3.137 GiB
perfectTableSetSize = 18.822 GiB
p&iTableSize = 1.743 GiB
p&iTableSetSize = 10.453 GiB
p/non-p = 0.4236
p&i/p = 0.5554
p&i/non-p = 0.2352
tableGenerationTime = 1.68 h
tableSetGenerationTime = 10.08 h
config1 vs. config2
p&iTableSetSize1 / p&iTableSetSize2 = 8.379/9.459 = 0.885823 = 88.59 % ( -1.08 GiB )
tableSetGenerationTime1 / tableSetGenerationTime2 = 2.2787 = 227.37 % ( +17.71 h )

config2 vs. config3
p&iTableSetSize2 / p&iTableSetSize3 = 0.9049 ( -0.994 GiB )
tableSetGenerationTime2 / tableSetGenerationTime3 = 1.374 ( +3.77 h )

config1 vs. config3
p&iTableSetSize1 / p&iTableSetSize3 = 0.8016 = 80.15 % ( -2.074 GiB )
tableSetGenerationTime1 / tableSetGenerationTime3 = 3.1309 = 313.09 % ( +21.48 h )

In English :
config1 is 88.6% the size of config2 ( you save 1 GiB if you use config1 ), but it takes 18 h longer to create config1.

config2 is 1 GiB smaller than config3, but it takes 4 hours longer to create config2.

config1 in 2 GiB smaller than config3, but it takes 21.5 hours longer to create config1.

That's why I suggest using 5 perfect rainbow tables.
We should do the following config.

config4
chainLen = 6000
chainCount = 831222222
expectedUniqueChains = 257000000
tableSuccessRate = 0.7504161938565632
tableSetSuccessRate = 0.999032 = 99.9032 %
bFpoint = 12344
perfectTableSize = 3.83 GiB
perfectTableSetSize = 19.148 GiB
p&iTableSize = 2.088 GiB
p&iTableSetSize = 10.442 GiB

Sc00bz, freerainbowtables.com is creating perfect tables ?
650 milion chains - perfect chains
694 million chains completed - non-perfect, that are perfected in order to get 650 million ?
i don't get it, because chainCount / expectedUniqueChains is much higher than 694/650

* Sc00bz, is freerainbowtables.com creating perfect tables ?
I'm like 99.9999% sure that we are.

* 650 million chains - perfect chains; 694 million chains completed - non-perfect, that are perfected in order to get 650 million?
No, that's 650 million perfect chains and 694 million perfect chains.

* i don't get it, because chainCount / expectedUniqueChains is much higher than 694/650
By the time the server realized that the table was done and started on the next table it got 44 million extra perfect chains.

so those 44 million extra chains are added to the table ? (i hope they are)

Yes they are.

creating 5 tables vs 4, will that increase cryptanalysis time? though i guess its hard to tell since cLength and Count are different.

You need to look at success rate to determine the optimal number of tables. I'm pretty sure that 5 tables is the optimal time-memory trade off for the success rate of that table set. I found the optimal time-memory trade off for a 99.9% success rate table set is 4 tables for both non-perfect and perfect table sets. viewtopic.php?p=10969&f=2#p10969

This table set is 99.9816%, if you use just 4 out of 5 of those tables it's 99.8974%. So I'm pretty sure 5 tables is the optimal time-memory trade off for 99.9816%.

** I'm guessing on this **
In general the least number of perfect tables to achieve a given success rate is the optimal time-memory trade off (for doing a look up). Also the number of non-perfect tables is the same as the perfect tables. Now if you want a success rate of 86.4646% then the optimal number of perfect tables is 1, but it will take forever to generate that table as your work factor will be the same as your chain length (a few thousand vs 13 [roughly the table work factor for most tables FRT has done in the past]). Also the shortest time to generate a table set for a given success rate is to have each chain be it's own table which will make it take forever to do a look up.

The "optimal time-memory trade off (for doing a look up)" does not account for false alarm checking because I don't know the formula for this and I have not taken the time to derive it. Ohh also this does not account for disk access which only matters if you search the table by seeking around in the file.