anyone tried running with VIA Padlock extensions?

lfm

full member

Activity: 196

Merit: 104

Quote from: SawEfDir on December 22, 2010, 12:23:29 PM

Quote from: SawEfDir on December 12, 2010, 12:36:14 PM

I'll try other algos now, to see if this behaviour is independent of the selected algorithm or not.

The -4way algo does seem to work alright and successfully generated a few coins within a day or so.

It seems there something wrong with the padlock code for the VIA Nano, at least in 64bit mode.

I dont think it supports 64 bit mode, it is only coded for the via c7 atm. the C7 doesnt have 64 bit support. It should work compiled for 32 bit mode on the nano even if it is a 64 bit os. If you want to get involved, the nano has some extended hash instructions that would be usefull I think to speed it up on the nano. Make a separate sha256_nano module, keep the sha256_via separate for the c7 I think would be best for now.

There may be still some problem with the sha256_via even on the c7 in 32 bit mode. Not sure yet. I am doing a testnet run but no results for certain yet.

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: SawEfDir on December 22, 2010, 12:23:29 PM

It seems there something wrong with the padlock code for the VIA Nano, at least in 64bit mode.

Are you using cpuminer? You need version 0.3.1 for sha256_via fixes.

SawEfDir

newbie

Activity: 11

Merit: 0

Quote from: SawEfDir on December 12, 2010, 12:36:14 PM

I'll try other algos now, to see if this behaviour is independent of the selected algorithm or not.

The -4way algo does seem to work alright and successfully generated a few coins within a day or so.

It seems there something wrong with the padlock code for the VIA Nano, at least in 64bit mode.

lfm

full member

Activity: 196

Merit: 104

Quote from: kabo on December 11, 2010, 06:09:02 PM

How many khashes per second are you currently getting on a via-padlock?

On a via C7 at 1.8 ghz I get 1418 khash/sec on linux

$ cat /proc/cpuinfo
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 13
model name : VIA C7-D Processor 1800MHz
stepping : 0
cpu MHz : 1800.000
cache size : 128 KB

SawEfDir

newbie

Activity: 11

Merit: 0

I've tried that patch to main.cpp you suggested. Here the output from minerd:

Code:

DBG: found zeroes in hash:
7e242ac3d2f4298e502efd7e4b3677cc287114488e1c77c4a1406cba00000000
HashMeter(0): 7994345 hashes, 1587.98 khash/sec
PROOF OF WORK FOUND?  submitting...
PROOF OF WORK RESULT: false (booooo)

The output from patched bitcoind is this:

Code:

proof-of-work check FAILED...
  hash: 9c581ce97e417b9ea6ffb2502041a46ad740a74567e55bbd636d8944cc552995
target: 0000000045120800000000000000000000000000000000000000000000000000

FYI, I'm using bitcoin on a amd64 Debian unstable machine. Both bitcoind and minerd were compiled natively for amd64.

I'll try other algos now, to see if this behaviour is independent of the selected algorithm or not.

kabo

newbie

Activity: 7

Merit: 0

How many khashes per second are you currently getting on a via-padlock?

jgarzik

legendary

Activity: 1596

Merit: 1100

git updated with sha256_via, sha256_4way fixes.

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: lfm on December 05, 2010, 10:52:51 PM

jgarzik:

trying your cpu-miner on via:

bug in main pprogram segment violation: needs extra NULL check for sparse array in parse arg

Code:

                       if (algo_names[i] != NULL &&
                            !strcmp(arg, algo_names[i])) {

Good catch. Applied similar patch.

Thanks for taking a look!

lfm

full member

Activity: 196

Merit: 104

ok in sha256_via.c also align tmp_hash1 to 128 to avoid stack clobber.

btw I am on a via-c7 which is less capable than the via nano (eg no sse2 or 64 bit but also lesser padlock support)

There was another problem in the compiling the sha256_4way.c on my system I had disable some headers that errored when I had no sse support in the compiler thus:

Code:


#include 
#include 

#ifdef WANT_SSE2_4WAY

#include 
#include 
#include 
#include "miner.h"

#define NPAR 32

but I got it working eventually about the same speed as my old version of the main prog and easier to support

lfm

full member

Activity: 196

Merit: 104

jgarzik:

trying your cpu-miner on via:

bug in main pprogram segment violation: needs extra NULL check for sparse array in parse arg

Code:

                       if (algo_names[i] != NULL &&
                            !strcmp(arg, algo_names[i])) {

now it is reporting stack clobbered but I havnt found that yet

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: SawEfDir on December 03, 2010, 04:07:38 PM

Thanks for the info. I'll let the testnet client run for the night. What generate setting should bitcoind have? setgenerate set to true with limit to zero processors, or should setgenerate be set to false?

setgenerate controls the in-client miner. So, it may be set, or not, as you choose.

These external miners use the 'getwork' JSON-RPC call, which works regardless of the setgenerate setting.

SawEfDir

newbie

Activity: 11

Merit: 0

Thanks for the info. I'll let the testnet client run for the night. What generate setting should bitcoind have? setgenerate set to true with limit to zero processors, or should setgenerate be set to false?

jgarzik

legendary

Activity: 1596

Merit: 1100

You may find this patch to bitcoin helpful:

Code:

diff --git a/main.cpp b/main.cpp
index a1865a4..da85b0d 100644
--- a/main.cpp
+++ b/main.cpp
@@ -3273,8 +3273,11 @@ bool CheckWork(CBlock* pblock, CReserveKey& reservekey)
     uint256 hash = pblock->GetHash();
     uint256 hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256();
 
-    if (hash > hashTarget)
+    if (hash > hashTarget) {
+           printf("proof-of-work check FAILED...\n  hash: %s\ntarget: %s\n",
+                  hash.GetHex().c_str(), hashTarget.GetHex().c_str());
         return false;
+    }
 
     //// debug print
     printf("BitcoinMiner:\n");

This will show the proper, byte-reversed hash, and how close you came to the target. That is very helpful in verifying whether or not the algorithm is truly working.

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: SawEfDir on December 03, 2010, 02:08:28 PM

I've tried the cpuminer version 0.2.1 on a VIA Nano machine. I used the "via" algo with a bitcoin running on the testnet. The miner worked, but the results generated seemed to be wrong, debug output pasted in below.
The system is a 64bit Debian unstable machine with a VIA VB8001 motherboards. It's running a stepping 2 VIA Nano. The kernel seems to do a workaround for Nanos with that stepping, perhaps something needs to be done in the miner code, as well.

Code:

HashMeter(0): 16777216 hashes, 1589.69 khash/sec
DBG: found zeroes in hash:
9ec42e51b34b69fc2f7209f3e334afcfa563d1da21647832cd2b312c00000000
HashMeter(0): 6644792 hashes, 1606.76 khash/sec
PROOF OF WORK FOUND?  submitting...
DBG: sending RPC call:
{"method": "getwork", "params": [ "000000016f643cccfaa9574cd1a3369a23da6452fcf296587e4da572a008520300000001f1071376c66751bede719672dd1e9e3b2a3daeec709fc5bcaede21364748d93a4cf93ea21d05106000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000" ], "id":1}
PROOF OF WORK RESULT: false (booooo)

Actually, it looks like it is working, to me. As explained in this thread, cpuminer searches for an approximate number of leading zeroes in the hash.

It then submits that hash to bitcoin, for final verification. Thus, it is normal for cpuminer to find several almost-solutions, before finding a real solution, depending on current difficulty.

The official bitcoin client works this way too -- it stops hashing when a certain amount of zeroes appear. However, it does so silently, whereas cpuminer print something.

SawEfDir

newbie

Activity: 11

Merit: 0

I've tried the cpuminer version 0.2.1 on a VIA Nano machine. I used the "via" algo with a bitcoin running on the testnet. The miner worked, but the results generated seemed to be wrong, debug output pasted in below.
The system is a 64bit Debian unstable machine with a VIA VB8001 motherboards. It's running a stepping 2 VIA Nano. The kernel seems to do a workaround for Nanos with that stepping, perhaps something needs to be done in the miner code, as well.

Code:

HashMeter(0): 16777216 hashes, 1589.69 khash/sec
DBG: found zeroes in hash:
9ec42e51b34b69fc2f7209f3e334afcfa563d1da21647832cd2b312c00000000
HashMeter(0): 6644792 hashes, 1606.76 khash/sec
PROOF OF WORK FOUND?  submitting...
DBG: sending RPC call:
{"method": "getwork", "params": [ "000000016f643cccfaa9574cd1a3369a23da6452fcf296587e4da572a008520300000001f1071376c66751bede719672dd1e9e3b2a3daeec709fc5bcaede21364748d93a4cf93ea21d05106000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000" ], "id":1}
PROOF OF WORK RESULT: false (booooo)

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: sgtstein on November 27, 2010, 09:53:11 AM

Quote from: jgarzik on November 27, 2010, 02:26:46 AM

I had not even gotten far enough to determine why your code lacked the midstate caching stuff

If you have the hardware (I don't), giving my miner a try would be really helpful. I don't even have a simple "it works" confirmation on VIA yet.

If you happen to figure out anything interesting, I'll be happy to integrate it and post a new Windows build.

No problem. I'll see if I can find some time to boot a linux live cd and play with it. Otherwise it's running a Windows build right now.

You don't need Linux... there's a Windows build: http://yyz.us/bitcoin/cpuminer-installer-0.2.zip

sgtstein

member

Activity: 61

Merit: 10

Quote from: jgarzik on November 27, 2010, 02:26:46 AM

I had not even gotten far enough to determine why your code lacked the midstate caching stuff

If you have the hardware (I don't), giving my miner a try would be really helpful. I don't even have a simple "it works" confirmation on VIA yet.

If you happen to figure out anything interesting, I'll be happy to integrate it and post a new Windows build.

No problem. I'll see if I can find some time to boot a linux live cd and play with it. Otherwise it's running a Windows build right now.

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: sgtstein on November 27, 2010, 02:12:21 AM

Quote from: jgarzik on November 27, 2010, 01:31:27 AM

Thanks for the inspiration. After reading this, I added VIA padlock support to my CPU miner.

Cool! Did you ever figure out how to get midstate caching working with it? I thought th C7 were capable of it. I know the Nanos are, but I thought VIA had it somewhere on their site. I'll have to try a Windows build of it.

I had not even gotten far enough to determine why your code lacked the midstate caching stuff

If you have the hardware (I don't), giving my miner a try would be really helpful. I don't even have a simple "it works" confirmation on VIA yet.

If you happen to figure out anything interesting, I'll be happy to integrate it and post a new Windows build.

sgtstein

member

Activity: 61

Merit: 10

Quote from: jgarzik on November 27, 2010, 01:31:27 AM

Thanks for the inspiration. After reading this, I added VIA padlock support to my CPU miner.

Cool! Did you ever figure out how to get midstate caching working with it? I thought th C7 were capable of it. I know the Nanos are, but I thought VIA had it somewhere on their site. I'll have to try a Windows build of it.

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: sgtstein on August 21, 2010, 10:05:03 AM

Download 0.3.10 HERE!!

Thanks for the inspiration. After reading this, I added VIA padlock support to my CPU miner.

Topic: anyone tried running with VIA Padlock extensions? (Read 17108 times)