Topic: Ufasoft Miner - Windows/Linux, x86/x64, SSE2/OpenCL, Open Source - page 40. (Read 631117 times)

greetings fellow miners.

I downloaded bitcoin-miner-0.10 and am building it on debian squeeze.
* I added wheezy repository so as to get gcc 4.5.x and g++ 4.5.x
* I downloaded jwasm-latest and built/installed that to /usr/local/bin and extended my path
* I fixed the .asm files to hard-code the language as C

However, I am now stuck with this error at the final stage of linking



the .o files appear to be corrupted:

any ideas please?

thanks very much
Paul

Is there any changelog/source for Windows version?
Binaries shows v0.12, source for linux is v0.10...

hi,

downloaded the exe from ufasofts site and am having difficulty getting it to run (it just crashes on launch)

C:\bitcoin\bitcoin-miner.exe -a 5 -o http://pit.deepbit.net:8332 -u XYZ -p ABC

I got this from deeppit, but am getting the feeling its probably the shortcuts valuves im using that are causing problems

cheers everyone

t

Hi,
I'm running latest 0.12 version. Miner connects fine and starts mining. Returns first result just fine. Then there is series of:
ERROR 80190191
messages.
Then it continues again, returns result and again:
80190191
80190191
80190191

after a while my account is banned and I have to go through un-bun procedure on http://www.bitcoinpool.com/.

I tried these with the same result:
bitcoin-miner.exe -t 2 -o http://bitcoinpool.com:8332/ -u [user] -p [pass]
bitcoin-miner.exe -t 2 -v -o http://bitcoinpool.com:8332/ -u [user] -p [pass]
bitcoin-miner.exe -t 2 -g no -v -o http://bitcoinpool.com:8332/ -u [user] -p [pass]

i think that's the "can't connect to host" error, isn't it?

noob question for anyone out there. finally got pooled mining working using this miner (props to dev, thank you, it's been a headache for a day trying to see some results here). so now i'm wondering- this is just a test, just want to see if it can work, i'm only hashing at .8ish Mhash/s, super slow i know, in the pool mining.bitcoin.cz; i'm wondering in my stats when i should be able to see an estimated reward for current round or whatever. is it too slow to even expect any portion of the block in return? or do i have to wait for the next block or something?

thanks!

"Error 801901F4" - what is this??? 

Use jwasm <=2.04, the latest one (2.05) refuses to compile.

Try one of the GPU miners. This miner is CPU only.

hey Everyone, i'm new to the group and i just playing with bitcoin and its great. i've got it running on a decent rig but its only using the CPUs. i have 4 dual core cpus, 8 logical on an i7 [email protected]. this is ok and i'm getting 14mhash with all cpus pegged.

i have two Radeon 3400 HD cards installed but i don't think bitcoin-miner is using them. i tried running bitcoin-miner with -t 0 to disable cpu but nothing happened. 0%

i should get more out of the video cards than cpu right?

i've already found so much great info here. any help is greatly appreciated

thanks

Al

.... there's nothing wrong with a 64 bit kernel because an obscure program that has missing parts of a 64 bit implementation design doesn't work on it.

It's a bit analogous to "Eff blue-ray players - my Sony MiniDiscs are useless now!"

You can download the source and you are completely free to shim up the assembly.

If you look through the source, you'll see quite a few instances where 64 bit "stuff" was added but never completed.  For example, the language definition not existing for 64 but being present for 32.

I thought 64-bit Linux was ready for prime time -- and if it's not, WHEN will it be?
I was one of the early adopters back in '07, but I gave it up because it didn't seem ready.

Why can't Ufasoft's miner compile in 64-bit? You'd think if everything was 64-bit it would compile fine.

Matthew

I just had to create a new symbolic link to the PCRE library -- I'm off and running now with UFAsoft 32-bit on my 64-bit machine.

I'm getting 18 MH/s on my 2600K (3.4 GHz quad core) CPU.

Hi everyone,

I'm getting a bit of a weird assembler error here on Ubuntu 11.04 with jwasm 2.05 (didn't find any specific version requirements):

However, the respective scale factors in the assembler code are always 4...?
Error occurs both in 64-bit and 32-bit compilation. Any hints?

Thanks,
Florian

I have to give credit to Ufasoft --

My wife's machine (3.3 GHz Sandy Bridge Quad Core, 6 MB cache) maxes out at 17.1 MHash/s
My machine (3.4 GHz Quad Core, 8 MB cache) with the best "runner up" software -- "Cpuminer" with the SSE2 64-bit plugin -- gets 16 MHash/s.

Call me crazy, but I think I could do better with Ufasoft's miner.

Yes, your advice helped.

Here's what I got:

/ufasoft_bitcoin-miner-0.10# ldd ./bitcoin-miner
   linux-gate.so.1 =>  (0xf7737000)
   librt.so.1 => /lib32/librt.so.1 (0xf7709000)
   libdl.so.2 => /lib32/libdl.so.2 (0xf7705000)
   libcurl.so.4 => /usr/lib32/libcurl.so.4 (0xf76b2000)
   libpthread.so.0 => /lib32/libpthread.so.0 (0xf7699000)
   libpcre.so.0 => not found
   libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf75ad000)
   libm.so.6 => /lib32/libm.so.6 (0xf7587000)
   libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf756b000)
   libc.so.6 => /lib32/libc.so.6 (0xf740e000)
   /lib/ld-linux.so.2 (0xf7738000)
   libidn.so.11 => /usr/lib32/libidn.so.11 (0xf73dc000)
   liblber-2.4.so.2 => /usr/lib32/liblber-2.4.so.2 (0xf73ce000)
   libldap_r-2.4.so.2 => /usr/lib32/libldap_r-2.4.so.2 (0xf7389000)
   libgssapi_krb5.so.2 => /usr/lib32/libgssapi_krb5.so.2 (0xf7359000)
   libssl.so.0.9.8 => /lib32/libssl.so.0.9.8 (0xf7311000)
   libcrypto.so.0.9.8 => /lib32/libcrypto.so.0.9.8 (0xf71c5000)
   libz.so.1 => /usr/lib32/libz.so.1 (0xf71af000)
   libresolv.so.2 => /lib32/libresolv.so.2 (0xf719a000)
   libsasl2.so.2 => /usr/lib32/libsasl2.so.2 (0xf7183000)
   libgnutls.so.26 => /usr/lib32/libgnutls.so.26 (0xf70ed000)
   libgcrypt.so.11 => /lib32/libgcrypt.so.11 (0xf7079000)
   libkrb5.so.3 => /usr/lib32/libkrb5.so.3 (0xf6fca000)
   libk5crypto.so.3 => /usr/lib32/libk5crypto.so.3 (0xf6fa6000)
   libcom_err.so.2 => /lib32/libcom_err.so.2 (0xf6fa2000)
   libkrb5support.so.0 => /usr/lib32/libkrb5support.so.0 (0xf6f9a000)
   libkeyutils.so.1 => /lib32/libkeyutils.so.1 (0xf6f96000)
   libtasn1.so.3 => /usr/lib32/libtasn1.so.3 (0xf6f84000)
   libgpg-error.so.0 => /lib32/libgpg-error.so.0 (0xf6f7f000)


I compiled mine on my old 32-bit Ubuntu 10.04 machine, and I kept all my original folders on a backup device.

So compiling it wasn't an issue -- running it is.

What's the easiest way to get 32-bit PCRE library on my PC? Can I compile it on my current 64-bit Linux Mint 11 system?

Matthew

Doing a bit more testing, with aggregate rates of Phoenix + UFASoft, seems 7 threads on 4 real cores + HT is best.

With  7 threads - 1 of my 8 leftover for phoenix (modulo some thrashing of cache/etc due to HT not really being a real core), i get 18.4 on Phoenix (i know, crap, i havent got a real GPU yet, just testing things) + 14 from UFA = 32.4 total, if I use 3 threads (3 real cores) and leave one for phoenix, i only get 20.1 on Phoenix and 11.5 on UFA = 31.6. So faster to share a core with Phoenix.

These slowdowns for phoenix im assuming would be proportionally the same for anyone with a real GPU, tho testing would prove such. If anyone has results, im interested.

note i havent really played with nice levels here either, just running all at nice level 0 (or all at nice 20 and not using the machine for anything else).

( Did my instructions help anyone? Did you use it yourself and verify your claim?)

It was spawning 0 threads and sitting there doing nothing.

And 4 vs 8 - not entirely true, it depends on if the ASM code has already considered the superpipelining of the CoreI7 and has worked with it. If it has not, and is merely agnostic to the CPU and relies on one core acting like a regular CPU, then the in-chip pipelining and dual execution of some instructions may help.

This aint the hyperthreading your grandfather used to enjoy in the Pentium D days It's reborne, and mildly more useful!

How to tell for sure is to let the thing run a bit and compare speeds... sit down for a beer with me while it runs....

ok.... done:

8 threads:
Processed: 81562 Mhash, 5856s with average Rate: 13.9 MHash/s

4 threads:
Processed: 14084 Mhash, 1133s with average Rate: 12.4 MHash/s

16 threads (just for the hell of it):
Processed: 6431 Mhash, 437s with average Rate: 14.7 MHash/s

course this now competes with python for phoenix and makes my GPU miner run slower (why the heck python is at 100% on the cpu for  gpu miner is confusing..)

really i should be running -1 core cuz !!&#!( python is using one core, or i should just stop the GPU to truly know (except, i'd never run UFA without phoenix going too, so... why bother.)

so: 6 threads (3 cores x HT, 1 full core for python phoenix....)
Processed: 4130 Mhash, 315s with average Rate: 13.1 MHash/s

cant say that CPU affinity kept the extra threads off the python core tho, and im too tired to bother trying to set that up... so theorize away...

I might need to run them all longer or something to get better numbers....

anyone care to explain?

If it was spawning 4 threads, then it seems a lot like it figured out the max cores by itself.

Hyperthreading doesn't help you here, you have 4 cores.

HOW TO COMPILE THE UFASOFT SSE2 ASM MINER IN 64 BIT DEBIAN/UBUNTU

I already wrote this then a stray alt/ctrl key + mouse wheel threw me thru ffox's history POST trapdoor and I lost my whole !*@&# post. So redoing here what i JUST wrote. GRRR!!!

1) be root and make a dir to create a 32bit environment in:


2) debootstrap a 32 bit debian sid (unstable/latest) image into it:


takes 3-15 minutes depending on speed to internet cpu, disk etc. Feel free to change mirrors, etc. (Ftp.ca.debian.org in canada, .uk in uk, etc etc.)

(Yes you can debootstrap an ubuntu image, but since its a standalone environment, debian will be fine. Sides it's better Any binaries from it will run fine in ubuntu anyway).

3) chroot into the dir, now you're in a 32 bit environment, and install some tools:


4) make sure you have the jwasm zip file downloaded from somewhere:

17:06 < math>  http://www.japheth.de/JWasm.html (more up to date source than most)

copy the JWASM from it into somewhere on your path as 'jwasm' (lowercase important), you might need to extend
your path. Dont embarass yourself by putting it in /usr/bin, it'll make admins cry (and breaks package management).
At worst put it in /usr/local/bin and add that to your path!


(last line makes sure its executable. make sure it is!)

5) go into the ufasoft source dir and configure it for compilation:

if you have issues, reply here for help. Configure is pretty good about telling you what you're missing.


6) now the makefiles are created but have a buncha x86-64 specific stuff. Need to change that to i386.

This command will do that and show the changes, should be only 2 lines (turned out to be easier than I
thought, didnt need to fool ld, needed to fool jwasm!)


7) COMPILE!!


Should take like 10-15s on modern hardware. You DO have modern hardware right? Or you're wasting your money mining... )
(tho anyone without a gpu is anyway.. hell i think using ANY CPu based mining is probably a waste of extra power )

now you have a ./bitcoin-miner binary. feel free to strip it down to make it smaller:


9)  This will run in this chroot 32 bit environment just fine, but in the 64bit environment you'll need these
packages for 32bit compat: (remember to exit the chroot first with 'exit' to get back to the 64 bit environ)

apt-get install ia32-libs ia32-libs-gtk lib32gcc1 lib32stdc++6 lib32z1 libc6-i386

Running shouldnt say 'missing' for any libraries. If they are, try installing apt-file and apt-file search the library name to find what pkg to install.

10) now run the UFASOFT sse2 ASM miner!


-t 8 needed (despite -h help's claim to be auto max # cores) to use 8 cores (on my 4 core x HT Core i7 960),
-g no because i dont see any extra speed with the GPU (sides, the gpu-specific clients like Phoenix are far better)
-o user:password @ localhost:8332 cuz thats where my client is

On my Core i7 960 3.2Ghz 4core + HT I get about 14-15MH/s while my phoenix GPU miner runs too (which seems to use one whole core for python, which I dont like/get - but ill ask in another thread appropriate)

10) No one should use untrusted binaries on the internet. People could steal your hash efforts, or otherwise. I havent done so, but dont trust in general..

Nonetheless, my binary compilation is here:

  http://sizone.org/~math/bitcoin/ufa


11) Because I've now increased the hash rate of the market, Ill be earning fewer coins! Please donate in exchange!

mathx -- 1BTFUtEscdizVPGiqrKhpy5s6QiQ4nNemC  -- thanks for the Donations!

32-bit version runs on Ubuntu fine if you install a needed 32-bit libcurl library with getlibs (in addition to ia32-libs package).  The other question is that it doesn't compile in 32-bit with 64-bit system libcurl (probably building libcurl from sources will help but I didn't want to get on such quest and just quickly built it on an x86 box).