[POOL][Scrypt][Scrypt-N][X11] Profit switching pool - wafflepool.com

[vivalite]

The "more RAM is needed" thing is pure unfounded bullshit.

If someone is only interested in mining scrypt or vertcoin (At its current N factor), I will say you are correct.  Vertoin's N factor will eventually change (at the same pace as glaciers move - across land)

On other coins, that increment their N factor regularly, some are up to N=14.  If you get more than 2 cards that run 4GB each, you'll want to have 8 GB system ram.  The miner software has to allocate the scrypt buffer in system memory to start, and allocating a 3.5 GB buffer for 3, 4, or 6  cards just doesn't fit into 4 GB of RAM.

I just fired up 5x R9 290 cards at N=12,13, and 14, with 4GB of system memory for several minutes at each N.  Seemed to compile/load the kernel and hash fine.  This might not be the case on windows, mind you - I run a custom gentoo install on all my rigs.

Just interest to know. Is your Linux 64bit? My BAMT (32bit) on 4GB memory just shows me less than 2.6GB available.
what is your "cat /proc/meminfo"?  Thank you.

[1714227275]

1714227275

[1714227275]

1714227275

[Thirtybird]

You absolutely do not need more RAM to hash...  I never run more then 4GB of ram on a rig, and I average over 900KH/s/card at scrypt(1024,1,1) and 450KH/s at scrypt(2048,1,1) on my R9 290s.  The "more RAM is needed" thing is pure unfounded bullshit.

Is that an absolute statement?  Will it always apply?  

If someone is only interested in mining scrypt or vertcoin (At its current N factor), I will say you are correct.  Vertoin's N factor will eventually change (at the same pace as glaciers move - across land)

On other coins, that increment their N factor regularly, some are up to N=14.  If you get more than 2 cards that run 4GB each, you'll want to have 8 GB system ram.  The miner software has to allocate the scrypt buffer in system memory to start, and allocating a 3.5 GB buffer for 3, 4, or 6  cards just doesn't fit into 4 GB of RAM.

No Thirtybird, clearly phzi is right as phzi is always right.  If you don't believe him, then just ask him.  And who the heck are you to question him anyway.  After all, you only extended cgminer to create yacminer with support for more hashing algorithms, among other various enhancements, and are only intimately familiar with the code, whereas his knowledge knows no boundaries.  So please so not question his intellectual superiority, as we will have none of that here.  HA!

wow, um... thanks?  I appreciate the sentiment, but the tone is really unnecessary.  I would rather have decent information out there and teach people how things work - ego aside.  I used to be wrong on how it worked and had to learn how it actually works as someone who wasn't originially intimately familiar with it.

There's being right, and then there's being a d$#k about it.  I would prefer noone be a d#$k. 

[Thirtybird]

The "more RAM is needed" thing is pure unfounded bullshit.

If someone is only interested in mining scrypt or vertcoin (At its current N factor), I will say you are correct.  Vertoin's N factor will eventually change (at the same pace as glaciers move - across land)

On other coins, that increment their N factor regularly, some are up to N=14.  If you get more than 2 cards that run 4GB each, you'll want to have 8 GB system ram.  The miner software has to allocate the scrypt buffer in system memory to start, and allocating a 3.5 GB buffer for 3, 4, or 6  cards just doesn't fit into 4 GB of RAM.

I just fired up 5x R9 290 cards at N=12,13, and 14, with 4GB of system memory for several minutes at each N.  Seemed to compile/load the kernel and hash fine.  This might not be the case on windows, mind you - I run a custom gentoo install on all my rigs.

What thread concurrency were you running?  It's absolutely possible to fire up a miner at any value of N with 1-2GB per thread, but if your cards have 4GB of ram on each of them and you are firing them up using only 1GB on each, then it's really not a great test.  I'd be happy to create a command line for you that replicates how I run my 4x4GB card system.  I couldn't even fire up a single thread allocating 3.5GB memory per card when I had 4 GB system ram.  Let me know if you want to test it out.

[comeonalready]

You absolutely do not need more RAM to hash...  I never run more then 4GB of ram on a rig, and I average over 900KH/s/card at scrypt(1024,1,1) and 450KH/s at scrypt(2048,1,1) on my R9 290s.  The "more RAM is needed" thing is pure unfounded bullshit.

Is that an absolute statement?  Will it always apply?  

If someone is only interested in mining scrypt or vertcoin (At its current N factor), I will say you are correct.  Vertoin's N factor will eventually change (at the same pace as glaciers move - across land)

On other coins, that increment their N factor regularly, some are up to N=14.  If you get more than 2 cards that run 4GB each, you'll want to have 8 GB system ram.  The miner software has to allocate the scrypt buffer in system memory to start, and allocating a 3.5 GB buffer for 3, 4, or 6  cards just doesn't fit into 4 GB of RAM.

No Thirtybird, clearly phzi is right as phzi is always right.  If you don't believe him, then just ask him.  And who the heck are you to question him anyway.  After all, you only extended cgminer to create yacminer with support for more hashing algorithms, among other various enhancements, and are only intimately familiar with the code, whereas his knowledge knows no boundaries.  So please so not question his intellectual superiority, as we will have none of that here.  HA!

wow, um... thanks?  I appreciate the sentiment, but the tone is really unnecessary.  I would rather have decent information out there and teach people how things work - ego aside.  I used to be wrong on how it worked and had to learn how it actually works as someone who wasn't originially intimately familiar with it.

There's being right, and then there's being a d$#k about it.  I would prefer noone be a d#$k.  

Normally I would not resort to such a tone, but there are certain types of people who only respond from their ego when their stated beliefs are questioned, and I thought it was important to let others here know that some of the advice that phzi has been giving is not entirely accurate, but being presented as absolute.  (just as in the case with you)  Thanks for participating here.  Helpful advice which does not steer others down the wrong path is always greatly appreciated by all.

[phzi]

Normally I would not resort to such a tone, but there are certain types of people who only respond from their ego when their stated beliefs are questioned, and I thought it was important to let others here know that some of the advice that phzi has been giving is not entirely accurate, but being presented as absolute.

You mean people like you... who only respond from their ego? I say to you again, please show me what 'advice' I have offered that was not accurate.  Stop posting non-contextual bullshit without quotes - aka, stop trolling like a fool.

@Thirtybird: please do send me the config inc TC you are talking about.  Would be interested to investigate this further.  I have yet to run into a situation where RAM beyond 4GB was needed with cgminer varients - and I have done lots of testing.

[suchmoon]

What thread concurrency were you running?  It's absolutely possible to fire up a miner at any value of N with 1-2GB per thread, but if your cards have 4GB of ram on each of them and you are firing them up using only 1GB on each, then it's really not a great test.  I'd be happy to create a command line for you that replicates how I run my 4x4GB card system.  I couldn't even fire up a single thread allocating 3.5GB memory per card when I had 4 GB system ram.  Let me know if you want to test it out.

Just to clarify: how exactly does the buffer size relate to the memory size on the card and the N? If you have a link to something that explains this for noobs I'd appreciate it. Thanks.

[comeonalready]

Normally I would not resort to such a tone, but there are certain types of people who only respond from their ego when their stated beliefs are questioned, and I thought it was important to let others here know that some of the advice that phzi has been giving is not entirely accurate, but being presented as absolute.

You mean people like you... who only respond from their ego? I say to you again, please show me what 'advice' I have offered that was not accurate.  Stop posting non-contextual bullshit without quotes - aka, stop trolling like a fool.

There really is something very wrong with you, isn't there?  We're done with this.  If it makes you happy, you can imagine that you "won" something by my decision to drop out of this exchange.  Seems like you need it as some measure of self worth.

[Thirtybird]

What thread concurrency were you running?  It's absolutely possible to fire up a miner at any value of N with 1-2GB per thread, but if your cards have 4GB of ram on each of them and you are firing them up using only 1GB on each, then it's really not a great test.  I'd be happy to create a command line for you that replicates how I run my 4x4GB card system.  I couldn't even fire up a single thread allocating 3.5GB memory per card when I had 4 GB system ram.  Let me know if you want to test it out.

Just to clarify: how exactly does the buffer size relate to the memory size on the card and the N? If you have a link to something that explains this for noobs I'd appreciate it. Thanks.

@suchmoon

https://github.com/Thirtybird/YACMiner/blob/master/SCRYPT-README

starting around line 56.  buffer-size replaces thread-concurrency because all that is really doing behind the scenes is setting the scrypt buffer-size.  Simplification IMHO.

@phzi
my exact configuration command line is as follows:

yacminer --scrypt-chacha --worksize 128 -g 1 --lookup-gap 2 -R 1280 --buffer-size 3040 --auto-gpu --temp-target 70 --temp-overheat 76 --gpu-engine 900-1100 --gpu-memclock 1000 --gpu-powertune 20 -o stratum+tcp://yac.m-s-t.org:3333 -u Thirtybird.R7240 -p x

Now, this doesn't even try to push the memory boundary on each card because with the number of shaders those R7 240's have, it's not necessary at N=14.  For N=15 I will need to increase the buffer-size.  I haven't found the top of buffer-size, but to push the buffer-size a bit, I can use --buffer-size 3664.

To interpret this for cgminer, you'll need to change a few things - probably something like this...

cgminer --scrypt --worksize 128 -g 1 --lookup-gap 2 -I 12 --thread-concurrency 58624 <pool parameters> <nfactor settings>

it will probably be about the same for vertminer.  The parameters that affect the scrypt buffer are thread-concurrency and lookup-gap.  You can change anything else you want, but you'll need to use the two values I specified to allocate 3,664 MB per thread (don't use -g 2 [or any number higher than 1]!!!!).  Honestly though, these parameters are independent of what coin you're mining.  Why it doesn't show up at lower n factors is because scrypt mining, and vertcoin mining both require much less RAM by comparison, that setting up to mine those coins is much simpler.

[lagster]

Normally I would not resort to such a tone, but there are certain types of people who only respond from their ego when their stated beliefs are questioned, and I thought it was important to let others here know that some of the advice that phzi has been giving is not entirely accurate, but being presented as absolute.

You mean people like you... who only respond from their ego? I say to you again, please show me what 'advice' I have offered that was not accurate.  Stop posting non-contextual bullshit without quotes - aka, stop trolling like a fool.

is it possible for you two to get married?
or just kiss and post it here as a proof of true manliest friendship.

[suchmoon]

don't use -g 2 [or any number higher than 1]

It is just for the purposes of this experiment, or is there any other reason to use only 1 thread? Most cards that I have seem to perform much better at 2.

[phzi]

To interpret this for cgminer, you'll need to change a few things - probably something like this...

cgminer --scrypt --worksize 128 -g 1 --lookup-gap 2 -I 12 --thread-concurrency 58624 <pool parameters> <nfactor settings>

A TC as high as 58624 won't work on any of my cards.  Right now, I primarily use either 20479 or 28672 , although different values seem to be optimal for different algorithms/clockrates/BIOS versions.  My experience suggests that lower thread concurrency actually yields better results a good portion of the time, and I find the lowest (shaders*n)+1 or -1 value that doesn't produces HW errors often yields the most completed work.

I will pull and build YACMiner on one of my rigs setup later and see what happens when I try your posted settings.

<snip>

comeonalready just needs to:
1> Backup his personal attacks with quotes
2> STFU

I am not looking for a troll war.

[lagster]

I am not looking for a troll war.

i cant sniff for anyone but myself at hetzner, digitalocean and other minor hosters, are you certain that it is possible at all and still possible right now at wp\cm\mp hoster?

[lagster]

Normally I would not resort to such a tone, but there are certain types of people who only respond from their ego when their stated beliefs are questioned, and I thought it was important to let others here know that some of the advice that phzi has been giving is not entirely accurate, but being presented as absolute.

You mean people like you... who only respond from their ego? I say to you again, please show me what 'advice' I have offered that was not accurate.  Stop posting non-contextual bullshit without quotes - aka, stop trolling like a fool.

There really is something very wrong with you, isn't there?  We're done with this.  If it makes you happy, you can imagine that you "won" something by my decision to drop out of this exchange.  Seems like you need it as some measure of self worth.

did i miss your answer to https://bitcointalk.org/index.php?topic=448649.msg5931422#msg5931422, or just like "Hawking once said, "The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge"."

[Thirtybird]

To interpret this for cgminer, you'll need to change a few things - probably something like this...

cgminer --scrypt --worksize 128 -g 1 --lookup-gap 2 -I 12 --thread-concurrency 58624 <pool parameters> <nfactor settings>

A TC as high as 58624 won't work on any of my cards.  Right now, I primarily use either 20479 or 28672 , although different values seem to be optimal for different algorithms/clockrates/BIOS versions.  My experience suggests that lower thread concurrency actually yields better results a good portion of the time, and I find the lowest (shaders*n)+1 or -1 value that doesn't produces HW errors often yields the most completed work.

I will pull and build YACMiner on one of my rigs setup later and see what happens when I try your posted settings.

This is why you were having success then.  To mine YACoin, YBCoin, ZcCoin OneCoin, or anything that's currently at N=14, you NEED as much memory allocated as you can.  That thread-concurrency (58624) is the equivalent of the value I'm able to allocate on my cards.  I could NOT allocate that amount when I only had 4GB on system memory - I was limited to somewhere around a TC of 28000.  I could get the equivalent hash rate by allocating half of what I needed and running half the shaders, but when I added a third card, I couldn't even allocate half on the third card. 

In my experience, I advise anyone who asks to put in 8 GB of system memory for mining scrypt-chacha coins that will be running cards with 4 GB of memory on the card.  My other machine with 4 2GB cards works just fine with 4 GB system memory - it is at the limit though as I'm allocating 1753 MB per card - much more than that and I was having problems.

[utahjohn]

To interpret this for cgminer, you'll need to change a few things - probably something like this...

cgminer --scrypt --worksize 128 -g 1 --lookup-gap 2 -I 12 --thread-concurrency 58624 <pool parameters> <nfactor settings>

A TC as high as 58624 won't work on any of my cards.  Right now, I primarily use either 20479 or 28672 , although different values seem to be optimal for different algorithms/clockrates/BIOS versions.  My experience suggests that lower thread concurrency actually yields better results a good portion of the time, and I find the lowest (shaders*n)+1 or -1 value that doesn't produces HW errors often yields the most completed work.

I will pull and build YACMiner on one of my rigs setup later and see what happens when I try your posted settings.

This is why you were having success then.  To mine YACoin, YBCoin, ZcCoin OneCoin, or anything that's currently at N=14, you NEED as much memory allocated as you can.  That thread-concurrency (58624) is the equivalent of the value I'm able to allocate on my cards.  I could NOT allocate that amount when I only had 4GB on system memory - I was limited to somewhere around a TC of 28000.  I could get the equivalent hash rate by allocating half of what I needed and running half the shaders, but when I added a third card, I couldn't even allocate half on the third card.  

In my experience, I advise anyone who asks to put in 8 GB of system memory for mining scrypt-chacha coins that will be running cards with 4 GB of memory on the card.  My other machine with 4 2GB cards works just fine with 4 GB system memory - it is at the limit though as I'm allocating 1753 MB per card - much more than that and I was having problems.

This is USEFUL information I had suspected I might need to upgrade system RAM in my question regarding mining with alternate kernels.  I will be upgrading to 8G ASAP, 2G only (which works just fine for scrypt) will hamper my success.  Unfortuantely DDR2 which my old Intel DG965RY board uses is WAY more expensive.  However moving to a newer DDR3 board would be much more of an investment I am not going to make  I built my miner using old parts I had on hand ... (other than the GPU's and 1000W PS which I had to purchase.)  Still have 2 pci-e slots available to add cards as panic dumpers sell their GPU's on e-bay  Third card may be pushing my luck regarding PS wattage. Fourth card will definitely need higher rated PS.  As I have mentioned before volt-modding these cards that I have significantly lowered temps and cost to operate.

My old GPU's are 280x and 7950 both have 3G.  Will these be sufficient as N increases over time and will I have to be re-tuning cards every time N goes up?

[Thirtybird]

My old GPU's are 280x and 7950 both have 3G.  Will these be sufficient as N increases over time and will I have to be re-tuning cards every time N goes up?

Depends on the coin you're mining.  If you set it up to allocate 2680 MB or so (just guessing what it might be), you'll be good at lookup-gap = 2 until N=12.  You'll have to fiddle with LG at that point.  Anytime N changes though you want to fiddle with your settings - it's not always obvious what the best settings will be.  Sometimes running a lower lookup gap and limiting the intensity (using --rawintensity) gives better performance than going with a higher LG and using all the shaders.

For YACoin at N=14, My R7 250 GB card started at 1.6 KH/sec using the OLD yacminer.  After I updated the software and figured out how to configure it properly, I found settings that gave me 2.5 KH/sec.  I ran with that for a month before experimenting with lowering the LG by 1 and limiting the shaders.  I got an extra 8% hashrate by doing this.  I will eventually be releasing a spreadsheet or web application for y'all to put your settings into to get the same kinds of results, but it won't be until the algorithms are integrated into YACMiner.  I still have one performance metric to come up with a formula for, but I've got quite a bit of data for it now.

[bbbbbb2014]

Well, they can talk all they want. Maybe Windows needs that much, I don't know. This is BAMT with 4 cards and vertminer:

Mem:   2830160k total,  1320704k used,  1509456k free

PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
20   0  591m  162m  67m S    3  6.0  25:58.63 vertminer


As you can see it's even less than 4GB total, I probably forgot to disable Intel graphics.

Care to share what cards are you using and what hash rate are you able to get?

[suchmoon]

Well, they can talk all they want. Maybe Windows needs that much, I don't know. This is BAMT with 4 cards and vertminer:

Mem:   2830160k total,  1320704k used,  1509456k free

PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
20   0  591m  162m  67m S    3  6.0  25:58.63 vertminer


As you can see it's even less than 4GB total, I probably forgot to disable Intel graphics.

Care to share what cards are you using and what hash rate are you able to get?

270X

~215 KH/s for Vertcoin

[gsrcrxsi]

What's all this talk of another "attack"?? The only attack I'm aware of was the DDOS a few days ago. And I haven't seen pool waffle mention another attack, unless I've missed it.

Sounds like you conspiracy theorists are claiming someone is stealing your hashing power? I've seen no dropping in hashrate reported by waffle. The Hashrate reported by waffle if still on par with what cgminer reads. And I've been running the same config on waffle for over a month without reconfiguring anything.

[suchmoon]

What's all this talk of another "attack"?? The only attack I'm aware of was the DDOS a few days ago. And I haven't seen pool waffle mention another attack, unless I've missed it.

Sounds like you conspiracy theorists are claiming someone is stealing your hashing power? I've seen no dropping in hashrate reported by waffle. The Hashrate reported by waffle if still on par with what cgminer reads. And I've been running the same config on waffle for over a month without reconfiguring anything.

If it's a conspiracy it must be a really good one. You can start here:

https://bitcointalk.org/index.php?topic=433634.msg5853318#msg5853318