@afr33sl4ve:
you have to start your client with that parameter, it's not a RPC call!!
http://coinplorer.com/PTS/Addresses/PuDmCckuUoPe9wvzTwZb9rABukVFSXnseL

@MrMeow:
because you made 7702 / 1237920 and then 3417 / 572167
you're aware of the randomness of cryptocoin mining?

@drmyfore:
AVX (should be enabled) & something between 20 and 40 threads
you'll have to test this as the ram access probably will become a bottleneck

@ryen123:
thank you

- xolokram

@xrpbtc:
orphans are normal, it's nothing you can prevent 100%
the orphan "streak" was a f---up on the backend of the pool, read the posts about it here

@zvs:
windows binaries are not yet updated, i'll do this later today
the reconnect on rejects is just a (dirty) workaround anyway
i would prefer to find the real origin of the problem and fix that

@MrMeow:
maybe you shouldn't compare rounds with ~60k shares to rounds with 200k+ shares?

- xolokram

if this is true it can be a very helpful information actually

@btc2084:
as you see the rejects come in blockwise (ends on "work received"), there's a bug somewhere (in the miner i ---guess---)
this is a known issues, there's a dirty workaround in the latest github (not helpful for windows user i know)

@recci:
protoshares is 1 year ahead of it's schedule... just saying 

- xolokram

ps. sorry, i dont have much time today for PMs/thread/community/tech support

htop <3

anyway, how are the rejection rates?
has someone tested the 'dirty' workaround commit @github yet?

i just added a small workaround for the rejection problem on whole blocks (auto-reconnecting after 3 rejects in a row) to github.

thx for the information on AVX on EC2, i didn't know that.

to the people who PM me because they are 'not able' to reach the payout barrier, i'll think of a way to execute a manual payout (e.g. using the verify message feature of the miner). give me some time.

@grigower:
i dont understand what you're trying to ask or want to know.

@ahpigsy:
some more detail please.

@grubles:
the stats are update every few minutes when there's activity on the web frontend.

- xolokram

server should be running again
and the miners should reconnect on their own (but checking it is never a bad idea )

wow
nothing to add
 

@cjrhoades:
it's a known issue, it happens on rare occasions on a block round of received work
i'll work on that asap

@Gekko:
maybe your RAM access is the bottleneck
thus using more RAM keeps your CPU waiting for data

@wolf95:
like jedixjarf said, maybe you're using the wrong parameter for your miner

- xolokram