i don't find the cgminer linux binary 32 bits on the website  Well, hell, I guess you're right |
|
|
|
Ok thank you to your help. I can't compile it. there are too many code incompatibility. I try to compile bfgminer i can have more chance  There isn't any ports to miner software in FreeBSD ports only one port to bitcoin software. Why not just run a Linux binary? FreeBSD has excellent Linux emulation. |
|
|
|
hahhahaha
also
can we used
enbles cores paths
at november jupiter???
don't think so. to stay on the secure side do not change the firmware until we received a statement of KnC about this. If you look on the KnC support page, it already says very clearly, in red type for emphasis, to NOT use any of the 'troubleshooting tools' for November units: From https://www.kncminer.com/pages/troubleshootingDo not run any of the below tools on November miners, they are specifically for the October batch.
|
|
|
|
I understand that the first batch of Jupiters had to make over 70 coins to break even in BTC and that was going to be tough... but how can you look at a Neptune and say that it will produce less than 10 coins. My two jupiters today still create 1 coin a day (combined). The risk is very different than it was with purchasing Jupiters when BTC was at $100.
unless you've got 2 November Jupiters pushing 700GH/s each I find it had to believe you can mine 1 BTC a day. please explain how you're doing this if it's true. or is it a mistake and you're calculations are incorrect. I have less than 200gh pointed to slush right now, and I'm making .25btc/day. I have no doubt he's making 1btc/day. I've just checked slush pool luck:  so for the last week we had 103%, so you should have slightly more btc than whatsoever profit calculator will tell you, 3% more on avg to precise. So in the last week a 200GH/s machine should have minted 0.1422 * 1.03 = 0.1464 BTC a day. My merc made 1.008 over that period. 142GH =/- a couple of GH constant. That's actual, not calculated. On Slush. on a 7 days period? good for you. 142 GH/s eq 0.1010/day avg. so 0.1010 * 7 * 1.03 = 0.7282 so maybe slush pool luck calculation is not as accurate as one might think. ps: I've just noticed that slush is currently experiencing a very bad round 13.5hs without a solving block.... As long as we are comparing pool luck  , I switched to P2Pool about a week ago, and the luck has been awesome: From http://p2pool.info/ : Pool Luck (7 days, 30 days, 90 days): 174.9%137.5%123.1% I have made 1 BTC +/- 0.1 BTC with a single Jupiter every day during this past week P2Pool rocks. |
|
|
|
Hi, I try to delete -ldl switch to Makefile. But now i have an other problem during compilation on the same object: CCLD cgminer
cgminer-cgminer.o(.text+0x18b4): In function `libusb_poll_thread':
/tmp/cgminer-3.8.4/cgminer.c:7801: undefined reference to `libusb_handle_events_timeout_completed'
cgminer-cgminer.o(.text+0x18da):/tmp/cgminer-3.8.4/cgminer.c:7809: undefined reference to `libusb_handle_events_timeout_completed'
cgminer-util.o(.text+0x17bc): In function `nanosleep_abstime':
/tmp/cgminer-3.8.4/util.c:1001: undefined reference to `clock_nanosleep'
cgminer-usbutils.o(.text+0x1b37): In function `usb_all':
/tmp/cgminer-3.8.4/usbutils.c:999: undefined reference to `libusb_error_name'
cgminer-usbutils.o(.text+0x1cc4):/tmp/cgminer-3.8.4/usbutils.c:903: undefined reference to `libusb_error_name'
cgminer-usbutils.o(.text+0x1cf7):/tmp/cgminer-3.8.4/usbutils.c:899: undefined reference to `libusb_error_name'
cgminer-usbutils.o(.text+0x1d6e):/tmp/cgminer-3.8.4/usbutils.c:979: undefined reference to `libusb_error_name'
cgminer-usbutils.o(.text+0x6988): In function `resource_process':
/tmp/cgminer-3.8.4/usbutils.c:3547: undefined reference to `semtimedop'
cgminer-usbutils.o(.text+0x88f3): In function `_usb_transfer_read':
/tmp/cgminer-3.8.4/usbutils.c:2899: undefined reference to `libusb_error_name'
cgminer-usbutils.o(.text+0x8cec): In function `__usb_transfer':
/tmp/cgminer-3.8.4/usbutils.c:2830: undefined reference to `libusb_error_name'
cgminer-usbutils.o(.text+0x9b74): In function `_usb_write':
/tmp/cgminer-3.8.4/usbutils.c:2732: undefined reference to `libusb_error_name'
cgminer-usbutils.o(.text+0xa181): In function `_usb_read':
/tmp/cgminer-3.8.4/usbutils.c:2641: undefined reference to `libusb_error_name'
gmake[2]: *** [cgminer] Error 1
gmake[2]: Leaving directory `/tmp/cgminer-3.8.4'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/tmp/cgminer-3.8.4'
gmake: *** [all] Error 2
you have an idea ? It looks like compiling cgminer on FreeBSD is not going to be a trivial task. I would be glad to help you through it, but I haven't had a FreeBSD box in some years, so I really can't. I think your options are these: 1) There may actually be a FreeBSD port for CGMiner that already exists. If so, that is clearly the best way to build it. 2) If not, download the Linux binary and run it. The FreeBSD Linux emulation is very good, and I'd be surprised if it didn't work just fine. 3) Get onto the FreeBSD ports mailing lists/forums and ask around. I would be surprised if no FreeBSD users are using cgminer, and some of them can probably help you get it compiled. Maybe you can inspire someone to create a port and add it to the ports tree. |
|
|
|
Hi, thanks to your help I try with gmake compilation some files are compiled but i have this error now: gcc: -lpthread: linker input file unused because linking not done
CC cgminer-logging.o
In file included from logging.c:16:
miner.h:50:1: warning: "alloca" redefined
In file included from ./compat/jansson-2.5/src/jansson.h:12,
from miner.h:10,
from logging.c:16:
/usr/include/stdlib.h:237:1: warning: this is the location of the previous definition
gcc: -lpthread: linker input file unused because linking not done
CCLD cgminer
/usr/bin/ld: cannot find -ldl
gmake[2]: *** [cgminer] Error 1
gmake[2]: Leaving directory `/tmp/cgminer-3.8.4'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/tmp/cgminer-3.8.4'
gmake: *** [all] Error 2
/usr/local/ld exist and works fine on the system It seems cgminer wants to link against libdl, which does not exist on FreeBSD. Usually programs that use libdl are looking for functions that are built into libc on FreeBSD, so if you just remove the references to libdl from the makefile it will probably compile and run just fine. |
|
|
|
No, I use gcc: xxxxx# gcc --version
gcc (GCC) 4.2.1 20070719 [FreeBSD]
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
It's been a lot of years since I ran FreeBSD, but as I recall, the default 'make' command they use is BSD-specific and not compatible in all ways with the Gnu make that comes with GCC, so you typically have to tell it to use gmake explicitly when using some Gnu make makefiles. I think if you type 'MAKE=gmake; gmake' it will probably work. |
|
|
|
I think it's also kinda complicated. The machines don't do it well by themselves, so to be effective, especially if you are purchasing a lot of hashpower, you pretty much have to set up a pool. Solo mining would be a lot simpler and more viable if someone capable could optimize GBT a little better so that it's viable to use on networked miners built on embedded platforms like the KnC miners. You can solo mine without a pool easily using BFGMiner's capability to talk GBT straight to bitcoind/bitcoin-qt, but it is too heavy-weight to run on a Raspberry Pi or a Beagle Bone Black as it is now. If you're using USB-based ASIC miners, like BFL, you can use BFGMiner right now to solo mine without a pool. If the miner has to run on something less powerful than a traditional PC though, odds are that it won't have the horsepower to handle GBT mining as it exists now. |
|
|
|
Is anyone mining October Jupiters on P2Pool with cgminer successfully. I know when we tried the other week it would mine OK but every so often cgminer would crash. So it'd just go unhashing for hours until we realised. We have two October Jupiters and a November one on the way that we'd like to hash on P2Pool.
I just started mining my Jupiter on P2Pool 2 days ago, but so far it has been running great - no problems at all. CGMiner reports a low average hash rate - ~450 GH/s while I typically see a very consistent 566 GH/s on other pools - but P2Pool reports close to the actual hash rate, and the payouts are correct for my actual hash rate. [EDIT: I should say that this is with the latest 0.99-tune firmware. It was running the same on the plain 0.99 before I updated.] Yeah it too a good few days between crashes but we was losing that many coins we had to move them off P2Pool. I remember seeing a bug fix by ckolivas for a serious memory leak that occurred when using the cgminer API. If you were using the miner GUI alot, especially if you were using something like Bertmod, that might explain the crashes you were seeing. If so, you might want to try with the latest cgminer. If not, well, maybe I will start seeing crashes later too I sure hope not. Let me know how it goes please. Will do. |
|
|
|
Can anyone tell me some tricks to minimize bitcoind GetBlockTemplate latency? Mine seems to run very consistently at ~1s, but I see many public nodes with less than 0.3s.
What is the source of this latency and what can be done to address it?
blockmaxsize= bigger the slower, minrelaytxfee= smaller is slower , bitcoind on ssd or ramdisk is fast. Bitcoin blocks are stored very stupid way, because blocks arent in folders, so you cant mount --bind some of them to ramdisk, I think all the blocks must be in ram or ssd to get any improvement.. 15,4gt now.. Thanks |
|
|
|
|
Can anyone tell me some tricks to minimize bitcoind GetBlockTemplate latency? Mine seems to run very consistently at ~1s, but I see many public nodes with less than 0.3s.
What is the source of this latency and what can be done to address it?
|
|
|
|
Is anyone mining October Jupiters on P2Pool with cgminer successfully. I know when we tried the other week it would mine OK but every so often cgminer would crash. So it'd just go unhashing for hours until we realised. We have two October Jupiters and a November one on the way that we'd like to hash on P2Pool.
I just started mining my Jupiter on P2Pool 2 days ago, but so far it has been running great - no problems at all. CGMiner reports a low average hash rate - ~450 GH/s while I typically see a very consistent 566 GH/s on other pools - but P2Pool reports close to the actual hash rate, and the payouts are correct for my actual hash rate. [EDIT: I should say that this is with the latest 0.99-tune firmware. It was running the same on the plain 0.99 before I updated.] Yeah it too a good few days between crashes but we was losing that many coins we had to move them off P2Pool. I remember seeing a bug fix by ckolivas for a serious memory leak that occurred when using the cgminer API. If you were using the miner GUI alot, especially if you were using something like Bertmod, that might explain the crashes you were seeing. If so, you might want to try with the latest cgminer. If not, well, maybe I will start seeing crashes later too I sure hope not. |
|
|
|
Is anyone mining October Jupiters on P2Pool with cgminer successfully. I know when we tried the other week it would mine OK but every so often cgminer would crash. So it'd just go unhashing for hours until we realised. We have two October Jupiters and a November one on the way that we'd like to hash on P2Pool.
I just started mining my Jupiter on P2Pool 2 days ago, but so far it has been running great - no problems at all. CGMiner reports a low average hash rate - ~450 GH/s while I typically see a very consistent 566 GH/s on other pools - but P2Pool reports close to the actual hash rate, and the payouts are correct for my actual hash rate. [EDIT: I should say that this is with the latest 0.99-tune firmware. It was running the same on the plain 0.99 before I updated.] |
|
|
|
Well I have had it proxies. It looks easier for me to use getwork and directly connect my blade with no pc. Most likely I am committing an error, however my blade could be defective.
IP 192.168.1.254
Mask 255.255.255.0
Gateway My router's gateway?, my LAN IP address?, or my computer's IP?
WEB Port 8000 I have a port forward at 8000 other values do not seem to work. If i change this do I need a new port forward?
Primary DNS my router's primary DNS or should I use another value here?
Secondary DNS my router's secondary DNS
Ports 8332,8337 The ports of BTCoxygen,Eligius getwork servers.
Server addresses BTCOxygen.com,getwork.mining.eligius.st
user:pass xxxxxxxxx:xxx,yyyyyyy:yyy
These are the values I will be trying out today. Any advice is welcome. I have been at this for three days and bfgminer just can't see my blade. I don't really like MinGW now that I've tried it out. I had to link bfgminer.exe into MinGW/msys as a hack so my money is on user error here. Stratum Proxy passed a lot of errors but I may give it one more go. If these trials do not get me hashing I am returning my blade to the seller as defective.
Start BFGMiner with the '--http-port' option. I use '-http-port 8330'. Then configure your blade so that BOTH pool setups are pointed to the address of the machine running BFGMiner. Make sure BOTH ports are set to 8330, or whatever port you used with the '-http-port' option. You can use any username/pass for BFGMiner, but if you have multiple instances running for multiple workers, make sure to use a unique user name for each worker. Then setup BFGMiner to connect to the pool (and backup pools) you want as usual. Yes, the gateway is your router IP, usually 192.168.1.1 for most people. To summarize: IP 192.168.1.254 Mask 255.255.255.0 Gateway My router's gateway WEB Port 8000 Primary DNS my router's primary DNS Secondary DNS my router's secondary DNS Ports 8330,8330 (or whatever you set in --http-port) Server addresses <BFGMiner machine address>, <BFGMiner machine address> user:pass xxxxxxxxx:xxx,xxxxxxxxx:xxx |
|
|
|
Hi,
I received the newsletter, i have accounts on knc but i have not purchased from them in the past, I can buy Neptune?
Log in to your account on KnC and right under your phone number you will see a 'customer group' line. If it says 'Neptune', you are good to go. |
|
|
|
Hi guys sorry if this has already been asked but i want to use Eligius pool but understand from your guide that only slush can easily be used with stratum because its more efficient
Is there any statum proxy exe, similar to the one for slush pool, which works with eligius. I could only find that your basically only able to use getawork protocol is that right? Is there a huge disadvantage to this?
Cheers
The same stratum proxy that works for Slush' pool will work with any pool that uses stratum, including Eligius. BFGMiner also has a proxy mode that you can use to connect to stratum pools with your blades. |
|
|
|
<AWESOME Guide Deleted>
Wow, very nice write-up |
|
|
|
Just want to confirm guys, Black Arrow Matt is who he says he is ...but who are you?  Bobsag3 is the official reseller for BA products in the USA. I should probably have wrapped my reply in a <joke></joke>. Apparently a wink is not enough.  |
|
|
|
Just want to confirm guys, Black Arrow Matt is who he says he is ...but who are you? |
|
|
|
yep, ouch. single rails provide much cleaner power and are able to supply the extra amperage during the spikes in hashrate... and two 1500watt supplies on a 20 amp circuit is not so good either...(20 amps x 110v = 2200 watt max per 20 amp circuit, (or in EU...220v x 10amp = 2200watt)and you are saying there is more than two jupiters on that circuit?....I really think it's your power situation now for sure...
I think these 'spikes in hashrate' you see is just variance. The chips run at a constant speed. Variance does not cause your miner to draw more or less current. Okay spikes are variance....? yes... and what causes that variance?...who knows...have you used a kil-o-watt to see that what you are saying is correct? Yours stay rock-solid on a single wattage reading? Mine don't. The reading on mine at the wall goes up & down in direct correlation with the variance... and when I had them on a "Shared circuit" it was terribly obvious the other things going on were effecting it when the kil-o-watt dropped when other things were used in the house, like microwave oven, coffee pot, toaster, aircon, etc.... That's just my observations here, which is why I say that. You can even watch bertmod to verify what I'm saying.... the vrm output goes up & down with hashrate as well My VRM's are outputting a FULL 12v, @ 50amps now btw... and if I said how...Edgar would complain.... but it has to do with temps and clean, unwavering, unlimited power.... Variance is caused by luck. Spikes (both up and down) in your apparent hashrate can (and do) happen based on sheer luck. Your miner could, say, generate 10 diff 256 shares in 10 hashes, and it will look to the pool like your hashrate is much higher than it really is, briefly. The converse is also true. One thing that could possibly explain your observation though is the enabling and disabling of cores - that would affect both your hashrate and the current draw, I imagine, but it seems like the difference would be pretty small unless a number of cores get enabled/disabled at once. Each core is only 1/192 of one modules hashpower and probably an even smaller fraction of it's current requirements. okay...I'm just dreaming, which is why I can get 143GH+ from every single board, even those with the "Die 0" problem. I don't understand that response. How is this related to hash-rate spikes being caused by variance? |
|
|
|
|
Show Posts
