yes, you should be able to use that port i just wrote up there
hmmm, I’m confused about the -l parameter. If I pass zec-eu, then the program automatically extends it to zec-eu.suprnova.cc:2142
So is an IP address accepted? What’s the correct command line exactly?
ah it depends which version of the miner you take, but usually it should be
nheqminer -l 37.187.150.11:80 -u myuser.myworker -p x
not all miners accept the -l string though, linux does
I need 0.3a on windows. It’s not working: it’s trying to connect to 37.187.150.11:80.suprnova.cc:2142 
Furthermore, I need to setup the proxy in some way: no IP can be reached but via proxy. How can nheqminer be configured to access the network through a proxy?
Is there any problem with the pool right now? In the last 4 hours I’ve got only half of the coins calculated with my hashrate.
the luck on the pool was bad last hrs…also lost about 0.3 btc in mining with less amount…1 hr later i made 0.3 btc back with mining so…bad timing
Sry, I misread. I thought you were talking about the website not reachable… 
@ocminer, any idea on proxy settings?
whats going on chaps… coinage been frozen for an hour even tho im hashing like fuck
1 Like
Took an hour to find the next block.
2 Likes
Diff up, luck down… Happens
thanks
genoil working a treat on supernova pool
-k zec zec giving me a steady 30s/s
Could you maybe fix the formula for time to find block, luck etc.? You have to use 2^13 instead of the ‘conventional’ 2^32.
It’s on my list, I had to do several tweaks because of the kH/s → H/s (or Sol/s) conversion
market… seems a bit of trading going on just now … sadly no spikes tonight… what you think ? hold or sell
1 Like
For those using genoil. If you want to get rid of the 0 Sol/s drops, use a fixed diff. I am still on v0.5, simply because it runs now for more than 24h without any issues. Actually it still drops to 0 Sol/s but only once every 24h when the router reconnects. I think genoil fixed that in v0.6 though I haven’t tried that because when it runs I won’t touch it.
You want to use d=64 for any recent card that can do 25 Sol/s or faster. Probably even d=128 for the faster ones. See screenshot how it should look like. If you get more submitted/accepted lines increase the diff. Wait a few minutes after start to evaluate if you submit shares too frequent or too infrequent.
Example: -p d=64 instead of -p x
If you use a too low fixed diff, say 32 or 16, you will get lots of 0 Sol/s errors.
This bug is obviously related to the diff. The lower it is in a vardiff setup, the more frequent it triggers. This is why it occurs most often after a reconnect (following a 21 error) because that’s when vardiff is low. Or simply in the first minute after starting the miner. And it also explains why some pools are not affected or much less affected, simply because they are probably setup to serve higher diff jobs.
As I said, using a high enough fixed diff completely eliminated the bug for me.
2 Likes
how do you get the double/triple instances ?
What multiple instances? That’s a rig with 4 cards, nothing else. No -k zec zec at all because on Nanos zec zec will drop the hashrate by 15% and increase power draw by 20%. Even though the Nanos have 4GB and can run two instances. It just makes no sense, at least how it is implemented in the current genoil. Obviously a bottleneck somewhere.
1 Like
i get you man okay cheers
1 Like
suprnova rules zcash:
Click on Miner Distribution.
That monster miner which previously was pushing 500 kSol/s and now has an unbelievable 800 kSol/s clearly helps.
That’s more than 20,000 GPUs!
ETH/ETC hashrates have collapsed as a result of the miners migration to ZEC. The hashrate bloodbath at other coins will continue for another four weeks at least.