Luke wants his MTV...
What's MTV? I'm just tired of DSL. |
|
|
|
Who's responsibility is the transformer? Isn't that the power companies not mine?
They said if i blow the fuse again they won't be back until morning. This is in CO, USA with excel energy.
DON'T give in to them! I live in Colorado (Arvada) they tried to make me pay to move a line that had been connected to my garage 10 years BEFORE I bought the house. They came out, put in a new pole, moved the line and tried to stick me with an $1800 bill. Fricken pound sand Xcel Energy!!! I called the Public Utilities Commission, super nice lady, told me to write them (P.U.C.) a letter. In just two weeks I got a nice little letter back from Xcel stating they were sorry for the error in judgement and I would NOT have to pay the $1800. So fight it!! You are paying your bill every month so they can just pony up the money and build out what you need to support your mining business. Hope this helps. Rob I wonder if there's someone from the city I could complain to, to get cable... BrightHouse wants $30k to run it to me (1 mile). |
|
|
|
What about uthash? I don't know why, but configure does not search uthash headers in the /usr/local/include. I modified configure.ac, and wrote direct path to include files (added part is bold): #include < /usr/local/include/utlist.h> #include < /usr/local/include/uthash.h> Thereafter, configure runs OK. This is a compiler/OS issue. The standard "bitforce" driver should work fine. Sorry, but something wrong. see terminal output: # lsusb Bus /dev/usb Device /dev/ugen2.2: ID 0403:6014 Future Technology Devices International, Ltd Bus /dev/usb Device /dev/ugen2.1: ID 0000:0000 Bus /dev/usb Device /dev/ugen1.1: ID 0000:0000 Bus /dev/usb Device /dev/ugen0.1: ID 0000:0000 # ls -la /dev/ugen2.2 lrwxr-xr-x 1 root wheel 9 Apr 19 20:27 /dev/ugen2.2 -> usb/2.2.0 # ls -la /dev/usb/2.2.0 crw------- 1 root operator 0, 120 Apr 19 20:27 /dev/usb/2.2.0 # ./bfgminer/bfgminer -o pool.xxx.com:0000 -u username -p secret -D -T --verbose -S all [2014-04-19 20:32:46] setrlimit: Changed soft fd limit from 11095 to 1024 (FD_SETSIZE=1024; hard limit=11095) [2014-04-19 20:32:46] Started bfgminer 3.99.0 [2014-04-19 20:32:46] lowlevel_scan: Found usb device at usb:002:002 (path=(null), vid=0403, pid=6014, manuf=FTDI, prod=BitFORCE SHA256 SC, serial=(null)) [2014-04-19 20:32:46] lowlevel_scan: Found usb device at usb:002:001 (path=(null), vid=0000, pid=0000, manuf=CMDTECH, prod=OHCI root HUB, serial=(null)) [2014-04-19 20:32:46] lowlevel_scan: Found usb device at usb:001:001 (path=(null), vid=0000, pid=0000, manuf=SiS, prod=OHCI root HUB, serial=(null)) [2014-04-19 20:32:46] lowlevel_scan: Found usb device at usb:000:001 (path=(null), vid=0000, pid=0000, manuf=SiS, prod=OHCI root HUB, serial=(null)) [2014-04-19 20:32:46] lowlevel_scan: Found ft232r device at usb:002:002 (path=(null), vid=0403, pid=6014, manuf=FTDI, prod=BitFORCE SHA256 SC, serial=(null)) [2014-04-19 20:32:46] Reattaching kernel driver for usb:002:002 [2014-04-19 20:32:46] Reattaching kernel driver for usb:002:002 [2014-04-19 20:32:46] Device rescan requested [2014-04-19 20:32:46] lowlevel_scan: Found usb device at usb:002:002 (path=(null), vid=0403, pid=6014, manuf=FTDI, prod=BitFORCE SHA256 SC, serial=(null)) [2014-04-19 20:32:46] lowlevel_scan: Found usb device at usb:002:001 (path=(null), vid=0000, pid=0000, manuf=CMDTECH, prod=OHCI root HUB, serial=(null)) [2014-04-19 20:32:46] lowlevel_scan: Found usb device at usb:001:001 (path=(null), vid=0000, pid=0000, manuf=SiS, prod=OHCI root HUB, serial=(null)) [2014-04-19 20:32:46] lowlevel_scan: Found usb device at usb:000:001 (path=(null), vid=0000, pid=0000, manuf=SiS, prod=OHCI root HUB, serial=(null)) [2014-04-19 20:32:46] lowlevel_scan: Found ft232r device at usb:002:002 (path=(null), vid=0403, pid=6014, manuf=FTDI, prod=BitFORCE SHA256 SC, serial=(null)) [2014-04-19 20:32:46] Reattaching kernel driver for usb:002:002 [2014-04-19 20:32:46] Reattaching kernel driver for usb:002:002 [2014-04-19 20:32:46] Device rescan requested a second time, delaying [2014-04-19 20:32:46] schedule_rescan: Scheduling rescan (no rescans currently pending) [2014-04-19 20:32:46] No devices detected!
[2014-04-19 20:32:46] Waiting for devices [2014-04-19 20:32:46] Probing for an alive pool I seen this message, and decided, probably some problems with a driver. Also, I tried to use M+, with line: Enter target: bitforce/dev/ugen2.2Anyway see: (no devices) [Plus] Add device(s) [Enter] Close device manager No new devices found So, this time I have no idea, what is happening... I would expect something like /dev/cuaU0 on BSD. |
|
|
|
I downloaded bfgminer from Git, and built it successfully on FreeBSD 9.1
There was minor problem with configure.ac (path to uthash headers), but I built it successfully. What about uthash? But, I see, the new configure does not support anymore bflsc driver,
so I unable to run configure with this option:
./configure --enable-bflsc There never was a "bflsc" driver. And, as result, I cannot use bfgminer with Butterfly SC 60 device. Why not? The standard "bitforce" driver should work fine. PS:
I tried to checkout old commit from Oct, 18, dfa849ab62f886d448002453c9434f928038ae24.
this commit contains driver, but unfortunately, FreeBSD does not have libusb, and configure stops at:
configure: error: ./configure failed for compat/libusb-1.0 This commit is from the cgminer fork, not BFGMiner. |
|
|
|
using bfgminer 3.10.0 with the Gridseed Blade and here are the results: BFGMiner 3.10.0 doesn't support any scrypt ASICs at all. So, what are these results with? |
|
|
|
BFx2 support merged into BFGMiner git ( Windows builds can be obtained here). Note that since it's impossible to tell it apart from various other devices (including BFL/Cairnsmore1 miners and even many non-mining devices!), you must run with the -S bfx:all option. I do not know what this will do with other devices; it may start fires, launch nuclear missiles (please don't run BFGMiner on computers with missile controls), etc. (this warning is true of cgminer in general btw; BFGMiner is no less safe than that) So, using this? bfgminer.exe -o stratum+tcp://us1.ghash.io:3333 -u <USERNAME> -p <PWD> -S bfx:all --bxm-bits=54 With cgminer, I still have the same issue of my computer getting disconnecting from the wireless network. bfgminer -o stratum+tcp://us1.ghash.io:3333 -u <USERNAME> -p <PWD> -S bfx:all --set bfx:osc6_bits=54 |
|
|
|
BFx2 support merged into BFGMiner git ( Windows builds can be obtained here). Note that since it's impossible to tell it apart from various other devices (including BFL/Cairnsmore1 miners and even many non-mining devices!), you must run with the -S bfx:all option. I do not know what this will do with other devices; it may start fires, launch nuclear missiles (please don't run BFGMiner on computers with missile controls), etc. (this warning is true of cgminer in general btw; BFGMiner is no less safe than that) |
|
|
|
Hello, if anyone could help me figure this out it would be great! I have BFGminer on my wr703n (openWRT) running a few antminers. The thing is, if I run the command from an ssh session everything is ok, but if I put the same command into the luci startup so it would run automatically on each boot BFGminer eats 100% of the routers CPU and becomes unstable after a few hours, hardware errors and GH/s drop. The command is: bfgminer -S antminer:all -o mypool -u myusername -p x --set-device antminer:clock=x0981 So again, through a ssh session, the CPU usage is 0 to 1%, as a startup command its 99 to 100%. The main point of the wr703n miner was so my computer does not have to be on, but I am not there yet  Try --syslog ? Or -T and pipe output to /dev/null |
|
|
|
So the wiki's SSL cert is throwing these errors. Can TPTB please look into it?
We're already looking into it (IIRC CloudFlare suggested it was a temporary problem that will resolve itself), but what is "TPTB"? |
|
|
|
|
I'm guessing the bot got lost in the migration...
|
|
|
|
|
Note: BFx2 uses an uncommon (but not bad) design which means BFGMiner will also use WinUSB/Zadig for the driver on Windows platforms.
|
|
|
|
luke,
received your OneStringMiner dev stack yet from @benturas?
Yes, we're working on it. |
|
|
|
Sure, I'll engrave it for you. Send over the private key plus costs.   Actually the private key without the public is worthless, correct? As long as he keeps the public key on another plate he should be safe. You can calculate the public key from the private key. |
|
|
|
Is mining.get_transactions mandatory to be implemented on pool side? Is it safe to simply ignore this client request (send back nothing)? It can be ignored, but should send back an error if not supported. Does your BFGMiner correctly handle variable sizes of extranonce1 and extranonce2? Can extranonce1 be 5 bytes, extranonce2 3 bytes and shares provided valid?
Yes, any reasonable value (bounded by memory size I think) should work fine, but BFGMiner will only actually use at most 40 bits of extranonce2 right now (32 in most cases). Note that the stratum proxy feature requires at least 24-bit extranonce2 (failure to meet this requirement disconnects all clients and rejects new ones). |
|
|
|
I'm not very happy about the information system. A notification integration that there is a new version available would be the least in the Bitcoin Core.
I wouldn't force the users to upgrade their Bitcoin Core, but at least an Integrated Info-System would be highly apreciated.
That I have to go to the Bitcointalk Forum to read about it, is terrible in my eyes.
It exists. It just wasn't used for 0.9.1. |
|
|
|
I would like it to be replaced by the old "accepted shares per minute", a good measure of miners performance. Accepted shares per minute is absolutely useless information... it tells nothing about performance. Oh yes?!? My ignorance then... but how come that? Is there something I should study or read about this? I thought it was what I should look after for each miner... Shares often have different targets/weights. |
|
|
|
I would like it to be replaced by the old "accepted shares per minute", a good measure of miners performance. Accepted shares per minute is absolutely useless information... it tells nothing about performance. |
|
|
|
|
Show Posts
