Bitmain Launches the New Antminer B3 Miner

[suchmoon]

Saw something that doesn’t match bitmain’s story about the amount of B3’s they sold in Bstch 1
http://miningpoolstats.stream/bytom

It’s on 7700 clients now while a few (including me) still need to receive their Batch 1 B3.

Antpool alone is ~3 MH/s, which would be nearly 4000 B3s. Clearly more than the supposed 2500 they sold in the first batch.


Edited 2020-11-29 to fix a broken image

[mellonballer]

the first batch is 5000, not 2500. 2500 was wishful thinking. Read back through the thread, this has been verified by a bytom developer

[peeraroje]

Guys if i mine via Antpool and provided Hitbtc wallet address. Will the payment be proceeded to hitbtc exchange platform and will i be able to exchange coin? Thanks in advance

Does your BTM address at hitbtc start with 0x? If yes then yes your coins will deposited to the exchange without any problems. Make sure to keep track of your address on the exchange as it might change.

I'm sure that I use ERC20 address on Antpool.
My BTM address start with 0x but my payments is inn "paying" status.

Has anyone run into the same problem?

[Antlia]

Guys if i mine via Antpool and provided Hitbtc wallet address. Will the payment be proceeded to hitbtc exchange platform and will i be able to exchange coin? Thanks in advance

Does your BTM address at hitbtc start with 0x? If yes then yes your coins will deposited to the exchange without any problems. Make sure to keep track of your address on the exchange as it might change.

I'm sure that I use ERC20 address on Antpool.
My BTM address start with 0x but my payments is inn "paying" status.

Has anyone run into the same problem?

Yes me too, 

[SplinterZalinsk]

Guys if i mine via Antpool and provided Hitbtc wallet address. Will the payment be proceeded to hitbtc exchange platform and will i be able to exchange coin? Thanks in advance

Does your BTM address at hitbtc start with 0x? If yes then yes your coins will deposited to the exchange without any problems. Make sure to keep track of your address on the exchange as it might change.

I'm sure that I use ERC20 address on Antpool.
My BTM address start with 0x but my payments is inn "paying" status.

Has anyone run into the same problem?

Yes me too, 

Did you guys set the minimum payment for 100 BTM on the pool settings?

[SplinterZalinsk]

I'm definitely looking for a solution about the excessive noise of this baby

[henrylitee]

if i'm not wrong minning in antpool 24 hours you can get 55-60 BTM coins, its not really good..

[tw0rak]

if i'm not wrong minning in antpool 24 hours you can get 55-60 BTM coins, its not really good..

I think 50usd/day is very good...
What did you expect - 500usd/day?

[peeraroje]

Guys if i mine via Antpool and provided Hitbtc wallet address. Will the payment be proceeded to hitbtc exchange platform and will i be able to exchange coin? Thanks in advance

Does your BTM address at hitbtc start with 0x? If yes then yes your coins will deposited to the exchange without any problems. Make sure to keep track of your address on the exchange as it might change.

I'm sure that I use ERC20 address on Antpool.
My BTM address start with 0x but my payments is inn "paying" status.

Has anyone run into the same problem?

Yes me too, 

Did you guys set the minimum payment for 100 BTM on the pool settings?

The problem is not about the minimun payment which is fixed to 100 BTM by default.

[llanaio]

All,
Curious to know if anyone else is seeing the same behaviors as me.

1) No matter the pool configuration order, 0 and 2 are always marked dead.
Bmminer always chooses pool priority 1, regardless of the port.
Same behavior for 443, 6666 and 25.

2) Rejected share rates seem to be very high. Roughly 45% in my case. It doesn’t appear that my profitability has been affected at the pool, but I’d like some anecdotal feedback that others are seeing the same reject rates.

Does anyone know if these are all getwork ports at the moment?
The only pool source released by BYTOM is getwork-based, and no formal stratum protocol reference has been published.
I suspect Antpool plans on deprecating GETWORK support on ports 6666 and 443.

Cheers,
9600

I'm getting "Alive" on all three pools and priority is given to pool 0. Also, I am receiving Getworks on all three pools. (Though pool 0 is the most by far.) This may be a local issue for your miner. However, my rejected share rate is generally in line with yours.

Just another data point in case it helps diagnose your issue. Good luck!

[suchmoon]

I'm definitely looking for a solution about the excessive noise of this baby

Did you try unplugging the exhaust fan? If your room is cool enough you might get away with that.

Another option is to replace the fans. I had a couple of Delta fans (Dell part # Y4574; 5-pin plug - had to replace that) laying around so I put them on. Not quiet but much better. No more high-pitch screaming noise.

Hopefully a firmware update will rectify this.

[SplinterZalinsk]

I'm definitely looking for a solution about the excessive noise of this baby

Did you try unplugging the exhaust fan? If your room is cool enough you might get away with that.

Another option is to replace the fans. I had a couple of Delta fans (Dell part # Y4574; 5-pin plug - had to replace that) laying around so I put them on. Not quiet but much better. No more high-pitch screaming noise.

Hopefully a firmware update will rectify this.

Nice... I'm probably going to change the fans of mine as well

[9600]

the first batch is 5000, not 2500. 2500 was wishful thinking. Read back through the thread, this has been verified by a bytom developer

I believe the breakdown was 2500 for the Global market and 2500 for the Chinese domestic market. (Remember, BYTOM is huge in its domestic market. Their Global outreach is just now beginning to take shape)

Also, Batch two units are beginning to arrive. Mine is set to be delivered early (Tomorrow) for some reason.
Expect B1/B2 A3 ROI times here. I’d be surprised if we’re mining 25 BTM a day by next week.

It’s also worth mentioning that just because one hasn’t been made public, doesn’t mean a GPU/TPU solver (Tensor Processing Unit like Sophon/Movidius/Google TPU) isn’t out in the wild. The source and C implementation of Tensority has been published for a while now.  The Nvidia TPU cores on their Volta GPUs are far more powerful than even the Sophon units, so it’s possible cloud provider mining is profitable atm.

[motomart]

You can adjust the fan speeds by editing the file /config/bmminer.conf and adding these lines:

"bitmain-fan-ctrl" : true,
"bitmain-fan-pwm" : "50"


That adjusts it to 50 percent the default speed

Here is the whole bracket in my current config:

}
]
,
"api-listen" : true,
"api-network" : true,
"api-groups" : "A:stats:pools:devs:summary:version",
"api-allow" : "A:0/0,W:*",
"bitmain-use-vil" : true,
"bitmain-freq" : "_ant_voltage=0706",
"bitmain-voltage" : "0706",
"multi-version" : "1",
"bitmain-fan-ctrl" : true,
"bitmain-fan-pwm" : "50"
}

My only concern with this, is any potential reason Bitmain shipped them without PWM control enabled. It’s clear that there shouldn’t be a need for this volume of air when dissipating 330W, but I’d be curious to see if the rejected share rate gets higher as the temperatures creep closer to 70+

(I don’t think BMMiner is reading HW errors in the traditional sense in this Tensority build.)

The miner seems overengineered.
Has anyone tried pushing the ASICs past 750 yet?
(The default config shows “bitmain-freq" : "750" in bmminer.conf.factory)

Either there’s headroom both ways, or the blocks on these ASICs start to bug out at higher frequencies/temperatures.

Who’s willing to figure out? 

PS - Anyone else get shipping confirmation for batch 2? Seems early...

I have tried to change frequency in bmminer.conf and bmminer.conf.factory but it stays at 750.

[Kavela]

the first batch is 5000, not 2500. 2500 was wishful thinking. Read back through the thread, this has been verified by a bytom developer

I believe the breakdown was 2500 for the Global market and 2500 for the Chinese domestic market. (Remember, BYTOM is huge in its domestic market. Their Global outreach is just now beginning to take shape)

Also, Batch two units are beginning to arrive. Mine is set to be delivered early (Tomorrow) for some reason.
Expect B1/B2 A3 ROI times here. I’d be surprised if we’re mining 25 BTM a day by next week.

It’s also worth mentioning that just because one hasn’t been made public, doesn’t mean a GPU/TPU solver (Tensor Processing Unit like Sophon/Movidius/Google TPU) isn’t out in the wild. The source and C implementation of Tensority has been published for a while now.  The Nvidia TPU cores on their Volta GPUs are far more powerful than even the Sophon units, so it’s possible cloud provider mining is profitable atm.

How you get your second batch while my first batch is still on its way its kinda not fair then. :/

[9600]

the first batch is 5000, not 2500. 2500 was wishful thinking. Read back through the thread, this has been verified by a bytom developer

I believe the breakdown was 2500 for the Global market and 2500 for the Chinese domestic market. (Remember, BYTOM is huge in its domestic market. Their Global outreach is just now beginning to take shape)

Also, Batch two units are beginning to arrive. Mine is set to be delivered early (Tomorrow) for some reason.
Expect B1/B2 A3 ROI times here. I’d be surprised if we’re mining 25 BTM a day by next week.

It’s also worth mentioning that just because one hasn’t been made public, doesn’t mean a GPU/TPU solver (Tensor Processing Unit like Sophon/Movidius/Google TPU) isn’t out in the wild. The source and C implementation of Tensority has been published for a while now.  The Nvidia TPU cores on their Volta GPUs are far more powerful than even the Sophon units, so it’s possible cloud provider mining is profitable atm.

How you get your second batch while my first batch is still on its way its kinda not fair then. :/

I ABSOLUTELY AGREE WITH YOU!  

Do you have your shipment information from them?
What does your tracking say?

I can't be the ONLY ONE who got alerts for batch 2.
I do use DHL and perhaps that makes a difference. As does the final destination.
My shipping destination is usually pre-cleared with customs before any hardware hits the shore.
Products usually arrive at my door within 48 hours of leaving Bitmain's facilities.

[Dlikrot]

In the same boat. Waiting for batch nr 1....

[9600]

You can adjust the fan speeds by editing the file /config/bmminer.conf and adding these lines:

"bitmain-fan-ctrl" : true,
"bitmain-fan-pwm" : "50"


That adjusts it to 50 percent the default speed

Here is the whole bracket in my current config:

}
]
,
"api-listen" : true,
"api-network" : true,
"api-groups" : "A:stats:pools:devs:summary:version",
"api-allow" : "A:0/0,W:*",
"bitmain-use-vil" : true,
"bitmain-freq" : "_ant_voltage=0706",
"bitmain-voltage" : "0706",
"multi-version" : "1",
"bitmain-fan-ctrl" : true,
"bitmain-fan-pwm" : "50"
}

My only concern with this, is any potential reason Bitmain shipped them without PWM control enabled. It’s clear that there shouldn’t be a need for this volume of air when dissipating 330W, but I’d be curious to see if the rejected share rate gets higher as the temperatures creep closer to 70+

(I don’t think BMMiner is reading HW errors in the traditional sense in this Tensority build.)

The miner seems overengineered.
Has anyone tried pushing the ASICs past 750 yet?
(The default config shows “bitmain-freq" : "750" in bmminer.conf.factory)

Either there’s headroom both ways, or the blocks on these ASICs start to bug out at higher frequencies/temperatures.

Who’s willing to figure out? 

PS - Anyone else get shipping confirmation for batch 2? Seems early...

I have tried to change frequency in bmminer.conf and bmminer.conf.factory but it stays at 750.

Unfortunately we know nothing about this version of BMMiner and Bitmain has yet to publish the source used in this firmware.
I'd be curious to know if the parameters work when passed to BMMiner directly.

PS the running cgminer, copy the launch syntax, kill the process, and then launch the miner from the CLI using the fan, fan PWM, and freq flags in line. Can't hurt to try.

I can archive the filesystem and host the gzip if anyone's interested in poking around.

[suchmoon]

Unfortunately we know nothing about this version of BMMiner and Bitmain has yet to publish the source used in this firmware.
I'd be curious to know if the parameters work when passed to BMMiner directly.

PS the running cgminer, copy the launch syntax, kill the process, and then launch the miner from the CLI using the fan, fan PWM, and freq flags in line. Can't hurt to try.

I can archive the filesystem and host the gzip if anyone's interested in poking around.

Good point. Unfortunately I'm not near my miner so I can't see if the fans react to the command line at all. Frequency is ignored, at least in the GUI. Shows 750 regardless of what's being passed to bmminer.

Launch command:

Code:

/usr/bin/bmminer --version-file /usr/bin/compile_time --default-config /config/bmminer.conf -T

--help output:

Code:

root@antMiner:~# /usr/bin/bmminer --help
bmminer 2.0.0
Built with bitmain_c5 mining support.
Usage: /usr/bin/bmminer [-DElmpPQqUsouOchV]
Options for both config file and command line:
--version-file <arg> Set miner version file
--logfile-openflag <arg> Set log file open flag, default: a+
--logwork <arg>     Set log work file path, following: minertext
--logwork-asicnum <arg> Set log work asic num, following: 1, 32, 64
--logwork-diff      Allow log work diff
--logfile <arg>     Set log file, default: bmminer.log
--api-allow <arg>   Allow API access only to the given list of [G:]IP[/Prefix] addresses[/subnets]
--api-description <arg> Description placed in the API status header, default: cgminer version
--api-groups <arg>  API one letter groups G:cmd:cmd[,P:cmd:*...] defining the cmds a groups can use
--api-listen        Enable API, default: disabled
--api-mcast         Enable API Multicast listener, default: disabled
--api-mcast-addr <arg> API Multicast listen address
--api-mcast-code <arg> Code expected in the API Multicast message, don't use '-'
--api-mcast-des <arg> Description appended to the API Multicast reply, default: ''
--api-mcast-port <arg> API Multicast listen port (default: 4028)
--api-network       Allow API (if enabled) to listen on/for any address, default: only 127.0.0.1
--api-port <arg>    Port number of miner API (default: 4028)
--api-host <arg>    Specify API listen address, default: 0.0.0.0
--balance           Change multipool strategy from failover to even share balance
--benchfile <arg>   Run cgminer in benchmark mode using a work file - produces no shares
--benchfile-display Display each benchfile nonce found
--benchmark         Run cgminer in benchmark mode - produces no shares
--bitmain-fan-ctrl  Enable bitmain miner fan controlling
--bitmain-fan-pwm <arg> Set bitmain fan pwm percentage 0~100 (default: 50)
--bitmain-freq <arg> Set frequency (default: 200)
--debug|-D          Enable debug output
--disable-rejecting Automatically disable pools that continually reject shares
--expiry|-E <arg>   Upper bound on how many seconds after getting work we consider a share from it stale (default: 120)
--extranonce-subscribe Enable 'extranonce' stratum subscribe for MinToRRo by Zwilla
--failover-only     Don't leak work to backup pools when primary pool is lagging
--fix-protocol      Do not redirect to a different getwork protocol (eg. stratum)
--fallback-time <arg> Set time in seconds to fall back to a higher priority pool after period of instability (default: 120)
--load-balance      Change multipool strategy from failover to quota based balance
--log|-l <arg>      Interval in seconds between log output (default: 5)
--lowmem            Minimise caching of shares for low memory applications
--monitor|-m <arg>  Use custom pipe cmd for output messages
--net-delay         Impose small delays in networking to not overload slow routers
--no-submit-stale   Don't submit shares if they are detected as stale
--pass|-p <arg>     Password for bitcoin JSON-RPC server
--per-device-stats  Force verbose mode and output per-device statistics
--protocol-dump|-P  Verbose dump of protocol-level activities
--queue|-Q <arg>    Maximum number of work items to have queued (default: 1)
--quiet|-q          Disable logging output, display status and errors
--quota|-U <arg>    quota;URL combination for server with load-balance strategy quotas
--real-quiet        Disable all output
--rotate <arg>      Change multipool strategy from failover to regularly rotate at N minutes
--round-robin       Change multipool strategy from failover to round robin on failure
--scan-time|-s <arg> Upper bound on time spent scanning current work, in seconds (default: -1)
--sched-start       Set a time of day in HH:MM to start mining (a once off without a stop time)
--sched-stop        Set a time of day in HH:MM to stop mining (will quit without a start time)
--sharelog          Append share log to file
--shares <arg>      Quit after mining N shares (default: unlimited)
--socks-proxy <arg> Set socks4 proxy (host:port)
--suggest-diff <arg> Suggest miner difficulty for pool to user (default: none)
--multi-version <arg> Multi version mining!
--syslog            Use system log for output messages (default: standard error)
--url|-o <arg>      URL for bitcoin JSON-RPC server
--user|-u <arg>     Username for bitcoin JSON-RPC server
--userpass|-O <arg> Username:Password pair for bitcoin JSON-RPC server
--verbose           Log verbose output to stderr as well as status output
--widescreen        Use extra wide display without toggling
--worktime          Display extra work time debug information
Options for command line only:
--config|-c <arg>   Load a JSON-format configuration file
See example-S7.conf or S9.conf for an example configuration.
--default-config <arg> Specify the filename of the default config file
Loaded at start and used when saving without a name.
--help|-h           Print this message
--version|-V        Display version and exit
root@antMiner:~#

[motomart]

Unfortunately we know nothing about this version of BMMiner and Bitmain has yet to publish the source used in this firmware.
I'd be curious to know if the parameters work when passed to BMMiner directly.

PS the running cgminer, copy the launch syntax, kill the process, and then launch the miner from the CLI using the fan, fan PWM, and freq flags in line. Can't hurt to try.

I can archive the filesystem and host the gzip if anyone's interested in poking around.

Good point. Unfortunately I'm not near my miner so I can't see if the fans react to the command line at all. Frequency is ignored, at least in the GUI. Shows 750 regardless of what's being passed to bmminer.

Launch command:

Code:

/usr/bin/bmminer --version-file /usr/bin/compile_time --default-config /config/bmminer.conf -T

--help output:

Code:

root@antMiner:~# /usr/bin/bmminer --help
bmminer 2.0.0
Built with bitmain_c5 mining support.
Usage: /usr/bin/bmminer [-DElmpPQqUsouOchV]
Options for both config file and command line:
--version-file <arg> Set miner version file
--logfile-openflag <arg> Set log file open flag, default: a+
--logwork <arg>     Set log work file path, following: minertext
--logwork-asicnum <arg> Set log work asic num, following: 1, 32, 64
--logwork-diff      Allow log work diff
--logfile <arg>     Set log file, default: bmminer.log
--api-allow <arg>   Allow API access only to the given list of [G:]IP[/Prefix] addresses[/subnets]
--api-description <arg> Description placed in the API status header, default: cgminer version
--api-groups <arg>  API one letter groups G:cmd:cmd[,P:cmd:*...] defining the cmds a groups can use
--api-listen        Enable API, default: disabled
--api-mcast         Enable API Multicast listener, default: disabled
--api-mcast-addr <arg> API Multicast listen address
--api-mcast-code <arg> Code expected in the API Multicast message, don't use '-'
--api-mcast-des <arg> Description appended to the API Multicast reply, default: ''
--api-mcast-port <arg> API Multicast listen port (default: 4028)
--api-network       Allow API (if enabled) to listen on/for any address, default: only 127.0.0.1
--api-port <arg>    Port number of miner API (default: 4028)
--api-host <arg>    Specify API listen address, default: 0.0.0.0
--balance           Change multipool strategy from failover to even share balance
--benchfile <arg>   Run cgminer in benchmark mode using a work file - produces no shares
--benchfile-display Display each benchfile nonce found
--benchmark         Run cgminer in benchmark mode - produces no shares
--bitmain-fan-ctrl  Enable bitmain miner fan controlling
--bitmain-fan-pwm <arg> Set bitmain fan pwm percentage 0~100 (default: 50)
--bitmain-freq <arg> Set frequency (default: 200)
--debug|-D          Enable debug output
--disable-rejecting Automatically disable pools that continually reject shares
--expiry|-E <arg>   Upper bound on how many seconds after getting work we consider a share from it stale (default: 120)
--extranonce-subscribe Enable 'extranonce' stratum subscribe for MinToRRo by Zwilla
--failover-only     Don't leak work to backup pools when primary pool is lagging
--fix-protocol      Do not redirect to a different getwork protocol (eg. stratum)
--fallback-time <arg> Set time in seconds to fall back to a higher priority pool after period of instability (default: 120)
--load-balance      Change multipool strategy from failover to quota based balance
--log|-l <arg>      Interval in seconds between log output (default: 5)
--lowmem            Minimise caching of shares for low memory applications
--monitor|-m <arg>  Use custom pipe cmd for output messages
--net-delay         Impose small delays in networking to not overload slow routers
--no-submit-stale   Don't submit shares if they are detected as stale
--pass|-p <arg>     Password for bitcoin JSON-RPC server
--per-device-stats  Force verbose mode and output per-device statistics
--protocol-dump|-P  Verbose dump of protocol-level activities
--queue|-Q <arg>    Maximum number of work items to have queued (default: 1)
--quiet|-q          Disable logging output, display status and errors
--quota|-U <arg>    quota;URL combination for server with load-balance strategy quotas
--real-quiet        Disable all output
--rotate <arg>      Change multipool strategy from failover to regularly rotate at N minutes
--round-robin       Change multipool strategy from failover to round robin on failure
--scan-time|-s <arg> Upper bound on time spent scanning current work, in seconds (default: -1)
--sched-start       Set a time of day in HH:MM to start mining (a once off without a stop time)
--sched-stop        Set a time of day in HH:MM to stop mining (will quit without a start time)
--sharelog          Append share log to file
--shares <arg>      Quit after mining N shares (default: unlimited)
--socks-proxy <arg> Set socks4 proxy (host:port)
--suggest-diff <arg> Suggest miner difficulty for pool to user (default: none)
--multi-version <arg> Multi version mining!
--syslog            Use system log for output messages (default: standard error)
--url|-o <arg>      URL for bitcoin JSON-RPC server
--user|-u <arg>     Username for bitcoin JSON-RPC server
--userpass|-O <arg> Username:Password pair for bitcoin JSON-RPC server
--verbose           Log verbose output to stderr as well as status output
--widescreen        Use extra wide display without toggling
--worktime          Display extra work time debug information
Options for command line only:
--config|-c <arg>   Load a JSON-format configuration file
See example-S7.conf or S9.conf for an example configuration.
--default-config <arg> Specify the filename of the default config file
Loaded at start and used when saving without a name.
--help|-h           Print this message
--version|-V        Display version and exit
root@antMiner:~#

Edited /etc/init.d/bmminer.sh and restarted bmminer by running the script.

Code:

3528  3527 root     S <   246m 50.7   0  9.5 /usr/bin/bmminer --version-file /usr/bin/compile_time --default-config /config/bmminer.conf --bitmain-freq 220 -T

Still hashing about the same @800 H/s and show frequency 750