Vertcoin - First Scrypt N | First Stealth Address - Privacy without mixer

[DRPD]

What processor do I need - I have CPU, AMD Sempron 145 /2.8GHz/ 1MB Cache/ AM3/


Edit: https://github.com/Paul-Bradley/EasyNode/releases  - There aren’t any releases here

I don't think CPU will be a big issue, it should be quite light on that.

The release is still being uploaded. Should be available in the next 30 minutes or so.

Is this somthing which can be run under VMWare esxi (or converted to esxi)?
Correct me if im wrong, but isn't a personal p2pool the same thing as solo mining, ie, you get paid only for finding blocks and not by shares?

i use a virtual w7 installation on vmware esxi as my p2pool (nothing else installed only p2pool, the phyton stuff and all the mambo jambo needed for and the 3 wallets).

the hypervisor is running on an old Xeon E5504 with 2ghz.
w7 has only 2 cpu cores and 4gb ram assigned (need rest for a sbs and a linux nas running on the same hypervisor)

if all is running and my 4 workers are connected, w7 taskmanager shows about 1-2% cpu and 1.5gb ram usage.
so i guess the p2pool can run on a toaster or an iphone these days with 1 core and 1-2gb ram.
running a public p2pool is a different story ....

[MichBjukenon]

The files are now finished uploading and the p2pool "node in a box" is available (complete with README) at https://github.com/Paul-Bradley/EasyNode

This is preconfigured to triple merge-mine VTC+MON+PLX and is the best way to mine, with the highest possible payouts and zero fees.


A reminder - please vote for MON on CoinedUp at http://www.reddit.com/r/CoinedUp/comments/24yk8a/please_add_mon_vtc_team_release_mergemined_on_vtc/

great stuff as allways ty sir

[guzi]

my GPUs simply come up and report OFFLINE or DEAD, but going back to Scrypt seems to work fine.

Scrypt-N is more intensive and will tax your GPU to the max, chances are that your GPU settings are not stable enough so they keep crashing.

It's somthing more than that, because I have several rigs which run scrypt fine.
I converted to vertminer and they were all DEAD.
I then tried a bunch of setting changes, including removing almost everything and letting vertminer choose the defaults.
Still, everything comes up DEAD, even at intensity 8.
Switching back to Scrypt, everything runs fine again and I get good hashrates at intensity 20.

So, in summary, there is either a problem with how vertminer chooses default values, or with the scrypt-N running on certain brands/models of GPUs.

Then it's a RAM issue, how many and what GPUs are you running and how much RAM are you using?

usao: You do not need to have more than 4GB of RAM per rig, granted, the more the better but it will most likely not solve your problems.  What version of vertminer are you using?  The 5.2 version on the site does not seem to work, at least for me.  I was only able to get 5.3 to work.  Here is the link to the 5.3 download: https://www.dropbox.com/s/5n70hj3izjj64y1/vertminer-0.5.3.zip.  As for the 7850 settings...  those are a bitch.  Here are the settings I got to work and get about 140K from each.

vertminer.exe --scrypt-vert -o stratum+tcp://stratum.vertco.in:8080 -u UserName -p Password -v 1 -w 256 -I 14 -g 2 --lookup-gap 2 --temp-overheat 85 --temp-cutoff 90 --gpu-engine 1000,1000 --gpu-memclock 1300,1300 --thread-concurrency 4096

Hope that helps.  The pain in the ass is getting the thread-concurrency value right.

[usao]

my GPUs simply come up and report OFFLINE or DEAD, but going back to Scrypt seems to work fine.

Scrypt-N is more intensive and will tax your GPU to the max, chances are that your GPU settings are not stable enough so they keep crashing.

It's somthing more than that, because I have several rigs which run scrypt fine.
I converted to vertminer and they were all DEAD.
I then tried a bunch of setting changes, including removing almost everything and letting vertminer choose the defaults.
Still, everything comes up DEAD, even at intensity 8.
Switching back to Scrypt, everything runs fine again and I get good hashrates at intensity 20.

So, in summary, there is either a problem with how vertminer chooses default values, or with the scrypt-N running on certain brands/models of GPUs.

Then it's a RAM issue, how many and what GPUs are you running and how much RAM are you using?

usao: You do not need to have more than 4GB of RAM per rig, granted, the more the better but it will most likely not solve your problems.  What version of vertminer are you using?  The 5.2 version on the site does not seem to work, at least for me.  I was only able to get 5.3 to work.  Here is the link to the 5.3 download: https://www.dropbox.com/s/5n70hj3izjj64y1/vertminer-0.5.3.zip.  As for the 7850 settings...  those are a bitch.  Here are the settings I got to work and get about 140K from each.

vertminer.exe --scrypt-vert -o stratum+tcp://stratum.vertco.in:8080 -u UserName -p Password -v 1 -w 256 -I 14 -g 2 --lookup-gap 2 --temp-overheat 85 --temp-cutoff 90 --gpu-engine 1000,1000 --gpu-memclock 1300,1300 --thread-concurrency 4096

Hope that helps.  The pain in the ass is getting the thread-concurrency value right.

Yes, im using 5.2. I would really rather not have to boost RAM if there is another option as I can only do that by taking another rig offline unless I go buy more which will take time and money.

Did you try letting vertminer self-select the parameters including thread concurrency or did you have to manually specify them?

These are the last set of params I tried to use (unsuccessfully)
"api-allow" : "W:127.0.0.1",
"api-listen": true,
"api-port" : "4028",
"auto-fan" : true,
"expiry" : "1",
"gpu-dyninterval" : "7",
"gpu-engine" : "1200",
"gpu-fan" : "0-85",
"gpu-platform" : "0",
"gpu-memclock" : "1350",
"gpu-powertune" : "0",
"gpu-threads" : "2",
"intensity" : "13",
"lookup-gap" : "2",
"no-pool-disable" : true,
"no-submit-stale" : true,
"queue" : "1",
"scan-time" : "1",
"temp-cutoff" : "85",
"temp-hysteresis" : "1",
"temp-overheat" : "80",
"temp-target" : "75",
"thread-concurrency" : "8193",
"vectors" : "1",
"worksize" : "256"

[usao]

I downloaded the vertminer-0.5.3 and ran your exact command to bypass my CFG file.
3 out of 4 gpu's failed immediately and only 1 ran at single digit hashrate.

[BorisTheSpider]

I am updating the https://github.com/Paul-Bradley/EasyNode repo to include an OVA (Open Virtualisation Format) version of the triple-merge-mining "p2pool node in a box" VM image, so it's easier to import into other virtualisation software. Uploading now and should be available in an hour or so.

[MichBjukenon]

I am updating the https://github.com/Paul-Bradley/EasyNode repo to include an OVA (Open Virtualisation Format) version of the triple-merge-mining "p2pool node in a box" VM image, so it's easier to import into other virtualisation software. Uploading now and should be available in an hour or so.

iv setup easynode and im getting accepted untracked stratum share,is this normal or?

[guzi]

I downloaded the vertminer-0.5.3 and ran your exact command to bypass my CFG file.
3 out of 4 gpu's failed immediately and only 1 ran at single digit hashrate.

Try lowering the intensity to 11.  Are you running 4 7850's on that rig?  Not that it matters but what brand?

[usao]

I downloaded the vertminer-0.5.3 and ran your exact command to bypass my CFG file.
3 out of 4 gpu's failed immediately and only 1 ran at single digit hashrate.

Try lowering the intensity to 11.  Are you running 4 7850's on that rig?  Not that it matters but what brand?

I tried running with I=8, same problem. 3 out of 4 died immediately, although not the same ones as before.
These are XFX 7850s. Im not 100% sure if they have 1G or 2G memory, ill have to wait till I get home to see the box.
This is the settings I just tried again:
"api-allow" : "W:127.0.0.1",
"api-listen": true,
"api-port" : "4028",
"auto-fan" : true,
"expiry" : "1",
"gpu-dyninterval" : "7",
"gpu-engine" : "1000",
"gpu-fan" : "0-85",
"gpu-platform" : "0",
"gpu-memclock" : "1300",
"gpu-powertune" : "0",
"gpu-threads" : "2",
"intensity" : "8",
"lookup-gap" : "2",
"no-pool-disable" : true,
"no-submit-stale" : true,
"queue" : "1",
"scan-time" : "1",
"temp-cutoff" : "85",
"temp-hysteresis" : "1",
"temp-overheat" : "80",
"temp-target" : "75",
"thread-concurrency" : "4096",
"vectors" : "1",
"worksize" : "256"

[usao]

I am able to manually enable the GPU's, but they show 0 KHs. If I try to use the restart command, they go offline.

How much system memory is needed? I was under the impression that all the mining was on the GPUs and the system ram was just to run the OS. Someone earlier recomended using 8Gb, but I don't understand why that would be needed. The host CPU isn't doing anything but passing packets between the GPUs and the pool or am I wrong?

[guzi]

I am able to manually enable the GPU's, but they show 0 KHs. If I try to use the restart command, they go offline.

How much system memory is needed? I was under the impression that all the mining was on the GPUs and the system ram was just to run the OS. Someone earlier recomended using 8Gb, but I don't understand why that would be needed. The host CPU isn't doing anything but passing packets between the GPUs and the pool or am I wrong?

If you completely remove the --gpu-engine and --gpu-memclock portion do all 4 of them work?  Those settings may be a little high for the XFX cards, try leaving them out and if that works, add them back but at a much lower level, like 800.  I'm not completely sure about the system memory part, I know scrypt-n uses more memory than just plan scrypt but I haven't had any problems with only 4GB per rig.

[BorisTheSpider]

iv setup easynode and im getting accepted untracked stratum share,is this normal or?

Your connection to the node may be a little flaky (or the node might be struggling for CPU or RAM), here's what untracked stratum shares mean:

When cgminer sends shares via stratum, it does not send the share and then wait for the response as this might slow down the sending of other shares. This means that the response back from the pool is processed separately from the share submission (to make the most of a truly multithreaded environment). However there is never a guarantee that the responses come back in the same order you send them. So cgminer stores a copy of each share as it sends it to the server in its own local database of submitted shares. When it gets a response back about that share from the pool, it deletes the copy of that share. Now stratum is meant to be an uninterrupted connection to the pool, and if you lose that connection, it is assumed that your "session" is no longer valid. So if you send some shares and get disconnected before you get a response, cgminer has to assume that those shares have been lost - otherwise it may end up keeping copies of heaps of shares that it will never get a response to and wastes memory. If you manage to reconnect, sometimes the pool will actually tell you "oh by the way those shares are ok" - however cgminer has now thrown out the record of what those shares were and can only say that the pool said a share was accepted or rejected. Then cgminer just says it's an "untracked share"." (c) ckolivas

In other words, it probably won't affect your profitability - the share got there, but the connection dropped (perhaps just momentarily) from the miner to the node before it could be acknowledged, so now it got acknowledged later and the miner no longer knows which share it was. Best thing to do is probably keep an eye on payouts and see if they seem OK, and/or increase the RAM allocation to the node VM

[usao]

I am able to manually enable the GPU's, but they show 0 KHs. If I try to use the restart command, they go offline.

How much system memory is needed? I was under the impression that all the mining was on the GPUs and the system ram was just to run the OS. Someone earlier recomended using 8Gb, but I don't understand why that would be needed. The host CPU isn't doing anything but passing packets between the GPUs and the pool or am I wrong?

If you completely remove the --gpu-engine and --gpu-memclock portion do all 4 of them work?  Those settings may be a little high for the XFX cards, try leaving them out and if that works, add them back but at a much lower level, like 800.  I'm not completely sure about the system memory part, I know scrypt-n uses more memory than just plan scrypt but I haven't had any problems with only 4GB per rig.

Removing the engine/memory settings had no effect. I only got 1 out of 3 running, even at intensity 8.
Notably, when running scrypt, the engine is set to 1200 and the memclock to 1350. Perfectly stable, runs for days generally.

[ymer]

Try with more RAM or remove some of the GPUs and see for yourself 

[leiman]

Try this with kernel zuikkis , maybe for 7850 you need a lower values :
http://blog.supercrypt.co/2014/03/latest-sgminer-compiled-from-veox.html
I am getting 340Kh/s per card from my asus 7950
engine : 1100
memory : 1650
volts : 1100
temp : 66-70
fan rpm : 35%
here is my .bat settings :
sgminer.exe -o stratum+tcp://p2pool.vtcpool.co.uk:9555 -u xxxxx -p xxxxx --nfactor 11 -w 256 --thread-concurrency 8192 --xintensity 4 -g 2 --lookup-gap 2 --expiry 1 --scan-time 1 --queue 0 --kernel zuikkis

[bengx]

That buy order  


Edit: Aaaaaand it's gone.

[Kalizar]

That buy order  


Edit: Aaaaaand it's gone.

Go back a few pages where I told people to buy in around .60 USD =)

It's still not too late folks!

[MichBjukenon]

its gona explode soon 

[MichBjukenon]

iv setup easynode and im getting accepted untracked stratum share,is this normal or?

Your connection to the node may be a little flaky (or the node might be struggling for CPU or RAM), here's what untracked stratum shares mean:

When cgminer sends shares via stratum, it does not send the share and then wait for the response as this might slow down the sending of other shares. This means that the response back from the pool is processed separately from the share submission (to make the most of a truly multithreaded environment). However there is never a guarantee that the responses come back in the same order you send them. So cgminer stores a copy of each share as it sends it to the server in its own local database of submitted shares. When it gets a response back about that share from the pool, it deletes the copy of that share. Now stratum is meant to be an uninterrupted connection to the pool, and if you lose that connection, it is assumed that your "session" is no longer valid. So if you send some shares and get disconnected before you get a response, cgminer has to assume that those shares have been lost - otherwise it may end up keeping copies of heaps of shares that it will never get a response to and wastes memory. If you manage to reconnect, sometimes the pool will actually tell you "oh by the way those shares are ok" - however cgminer has now thrown out the record of what those shares were and can only say that the pool said a share was accepted or rejected. Then cgminer just says it's an "untracked share"." (c) ckolivas

In other words, it probably won't affect your profitability - the share got there, but the connection dropped (perhaps just momentarily) from the miner to the node before it could be acknowledged, so now it got acknowledged later and the miner no longer knows which share it was. Best thing to do is probably keep an eye on payouts and see if they seem OK, and/or increase the RAM allocation to the node VM

ty boris,you have always been a gentleman

[bengx]

That buy order  


Edit: Aaaaaand it's gone.

Go back a few pages where I told people to buy in around .60 USD =)

It's still not too late folks!

It's back again for 13402.43393370 VTC at 0.00190 BTC/VTC, 25.46462447 BTC worth!