Topic: Block Erupter Tube Sales Information Thread [Round4, Price at <1btc per TH/s] - page 11. (Read 88194 times)

Have any of the round's early buyers received their refund yet?

Having no problems running the Tubes on BitcoinAffiliateNetwork - PPS with 12.5% bonus atm...

I thought I'd look into this 1% PPS pool because it seemed interesting, but upon looking into it, its no longer PPS, it was like two years ago. It now does SMPPS;

"Reward system changed to SMPPS

We are changing reward system to SMPPS (Shared Maximum Pay Per Share). It's same like PPS (Pay Per Share), but mining pool will never pays more than it earns. This is for protect against the loss of profitability of our mining pool. "

So that was disappointing. Eligius would be better would it not? 0% fee.

maybe throw in configured pi with proxy

i am thinking about php script pinging pools and switching them

but there is one problem

controller not allways save data. if it is stuck you have to take off hashing cable, power cable, power on without hashing cable, switch pool, power off, insert hashing cable, power on

A little above my skill set.  This really quite annoying as I can see a decent ebay market for these.  I just hate to sell them with the controller programmed as a 1 trick pony.  many of my buyers are so-so with gear and like me to setup pools for them. A one pool limit will restrict my sales and cause returns.
I sold about 30 -40 s-1's and s-3's on the bay with very few problems  mainly due to the fact that I would offer free setup for the gear run it a day at my house on the buyers pool of choice then ship it. The 3 pool switching feature is a good seller for many buyers.

Selling this with only the one pool on the controller is going to slow my resales.  I may have gotten a 10 pack for 7.9btc sold 7 or 8 and kept 2.  Now I will just sit back and wait to see if a fix comes round.

maybe way to go is specially set router for routing this controller into alive pool

for example set at controller
pool: working.pool
username: worker (same at all pools)
pass: x (same at all pools)

and route controller packets into working pool if dies switch to another
(
routing dns for working.pool:
first mining.bitcoin.cz
second ghash.io
etc.
slush and ghash worker names are compatibile)


proxy pool with pi or other stuff only adds another points of failure

- dead/overheated pi
- broken pi psu
- pi network cable eaten by rats
- pi hack
- pi software failure
- any other from murphy list

if your proxy dies your farm dies too

the 100% error is a software bug comes and goes with me too. on the good end both mmpool.org and ghash showed me to be in the 98-101 % of hash range.

the only reason for switching is the pool goes down. at least that is how I see it. but i also don't seem to be able to  get the controller to do autoswitching if a pool dies.

few post above

 
also slush has bad round 11hours and growing
no luck. i hate this.

i would love to mine at polmine (pps, 1% fee, mm, fancy stuff)
but it is not compatibile yet

that would be excellent. I'd love to know if these settings can fix some of our problems.

Mine too since day 1. someone posted earlier a glitch in reporting.

Mine does that as well. Gotta be a glitch in the controller. With 3 boards working, 2 are showing 100% HWE. Pool shows all 3 running at 700 GH/s, controller says 675 GH/s.

If you're mining somewhere with no issues, what reason is there to switch? Slush recoded their backend specifically so people could mine there on these Tubes.

Though... what's up with that error rate?

i am mining at slush with no issues...
should i change to ghash? i hate them


Board 05: Prf:230.04GHs, ExP:207.36GHs, Uti:3213.60, Efi:110.94%, HWe:100.00%, PwrDn:00
Board 06: Prf:206.59GHs, ExP:207.36GHs, Uti:2886.04, Efi:099.63%, HWe:100.00%, PwrDn:00
Board 07: Prf:195.55GHs, ExP:207.36GHs, Uti:2731.74, Efi:094.30%, HWe:000.00%, PwrDn:00
Board 08: Prf:223.29GHs, ExP:207.36GHs, Uti:3119.31, Efi:107.68%, HWe:100.00%, PwrDn:00
Board 09: Prf:172.65GHs, ExP:207.36GHs, Uti:2411.89, Efi:083.26%, HWe:000.00%, PwrDn:00
Board 10: Prf:187.41GHs, ExP:207.36GHs, Uti:2618.13, Efi:090.38%, HWe:000.00%, PwrDn:00
Board 11: Prf:198.71GHs, ExP:207.36GHs, Uti:2775.99, Efi:095.83%, HWe:100.00%, PwrDn:00
Board 12: Prf:185.81GHs, ExP:207.36GHs, Uti:2595.69, Efi:089.61%, HWe:100.00%, PwrDn:00
Board 13: Prf:221.22GHs, ExP:207.36GHs, Uti:3090.42, Efi:106.69%, HWe:000.00%, PwrDn:00
Board 14: Prf:200.48GHs, ExP:207.36GHs, Uti:2800.71, Efi:096.68%, HWe:100.00%, PwrDn:00
Board 15: Prf:203.39GHs, ExP:207.36GHs, Uti:2841.25, Efi:098.08%, HWe:100.00%, PwrDn:00
Board 16: Prf:220.60GHs, ExP:207.36GHs, Uti:3081.69, Efi:106.38%, HWe:000.00%, PwrDn:00
Board 17: Prf:200.55GHs, ExP:207.36GHs, Uti:2801.62, Efi:096.72%, HWe:000.00%, PwrDn:00
Board 18: Prf:185.09GHs, ExP:207.36GHs, Uti:2585.71, Efi:089.26%, HWe:000.00%, PwrDn:00
Board 19: Prf:217.15GHs, ExP:207.36GHs, Uti:3033.49, Efi:104.72%, HWe:000.02%, PwrDn:00
Board 20: Prf:201.49GHs, ExP:207.36GHs, Uti:2814.76, Efi:097.17%, HWe:000.00%, PwrDn:00
Board 21: Prf:202.95GHs, ExP:207.36GHs, Uti:2835.16, Efi:097.87%, HWe:100.00%, PwrDn:00
Board 22: Prf:207.55GHs, ExP:207.36GHs, Uti:2899.48, Efi:100.09%, HWe:100.00%, PwrDn:00
Board 23: Prf:217.61GHs, ExP:207.36GHs, Uti:3040.00, Efi:104.94%, HWe:000.05%, PwrDn:00
Board 24: Prf:195.61GHs, ExP:207.36GHs, Uti:2732.57, Efi:094.33%, HWe:000.00%, PwrDn:00

        Clock:270MHz       
Accepted:4.4511e+10, Rejected:6.9563e+04, Hardware errors:100.00%, PwrDn:0
Real performance:4073.75GHs, Expected performance:4147.20GHs, Utility:56909.25
Miner:98.23%, Network diff:2.7429e+10, Worker diff:3329.00, Real_LP:8
Running time: 0d:03h:55m:02s, Session time: 0d:03h:54m:57s, RS:0, RC:0
Sha/m:20180, Subm/m:14 Jobs/m:485, Nonce/m:854, Cmd/s:11294, Ans/s:11294

www.gekkoscience.com/misc/slush_gekko.tar

That there should be the current (experimental) code we're working on slush proxy to make Tubes compatible with slush-based pools. I've got an instance running on ozcoin without any problems, haven't really tested any other pools but it's worth a shot. I don't think the install script works properly something or other, but ./mining_proxy.py should fire up what you need

Would be nice if some instructions where included as to what some of the entries under "settings" do.

Such as the "system port" or the "normal/smart" setting.  I have noticed that "normal" used firmware version 1.41 whereas "smart"

uses firmware version 1.53.  But I do not know what the difference is.   Maybe Friedcat would be kind enough to post brief instuctions.

Is anyone else using bfgminer as a proxy and periodically seeing a huge jump in duplicate shares causing high reject rates? I've noticed it periodically on ghash and initially it seems to happen on westhash as well...

He's already making you build them, why not make the customer engineer the firmware as well 

@friedcat, you make some great hardware, but the way you're skilfully avoiding any discussion about the woeful stratum implementation in this hardware and possible new firmware is rather disappointing and reminds me of the behaviour of deepbit and ghash in only discussing things that may increase their userbase while avoiding answering questions that users care about. Please address the issue directly.

I dont think I mind using BFGMiner as proxy, but I'll need a dedicated connection running it for best performance and less stales/dupes.

I was happy with it running on my HTPC, but when you start watching 1 HDTV MPEG2 stream and recording 2 others, the connection gets a little saturated @ 15-20mbps/stream, especially when its running in a virtualbox with bridged networking :/

Besides using a Raspi as a proxy, it'd be awesome if we could use it as a true controller via a USB->Serial/UART link.  In the rockminer thread, I tried, this, but progress has stalled.  It seems the existing driver won't do.