Folks whose Tubes are hosted with me, I'll be setting them up tomorrow. I got them all assembled - it took longer than I'd figured but a lot of the distractions were related to working out pool incompatibility issues. First thing in the morning I'll be finishing up the power wiring and meter installs, then firing up miners in the order that orders were placed with me. Since it's near the end of the month I'll combine the shipping, setup fees and August hosting into a single invoice on the 1st.

Anyone that I haven't gotten pool info from yet needs to get me that. I should be able to direct them at any pool without issue by tomorrow.

https://bitcointalk.org/index.php?topic=735728.msg8549984#msg8549984

In the post after that I posted a solution ckolivas worked up for me using his own proxy software, which runs linux native. I haven't fully tested its limitations yet, and I haven't tested BFG proxy at all, but once I get the rest of these tubes assembled I'll do some more work on both options and post results.

I'll look into it later this afternoon. There's probably enough demand for it to make it worthwhile. I try to avoid BFG in general but unless we want to recode slush proxy that might be the easiest option.

I might mess with it later if I get time. We were looking at tweaking the code for slush's proxy to include a bytelength test and truncation before repacking and forwarding the shares. Worst comes to it, we can look into that again.

Yeah I read about 930W, which would be around 10% over rated output but these server PSUs are pretty good. I've not pushed one of the 750W that hard before, but the 2000W we've run at 2500W for seven days continuous without issue.

Maybe once I'm done assembling them all. I got 31 total to put together and it's a five-step process, one step involving the installation of 156 screws.

I've had one of these on stock clock running off one of my D750 PSU setups for just shy of 10 hours straight, behind ckpool proxy pointed at ozcoin. Currently a 7-order difference in accepted shares versus rejected, reporting 816GH on the device and about 900GH at the pool, 98.4% efficient and 0.11% hardware errors. I'll test it out on some other pools later and see what looks like it should work. Probably any pool reported earlier with the same error response as ozcoin (so probably based on the same stratum backend code) would work just fine. I noticed some other pools, eligius and others using BFG stratum code, seem to hose the works again.

Install ckpool's proxy on a linux machine and punch in your pool and worker info into ckproxy.conf, point your Tube at the proxy.

I haven't ever messed with BFG as a proxy, but I don't think it requires a pi to run. If you got a linux machine the instructions probably aren't that different for installation.

So, news. I talked to ckolivas earlier and he helped me out. I directed a Tube through his hardware and he tracked down the issue. For one, there was indeed exactly the problem of the extranonce2 field always returning 4 bytes (I had mistakenly supposed 8 bytes but after looking at some source when it says '8 chars' in the error it means hex characters, two per byte) when the pool requests something other than 4 bytes. He also noted a lot of corrupt hex in the packets and it looks like the code was generally a botch job designed to work on their own pool, or maybe just ghash, whatever. In any case, not very good for actual customers.

So he patched the proxy in ckpool (https://bitbucket.org/ckolivas/ckpool) to truncate the extranonce2 and generally fix what was going wrong. I've got an instance testing now with a functional tube and so far it's looking good. At least, it works with ozcoin and slush that I've tested so far. Pools that don't use BFG software, best we can figure.

https://bitcointalk.org/index.php?topic=735982.msg8544454#msg8544454

I'd pull a 1000W PSU for each if you got 'em.

If I've tried it, it's posted in #201 above. I can only test stuff I have credentials for, or stuff folks supply me with credentials for to test.

mmpool.org, I don't know but my guy Novak mines there. If I'm reading packet contents right it's requesting a 2-byte extranonce2 but doesn't throw an error when it receives an 8-byte.

https://bitcointalk.org/index.php?topic=735728.msg8544195#msg8544195

I've got a list of pools I've tested so far, with the error messages returned.

Novak did some packet sniffing while I fetched a sammich, and it looks like it might be something like the server is requesting a 4-byte extranonce but the miner is returning an 8-byte every time.

The Cubes required the proxy because they only ran getwork. These guys do stratum natively, but apparently they don't do it quite right. Either that or every pool ever has implemented their standards wrong but every other hardware ever somehow compensated (which seems unlikely).

If I knew any python, and had any time at all, and knew more about the stratum packet formats, I'd consider tearing into the proxy and seeing if the erroneous portion can be spoofed and get a proxy going that'll fix the issue with these at least until there's a firmware update.

Unless you can convince it to use getwork, it looks like slush doesn't repack the shares at all over stratum. It could be that it's repacking them in the same noncompliant format? Dunno, but something's left blank that a lot of pool backend software really seems to hate.

Anyone tried bfgminer's proxy? I would but I'm allergic.

I got one already assembled. After going over it with Canary last night, it went pretty quickly. It's not running currently as I'm annoyed by trying to find pools that will accept its apparently not standards-compliant share format. I was hoping slush's proxy might for some reason repackage and submit shares but that doesn't appear to be the case, I think it just forwards stratum straight on as is.

Additionally I did some power tests. The DC power output measurements were erroneous/bad to be sure, but I hooked up a power meter to one of the hosting circuits and got some rough measures of AC load (into a D750) at various clock settings.

MHz	GH	IAC	VAC	WAC	W/GH
270	829	4.4	212	933	1.13
260	799	4.25	212	901	1.13
250	768	4.1	213	873	1.14
240	737	3.9	213	831	1.13
230	707	3.8	213	809	1.14
220	676	3.6	213	767	1.13
210	645	3.5	213	746	1.16
200	614	3.3	213	703	1.14

Those current measurements are by no means precise, as all I had was a 0-100A meter with tenths precision. Everything still reads out as a good 10-14% worse than expected.

Also if you'd have asked for hosting I'd have turned you away. We're full up, even without these pulling 10% more power than expected.

Newest version of proxy, after firmware update, ozcoin and eligius report the same errors. I also tried btcguild and got "REJECTED: (-2, u'unknown', None) about a berjillion times. I don't think it even polled a starting vardiff properly.

mmpool worked alright, but I was borrowing credentials for that. The pool picked up the full hashrate though, no rejected shares.

edit:

mmpool.org: accepted shares

us.ozco.in: REJECTED: (-2, u'Incorrect size of extranonce2. Expected 8 chars', None)
stratum.mining.eligius.st: REJECTED: (23, u'H-not-zero', None)
stratum.bitcoin.cz  REJECTED: (-2, u'Incorrect size of extranonce2. Expected 8 chars', None)
us2.eclipsemc.com "REJECTED: (23 u'H-not-zero', None)"
api.polmine.pl "REJECTED: (23 u'H-not-zero', None)"

mint.bitminter.com "REJECTED: (20, u'Extranonce2_size violated', None)"

stratum.westhash.com "REJECTED: (20, u'Invalid extranonce2 size.', None)"
stratum.nicehash.com "REJECTED: (20, u'Invalid extranonce2 size.', None)"

Dangit, no I didn't. I remember seeing that last week but completely forgot about it. I'll run the update and retest.

I'm using slush's mining_proxy.exe, whatever version was downloadable about October last year.

Sorry if this has been answered already, I just did a quick search. What's the word on firmware updates for these things to fix pool compatibility? I know they work on ghash, but I'm pretty sure I'd rather the machine sit idle than mine there.

I'm running one through mining_proxy and seeing the errors come through. Looks like a case of noncompliant share format that some pools aren't tolerating.

us.ozco.in: REJECTED: (-2, u'Incorrect size of extranonce2. Expected 8 chars', None)
Eligius: REJECTED: (23, u'H-not-zero', None)
mmpool.org: actually accepting shares

It came in 119 boxes with no instructions, if that says anything.