Uptime: 1d 13h 49m 29s
solo mining w/ eloipool + high diff
Good luck. Are you going for a block no matter how long it takes? Thanks for the luck, it apparently helped!  The following is, as far as I know, the first block found by a publicly released ASIC miner: http://blockexplorer.com/block/00000000000001528a3fa72b86032459e1fb6ab38720e19a26e3a1f4a64e461aSo far all known ASIC vendors have been highly ethical and not used their mining power on mainnet, which could mean that block #220386 is the first ASIC block found. Will it mine for as long as it takes? I imagine it will make more sense to mine on a pool once other ASIC miners start hitting mainnet. The average block production time, for the moment, should be around 2 days, 4 hours. |
|
|
|
|
Uptime: 1d 13h 49m 29s
solo mining w/ eloipool + high diff
|
|
|
|
|
Testers:
Another good, simple test: leave it running for 24+ hours, especially on Windows.
This helps verify longer term stability, and verifies that it keeps up with the network.
There had been some crash reports early in development, on Windows. Pretty sure those are solved, but extra testing through normal use cannot hurt.
|
|
|
|
Gavin, there's a typo 1. Subdirectories in the data directory changed names; to avoid re-indexing
the blockchain, rename:
mv $DATADIR/blktree $DATADIR/blocks/index
mv $DATADIR/coins $DATADIR/chainstate You actually want the content of blktree end up in blocks/index, so it should read mv $DATADIR/blktree/* $DATADIR/blocks/index Strictly speaking, it is not a typo; $DATADIR/blocks simply has to exist first, in order for it to work. So the instructions need "mkdir $DATADIR/blocks" |
|
|
|
My own notes: - Pieter gets a lions share of credit, for his ultraprune work
- Please test! Even an "it works for me" report is useful (just make sure to include your OS version and other helpful details in your "it works" post...)
- If you still have a slow block download, simply close the program and restart. That will start the download again, with another peer. There are still known issues with peer selection. "restart program" is an ugly but useful workaround.
|
|
|
|
Set up eloipool with the difficulty set to some high value (eg. 64 with ShareTarget = 0x0000000003ffffffffffffffffffffffffffffffffffffffffffffffffffffff). Mine with getwork, not getblocktemplate.
Dynamic targetting was used, which should in theory achieve same... maybe high+static is better. And make sure roll-n-time is functional. That setup should be able to handle hundreds of Ghash/s easily. That's what I use for my FPGA farm.
IIRC your pushpool and p2pool both hard-code the diff to 1. Isn't it why they can't keep up with the many getwork calls?
Multiple answers... pushpool has several known inefficiencies... besides being single-threaded for database + network + rpc, it simply proxies every client getwork to bitcoind, with some rewriting. bitcoind cannot keep up with that, once the miner load (historically difficulty 1.0) reaches a certain point, the whole system cannot keep up. Pool ops either solve this by scaling up the number of bitcoind processes (machines), or run pool server software that supports some amount of internal work generation, easing bitcoind's load. |
|
|
|
Another reliability update:
Now that difficulty is sufficiently high, no longer seeing machine or cgminer restarts.
The most common symptom now is a cessation of mining; cgminer and machine are both responding to status queries, but no work is occurring.
This symptom occurs every 24-48 hours.
A simple machine restart fixes the problem immediately.
Sure sounds like a memory leak. If you could check and record every hour or so, the free memory reported by 'free', and maybe capture which processes are using how much with 'ps axu', you may be able to find more definitive proof. 'free' is happy as a clam. The previous behavior can be attributed to a memory leak. Now that difficulty is sufficiently high, the box reaches a condition where the controller (linux kernel, cgminer) are active and accessible remotely, but no work is progressing. The box will restart if the memory leak condition is reached. The box does not restart upon this no-mining condition. |
|
|
|
|
Another reliability update:
Now that difficulty is sufficiently high, no longer seeing machine or cgminer restarts.
The most common symptom now is a cessation of mining; cgminer and machine are both responding to status queries, but no work is occurring.
This symptom occurs every 24-48 hours.
A simple machine restart fixes the problem immediately.
|
|
|
|
I would mine solo if I were you. A block solved every 2.5 days on average.
Already tried and failed mining solo with: bitcoind, p2pool, eloipool. And I know enough to know that my own pushpool, unmodified, cannot keep up either Need to hack pushpool or use another proxy server that can keep up. |
|
|
|
Sure, that's the predicted average. Machine/miner reliability, bad luck, the pool's cut, costs related to pool hopping and other factors definitely impact income. p2pool's income was something like 50% below predictions. |
|
|
|
That device has already paid for itself.
Not yet. Maybe another 1-2 days. Now he's making over $200 profit every single day.
Not true... I wish. |
|
|
|
jeff, does the cgminer interface have any configuration options? can you change the launch command?
i suppose you can ssh/telnet into the machine and run cgminer from the command line...would that manual instance show up in the GUI?
That is what the machine does during boot: run cgminer from the command line. That is necessarily how it must be run under Linux One only needs to edit /etc/rc.d/S99cgminer. Here is a sample of S99cgminer: DEVS=`find /dev/ -type c -name "ttyUSB*" | sed 's/^/-S/' | sed ':a;N;$!ba;s/\n/ /g'`
PARAMS=" $DEVS $POOL1 $POOL2 $POOL3 --avalon-options 115200:24:10:45:282 -q --api-allow "W:0/0" --api-listen "
ntpd -d -n -q -N -p 0.openwrt.pool.ntp.org \
-p 1.openwrt.pool.ntp.org -p 2.openwrt.pool.ntp.org -p 3.openwrt.pool.ntp.org && \
start-stop-daemon -S -x $APP -p $PID_FILE -m -b -- $PARAMS
|
|
|
|
|
Avalon ASIC miner is currently surviving >24 hour stretches without restarting, now that we're on a stable pool with a reasonably high difficulty value (BTC Guild, difficulty 32.0).
However, have now seen the machine get "stuck" in a strange state, where it is not mining or restarting. The fans ramp up, then ramp down, in a cycle.
Power cycling fixes the problem immediately, and the machine goes back to mining in >24 hour stretches again.
As a workaround, some pools have an "idle worker" notification system, to let you know when your miner disappears.
|
|
|
|
|
How does one force GBT usage in 2.10.4?
Trying to poke the ASIC miner into GBT'ing from bitcoind, rather than getwork'ing.
|
|
|
|
Some people were curious about the load on the controller (the CPU running the linux kernel + cgminer): Load Average: 0.49, 0.52, 0.50 OpenWRT process list: 546 root 1512 S /sbin/syslogd -C16
548 root 1492 S /sbin/klogd
550 root 852 S /sbin/hotplug2 --override --persistent --set-rules-f
556 root 1016 S /sbin/procd
560 root 1516 S /sbin/netifd
567 root 876 S < ubusd
766 root 1504 S /sbin/watchdog -t 5 /dev/watchdog
986 root 1520 S /usr/sbin/crond -c /etc/crontabs -l 5
994 root 1156 S /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p
1014 root 1152 S /usr/sbin/uhttpd -f -h /www -r OpenWrt -x /cgi-bin -
1043 nobody 944 S /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf
1056 root 1504 S /usr/sbin/ntpd -n -p 0.openwrt.pool.ntp.org -p 1.ope
1065 root 30052 R cgminer -S/dev/ttyUSB0 -o 1.2.3.4:9332 -O 1ABCDE
9244 root 1224 R /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p
9245 root 0 SW [kworker/0:1]
9266 root 1508 S -ash
9291 root 1500 R ps
Memory usage snapshot: root@OpenWrt:~# free
total used free shared buffers
Mem: 61832 25648 36184 0 2496
-/+ buffers: 23152 38680
Swap: 0 0 0
|
|
|
|
|
Miner "freeze" just past hour 20, mining p2pool: openwrt and cgminer status are accessible, but no work is being retrieved from / sent to p2pool.
Manually restarted.
|
|
|
|
|
Survived 18 hours so far on p2pool without a restart, either machine or cgminer.
Mining at difficulty 16.0, with stratum, to local p2pool/bitcoind.
|
|
|
|
But the contents are unknown. Either an integer or a pointer could be used depending on the implementation. And any optimisations would be useless in this case.
No, you're doing something wrong if you're stuffing/casting pointers into integers like that. File descriptors and handles returned by the OS are different in every way from a pointer. |
|
|
|
|
Show Posts
