Bitmain BM1382 & BM1384 GH/s Hash v Clock Frequency

[RichBC]

I guess quite a few of us have spent a lot of time testing and experimenting and then waiting for the Hash rate to stabilise to then log the GH/s?

It struck me while doing this that for a system that is working correctly surely there ought to be a direct relationship between Clock Frequency and GH/s?

So I looked back on the data sheets and measurements that I had made and came up with the following.

The S3+ (BM1382)  seems very straightforward and if you multiply the Clock Frequency by 2 then you get the hash in GH/s. So the spec of 225MHz = 453GH/s. In my testing this was confirmed over a range of frequencies.

So when I started work with an S5 (BM1384) I looked for something similar and it seemed to come to Clock Frequency x 3.3 = Hash in GH/s. So 355Mhz x 3.3 = 1150GH/s which is the spec of the S5, again this is borne out by the testing I have done over a range of frequencies & voltages.

In practice i have found the longer I wait for the Hash to stabilise the closer it get to the calculated value. So I wonder if we are we are wasting our time, for a system that is functioning correctly, waiting for Hash rates to stabilise as opposed to just doing some maths? Answers on a postcard to….

Rich

[dogie]

So when I started work with an S5 (BM1384) I looked for something similar and it seemed to come to Clock Frequency x 3.3 = Hash in GH/s. So 355Mhz x 3.3 = 1150GH/s which is the spec of the S5, again this is borne out by the testing I have done over a range of frequencies & voltages. In practice i have found the longer I wait for the Hash to stabilise the closer it get to the calculated value. So I wonder if we are we are wasting our time, for a system that is functioning correctly, waiting for Hash rates to stabilise as opposed to just doing some maths? Answers on a postcard to….

Sort of, although the 3.3 isn't a function of the chip itself but of the number of chips. You can the graph of S4+'s frequency vs hashrate vs temperature vs power consumption vs efficiency graph and its also very linear.

[TheRealSteve]

It struck me while doing this that for a system that is working correctly surely there ought to be a direct relationship between Clock Frequency and GH/s?

Yes - though some chips do have a drifting clock; BitFury's 55nm chips, for example.

So I looked back on the data sheets and measurements that I had made and came up with the following.

If anybody wants to skip the datasheets, check out the h/Hz column in https://en.bitcoin.it/wiki/List_of_Bitcoin_mining_ASICs

The S3+ (BM1382)  seems very straightforward and if you multiply the Clock Frequency by 2 then you get the hash in GH/s. So the spec of 225MHz = 453GH/s. In my testing this was confirmed over a range of frequencies.

Combined with the above list, we can deduce that the S3+ has 32 chips, but so far the trivia...

So I wonder if we are we are wasting our time, for a system that is functioning correctly, waiting for Hash rates to stabilise as opposed to just doing some maths? Answers on a postcard to….

Mainly because some of those hashes are going to be incorrect (HW errors), there can be delays (maybe USB/network traffic is hindering work, or the interface itself drops and has to be re-initialized either by hardware or software), and when you're mining at a pool you'd additionally want to take into account any shares dropped due to them being too old, etc.

For example, see the below copy/paste of a customized cgminer build:

Code:

cgminer version 4.9.2-compac - Started: [2015-08-13 20:55:07]
-------------------------------------------------------------------------------
(5s):22.72G (1m):20.78G (5m):20.53G (15m):20.56G (avg):20.60Gh/s
A:407269  R:208  HW:5228  X:4  T:142  GN:409896  WU:284.15/m  WE:98.76% HE:99.86% cf:375.00 ch:20625.00 t:86554
Connected to pool0.btcdig.com diff 16 with stratum as user BEUSB@gscompac
Block: ca71b6ee...  Diff:52.7G  Started: [20:44:21]  Best share: 571K
-------------------------------------------------------------------------------
[U]SB management [P]ool management [S]ettings [D]isplay options [Q]uit
0: AU3 0       : 375MHz 775mV            | 21.09G / 20.59Gh/s WU:284.1/m

The cf at 375MHz is the clock on a BM1384.
The ch is the calculated theoretical hash rate, at 20.625 Gh/s
However, the avg shows that it's 'only' getting 20.60Gh/s due to HW errors, the X USB crapping out T threads being restarted.
The HE, or hash efficiency, thus shows that it's only being 99.86% efficient in terms of the hardware.

Additionally there's the R rejected shares which bring the WE or work efficiency down even further, and the pool should see a value similar to that efficiency times the theoretical hash rate (... I think.. code's a bit of a mess)

so, tl;dr: It depends on whether you're only interested in theoretical hash rate, practical hash rate, or even pool-side hash rate (technically only properly evaluated at the pool itself).

[jstefanop]

I guess quite a few of us have spent a lot of time testing and experimenting and then waiting for the Hash rate to stabilise to then log the GH/s?

It struck me while doing this that for a system that is working correctly surely there ought to be a direct relationship between Clock Frequency and GH/s?

So I looked back on the data sheets and measurements that I had made and came up with the following.

The S3+ (BM1382)  seems very straightforward and if you multiply the Clock Frequency by 2 then you get the hash in GH/s. So the spec of 225MHz = 453GH/s. In my testing this was confirmed over a range of frequencies.

So when I started work with an S5 () I looked for something similar and it seemed to come to Clock Frequency x 3.3 = Hash in GH/s. So 355Mhz x 3.3 = 1150GH/s which is the spec of the S5, again this is borne out by the testing I have done over a range of frequencies & voltages.

In practice i have found the longer I wait for the Hash to stabilise the closer it get to the calculated value. So I wonder if we are we are wasting our time, for a system that is functioning correctly, waiting for Hash rates to stabilise as opposed to just doing some maths? Answers on a postcard to….

Rich

You are correct, the cores take a certain number of clock cycles to produce a single hash, so clock to hash rate can always be calculated from multiple factor of the clock frequency with a very high degree of accuracy.

The only thing that affects this is as you go higher in frequency heat/logical core failures will increase and slightly drop the hash rate.

[RichBC]

Hi Guys. Thanks for the inputs. I appreciate that it's as much a function of the number of chips as it is the GH of the individual chip. My point was actually rather a trivial one, that when playing with core voltages & frequencies I was actually spending / wasting a lot of time waiting for the cgminer GH/s(5s) to get close to the GH/s(Avg) before logging the value in the spreadsheet.....

Steve thanks for the links to the various chips, very interesting. Also the insight into the number of variables that can affect the Hash rate and the points at which they can be measured. As ever the deeper you look, and my understanding is minimal, the more comples these things seem to become.

BTW in cgminer I understand that DiffA# is Accepted Hashes & DiffR# Rejected, but what is Diff1#? Sometimes it seems to lead DiffA# & sometimes it's behind and I have not been able to make sense of it.

Rich

[TheRealSteve]

Well, it still makes sense to log actual values vs theoretical ones, especially if the settings you're using are causing a large number of hardware errors.  Log both, I'd say

Diff1 should be the number of nonces the hardware returns that are supposed to result in a hash with a difficulty of 1 or higher.  Most hardware tends to report these and leave it up to the controller to determine if it's actually correct, whether it also exceeds the difficulty of the pool/network, etc.

As for why the numbers don't seem to add up (or subtract down):

Q: Why don't the statistics add up: Accepted, Rejected, Stale, Hardware Errors,
Diff1 Work, etc. when mining greater than 1 difficulty shares?
A: As an example, if you look at 'Difficulty Accepted' in the RPC API, the number of difficulty shares accepted does not usually exactly equal the amount of work done to find them. If you are mining at 8 difficulty, then you would expect on average to find one 8 difficulty share, per 8 single difficulty shares found. However, the number is actually random and converges over time, it is an average, not an exact value, thus you may find more or less than the expected average.

[dogie]

My point was actually rather a trivial one, that when playing with core voltages & frequencies I was actually spending / wasting a lot of time waiting for the cgminer GH/s(5s) to get close to the GH/s(Avg) before logging the value in the spreadsheet.....

There's probably a more technical way of working out a good sample time, but generally setting a much lower than normal difficulty will get you there much faster. Ie 256 rather than 1024. 5s is okay although it will fluctuate significantly.

[RichBC]

Thanks again for the inputs. I am still progressing up the many learning curves there seem to be in this "game".

One more question & then I must be off as it's getting late in the UK, but something someone may be able to help with that has been bugging me since I started undervolting the S3 and now the S5.

cgminer has a voltage field on the S3 and despite all the reading I have done there is no firm conclusion on whether it works or not? My conclusion is that it does not work, is left over from S4 code where there are programmable VRM's and that you have to physically change the voltage. Which is what i have been doing.

So to my question. Steve as someone with an insight into cgminer. Are you aware of what happens below the text box, and if it should do something on an S3?  Or are you just writing to a lower level interface with no knowledge of what is or is not changed in the hardware?

Thanks again.

[TheRealSteve]

Thanks again for the inputs. I am still progressing up the many learning curves there seemSteve as someone with an insight into cgminer. Are you aware of what happens below the text box, and if it should do something on an S3?  Or are you just writing to a lower level interface with no knowledge of what is or is not changed in the hardware?

I don't think there's a software Vcore adjust for the S3, though I don't know why it would show voltage adjustments if they don't apply.. might just be a programming oversight.  Maybe have a read through https://bitcointalk.org/index.php?topic=699064 and/or ask there, or ask in the cgminer support thread at: https://bitcointalk.org/index.php?topic=28402 (only if original cgminer)

Edit: Also have a peek at pekatete's threads on S3 overclocking and S3+ overclocking

[dogie]

So to my question. Steve as someone with an insight into cgminer. Are you aware of what happens below the text box, and if it should do something on an S3?  Or are you just writing to a lower level interface with no knowledge of what is or is not changed in the hardware?

Almost all of the older S3+ batches had voltage control, but then batches became mixed between having voltage control and not. In order to unify the firmware (or to reduce the work required), they dissabled voltage modification via the firmware. So there is still a box but it won't do anything on the up to date firmwares.

[TheRealSteve]

In order to unify the firmware (or to reduce the work required), they dissabled voltage modification via the firmware. So there is still a box but it won't do anything on the up to date firmwares.

Ah them silly buggers, that'd explain that, then.

[sidehack]

BM1384 has 55 hashing cores according to Bitmain spec, and it appears they push through one hash per clock each. So 1MHz produces 55Mhash; per-chip factor then is MHz * 0.055 for gigahash. S5 factor is 3.3 because it has 60 chips, so MHz * 60 * .055 gives machine-level hashrate. Stock 350MHz * 55hash/Hz * 60 = 1,155,000MHash or 1155Gh.
BM1382 like on S3, S4 and S4+ has 63 cores and 1 hash per core per clock so a scaling factor of 63. So an S3 runs 16 chips per board (I believe in 4 banks of 4 chips, but I could be wrong) so 32 chips per machine. At 225MHz * 63 hash/Hz * 32 = 453600MHash or 453.6Ghash. S4+ runs four strings of 3x17 chips (three chips per node, 17 nodes dividing 12V down to 0.706V average per bank) so 51 chips per bank and 204 chips total and a stock clock of 200MHz. 200MHz * 63 hash/Hz * 204 = 2570.4Ghash per machine.
The S1 has 8 BM1380 chips per bank and 4 banks per board, so 32 chips per board and 64 per machine.
BM1380 has a scaling factor of 8 - either 8 cores per chip, or more cores running multiple clocks per hash. At stock speed of 350MHz, you get 350M * 64 * 8 = 179200MHash or 179.2GH per machine.

BE100 scaling factor was 28, and BE200 scaling factor was 32 - again, this probably corresponds to core count. BE100 typically operated on a 12MHz clock (on USB Block Erupter and standard-clock Blades) which gave you 336MH, as 12MHz * 28hash/Hz (either because of 28 cores or an internal 28x clock multiplier on a single core, not sure which). BE200 have higher core clocks and multiple cores, and the multiplier is 32 - so 270MHz at 32 hash/Hz gives 8640MHash per chip, or 8.64GH per chip. The AM Tube has 24 chips per board and four boards, so 96 chips total; at stock clock of 270MHz the expected hashrate is 270MHz * 32 * 96 = 829440MHash or 829.44GH per machine. Prismas run 48 chips per board and 240MHz, so 240MHz * 32 * 48 * 4 = 1474.56GH per machine.

That's what I recall from the chips and machines I'm familiar with. Not sure about anything else offhand.

Edit - oh yeah, S2. Four banks of 16x BM1380 per blade and ten blades per machine for 640 total chips clocked at 196MHz. 196MHz * 640 * 8 = 1003520MHash or 1003.52GHash per machine.

I forget Spondoolies Hammer ASIC clock ranges, but the SP10 has 12 banks of 8 chips per board and two boards for 192 chips total.

[RichBC]

Sidehack thanks for the detailed explanation of my simple multiplier, nice to know. I will put the numbers in a spreadsheet to fully understand the maths.

Rich



Off Topic S3 Voltage Control 

I have read just about everything on the Forum and still regard it as unproven that any S3 variant has voltage control. Reason for feeling this is that the only people that have reported improved J/GH are those with pencils and soldering irons. If there is such an animal it should be a keeper as I think the S3 is the best built of the Series, and undervolted & underclocked will make money at least until Halving.

I will pursue this niggle elsewhere.

[sloopy]

So to my question. Steve as someone with an insight into cgminer. Are you aware of what happens below the text box, and if it should do something on an S3?  Or are you just writing to a lower level interface with no knowledge of what is or is not changed in the hardware?

Almost all of the older S3+ batches had voltage control, but then batches became mixed between having voltage control and not. In order to unify the firmware (or to reduce the work required), they disabled voltage modification via the firmware. So there is still a box but it won't do anything on the up to date firmwares.

As you will see from Pekatete's threads and threads he references in his OP there were definitely some S3s which could change the core voltage and using the 10-24 firmware you can change it, do a cold boot and measure the difference.
Dogie is right on saying the batches were different because I think even single batches were mixed. I was unable to determine how to tell the difference between one which could be modified or not modified.
*Warning* The 10-24 firmware is the one which could not be reset, the button functionality is broken, which caused several people to brick their boards. However the 12-19 firmware and 1-09 firmware had their own issues. Even though they corrected the reset issue I still needed to check or uncheck keep my settings when upgrading firmware. I always have to completely reset to whatever is included with the firmware, the hash rate with both dropped consistently, and overall I was unable to maintain the same performance, even uptime at standard / default clock speeds.

I'd planned on testing out Kano's latest firmware but I've been so tied down to work projects and a couple of other home situations I have not had time. (I had some injections in the ol back today, so down for this weekend from those, doc said to take it easy).
I also ran across the pencil mod for the S3 here and wanted to test it out, but haven't gotten to it either.

The s3+ units have all responded to vcore change for me. I have consistent 500 hashrates with very low errors, but is that the best way to run these today? No, we want lower power usage with the best hashrate, or most of us do anyway, hence the pencil mod. Knowing you can go up usually means you can go down, but obviously nothing is ever absolute.

I understand BITMAIN removed the vcore adjustment because they had warranty issues with people making a change which didn't work out for them and for various reasons RMAd units. IMO this is when you password protect a screen or put something in so you know if the vcore was changed. Throw a disclaimer out regarding overclocking which is what they do now. If the unit is RMAd over said change then you explain to the customer they agreed that if they overclocked it isn't covered.

My issue with the way they handled the S5 is officially annouce it is a 1.1 unit but can do 1.3x then go on to officially say it can use a 9v input for lower clocks but you cannot, etc. These are simple things to prove before the unit hits the field. Coupled with the fact they do not support vcore adjustments on the S5 (hardware limited) then you have not given a way for underclocking to happen and that is the most important aspect for longevity in the current scene.

You know most people want to underclock (especially as the units age). Having or missing that in today's market is missing a huge selling point and is a huge reason why many people would still trade their left nut for Spondoolies gear. It was simply developed and matured quickly because the hardware options were there which allowed them to truly give the customers what they wanted.
Although it was completely misrepresented on the high end. Very few people ever attained the 1.7 and it was purely a hardware limitation. The firmware was certainly capable. Don't tell me it was because people did not cool them well enough, etc because I did it myself and even sitting outside in below freezing temps the heat was still too much and caused it to throttle, and even when I took everything out of the box with separate fans directly on the hash boards my best SP20 barely broke 1.6.
Maybe with phase change, DICE, chill box, or some other extreme cooling method you can get there, but I seriously doubt even spending the money for customized water blocks, or the gear which is water cooled with Rockerbox chips can attain the top spec they quoted.

In summary both companies misrepresented their flagship products and had to know they did so. All they had to do was test, and obviously they did so. You would think heads would roll over something like that. Say marketing simply published what engineering told them and therefore that is what miners were given. As soon as the CEO realized the product could not do what they told the public it would then a public apology should come out and someone should be fired.
The Asic world is a different place and I assume it is because it is so much smaller, there are so many scams, etc because we do (or would if we were able) continue to patronize those businesses.  

I am going into my S5+ purchase with the understanding it is still an S5, and not to expect a great underclock ability which actually saves significant power. At least I haven't seen any great results on the S5 units I own, but no problems overclocking. If I could purchase an SP50 I would be wary of the quoted top end.

If say any company (Sfards for example)  unit drops with clearly quoted, attainable upper and lower clocks / vcore / input voltage regulation, and they actually respected the hardware limitations in those quotes they would find themselves not only more customers but many of those customers willing to pay more for their units.

Again, IMO there is a lot to be said for honesty, realizing you made a mistake, owning it, and making it right. There really is not a reason to lie. Obviously lying about your products are never a good thing, but when you know your customer base has people with the skills to quickly prove these things it comes across more as an I don't care you will buy it anyway type of viewpoint.
 

[RichBC]

So to my question. Steve as someone with an insight into cgminer. Are you aware of what happens below the text box, and if it should do something on an S3?  Or are you just writing to a lower level interface with no knowledge of what is or is not changed in the hardware?

Almost all of the older S3+ batches had voltage control, but then batches became mixed between having voltage control and not. In order to unify the firmware (or to reduce the work required), they disabled voltage modification via the firmware. So there is still a box but it won't do anything on the up to date firmwares.

As you will see from Pekatete's threads and threads he references in his OP there were definitely some S3s which could change the core voltage and using the 10-24 firmware you can change it, do a cold boot and measure the difference.
Dogie is right on saying the batches were different because I think even single batches were mixed. I was unable to determine how to tell the difference between one which could be modified or not modified.
*Warning* The 10-24 firmware is the one which could not be reset, the button functionality is broken, which caused several people to brick their boards. However the 12-19 firmware and 1-09 firmware had their own issues. Even though they corrected the reset issue I still needed to check or uncheck keep my settings when upgrading firmware. I always have to completely reset to whatever is included with the firmware, the hash rate with both dropped consistently, and overall I was unable to maintain the same performance, even uptime at standard / default clock speeds.

I'd planned on testing out Kano's latest firmware but I've been so tied down to work projects and a couple of other home situations I have not had time. (I had some injections in the ol back today, so down for this weekend from those, doc said to take it easy).
I also ran across the pencil mod for the S3 here and wanted to test it out, but haven't gotten to it either.

The s3+ units have all responded to vcore change for me. I have consistent 500 hashrates with very low errors, but is that the best way to run these today? No, we want lower power usage with the best hashrate, or most of us do anyway, hence the pencil mod. Knowing you can go up usually means you can go down, but obviously nothing is ever absolute.

I understand BITMAIN removed the vcore adjustment because they had warranty issues with people making a change which didn't work out for them and for various reasons RMAd units. IMO this is when you password protect a screen or put something in so you know if the vcore was changed. Throw a disclaimer out regarding overclocking which is what they do now. If the unit is RMAd over said change then you explain to the customer they agreed that if they overclocked it isn't covered.

My issue with the way they handled the S5 is officially annouce it is a 1.1 unit but can do 1.3x then go on to officially say it can use a 9v input for lower clocks but you cannot, etc. These are simple things to prove before the unit hits the field. Coupled with the fact they do not support vcore adjustments on the S5 (hardware limited) then you have not given a way for underclocking to happen and that is the most important aspect for longevity in the current scene.

Ok lets persue S3 firmware voltage control here, and see if I can put it to bed.   I only have 1 S3 & 1 S3+ and I am quite certain that neither have Core Voltage Control. Quite apart from the fact that it does not work if you look at the boards they all have the TPS53355 which uses a potential divider to set the voltage & there is no additional circuitry to add that feature.

I have read Pekatete's thread from cover to cover and although it mentions what I would regard as secondary improvments I have not seen a mention of a measured core voltage or improved J/GH.

On the firmware I have tried them all. Is the 10-24 the only one that is supposed to change the voltage? What about 14-10-13, 14-11-26 & 14-12-19? I know that 15-01-09 reports it as removed.

So to the 64000 Dollar question. Are you saying that you have an S3+ that you have from cgminer set the voltage & then measured it to confirm that it has changed and seen an improved J/GH? If so do you have a picture of the Hash board showing the DC-DC converter circuitry?   I have seen pictures of Converters on an S3 hash board which do have a different converter IC but none of them were high enough resolution to read the chip number. Sorry to be anal about this, but I am a "If it hasn't been measured I don't believe it type of guy"

Heres the picture I posted, in the S3+ overclocking thread.



On the right is the TPS53355 and on the left the unkown chip that might, but I suspect does not,  support voltage control.

Rich

S5 can be undervolted. I am still investigating the differences between boards to understand what is preventing some from going below 11V, but that is a story for another thread on another day.

https://bitcointalk.org/index.php?topic=1151460.msg12124622#msg12124622

 S5+ who knows?

[sloopy]

Ok lets persue S3 firmware voltage control here, and see if I can put it to bed.   I only have 1 S3 & 1 S3+ and I am quite certain that neither have Core Voltage Control. Quite apart from the fact that it does not work if you look at the boards they all have the TPS53355 which uses a potential divider to set the voltage & there is no additional circuitry to add that feature.

I have read Pekatete's thread from cover to cover and although it mentions what I would regard as secondary improvments I have not seen a mention of a measured core voltage or improved J/GH.

On the firmware I have tried them all. Is the 10-24 the only one that is supposed to change the voltage? What about 14-10-13, 14-11-26 & 14-12-19? I know that 15-01-09 reports it as removed.

So to the 64000 Dollar question. Are you saying that you have an S3+ that you have from cgminer set the voltage & then measured it to confirm that it has changed and seen an improved J/GH? If so do you have a picture of the Hash board showing the DC-Dc converter circuitry?   I have seen pictures of Converters on an S3 hash board which do have a different converter IC but none of them were high enough resolution to read the chip number.

Rich

I did not try anything previous to the 10-24, but I did use the 12-14 and 1-09.
I did not take any pictures of the DC to DC converter circuitry.
I did measure a higher current draw using my Fluke i410 with my Fluke 87 III, albeit small and maybe / probably within the accumulated tolerances of every component involved. This was 9 months ago, so I do not remember the exact numbers.
I did see and record substantial hashrate improvements with much lower errors versus changing the Frequency alone -  which was what mattered to me. The amount drawn at the wall is not what I cared about then. It is / was the performance, but I was curious about what I read at the wall which is why I even went through the effort of measuring several times/
I did not post a reply to prove anything. I was simply sharing my experiences and am very interested in someone's experience with the pencil mod or any route to a much lower clock which is stable.
To answer your initial question of the last reply though is I set the voltage using the Bitmain interface in the 10-24 firmware. I did not play around with earlier versions as I thought / think earlier versions had other issues along with the reset button problem. The later versions had hashrate issues along with removing the voltage field. I kept a single unit that voltage never seemed to affect anyway on the 12-19, and another on the 1-09 purely for comparison and still firmly believe I made the right choice until I test Kano's and see if it works better because as most people my goal has changed from a higher hashrate and vcore to better overall efficiency with tightened security, and overall functionality improvements especially when discussing hashrate consistency.

I am going to be selling some of these units soon and if you are interested in something feel free to PM me.
If you are interested in a debate regarding the DC to DC circuit existing I am not interested as the S3 and S3+ are not going to be efficient enough for me even with a decent underclock for much longer and there are / were plenty of people / posts discussing such unless they have mysteriously disappeared over the past few months. Bitmain confirmed it as well if that holds water.
 

[RichBC]

Thanks for the detailed reply. Like you I will also be selling my S3's as they have limited life, even underclocked & undervolted. The firmware adjustable thing was just something that bugged me over the last Month going up the learning curve of how to get the best out of mining hardware. I will be putting all my effort into the S5 which apart from the fact that the chained supply scares me (feels a bit like old school Christmas lights) I think it offers the best value for money and best potential for an efficient miner that will still make money, at my $/KWH, after Bitcoin reward halving.

[dogie]

I'm assuming that picture on the right is mine? If so, that's one of the very first S3s to be made, ever (barcode #00003). It may have different board components than even batch #1 and surely will do from batch #1 of S3+s. It did have variable voltage control though.

[sloopy]

I'm assuming that picture on the right is mine? If so, that's one of the very first S3s to be made, ever (barcode #00003). It may have different board components than even batch #1 and surely will do from batch #1 of S3+s. It did have variable voltage control though.

If I remember correctly it was only the older S3s which had variable voltage Dogie.

I am going to retell some things I was told, but do not know these as facts myself, but what I remember reading when there was a big debate is being told the first "couple or few" batches of S3s did have it, but many of those first units stayed in the BITMINE(s) running with 0750 voltage and anywhere from 218 to 250 Frequency.
As they aged they were pulled but by this point the circuit had changed.
Then again when the S3+ came out same thing, many of those stayed in the BITMINE(s) and were not shipped and that there was quite a market saturation along with the fact the price started falling hard and the better performers were kept in the mines until they could begin exchanging those with the next revision (S4).
Even though it was released much later they worked on the S3++ as a private contract at the same time the S4 was being developed and slowly all of the S3 and S3+ best performers were blown off and sold. It wasn't an accident these were popping up occasionally, it was done by schedule, or "blocks" (no pun intended) of miners. Which those miners were well known because they knew what boards were used. The best for the best private contracts, and then they sold them used on ebay which really made it a random act  who picked them up.

This is a factual story I lived:
I lived in Alabama for a few years working for a very small company who handled CNC Machinery. My main job(s) changed many times over the years there but my last few years I was basically a Purchasing Agent / Service Manager. I bought tons of computers because a couple went with every plasma cutting system we sold to run offline software. I made some great friends at a local PC shop. The place was fantastic for me, they loved my business and it was young guys like me at the time. This was the late 90s. They were a place you could go pick up an Athlon Thunderbird 1.6 chip and it would be only $10.00 over what you paid online. They were competitive and went for volume. Birmingham is a big city.  They also had a self-service attitude. Bring your box in and work on it. Customers and employees would get together to figure out what was up.
 Since I'd stopped travelling I was in there every night doing my thing. Since I was buying a lot of PCs and "all the fixins", monitors, printers, you name it, they liked my business. I was treated like an employee in the good ways. When a new batch of RAM came in whoever was interested could pick out what they wanted. I would spend all night going through sticks of RAM, popping them in my test rig to see what they could handle. Those were the ones I bought, at cost when it was my personal money. The same thing with CPUs. As long as I cleaned them up everything was fine. As far as temps, yeah they need to burn in, but speeds, well it does take a while to run benches, but not relative to everything else we had going on. Video cards, you name it, we cherry picked it. We had heat guns to put the plastic wrap back on the boxes. My customers owned machine shops and they always had a son or nephew in the scene and they made water blocks for us, it was a great, fun, learning environment. A problem always turned into a competition and if someone absolutely needed something fixed fast this was the place to go. If someone needed something to finish a job it would be pulled from a personal system if needed. I would have rather worked there but they didn't pay anything close to what I was making. Most of those guys would have worked for free if they could have the bills paid and get frozen pizzas and mountain dew.  The technology was an addiction, add competition and that group of guys were teaching their vendors things. We put peltiers and watercooled anything that moved. I know for a fact some of the early articles on overclockers.com came from people working or doing work in that shop because it was nothing others would risk or even thought about at that point. It kept a lot of "kids" away from drugs by changing addictions, but the main point is you know the same thing happens at many manufacturers. Even BITMAIN.

There is not a moral to my story. I only wanted to get us thinking about how these things happen. How the best batches can be pulled, separated, and then distributed. BITMAIN is still a very new company in a technology area very few understand. Even at BITMAIN I bet young guns who are sick over the latest chips they get and cannot wait to try them in their latest rigs.
We all know the wafers have bad, better, best, blow your mind sections. You better believe the engineers and techs or whoever can get access are cherry-picking the hell out of it. They get a potentially huge contract from a big name and send some samples, what are they going to send? When the techs who pooled their money to buy 2000 BM1384 chips are finished testing, they swap the chips for another batch, and so on, until they know their home rigs are badass. The best of everything they can get from work.
Hey, its a perk. Us in the field are going to get what we were sold, it isn't like we are being done a disservice. I think the disservice comes from how long they stay in the BITMINE(s).

I am picking on BITMAIN here but I do not mean to do so in this case. This goes on anywhere and everywhere until the company gets so bureaucratic, people mature, inventory gets locked down, people lose interest, get married, have kids, etc but even then. There will always be a new batch of kids, with that burn to have the best and the fastest who will find a way. Not to mention if you are the engineer(s) with the keys to the closet.

While I am way off topic, I wanted to propose some other things which fit in what we see as random being perfectly predictable.
I never think it is unusual for someone to get one of the sickest machines, or a batch of them and the next batch be normal.
One of the best things that can be said about things happening this way is I know I always have and will treat my components like gold. I push them hard on the bench to see what they can do but follow instructions and always ask so many questions I'll get on your nerves. I never returned anything in bad condition. IF it was in bad shape it was because I'd seriously fucked up. As in sealing a processor in a mobo socket so well for condensation protection I couldn't get it back out and eventually broke it in half removing it.

These little aluminum heatsinks bitmain is using on the S5+ were going on video cards to cool the memory and processor 20 years ago. We used plexiglass to hang servers on the wall or build cubes of aluminum and have the equivalent of a huge network the size of an end table, watercooled with a volkswagen radiator on the back and plasma power supply pumps closing the loop. We filtered the water, etc, but the RAM, CPUs, Vid cards, hard drives, and anything else which can be cherry picked, was cherry picked.

Many of those mods were sold, and then sold used, again and again. So it was never unusual to hear about someone saying they bought this "kit" that had higher 3Dmark scores and an unusually fast this or that. It was usually something someone had built, played with for a month, sold and were building a new one with the next greatest technology.

Those were some fun nights