Bitcoin Forum
September 26, 2022, 09:19:09 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Economy / Computer hardware / [WTS] - Dell 550W PSU Connectors - UK, EU on: February 15, 2015, 02:31:18 AM
Anyone interested in buying Dell 550W server PSU endplate connectors? I am putting together some of these for my own use but have to buy larger quantities and thus offload the excess. These PSU's can be used to power S1's, S3's and you can use 2 to power an S5 (or one S5 underclocked).

The connectors can be assembled with either one, two or no switches.
1. For one switch it can either be used for reducing the fan RPM (this noise) or the power. If you choose to have it control the fan, then the plug will ship always switched on.
2. For two switches, one os for the fan and the other for powering up.
3. No switches means the plug will be switched on.

The terminals I use are rated at 32 amps @ 300V each so easily cope with the 550W Dell server PSU.
I can also source the PSU's (when available) + the 6pin PCI-e cables.

Here are some images of the WIP - only remaining bit is adding the switches and putting them together.

The Parts

The semi assembled plug

I am initially looking to ship to the UK and EU for a start as shipping farther may be too expensive, however, if you are not cowed by that, by all means get in touch!
2  Bitcoin / Mining support / S3+ (BM1382) Overclocking with voltage setting on: December 04, 2014, 09:36:42 PM
It has been suggested that the voltage setting under the Miner Configuration -> Advanced Settings tab that is in the new S3+ firmware is a left over from the S4 firmware and is of no effect to the S3+, however this is not the case. While trying to figure out the effect the setting had, I changed one of my slightly OC'ed S3's voltage setting to 0850 and left it there for as it seemed to slightly improve the speed it was hashing at. This unit (like the rest of my S3's) was powered by a 550W server PSU, and having left the unit to run for weeks, the PSU started restarting every so often, which none of the others ever did. I finally realised that the PSU was dead and the only difference in settings was the voltage, which confirmed to me that the setting surely has an effect on the S3+, thus this post.

I looked up the datasheet for the BM1382 chip that is used in the S3+ and found 2 sections that helped me work out what caused the fauilre of my PSU (and also led me to properly use the voltage setting to properly overclock an S3+).

1. The typical hash rate and power table

2. The input timing for the chip

The initial table has voltage settings and hash rates at each voltage, while the second table has the hash rates and frequencies to achieve them. Putting these together, I came up with the following.

I have added an extra row for each voltage setting of 0.75v and 0.80v as I found that with the two units I overclocked they had a higher HW error % at the frequencies in the datasheet. When I upped the frequency a notch, the HW error % reduced to acceptable levels. It goes without saying that you may need to add the added frequencies as they are not in the shipped firmware, here's alink to how you can add them:

Also worthy of note is that setting a chip voltage to 0.85 results in a (datasheet / theoretical) wattage draw for the S3 (32 chips) of 544 watts. Remember the server PSU that I was using on the over-volted S3 that I mentioned earlier was rated at 550 watts ..... no wonder it gave up its ghost! So ensure you have an adequate PSU powering your S3 before you begin. Addidtionally, it may be worth noting that a fully populated 6 pin PCI-e connector will carry a maximum of 24 Amps @ 12V = 288 Watts (though I normally assume they can only carry 22.5 Amps @ 12V = 270 Watts), so you may need to power your S3 with all 4 pins rather than just 2.

Finally, here's an image of one of the OC'ed units. The HW error % is a bit high on this, but the unit has hashed at lower rates for longer runs, and also higher hash rates! EDIT: The lower part of the image is the poolside registered rate(s) after OC'ing.

EDIT: It pains me to have to admit that the same voltage OC'ing will apply to the bitmain variants that have the BM1382 chips, e.g the S2 and S4; the reason it pains me is I do not have one!

EDIT 2: I thought I'd also post this to compare with my earlier OC'ing of my batch 6 S3 in this post: (also in my signature).

When I ran the test in August 2014 at freq 262.5 with the old firmware, I achieved an average hash-speed over a day of 529 Gh/s with 200 errors (0.00187113284%). Having set the voltage to 0750 in the newer firmware, I have a hash-speed 528.53 and a HW error rate of only 46 HW errors (0.0004%).

So again, not only does the voltage setting aid in OC'ing, it certainly does help with running efficiently!

EDIT: 6th Dec 2014

I had to post this. An update for the 262.5 freq @ 0.75 volts (0750 setting) after running for 2 days. There are only 96 92 HW errors and the % is still the same! The consistency you get from setting the voltage correctly is astoundingly repeatable / maintainable given what we've come to expect of ASIC rigs.

3  Economy / Computer hardware / [WTB] Antminer S1 or S3 blade(s) - London, UK on: November 07, 2014, 02:26:19 PM
Anyone have a spare S1 or S3 blade for sale in UK (to minimise postage)? Can pay reasonable BTC / PayPal / Cash. PM or reply here please.
4  Bitcoin / Hardware / Hashra 1TH Moonraker on: October 26, 2014, 03:31:46 PM
Just looking to get some feedback on this (pre-order?) for the Hashra Moonraker rated at 1TH+ @ USD325
Here's a link to the product page:
1. Their website says this will ship in December, but their disclaimer goes further to state they gurantee to ship by 31st December.
2. The accept payment with BTC but should they fail to ship by the end of the year, refunds will only be in fiat. I can understand this to a degree since, it seems, they will converting the BTC straight to fiat as soon as it hits their account.

This looks like a good deal compared to getting 2 antminer S3+'s, but is it? Does this company have any good reputation?
5  Bitcoin / Mining software (miners) / Help! Antminer S1 BM1380 chip on: September 26, 2014, 06:18:01 PM
I need some help from here.
After upgrading my S1 hardware to S3 with the kit, I now have several boards from the S1 with the BM1380 chip that I would like to undervolt and stick in a hashing rig, but I need to interface with the rig.

Thus far, I have connected a board using USB->TTL dongle and can send data accross and receive responses from the board. I have to state here that the data sent is a string of a generated target that I got from cgminer debug output, i.e

[2014-09-23 16:38:05] Generated target 0000000000000000000000000000000000000000
PS. I only send everything after the word target!

The response I get from the board is this:


NOTE: I am communicationg over USB (on windows) and send a text string and read / receive a binary response. (Am I doing this correctly?)

Anyone have any idea how to interface with this board, aka sending work to a specific chip etc?

PS. I have looked at the cgminer (and bfgminer) code but can not work out what is in the sendbuffer to initialize or send work to the board. If I can get help with what to send to the board, that will be fab.
6  Bitcoin / Mining support / Antminer S3 batch 6 overclocking on: August 21, 2014, 12:14:47 PM
I have been intrigued as to how far the S3 can be pushed and have been doing some tests over the last few days, running each chip_freq setting for approximately a day to get a more representative average result for that specific frequency.
I did this with a batch 6 S3 powered by a Dell PS-2521-1D server PSU rated at 550 watts connected via 2 PCIe connectors.

I carried out the testing over 5 days on 5 different sppeds starting with the stock speed of 218.75, and here's a summary of the settings and results.

| freq_value | timeout | GH/s(avg) | HW Errors

I am not sure of the formula used to calculate the error percentage for the S3, however from the image below, you can work it out since I have all the values in there.

I was amazed how well the temperatures were kept down by the S3 compared to the S1. Of note though, is that I keep my rigs outside the house, covered to protect them from the elements but very well ventilated.

A note about the PSU: The Dell PS-2521-1D has three 12V rails each pumping out approximately 15A on a 200-240V line. Even more interesting is that the PSU cost a mere GBP 10.00 from ebay!

I am not sure whether I can push the PSU any further as I do not have an anmeter hooked up to show the power being gobbled by the S3 at the higher clock speeds, however, from my initial tests, it seems the S3 can be pushed further without much ado. Anyone managed to clock higher?

UPDATE: - upgrade to cgminer 4.6 - 13th Sep 2014

I updated the overclocked S3 to the latest cgminer version 4.6 and below is the screen-shot after running for a day.
1. I am not sure what to attribute the drop in hashrate to, but its dropped from  an average of 529 to 514 (approx 15 GH/s over a day).
2. Hardware errors have also gone up by 50%+, though the percentage is still low generally. I would not have minded this number going up if the hash-rate was maintained or bettered.
3. The unit's GUI is very clearly more responsive (though you can not see that here), but the value of discarded shares has shot up again (did I mention I reduced the queue to 10 from the stock 4096?). I know that number is not useful, but the slight increase in temperature and the fan speed indicate to me the unit is working harder than before. Infact, I can attest to it as I hear the fans ramping up (they have a distict sound over the other fans I use on other units).

All in all, I am seriously wondering whether this upgrade is worth it on a performance level. It is well documented that 4.6 plugs some security flaws that are open in the stock version, but I am wondering whether it is worth the "pain" of losing 15 GH/s over a day's hashing.

-------- DEPRECATED! ---------- version 4.6 is no longer available Oct 2014, use 4.6.1 below
To upgrade to cgminer 4.6 follow this process.
1. SSH into the S3 and login
2. Issue the following commands sequentially.
  a) cd /usr/bin
  b) mv cgminer cgminer.bak
  c) wget
  d) chmod +x cgminer
  e) reboot

To revert back to the stock cgminer (assuming you followed the above process):
1. SSH into the S3 and login
2. Issue the following commands sequentially.
  a) cd /usr/bin
  b) mv cgminer cgminer.4_6
  c) mv cgminer.bak cgminer
  d) reboot

------ END DEPRECATED! ------

UPDATE: - upgrade to cgminer 4.6.1 - 10th Oct 2014

A further update to cgminer, aka version 4.6.1, was posted by ckolivas ( and being the ever inquisitive type I decided to install it on one of my S3+'s.

But first, an update to the previous version 4.6.0 which I had installed then removed due to the "apparent" drop in hashing speed. In the interim, I obtained a couple of S1 upgrade kits from bitmain (when they were still available) and upgraded a few of my S1's. The process required me to flash the now upgraded S1's with the S3+ firmware which I did, and I additionally installed cgminer 4.6.0 onto them. When I ran the upgrades, they were hashing marginally faster than my factory S3's and so I decided to upgrade the firmware on my S3's to the latest one AND install cgminer 4.6.0 and to my delight, the previously observed speed drop was no where!

Moving on, when the new update to cgminer was published, I installed it on both my upgraded (now) S3's and the factory S3's. In the announcement post, ckolivas mentions that version 4.6.1 does improve hashing speed to begin with, but overall it does not improve / increase the hashing speed. My observations are:
1. Hashing is more stable and gets up to speed quicker.
2. I have been hashing on slush which sets diff dynamically, and with version 4.6.1 my diff is set accurately quicker and remains stable for longer. Of course, I have only had this running for a few days.
3. On my machines, they are hashing marginally faster (and higher) than I have seen them before! So, I am happy to contradict the software author's opinion here.

Finally, to install cgminer version 4.6.1, the process is the same as before with only the file changing, i.e

Issue the following commands sequentially.
  a) cd /usr/bin
  b) mv cgminer cgminer.bak
  c) wget
  d) chmod +x cgminer
  e) reboot

EDIT: cgminer 4.6.1-141009 now deprecated  and un-available-

I'd recomend ensuring the S3 as the latest firmware if you want to install over the stock cgminer, however, it will run without the firmware update too.

UPDATE: - Adding frequencies to the latest firmware 21st Oct 2014

The stock firmware for the S3+ contains frequencies up to 250M, and should you want to overclock over that, you'll need to manually add the frequency. A guide for that can be found in the thread linked via:

UPDATE: - New S3+ Firmware released by bitmain 25th October 2014

Bitmain released a new firmware for the S3+ that now includes version 4.6.1 of cgminer. Unfortunately the firmware, at the time of writing this, contains an error which makes it impossible to update the miner configuration. There is a fix for this:

1. Download and flash firmware from:
2. When the rig reboots, SSH into the S3 and login (remember if you chose not to keep settings while flashing, it will pop up on the default IP of rather than its previous IP).
3. Enter this and press enter: sed -i 's/Save\&Apply/Save\&Apply/g' /usr/lib/lua/luci/model/cbi/cgminer/cgminer.lua

You can now browse to the miner configuration page and apply any changes. Also remember to change your network back to DHCP client as the firmware resets it to Static.

If this has been useful and you'd like to donate some BTC, please send to: 1AwgqD7A2KuQ4WT4273JXZPUf29BAbdp2
or point you rig for your chosen amount of minutes (or days ! Wink ) to: stratum+tcp:// with the user pekatete and password x

UPDATE: 20th December 2014 - Freq 275 voltage setting 0815, timeout 14 overclock

Since the release of the firmware that allowed to set voltage, I have found another sweet spot for the S3+ at a frequency of 275. I had to reduce the timeout from that suggested in some posts on this forum to be able to get a reasonable HW error rate. I ended up with the following setting in the respective file: pb:value("14:275:0a82", translate("275M")) which translates into timeout: 14, frequency: 275, register value: 0a82. The voltage setting I used is: 0815 (see also the voltage OC thread I posted here:

And after approx 24 hrs ....

And the poolside after approx 24 hrs ....

7  Other / Beginners & Help / Slush bitcoin blocks on: April 30, 2014, 05:14:33 PM
I hope this is the right place to ask this,

I have just been mining for the last few weeks on slush and noticed something peculiar.
1. The current block as per settings tab on slush is showing #298470 whereas BFGMiner is showing #298471
2. I am sure that BFGMiner was showing #298470 earlier but I had a network fault (which also resulted in the difficulty reducing from 6 to 5) and then the block number changed.

The concern here is that in addidition to block #298471 not beingisted on the pool's page, I also noticed that I "LOST" all the estimated earnings for the block on the pool status page when this happened, and though BFGMiner is clearly now dealing with a different block number, I am accumulating estimated rewards for the old block. Am I missing something obvious or is this not the place to ask about this kind of thing?

[img src=][/img]
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!