distributed cracking: relation between -s/-l value and Restore.Point value when cracked

[ytbe.use3]

You shouldn't make this type of connection between -s/-l value and the value you see at the time the hashes were cracked in the Restore.Point line (there are additional features that might influence it... like markov etc!, you could try with --markov-disable).

Please use --outfile-format 11 up to --outfile-format 15 to see the exact crack position.

To sum up, you shouldn't really worry about which node cracks the hashes etc, there might be further factors that influence it a little bit.

Sure. So, you say that, dividing as you described here https://hashcat.net/forum/thread-6448-po...l#pid34346 will make sure that only one of the nodes cracks the password. Right?

Also, I am assuming that the keyspace can be divided unequally with the same example you described in the above link (off course, without overlapping keyspace). Please let me know if this can cause some issues. For ex: 

hashcat -m 0 -a 3 --skip        0 --limit 16290126 hash_file.txt ?a?a?a?a?a?a?a  (Assigned twice load)
hashcat -m 0 -a 3 --skip 16290126 --limit 8145063  hash_file.txt ?a?a?a?a?a?a?a
hashcat -m 0 -a 3 --skip 24435189 --limit 8145063  hash_file.txt ?a?a?a?a?a?a?a
hashcat -m 0 -a 3 --skip 32580252 --limit 8145063  hash_file.txt ?a?a?a?a?a?a?a
hashcat -m 0 -a 3 --skip 40725315 --limit 8145063  hash_file.txt ?a?a?a?a?a?a?a
hashcat -m 0 -a 3 --skip 48870378 --limit 8145063  hash_file.txt ?a?a?a?a?a?a?a
hashcat -m 0 -a 3 --skip 57015441 --limit 8145063  hash_file.txt ?a?a?a?a?a?a?a
hashcat -m 0 -a 3 --skip 65160504                  hash_file.txt ?a?a?a?a?a?a?a (Assigned all remaining load)