I'm not going to use void * after-all as I just remembered the network code uses integers returned by socket(). Best keep it the way it was before. uint64_t can take any pointer or integer, so it's safest to just use that.
You want to use, not work around, the C type system. Use the type that most accurately reflects the contents. Google for alias analysis, as just one of many examples why you should not "hide" things from the compiler. |
|
|
|
|
More good news. Machine uptime and cgminer uptime are both now 24 hours. Pool was BTC Guild, and stratum seems to most commonly use a share difficulty of 32.00000.
Now going to play with p2pool some more, with higher difficulty rates.
It sounds like a theory of a memleak is certainly plausible, at least.
|
|
|
|
Remains try it in a solo. This power is enough for the production of a block of time in 3 days, but that's not the case, and in the stability.
Already tried straight solo mining to bitcoind, as noted elsewhere. Saw at least 10% "get failure" rate, and it was falling back to the 2nd and 3rd pools. It probably makes sense to set up a 1-person pool server, for solo mining, than go straight to bitcoind. |
|
|
|
well... duh?
Who would have thought it was a good idea to consider a transaction complete if a guy claims to have sent you funds but they haven't actually been verified as legit by ANYONE yet?
In general... agreed, with this sentiment and the opinions others have expressed in this thread. However, it should be noted that certain situations may benefit from a mixed approach. If you are a merchant shipping a physical product, the purchase process might look like - Request payment
- User sends bitcoins
- "Payment received!"
- Hours or days pass, while product is packed and prepped for shipment
- Order validation: Check and make sure bitcoins have not been double-spent
- Ship product
So it is really product/situation dependent. A situation like bitcoin exchange or SatoshiDICE would seem like the ideal example of when to not accept zero-conf transactions; alternately BitcoinStore.com would seem like an excellent example of what could follow the multi-step order flow above. Multi-step Zero-conf-now-check-later gives the best user experience: fast immediately confirmation of funds receipt, with the security of multiple confirmations before final product delivery/enablement. |
|
|
|
Good news. Mining on BTC Guild with vardiff seems to have dramatically reduced the restarts.
Which cgminer version are you using? For stratum Im using the latest xiangfu openwrt solution with cgminer 2.10.4 running 27 icarus and my rig is constantly restarting, before update was using cgminer 2.7.5(non stratum) and the 703n was more stable. Avalon's cgminer 2.10.4, as described in the review linked in the OP: http://garzikrants.blogspot.com/2013/01/avalon-asic-miner-review.htmlMake sure you are not mining at difficulty 1.0. diff-1 is the original difficulty for pools, and it generates too much network traffic for this ASIC miner, possibly leading to many restarts. Find a pool with "variable difficulty" or "vardiff." p2pool supports a higher-than-1.0 difficulty by appending "+N" to the worker's name, e.g. "1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj+8" for difficulty 8.0. 13 hours uptime and counting, since switching back to BTC Guild/stratum/vardiff. |
|
|
|
|
Good news. Mining on BTC Guild with vardiff seems to have dramatically reduced the restarts.
|
|
|
|
|
Continuing to see restarts. Restarts result in resumed mining, in all but one case. In the "one case", the miner was accessible via web and cgminer was alive, but no work was being performed.
Yifu does not think heat is a factor, but speculates that other software components may be at fault.
Switched from slush to BTC Guild for the "vardiff" feature, to reduce network overhead. Eligius also just deployed the "vardiff" feature. This feature will be crucial for ASIC miners.
|
|
|
|
Don't forget that Jeff measured power consumption with the UPS included, our APC Matrix 3000 uses about 120 Watts to keep it's batteries afloat and run the electronics.
The measurement was taken with the Kill-A-Watt plugged into the UPS, and the miner plugged into the Kill-A-Watt. In other words, the Kill-A-Watt was between the UPS and the miner. Batteries and other miscellany are not included in that measurement. |
|
|
|
is it dead  No, not at all. A restart fixes everything. This is just describing the behavior before the restart. |
|
|
|
No speculation.
MHs says it is hashing - reread my last reply.
And as noted, that number is not changing. The number is constantly changing, normally. Other stats bear out the conclusion. |
|
|
|
Mighr be a stupid question but are you sure that your office isn't doing anything on the network that might be giving you an issue? Like proxy server settings?
Yes. |
|
|
|
|
Again, no, it was not hashing. Avoid speculating wildly based on a tiny subset of hundreds of variables.
|
|
|
|
i.e. still hashing, still getting work, but not sending anything back to the pool/bitcoind.
No, not hashing. |
|
|
|
1:-As it seems to stand at the moment we have only 2 or 3 confirmed Avalons “in the wild” One of those was shipped “express” to an individual who has a “high profile” within the BTC community, assuring widest exposure of its release and performance. Consider what would be the cost to produce 2 or 3 “one-off” prototypes.
[...]
I am not saying it is, but I am saying that at this point in time. It is difficult to avoid recognising just how closely this situation fits the criteria of a classic scam.
Yes, consider the cost of producing 2-3 one-off ASIC prototypes... because apparently you have not done so. It's about the same as producing 300, in terms of the chips produced. ASICs have huge setup costs, compared to per-chip costs. |
|
|
|
Still having some amount of reliability problems. Moving the miner in the office helped a great deal. However, still seeing machine restarts for unknown reasons (note: must ping support, inquire about reboot logging). And right now, the miner is in a strange state where the controller (running Linux) and cgminer are alive, but fans are not running, and no work is occurring: [Elapsed] => 10477
[MHS av] => 15419.77 (this is not changing)
[Found Blocks] => 0
[Getworks] => 385 (these are increasing, slowly)
[Accepted] => 37082 (these are not increasing)
[Rejected] => 398
...
[fan1] => 0 (indeed, fans are not moving)
[fan2] => 0
[fan3] => 0
[temp1] => 26
[temp2] => -1
[temp3] => 48
[temp_max] => 49
And the pool agrees that no shares are incoming. |
|
|
|
Alright, jgarzik measured 620 Watt at the wall.
At the UPS socket not wall, to be specific. |
|
|
|
Are you using getwork or stratum on p2pool? Did you try both? Any difference between the two?
Stratum, with "+8" (difficulty 8.0). Stratum seems to work better in general, with Avalon's modified cgminer 2.10.4. |
|
|
|
Avalon should have just done an auction format. Give people a few days to place bids, using 2 of 3 escrow to lock in coins, then take the top 600 bids. They could have a per-customer (shipping address?) limit if they wanted to ensure that the units were spread out.
That would have been nice. And as long as they are evenly distributed -- perhaps 3 per postal code + IP address location, or somesuch. |
|
|
|
|
Filled out shipping information and ordered 1 unit... but got charged $1 by walletbit.
Sounds like I missed out on batch #2... good luck to the people who got in!
|
|
|
|
Checkout
Oops, there is nothing in your cart.
Ditto. |
|
|
|
|
Show Posts
