Bitcoin Forum
December 05, 2016, 10:53:46 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: anyone tried running with VIA Padlock extensions?  (Read 9348 times)
sgtstein
Member
**
Offline Offline

Activity: 61


View Profile
November 27, 2010, 07:12:21 AM
 #21

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.
1480935226
Hero Member
*
Offline Offline

Posts: 1480935226

View Profile Personal Message (Offline)

Ignore
1480935226
Reply with quote  #2

1480935226
Report to moderator
1480935226
Hero Member
*
Offline Offline

Posts: 1480935226

View Profile Personal Message (Offline)

Ignore
1480935226
Reply with quote  #2

1480935226
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
November 27, 2010, 07:26:46 AM
 #22

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 Smiley  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.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
sgtstein
Member
**
Offline Offline

Activity: 61


View Profile
November 27, 2010, 02:53:11 PM
 #23

I had not even gotten far enough to determine why your code lacked the midstate caching stuff Smiley  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
*
qt
Offline Offline

Activity: 1470


View Profile
November 27, 2010, 06:19:03 PM
 #24

I had not even gotten far enough to determine why your code lacked the midstate caching stuff Smiley  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

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
SawEfDir
Newbie
*
Offline Offline

Activity: 11


View Profile
December 03, 2010, 07:08:28 PM
 #25

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
*
qt
Offline Offline

Activity: 1470


View Profile
December 03, 2010, 07:26:25 PM
 #26

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.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
December 03, 2010, 07:30:04 PM
 #27

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.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
SawEfDir
Newbie
*
Offline Offline

Activity: 11


View Profile
December 03, 2010, 09:07:38 PM
 #28

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
*
qt
Offline Offline

Activity: 1470


View Profile
December 03, 2010, 10:00:41 PM
 #29

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.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
lfm
Full Member
***
Offline Offline

Activity: 196



View Profile
December 06, 2010, 03:52:51 AM
 #30


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
lfm
Full Member
***
Offline Offline

Activity: 196



View Profile
December 06, 2010, 04:14:16 AM
 #31

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 <string.h>
#include <assert.h>

#ifdef WANT_SSE2_4WAY

#include <xmmintrin.h>
#include <stdint.h>
#include <stdio.h>
#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
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
December 06, 2010, 04:19:25 AM
 #32


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!

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
December 06, 2010, 06:01:38 AM
 #33

git updated with sha256_via, sha256_4way fixes.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
kabo
Newbie
*
Offline Offline

Activity: 7


View Profile
December 11, 2010, 11:09:02 PM
 #34

How many khashes per second are you currently getting on a via-padlock?
SawEfDir
Newbie
*
Offline Offline

Activity: 11


View Profile
December 12, 2010, 05:36:14 PM
 #35

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.
lfm
Full Member
***
Offline Offline

Activity: 196



View Profile
December 13, 2010, 03:12:06 PM
 #36

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
*
Offline Offline

Activity: 11


View Profile
December 22, 2010, 05:23:29 PM
 #37

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.
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
December 22, 2010, 06:46:18 PM
 #38

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.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
lfm
Full Member
***
Offline Offline

Activity: 196



View Profile
December 22, 2010, 09:00:50 PM
 #39

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.
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!