Yes!  That did the trick.

Seeing a hashrate of about 0.03 khash/s, e.g. 30 hashs/sec - virtually identical to my quad-core CPU - as expected.

Nice to see that validated.

Cassey

Will sgminer support large Ns, like N=16?  The scratchpad would need to be heap allocated, not stack.

IMACredit (http://www.imacredit.org) would love to have GPU support...

Cassey

OK, helps if I use "rpcpassword" instead of "rpcpass"... needed the "server=1" too.

So now its running, decimating anything I try to do on the windows box, but also seeing the CPU validation error.

Off to try and see if I need to set anything special for a GTX 560 Ti.  I'm noticing two messages that are probably relevant:

[2014-09-05 14:40:36] GPU #0: GeForce GTX 560 Ti with compute capability 2.0
[2014-09-05 14:40:36] GPU #0: the 't' kernel requires 3.5 capability!

Hit the web and sure enough, apparently the 560s are too old.

What hashrate are you seeing using the GPUs?

Cassey

Which version of CudaMiner are you using?  I'm getting an odd error:

           *** CudaMiner for nVidia GPUs by Christian Buchner ***
                     This is version 2014-02-28 (beta)
        based on pooler-cpuminer 2.3.2 (c) 2010 Jeff Garzik, 2012 pooler
            Cuda additions Copyright 2013,2014 Christian Buchner
          LTC donation address: LKS1WDKGED647msBQfLBHV3Ls8sveGncnm
          BTC donation address: 16hJF5mceSojnTD3ZTUDqdRhDyPJzoRakM
          YAC donation address: Y87sptDEcpLkLeAuex6qZioDbvy1qXZEj4
[2014-09-05 13:22:39] 1 miner threads started, using 'scrypt' algorithm.
[2014-09-05 13:22:41] HTTP request failed: Failed connect to 127.0.0.1:64096; No
 error
[2014-09-05 13:22:41] json_rpc_call failed, retry after 15 seconds
[2014-09-05 13:22:58] HTTP request failed: Failed connect to 127.0.0.1:64096; No
 error
[2014-09-05 13:22:58] json_rpc_call failed, retry after 15 seconds
[2014-09-05 13:23:15] HTTP request failed: Failed connect to 127.0.0.1:64096; No
 error

user/password/rpcallowip are all set in imacredit.conf and the windows wallet is up and running on the machine.

Any thoughts? 

Thanks for testing.  Let us know and I'll tweet the results!

Unfortunately, most of my GPUs are AMD, not NVidia.  Need to go catch up on cudaminer, its been awhile.

I'm looking on MediaFire that is hosting the wallet and its been downloaded 277 times.

http://www.mediafire.com/download/1vzyh5h0dg5bljh/imacredit-qt.exe

Please try that link directly.  Just  wondering if I garbled it on the website... Nope, download works for me.  Odd.

From the wallet code:

scrypt.h:static const unsigned long int SCRATCHPAD_SIZE = ((1 << (Nfactor + 1)) * 128 ) + 63;

Wondering if that +63 is biting you?  e.g.  your need 2^16+63?

Purely an intellectual pursuit, just curious...  Happy you found a GPU miner that works!

For those just wanting to test a wallet, I'm happy to announce the -testnet functionality has been restored.  You may need to cold sync if you have previously used -testnet.

Github is current now, Windows wallet is being uploaded as I type.

Cheers,

Cassey

I would guess you would need the next step down on cudaminer.  Are you having success with that setting?  e.g. finding blocks?

RE:  Not connecting.

Very odd, we have 3 seed nodes that have never failed any of the development team, one of which was in that list.

The good news is that we have over 120 connections this morning on one of those seeds and the network hashrate is up about 15X over where it was 10 hours ago.  We are still running at minimum difficulty, but I'm seeing blocks tick by fairly quickly now, so we should be getting close to minimum mass.

Keep up the good work!

Cassey

ps. I have a remote node I'll add next time I visit the site as another seed - that should help diversify the network.  

Update:  Think we found it.  Our seednodes were using the default maxconnections of 125 and apparently maxed out.  They have been changed to accept up to 1024 connections now.

On the zero hashes per second issue after doing a setgenerate:

Please wait at least 8 seconds before querying the hashrate.

I'm playing around with different timings now to see if perhaps a bit more patience (like a 30 second delay) will generate more consistent numbers.

Cassey

Update:  Ok, bumping the timing cycle from 4 seconds to 30 seconds absolutely leveled this out.  On my 6-core development VM, with a 5 second cycle, I was seeing the reported hashrate bounce between 0, 20s, 40s, 70s, 120s, then return to 0 and start the cycle again.  With a 30 second measurement cycle time, its holding steady between 72-78 hashes/sec, typically around 75.  Some variation is, of course, expected.

The next release will have this change.  I'll likely push a new wallet out tomorrow morning.

I've also changed the debug.log message to report hash/sec instead of khash/sec.

Cassey

  look like mined one block
It will take an hour
[/quote]

We definitely have not reach minimum mass to achieve target block times.  If you have more idle cpus, please assign them, and ask your friends to do the same. 

If you have GPU rigs mining other coins, consider having their CPUs mine this one, that would help a lot too.

Be calm, don't panic.  The coin is only 2 days old.  Its doing fine.  It just needs time to build up some momentum.

Cassey

That is not unusual, its hashing.  Just check your CPU usage.  Best I can tell its just a base sampling issue associated with the slow hashing rate this coins yields.  On a Unix wallet I watch regularly, I see it bounce around between 0 and 20 or so, occasionally hitting 120, but rarely.  I'll look into changing the units displayed so something more meaningful shows up - perhaps changing it to hash/minute?

For example, from my PC:  http://puu.sh/bkAuV/839742f46c.png  Note is was showing 75 on the previous getmininginfo, then 0.

Its a new coin, I'll work out these type of kinks as we find them.

Update:  Here is the problematic code, now just need to figure out what we can do about it:

Value gethashespersec(const Array& params, bool fHelp)
{
    if (fHelp || params.size() != 0)
        throw runtime_error(
            "gethashespersec\n"
            "Returns a recent hashes per second performance measurement while generating.");

    if (GetTimeMillis() - nHPSTimerStart > 8000)
        return (boost::int64_t)0;
    return (boost::int64_t)dHashesPerSec;
}

CPU.

In theory, with a bit of effort by the GPU miner software developers (like bfgminer, cgminer, and sgminer), GPUs could be used - but no software has been identified that currently supports the high N level used by this coin.  Even when they do, because of the high memory requirements of a N=16 n-scrypt coin, the advantage of GPUs will be limited over CPUs.

Cassey

I agree, that is a risk.  Not sure what anyone can do to prevent that though.

The math works out a bit differently to.  A corporate data center like GAW runs can easily have 1M times as much Scrypt ASIC based mining power as a home user would have with a CPU.  How many botnets are out there that could load a 22MB executable onto a million infected PCs, run it, and not have it show up on the taskbar?  Especially an executable that eats 100% of the systems CPU?

Will some try?  I suspect so.  

Could someone go to Amazon Web Services and rent 1000 VMs to mine?  Of course they could - but even that will hopefully represent a small fraction of the potential miners out there, and it wouldn't be free to the AWS renter.

Admittedly, success of this coin is dependent upon a large number of miners each going in with a relatively small amount of hash rate.  Will that happen?  Well, it won't without a coin to try it with.  It might either on its own, or based on the success of "The Crypto Void" game by 1BillionHex when that becomes available.

Cassey

Please let me know if you find a miner that doesn't stack overflow at N=16.  I have a half dozen GPUs I'd love to assign to IMACredit.

We tried SGMiner, but even at an intensity of 8, it crashed within minutes when N was set to 16.

Cassey

Its running on a real network right now.  Please let me know if you would like a testnet to be brought up.  Initial development was done there, but I'll need to correct a few things to reestablish it since the development team moved on.

Cassey

ps.  I accidentally posted this in the parent folder of the Announcement sub-folder.  More discussion is occurring down there.

More like CPU - yes, GPU - maybe, with a small advantage over CPUs (perhaps 10X, not 200X), ASIC - never.

If ASICs ever get close, say in a few years, a one line change in the source code and a new wallet is all that is required to regain the distance.  This coin has been tested up to N=20, its works just fine.  Also, with current technology and N=20, it hashes at about 1000 Hash/HOUR.  That was not viewed as practical.   N had to be 15 or greater to provide protection from this upcoming generation of ASIC, so N=16 was chosen to give the coin a few years to grow before technology caught up and required a new wallet.

This coin is NOT a Pump & Dump, there is no way for raiders to jump and and mine millions of early 'easy' coins, hold and then dump them.  In fact, early users are penalized just a bit by the slower block times associated with insufficient nethashrate.  Of course, the chances of finding a block are much greater for early adopters, just the rate of block finds on a network level are slower.

So crank up a wallet, run it in background, and come back in a week to check your balance - then rejoice in doing something different and in helping to prove that distributed mining IS the right way to generate coins.

Cassey

Because the true rarity of a coin is defined by the number of coins in existence at any given time.  

If you goal is to own all of the coins, then you are right, don't both.  If after a year, when about 2M coins exist, your subset will still be significant.

This coin has NO half-life, no scams associate with half-lives, etc.

The coin is designed for the long term, not to max out after a few weeks or months of mining.  And if, like some, it maxed out in 24 years, do you really care if it maxes in 24 vs. 48 vs. 96 vs. 1M years?

Cassey

Varies by miner.  For sgminer its a setting in the conf file, but I can attest that sgminer dies with a stack overflow (as expected).

Highly recommend you use the coin wallet to do your mining, either the windows one or the linux one.  Website (http://www.imacredit.org) has the details.

Note that most coins, like vertcoin, use N=11. This coin is MUCH more memory intensive and slower to mine, but its slower for everyone, so remains equitable.

Cassey