20 GH/s from NiceHash was working as 10 GH/s

Encounter a problem related to the pool or have a request for a feature? Post your issue here and we will help you out.
Forum rules
Welcome to the System Support forum! Encounter a problem related to the pool? Post your issue here and we will help you out.

Keep in mind that the forums are monitored by PROHASHING less closely than the official support channels, so if you have a pressing issue, please submit an official support ticket so that our Support Analyst can look into your issue in a timely manner.

We cannot answer financial questions related to your account on a public forum, so those questions should always be submitted through the orange Support button on prohashing.com/about.

For the full list of PROHASHING forums rules, please visit https://prohashing.com/help/prohashing- ... rms-forums.
Post Reply
neman
Posts: 1
Joined: Fri Jul 28, 2017 2:46 am

20 GH/s from NiceHash was working as 10 GH/s

Post by neman » Fri Jul 28, 2017 3:35 am

Hi guys,

Your pool is the best in the world, as I know :) I'm only waiting for all issues to be solved. Please look at my problem.

Yesterday I was mining from NiceHash at the speed of 20 GH/s but at ProHashing the speed was showing as ~10 GH/s. Unfortunately, I noticed that only after ~5 hours and cancelled the order. I've spent 0.16567330 BTC on this order. This means that about the half of this amount was lost.

Username: neman, Password: a=scrypt n=scrypt
Started: 2017-07-27 16:56:04 UTC+2 Ended: 2017-07-27 22:36:34 UTC+2

The questions are:
- is it a bug or restriction?
- if restriction, where it was published?
- could you please compensate the lost amount?

Thanks and best regards.
User avatar
FRISKIE
Posts: 117
Joined: Sun Apr 16, 2017 12:51 pm

Re: 20 GH/s from NiceHash was working as 10 GH/s

Post by FRISKIE » Fri Jul 28, 2017 8:01 am

Cheers neman,

I would just add a quick spot of advice being a fellow NH user - in current days of PH pool issues I myself have found it nearly impossible to run orders above 2 GHs

The reason being the current pool settings which will trigger var. diff. into a kind of runaway behavior that ends above 500K diff - these settings are temporary measures and have indeed been posted and discussed at length in the forum.

If you had an order of 20 GHs this runaway diff. will have definitely ended above 500K and slowed share submissions to a crawl.

If you will set an order of max 2 GHs with a static diff. of 65K the performance will be much better. I would also recommend (at least for now) to set static coin to Bitconnectcoin

Hope this helps!
FRISKE
Post Reply