c/m is more important for your overall performance
sh/m fluctuates depending on the pool configuration

please don't try to kill your hardware!
i don't know if it's a good idea to mine with a laptop

- xolokram

ps. there's a issue with the pool/new miner producing rejects for one round of received work (until the next work is received), this happens rarely, i'll work on that asap

fairy dust payout #1 & #2 - finally confirmed...
payout barrier changed to 0.2

@HaunterV:
windows? you have to edit the .bat file and run it

@goldtiger:
nope, i've not seen the post. i guess they just linked to my github and the current version is using a hardcoded pool address, i should re-add a convenient method for parameters
but i've seen this
"YPool is officially boycotted until they fix the 'bug' preventing them from processing transactions. Please use other pools."
a little too late imho and i guess they won't give a fu--

@lordfirefox:
can you give us more details on your problem?

@Silver_Pharaoh:
v0.5 & v0.4 work too, i'm kinda riddled by your issue...

@xornof / hayz:
thanks for your help / information

@Gekko:
which OS?
let me re-check the no-chrono makefile

@afr33sl4ve:
it's 'normal', because the payouts depend on confirmations of the found blocks. thus if there's a gap between to found block because of the randomness (bad luck) then there will be a gap for the payouts too.

- xolokram

ps. i'll implement the 'pay abandoned addresses' script now

thank you joele

and thank you crz & flashoftheblades <-- give them some hugs (@irc)

@memory settings:
it's highly depending on your system and the bottlenecks that arise from tweaking this parameter; if memory & cpu is fast enough 1024 can be the best solution for you. my tests showed that decent systems are working best with the 512 option. other & older systems may switch to 256 mb (=older) or 2048 (=high-end) or even higher/lower.

@xornof:
thank you for the bug report, will fix this asap
like i said these are not the final v0.7 binaries

the advantage of the sse4 binary for sse3 cpus is caused by the auto-optimization which is enabled in the 4 binaries.
ptsminer_amd.exe & ptsminer_intel.exe include MMX, (3DNow), SSE and SSE2
ptsminer_sse4.exe includes MMX, SSE, SSE2, SSE3 and SSE4.x
ptsminer_avx.exe includes MMX, SSE, SSE2, SSE3, SSE4.x and AVX
thus it looks like we're lucky and the code for the sse4 binary has been optimized using up to SSE3, giving you a small advantage over the _amd and _intel version (using SPHLIB)
if it would use SSE4 instructions (which is possible, because i compiled it with SSE4 support) too, it would crash on your SSE3 cpus

@miner: in general
there's still enough room for optimization, e.g. i found a sse3 version for the sha computation (but i'll have to check the code first). i'm not sure about the avx binary and bulldozer cpus, i think i should split this binary into avx-intel and avx-bulldozer to give the binaries a small extra boost.

also i'll have to re-enable the auto-detection for sse4/avx for the linux build.

but first i'll create the "payout abandoned addresses"-script today (later today, it's sunday, pts has to wait a little )

- xolokram

@yago:
send me a pm (as a reminder with the information i'll need)

@ram usage:
more ram is better, when the ram is fast enough!!

@seraphim:
still having problems with the latest github commit?
maybe make a fresh&clean clone

@ptsminer:
new windows version out (it's not final yet, still testing)
http://www.mediafire.com/download/52fdhw2c3ny81ti/ptsminer_v07a_x64_bundle_new.zip
now containing several binaries: generic (amd / intel), sse4 and avx
for more information please read: http://bitsharestalk.org/index.php?topic=234.msg9657#msg9657

LATEST GITHUB / LINUX USER:
with the current version @github you'll have to set the mining code manually as parameter, read the updated thread post (see above) or binary help (auto-detection will be fixed soon)

@network difficulty:
 

- xolokram

ps. i'm off now, see you tomorrow, keep calm, don't panic, everything will be fine

it's not slowing down (or at least it shouldn't from a coding perspective)
but the counter had a bug, showing wrong values after a connection loss / reconnect
pull the latest github update 

i'm sorry for the inconvencience

btw. last pool software restart (crash?) was 6 hours ago!

so the "decreasing" performance is was just a stupid bug in the counter or to be more precise, like i mentioned before, the col/min & sh/min counter was not reset properly on a connection loss
i fixed that with the last github commit, i'll update the windows binary in a few minutes


if your miner states ~1400 shares and the last blocks contains less than that, then the submission didnt reach the server

/edit1:
OR

the only thing i can image of is that the pool software crashed sending some of the shares of the current round into nirvana (for all users)
let me check the time of the last restart of the pool software
(this should also be the cause of your connection loss & buggy col/min+sh/min reset)

- xolokram