1. i am also at slush's, i believe this guy isn't sleeping
if there is a pool problem it is fixed so fast
2. i dont like this "maybe" MHs/sec, i am testing some optimization and i wanted a stable allover measurement so i did some changes
accsum = 0
for chain in self.chain_list:
acc = self.accepted_count[chain]
accsum = accsum + acc
rej = self.rejected_count[chain]
tot = self.nonce_count[chain]
inv = self.invalid_count[chain]
try:
rej_pct = 100.*rej/(acc+rej)
except ZeroDivisionError:
rej_pct = 0
try:
inv_pct = 100.*inv/tot
except ZeroDivisionError:
inv_pct = 0
status += ' | %d: %d/%d/%d %.1f%%/%.1f%%' % (chain, acc, rej, inv, rej_pct, inv_pct)
status += ' | ' + formatTime(time()-self.start_time)
status += ' | %.2f Gn/min' % (accsum/((time()-self.start_time+1)/60))
i removed the id thing because of space, even with the original mine.py the line is becoming to long for a windows-console.... i am thinking about a 2line status-line, but thats not the priority atm
i get 4.7Gn/min with the github code
and 4.8Gn/min with my code
so now its .2f, have to test this over a longer time and i guess the problem of "hanging up" has to do with the python lock() thing
you implemantation of lock() is clean afaik
found some forum posts on the internet with people having problems that 2 threads lock at the same time
but if its really a python bug... we are running on an old version so hard to say
i am doing some testing with a main-thread and only 1 mining thread for 2 chains, because the only part of the code that needs time is the communication-part, everything else i measured with 0.0000 seconds
3. @thirdlight: what OS do you have? and what python version? i guess 2.6.6 or 2.6.7?
4. @fizzisist: forget the last PM i send you yesterday, now i realized that you need to run 2 time mine.py if you have 2 cards
i only have one
