Ok, so let me start off by giving you the environment and setup details.
Late this afternoon, I was sent the latest codeset to the modified Ufasoft miner for review. After trying to compile it again, with the same results and trying several different scenarios, I was still unable to compile the software. I dug a little deeper into the error and consulted with BFL and we determined that the Ufasoft codebase is not 64 bit ready, and thus would not compile on my laptop. At this point, it was either postpone the test or make do with what we can until either a) Ufasoft is fixed to support 64 bit or b) I reinstall and use 32 bit Ubuntu. Neither of these options were something that was time feasible this evening.
As such, I elected to do the following:
Take the code set and compile it on BFL's laptop, tar up the directory and keep a copy for later review, both source and binary. With a working binary, albeit on BFLs laptop, we proceeded to conduct the testing.
First, we connected the miner to the pool as one would normally connect, though we were connected to a debug version of the getwork server and I observed the debug output as the miner connected and started mining. The debug output was rather enlightening in so far as some optimizations to speed up and decrease stales in the Ufasoft code became readily apparent. I will not go into detail in this post, but I am willing to discuss it elsewhere and/or at a later time. Suffice to say that the connection information appeared to be perfectly legitimate, coming from the appropriate IP.
After letting the miner mine for approximately 15 minutes, we disconnected, hooked up the Kill-A-Watt meter, then proceeded to connect BFL's laptop directly to one of the getwork servers on a non-routable IP address. I then made sure the routing table on BFL's laptop was cleared and no network connections, save for the non-routable ETH0 was operational. We then connected to the pool and began mining again. Because we had effectively reduced the latency to virtuallly nothing, some more optimization targets were revealed in some of the Ufasoft threading (or lack thereof) that will likely also yield and increase in average hashrate.
During the course of this, we were examining some of the scope traces of the power draw on the unit while also looking at the At-the-wall draw, which was fairly steady at 82W.
At 82W, I observed a fairly steady hashrate around 830 MH/s. The pool, of course, reports higher and lower hashrates based on estimated averages over a 15 minute window, which you can see in the picture. The other picture shows a peak stable rate on the miner side. As I said, average rate is about 830 MH/s on the miner side and it's fairly locked into that figure with the current configuration. See below for some thoughts on this as well as efficiency and power usage.
As I said, during this course we looked at some scope output and I noticed the ripple was fairly bad, with spikes well outside of tolerance, which would lead to severe instability... from talking with Sonny and examining both the power brick in use and the power design of the board, I have some conclusions to make. These are not backed up by BFL and are purely my own speculation:
1. The power brick they were using was rated for approximately 48w, and was being driving at nearly 100% over capacity - the power brick was excessively hot to the touch.
2. The MOSFETs on the board were similarly overheated.
3. The capacitors and power distribution design is not adequate for the amount of power being pushed through the unit under any circumstance. I have little doubt there would be premature failure on many, many units if they shipped with the current design. Especially if these units were stacked or otherwise restricted in a hot, low airflow environment.
I highlight these three issues to make a point about this development unit. The unit was stable at 830 MH/s, with underdesigned power distribution and a severely overloaded power brick. I estimate parasitic losses to inefficiency, heat and underdesign to be at the *very* least 20% on the power side. I also estimate that instability due to ripple due in a large part to improper power distribution to affect stable hashrates by as much as 10%. With a redesign of power distribution and a proper power supply, I would say the unit, as it stands right now, would achieve a 60w - 70w or better power envelope, instead of the 82w observed. I also estimate that the hashrate would increase by at least 10%. If, during any redesign that happened, the power issues were smoothed out and distribution was beefed up to at least double what it is now, the clockrate could be increased substantially, also increasing the hashrate to at or above initial targets (though power usage would still be 3x original target at a minimum, but still under 100w). Additionally, with lots of optimization of the Ufasoft code, I can see an effective rate increase and a huge, huge stale/reject decrease being realized.
All that said, I will be reviewing the code we used to mine over the course of the next day or two. BFL said they would release a unit to me in the next week or two for raping and pillaging at an undisclosed location with just myself and a BitForce box (The undisclosed location is my house. Shit, now it's not undisclosed.)
While I am disappointed that we were not able to use my laptop, I am confident that the tests performed were conducted in such a fashion as to minimize any possible outside interference, although not eliminate it entirely. Those of the more skeptical nature will have to wait until I get a unit that I can take home to due further testing, although the possibility of updated code that will compile on a 64 bit platform and a quick test to verify is not out of the question prior to that.
All tests were conducted in the DC and hooked directly into the appropriate parts of my pool to conduct the various tests. The pictures provided are of the Kill-A-Watt while the unit is in operation, the miner screen showing the internal hashrate (at a peak, not average) and a picture of the miner as described by the pool.
Summary / take away:
The unit operates at 830 MH/s internally at 82w as configured and as backed up by the pool as an estimated hashrate. Internal pool debug information confirms operation of the miner to be valid and within expected parameters. I believe with some redesign of the power distribution system, a new, beefier and high quality power brick and Ufasoft code optimization, substantial hashrate gains can be realized while reducing the power requirement by a significant margin. All tests were conducted in the DC, with the appropriate tests conducted on a non-routable network segment, hooked directly into the pool. All tests were conducted on BFLs hardware, but the software as used was taken prior to the test for later examination. A unit will be released for my at-home inspection / pictures soon and another test with updated Ufasoft code is a possibility.
I apologize for the quality of the pictures, I took them with my phone camera while standing on a ladder, leaning over the top of a rack. In retrospect, I should have brought my DSLR.
