Author

Topic: S9... Can I run just 1 or 2 blades? (Read 458 times)

member
Activity: 277
Merit: 70
January 17, 2018, 05:50:11 PM
#36
GbrilliantQ - I had to email once or twice for status updates, but each time an email came back within 24 hours.  if your worried it's taking a bit longer than expected shoot an email out.
full member
Activity: 189
Merit: 100
ƃqɹᴉllᴉɐuʇb
January 17, 2018, 02:48:38 PM
#35
Great to hear. I'm waiting for their follow up now.  I have 1 blade that got borked during a power outage.... I dont know how, but 19 other miners wasn't affected.   
member
Activity: 266
Merit: 13
January 17, 2018, 12:13:02 PM
#34
That’s great news. Glad it all worked out for you. When you pay for 3 boards and only get 2 that reallly kills the excitement.
member
Activity: 277
Merit: 70
January 17, 2018, 07:11:41 AM
#33
It is in and has been hashing for over 12 hours now.  The whole rig is up to 13.5T just like it should be, pulling 1377 watts from the wall.  The repaired board runs 8 - 10 degrees warmer than the other 2 (66, 68, 77), and has more hardware errors (9, 64, 257) but the total hw errors are .0002% which I've read is fine.  I'm sure it is just coincidence the board runs hotter, I know that temps can fluctuate quite a bit between boards on the same rig.

They forgot to put the foam back on around the top of the board where the pcie plugs stick out so it was a bit loose and rattled.  I have some self stick weatherstripping foam that was just the right size, so I slapped that on there and problem solved!

Thanks again for all of the help.  I can wholeheartedly recommend bitmainwarranty for your repair needs.
legendary
Activity: 3164
Merit: 2258
I fix broken miners. And make holes in teeth :-)
January 16, 2018, 10:18:36 PM
#32
Sweet. Glad it's fixed, and that's a pretty reasonable price for a FET swap. If Bitmainwarranty is doing a good job then that is very good to know.

I'd do about the same thing except I only take bitcoin and litecoin :-)

C
member
Activity: 266
Merit: 13
January 16, 2018, 09:25:41 PM
#31
Glad to hear they could fix it. I’d say you made the right choice by sending it to them vs Bitmain. Interested to hear how it’s working.
member
Activity: 277
Merit: 70
January 16, 2018, 11:36:41 AM
#30
For those of you still following my saga... here is an update!

The board was repaired by bitmainwarranty.com and has been shipped back to me.  The total cost for repairs and return shipping was exactly $200, which I could pay using paypal or crypto through coinbase.  While they never disclosed to me what was wrong with it, they responded very promptly to all of my emails, updating me with (paraphrased)

"we have received it"
"the tech is running diagnostics now"
"the tech believes it can be repaired"
"the tech has repaired it, please pay the invoice"

They shipped it out the same day I paid.

The entire process from me shipping out to having it back in hand took about a month, but Christmas and New Years undoubtedly slowed things down.  It is expected to be delivered today and I'll throw it in tonight and see what happens.  I am pretty confident that it will work, but I'll post one final time with the results.

In the meantime, I have been hashing away with just 2 boards at around 9 TH/s which has mined 0.037 BTC while awaiting the repairs.  The warranty is shot on the rig, since I opened it up to send the board, but in the long run I think I have made out ahead.

Thanks to all those who commented and helped along the way!  I'll post one more time after I get the board back in!
legendary
Activity: 3164
Merit: 2258
I fix broken miners. And make holes in teeth :-)
December 15, 2017, 08:31:01 PM
#29
Flip it over, other side same area. The FETs are small square things with 4 pins on one side and what look like 4 on the other (ground plane).

So the unit starts up, then shuts down that power supply once it hits a certain spot in the boot sequence? If so it means when the PS tries to buck by turning on the shorted FET takes it down. One interesting thing about S9's is that they put a heat sink on the other side of the board for them, which indicates they are running those supplies harder than the S7's....

C
member
Activity: 277
Merit: 70
December 15, 2017, 06:31:37 PM
#28
Not sure what a FET is lightfoot

https://imgur.com/a/G5s9Y. Does this help?
member
Activity: 277
Merit: 70
December 15, 2017, 06:24:58 PM
#27
Here is as far as the bad board gets before shutting down.

Code:
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.14.0-xilinx-ge8a2f71-dirty (lzq@armdev2) (gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-23) ) #82 SMP PREEMPT Tue May 16 19:49:53 CST 2017
[    0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine model: Xilinx Zynq
[    0.000000] cma: CMA: reserved 128 MiB at 16800000
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] On node 0 totalpages: 126976
[    0.000000] free_area_init_node: node 0, pgdat c0740a40, node_mem_map debd8000
[    0.000000]   Normal zone: 992 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 126976 pages, LIFO batch:31
[    0.000000] PERCPU: Embedded 8 pages/cpu @debc1000 s9088 r8192 d15488 u32768
[    0.000000] pcpu-alloc: s9088 r8192 d15488 u32768 alloc=8*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 125984
[    0.000000] Kernel command line: noinitrd mem=496M console=ttyPS0,115200 root=ubi0:rootfs ubi.mtd=1 rootfstype=ubifs rw rootwait
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 364356K/507904K available (5032K kernel code, 283K rwdata, 1916K rodata, 204K init, 258K bss, 143548K reserved, 0K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xdf800000 - 0xff000000   ( 504 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xdf000000   ( 496 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc06d1374   (6949 kB)
[    0.000000]       .init : 0xc06d2000 - 0xc0705380   ( 205 kB)
[    0.000000]       .data : 0xc0706000 - 0xc074cf78   ( 284 kB)
[    0.000000]        .bss : 0xc074cf84 - 0xc078d9fc   ( 259 kB)
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] Dump stacks of tasks blocking RCU-preempt GP.
[    0.000000] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] ps7-slcr mapped to df802000
[    0.000000] zynq_clock_init: clkc starts at df802100
[    0.000000] Zynq clock init
[    0.000015] sched_clock: 64 bits at 333MHz, resolution 3ns, wraps every 3298534883328ns
[    0.000306] ps7-ttc #0 at df804000, irq=43
[    0.000614] Console: colour dummy device 80x30
[    0.000645] Calibrating delay loop... 1325.46 BogoMIPS (lpj=6627328)
[    0.040206] pid_max: default: 32768 minimum: 301
[    0.040427] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.040447] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.042566] CPU: Testing write buffer coherency: ok
[    0.042898] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.042958] Setting up static identity map for 0x4c4b00 - 0x4c4b58
[    0.043182] L310 cache controller enabled
[    0.043202] l2x0: 8 ways, CACHE_ID 0x410000c8, AUX_CTRL 0x72760000, Cache size: 512 kB
[    0.121034] CPU1: Booted secondary processor
[    0.210225] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.210355] Brought up 2 CPUs
[    0.210374] SMP: Total of 2 processors activated.
[    0.210382] CPU: All CPU(s) started in SVC mode.
[    0.211043] devtmpfs: initialized
[    0.213458] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[    0.214674] regulator-dummy: no parameters
[    0.222354] NET: Registered protocol family 16
[    0.224592] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.226884] cpuidle: using governor ladder
[    0.226898] cpuidle: using governor menu
[    0.234341] syscon f8000000.ps7-slcr: regmap [mem 0xf8000000-0xf8000fff] registered
[    0.235872] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
[    0.235885] hw-breakpoint: maximum watchpoint size is 4 bytes.
[    0.235998] zynq-ocm f800c000.ps7-ocmc: ZYNQ OCM pool: 256 KiB @ 0xdf880000
[    0.257822] bio: create slab at 0
[    0.259244] vgaarb: loaded
[    0.259950] SCSI subsystem initialized
[    0.260988] usbcore: registered new interface driver usbfs
[    0.261229] usbcore: registered new interface driver hub
[    0.261460] usbcore: registered new device driver usb
[    0.261991] media: Linux media interface: v0.10
[    0.262145] Linux video capture interface: v2.00
[    0.262381] pps_core: LinuxPPS API ver. 1 registered
[    0.262392] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti
[    0.262513] PTP clock support registered
[    0.262863] EDAC MC: Ver: 3.0.0
[    0.263917] Advanced Linux Sound Architecture Driver Initialized.
[    0.266322] DMA-API: preallocated 4096 debug entries
[    0.266336] DMA-API: debugging enabled by kernel config
[    0.266422] Switched to clocksource arm_global_timer
[    0.287674] NET: Registered protocol family 2
[    0.288319] TCP established hash table entries: 4096 (order: 2, 16384 bytes)
[    0.288376] TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
[    0.288461] TCP: Hash tables configured (established 4096 bind 4096)
[    0.288506] TCP: reno registered
[    0.288524] UDP hash table entries: 256 (order: 1, 8192 bytes)
[    0.288557] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[    0.288801] NET: Registered protocol family 1
[    0.289189] RPC: Registered named UNIX socket transport module.
[    0.289202] RPC: Registered udp transport module.
[    0.289210] RPC: Registered tcp transport module.
[    0.289219] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.289232] PCI: CLS 0 bytes, default 64
[    0.289680] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
[    0.291678] futex hash table entries: 512 (order: 3, 32768 bytes)
[    0.293755] jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
[    0.293942] msgmni has been set to 967
[    0.294720] io scheduler noop registered
[    0.294732] io scheduler deadline registered
[    0.294772] io scheduler cfq registered (default)
[    0.306849] dma-pl330 f8003000.ps7-dma: Loaded driver for PL330 DMAC-2364208
[    0.306869] dma-pl330 f8003000.ps7-dma: DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
[    0.430203] e0001000.serial: ttyPS0 at MMIO 0xe0001000 (irq = 82, base_baud = 3124999) is a xuartps
[    0.998093] console [ttyPS0] enabled
[    1.002364] xdevcfg f8007000.ps7-dev-cfg: ioremap 0xf8007000 to df866000
[    1.010001] [drm] Initialized drm 1.1.0 20060810
[    1.026995] brd: module loaded
[    1.036345] loop: module loaded
[    1.045778] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[    1.051928] e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
[    1.059874] libphy: XEMACPS mii bus: probed
[    1.064246] ------------- phy_id = 0x3625e62
[    1.068991] xemacps e000b000.ps7-ethernet: pdev->id -1, baseaddr 0xe000b000, irq 54
[    1.077618] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.084250] ehci-pci: EHCI PCI platform driver
[    1.091494] zynq-dr e0002000.ps7-usb: Unable to init USB phy, missing?
[    1.098356] usbcore: registered new interface driver usb-storage
[    1.105211] mousedev: PS/2 mouse device common for all mice
[    1.111344] i2c /dev entries driver
[    1.118306] zynq-edac f8006000.ps7-ddrc: ecc not enabled
[    1.123800] cpufreq_cpu0: failed to get cpu0 regulator: -19
[    1.129693] Xilinx Zynq CpuIdle Driver started
[    1.134525] sdhci: Secure Digital Host Controller Interface driver
[    1.140676] sdhci: Copyright(c) Pierre Ossman
[    1.144959] sdhci-pltfm: SDHCI platform and OF driver helper
[    1.150782] mmc0: no vqmmc regulator found
[    1.154797] mmc0: no vmmc regulator found
[    1.196441] mmc0: SDHCI controller on e0100000.ps7-sdio [e0100000.ps7-sdio] using ADMA
[    1.205142] usbcore: registered new interface driver usbhid
[    1.210661] usbhid: USB HID core driver
[    1.215384] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
[    1.221690] nand: Micron MT29F2G08ABAEAWP
[    1.225651] nand: 256MiB, SLC, page size: 2048, OOB size: 64
[    1.231588] Bad block table found at page 131008, version 0x01
[    1.237810] Bad block table found at page 130944, version 0x01
[    1.243860] 3 ofpart partitions found on MTD device pl353-nand
[    1.249643] Creating 3 MTD partitions on "pl353-nand":
[    1.254733] 0x000000000000-0x000002000000 : "BOOT.bin-env-dts-kernel"
[    1.262775] 0x000002000000-0x00000b000000 : "angstram-rootfs"
[    1.270133] 0x00000b000000-0x000010000000 : "upgrade-rootfs"
[    1.279106] TCP: cubic registered
[    1.282341] NET: Registered protocol family 17
[    1.287052] Registering SWP/SWPB emulation handler
[    1.292939] regulator-dummy: disabling
[    1.297297] UBI: attaching mtd1 to ubi0
[    1.821255] UBI: scanning is finished
[    1.832872] UBI: attached mtd1 (name "angstram-rootfs", size 144 MiB) to ubi0
[    1.839954] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[    1.846715] UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[    1.853379] UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
[    1.860257] UBI: good PEBs: 1152, bad PEBs: 0, corrupted PEBs: 0
[    1.866225] UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
[    1.873357] UBI: max/mean erase counter: 5/2, WL threshold: 4096, image sequence number: 1283732989
[    1.882387] UBI: available PEBs: 0, total reserved PEBs: 1152, PEBs reserved for bad PEB handling: 40
[    1.891604] UBI: background thread "ubi_bgt0d" started, PID 1080
[    1.891610] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[    1.895496] ALSA device list:
[    1.895499]   No soundcards found.
[    1.911972] UBIFS: background thread "ubifs_bgt0_0" started, PID 1082
[    1.940829] UBIFS: recovery needed
[    2.026486] UBIFS: recovery completed
[    2.030150] UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[    2.036078] UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[    2.045220] UBIFS: FS size: 128626688 bytes (122 MiB, 1013 LEBs), journal size 9023488 bytes (8 MiB, 72 LEBs)
[    2.055097] UBIFS: reserved for root: 0 bytes (0 KiB)
[    2.060137] UBIFS: media format: w4/r0 (latest is w4/r0), UUID C72F8006-6DFF-46BA-BBE9-380960A89F92, small LPT model
[    2.071410] VFS: Mounted root (ubifs filesystem) on device 0:11.
[    2.078585] devtmpfs: mounted
[    2.081694] Freeing unused kernel memory: 204K (c06d2000 - c0705000)
[    2.920878] random: dd urandom read with 0 bits of entropy available
[    3.306468]
[    3.306468] bcm54xx_config_init
[    3.916468]
[    3.916468] bcm54xx_config_init
[    6.917287] xemacps e000b000.ps7-ethernet: Set clk to 24999999 Hz
[    6.923380] xemacps e000b000.ps7-ethernet: link up (100/FULL)
[   21.172908] In axi fpga driver!
[   21.176017] request_mem_region OK!
[   21.179368] AXI fpga dev virtual address is 0xdf9fc000
[   21.184473] *base_vir_addr = 0x8c510
[   21.199782] In fpga mem driver!
[   21.202849] request_mem_region OK!
[   21.206441] fpga mem virtual address is 0xe2000000
[   22.005851]
[   22.005851] bcm54xx_config_init
[   22.635773]
[   22.635773] bcm54xx_config_init
[   25.636352] xemacps e000b000.ps7-ethernet: Set clk to 24999999 Hz
[   25.642373] xemacps e000b000.ps7-ethernet: link up (100/FULL)
This is XILINX board. Totalram:       507527168
Detect 512MB control board of XILINX
DETECT HW version=0008c510
miner ID : 8120d5487600881c
Miner Type = S9
AsicType = 1387
real AsicNum = 63
use critical mode to search freq...
get PLUG ON=0x000000e0
Find hashboard on Chain[5]
Find hashboard on Chain[6]
Find hashboard on Chain[7]
set_reset_allhashboard = 0x0000ffff
Check chain[5] PIC fw version=0x03
Check chain[6] PIC fw version=0x03
Check chain[7] PIC fw version=0x03
chain[5]: [63:255] [63:255] [63:255] [63:255] [63:255] [63:255] [63:255] [63:255]
has freq in PIC, will disable freq setting.
chain[5] has freq in PIC and will jump over...
Chain[5] has core num in PIC
Chain[5] ASIC[5] has core num=2
Chain[5] ASIC[8] has core num=5
Chain[5] ASIC[15] has core num=1
Chain[5] ASIC[23] has core num=1
Chain[5] ASIC[29] has core num=4
Check chain[5] PIC fw version=0x03
chain[6]: [63:255] [63:255] [63:255] [63:255] [63:255] [63:255] [63:255] [63:255]
has freq in PIC, will disable freq setting.
chain[6] has freq in PIC and will jump over...
Chain[6] has core num in PIC
Chain[6] ASIC[12] has core num=2
Chain[6] ASIC[15] has core num=2
Chain[6] ASIC[20] has core num=1
Check chain[6] PIC fw version=0x03
chain[7]: [63:255] [63:255] [63:255] [63:255] [63:255] [63:255] [63:255] [63:255]
has freq in PIC, will disable freq setting.
chain[7] has freq in PIC and will jump over...
Chain[7] has core num in PIC
Check chain[7] PIC fw version=0x03
get PIC voltage=6 on chain[5], value=940
get PIC voltage=91 on chain[6], value=890
get PIC voltage=57 on chain[7], value=910
set_reset_allhashboard = 0x00000000
chain[5] temp offset record: 62,0,0,0,0,0,35,28
chain[5] temp chip I2C addr=0x98
chain[5] has no middle temp, use special fix mode.
chain[6] temp offset record: 62,0,0,0,0,0,35,28
chain[6] temp chip I2C addr=0x98
chain[6] has no middle temp, use special fix mode.
chain[7] temp offset record: 62,0,0,0,0,0,35,28
chain[7] temp chip I2C addr=0x98
chain[7] has no middle temp, use special fix mode.
set_reset_allhashboard = 0x0000ffff
set_reset_allhashboard = 0x00000000



(Moderator's note: This post was edited by frodocooper to use code tags for the log output.)
legendary
Activity: 3164
Merit: 2258
I fix broken miners. And make holes in teeth :-)
December 15, 2017, 06:24:09 PM
#26
OK brain trust..  I see no burns or obvious shorts.
How do I upload a picture?  Also my 2 good boards hash on all 3 controller ports.
Imgur is good for uploading then post the URL of the image.

What I'm looking for is a close up of the FETs to see if there is any bulging or discoloration on them. I'm curious to see if the addition of a second FET on the low side (which has to switch at a higher frequency) has caused the typical capacitance ringing problem where the FETs can't switch quickly enough and burn out even though you would think 2 fets are better than one....

C
member
Activity: 277
Merit: 70
December 15, 2017, 06:03:23 PM
#25
OK brain trust..  I see no burns or obvious shorts.
How do I upload a picture?  Also my 2 good boards hash on all 3 controller ports.
legendary
Activity: 3164
Merit: 2258
I fix broken miners. And make holes in teeth :-)
December 15, 2017, 09:13:14 AM
#24
Darn! If it's a dead short please take pictures of the FETs on the board (the things next to the little transformer). I want to see what they look like when they cut-through, this is the first report I've heard of a dead short.

Note: If the S9 is out of warranty and shuts down the power supply I can fix this :-) But since yours is in-warranty (what is the warranty these days? 1y or 90d) you should contact Bitmain for a swap.

C
legendary
Activity: 1624
Merit: 1130
Bitcoin FTW!
December 15, 2017, 08:55:42 AM
#23
Yeah... Seemed like a short.  I'll look.  Is that a warranty thing? Also is warranty process even worth it?  Im in the US, I've heard of a place in Colorado, anyone have experience with them?

Fred
Yes, that is Bitmainwarranty that also sells parts and hosts miners (I have a couple S7s hosted with them hashing away with no downtime). They are a paid repair service IIRC (I also remember someone saying they are transitioning to becoming an official repair service for Bitmain) but there's been mostly positive reviews of them from what I can tell. Better than shipping a miner to China where they really don't do jack shit.

It's really up to you, I'd suggest just contacting them and getting a repair quote and seeing if it isn't too much money to get the blade back up and running.
member
Activity: 277
Merit: 70
December 15, 2017, 07:17:06 AM
#22
Yeah... Seemed like a short.  I'll look.  Is that a warranty thing? Also is warranty process even worth it?  Im in the US, I've heard of a place in Colorado, anyone have experience with them?

Fred
sr. member
Activity: 244
Merit: 280
December 15, 2017, 07:10:35 AM
#21
If that blade alone collapses an APW3 on 220V, it's a serious dead short.  Check for solder bridging on the leads of the PCI connectors.  If you don't see something obviously shorting the pins, you'll need to talk to bitmain.
member
Activity: 277
Merit: 70
December 15, 2017, 05:58:42 AM
#20
Thanks, but I have the apw3 hooked up now, so power draw shouldn't be a problem.  The apw3 also shuts down when connected to just that one blade.  I disconnected it and the other 2 have been hashing wonderfully for 12 hours....

Any other thoughts?
sr. member
Activity: 244
Merit: 280
December 14, 2017, 10:53:38 PM
#19
Not good or bad, the third blade just takes more power and probably collapses your supply and causes bmminer to crash and restart.

The other two blades are probably really close to the same limit, so don't be surprised if they flake out too from time to time.  Limp along until the APW arrives, but don't be suprised if that 750W power supply dies an early death running over it's rating.  Smiley
member
Activity: 277
Merit: 70
December 14, 2017, 07:12:18 PM
#18
I am using an APW3++ on 220V so power shouldnt be a problem

ok... here is what happens.  When the "bad blade" is hooked up alone, the miner and psu shut down after 30 seconds or so.  If I have the "bad blade" hooked up with one or two of the "good blades"  the miner restarts every 30 seconds, and never starts to hash.   I know this, beacuse the system tab shows uptime of 0 or it disconnects.  teh fans shut off completely, not slow down like the autotune cycle.

When I hook up one of the good blades I hash at around 4.5 TH/S
When I hook up two of the good blades I hash at around 9 TH/S

What gives?  I shook the miner gently to ensure no loose parts.  What is up with the "bad blade?"
newbie
Activity: 4
Merit: 0
December 14, 2017, 06:49:49 PM
#17
Here is how you test your boards.  Plug in one board only. Boot the machine, wait for it to start mining. If it is mining ok under "mining status" then that board is good. Repeat this process to verify each board. Where you see a bunch of "0" (zeros) those are the chips with a status. If you see "X" that means the chip has hardware errors. This can be due to a number of reasons and often a reboot fixes it. If you repeatedly boot up with "X" in the status then your board has a serious problem. If you boot up and the board doesn't mine at all then it could be a number of things but in any case you will have to get technical to fix it or replace it in any of these scenarios.

FYI it says on the sheet of paper that comes with an S9 that the boards can pull up to 533 Watts each.

That means if your power supply can only handle < 500 W you could have problems. Bitmain advertises inaccurate numbers for the power usage on the S9 on their site but tells you straight up on the paper that comes in the box. Under "normal" conditions where you have a 200-240 V power source you should be drawing close to 1600 W as opposed to < 1400 W as they claim.

These numbers are also dependent on environmental factors as colder temps will allow the fans to spin less which means less energy, sometimes 30 or more watts less (this is my average for an entire facility including building exhaust fans).
member
Activity: 277
Merit: 70
December 14, 2017, 06:39:28 PM
#16
update... when i hash with the 2 boards hooked up that didn't have the red light it works... do i have a bad board?
member
Activity: 277
Merit: 70
December 14, 2017, 06:18:01 PM
#15
also... a red light shows up on one of the hashboards near the pcie after the 2nd "restart"..that seems bad.  I'm starting to get nervous again...
member
Activity: 277
Merit: 70
December 14, 2017, 05:34:44 PM
#14
Ok, PSU hooked up to all blades.  Been running for almost an hour...  just keeps cycling the fan between air raid siren and silent.  What do I need to look for to see what's wrong?   Please help me...
legendary
Activity: 1624
Merit: 1130
Bitcoin FTW!
December 12, 2017, 08:11:39 PM
#13
Yes unfortunately. Early batches didn't have autotune but Bitmain just had to add it in, most people like the earlier ones as they had more customizability. Makes the miners more plug and play but I wish they'd just make it optional.
member
Activity: 277
Merit: 70
December 12, 2017, 07:58:14 PM
#12
Ah!  I'm used to scrypt miners like the L3+ and A4 which are up and running in 30 seconds or so.  The auto tune thing is new to me.  I did notice there were no advanced options to control the fan or the freq.  That makes me feel WAY better.  Thanks Fanatic26!

Is 30 - 40 minutes really the norm?  That seems nuts!

Phillip - Ha, I fuck up a lot it seems!  I let it cycle for 5 minutes or so each time.  I'm used to way faster response time.  I get that it was too fast now that I understand the autotune process...

PS - I actually just ordered another APW3 on ebay (SO OVERPRICED!) which should get here in 2 days or so, so I'll have an update then.  If the original one ever leaves Asia, I'll have an extra for sale!
legendary
Activity: 4326
Merit: 8899
'The right to privacy matters'
December 12, 2017, 07:52:23 PM
#11
Update... it didn't work.

I attached the 4 pcie connectors to the s9.  3 on a single blade, and the 4th on the connector.  I used the jumper block, so the PSU came on.  S9 powered on, had quiet fan, turbo fan, then quiet fan.  I was able to access the web interface, but miner status showed nothing was happening.  I powered off and powered on a few times, but still nothing.  I disconnected everything and will wait for the APW3 PSU.  If when the good PSU comes I need help again, I'll post.  Thanks to all of you who replied to me.


you fucked up just let it run for a good 20 to 30 minutes.

never turn it on and 0ff and on and off quickly.

turn it on and look in about 30 minutes
hero member
Activity: 756
Merit: 560
December 12, 2017, 07:47:45 PM
#10
It can take in excess of 30-40 minutes to start hashing in some cases. You can just turn an S9 on and expect it to be hashing inside of 5 minutes since they went with the autotune firmware. The ramping up and down is the autotune firmware testing various voltages on your hashing board to see how fast it can run.
member
Activity: 277
Merit: 70
December 12, 2017, 07:31:16 PM
#9
Update... it didn't work.

I attached the 4 pcie connectors to the s9.  3 on a single blade, and the 4th on the connector.  I used the jumper block, so the PSU came on.  S9 powered on, had quiet fan, turbo fan, then quiet fan.  I was able to access the web interface, but miner status showed nothing was happening.  I powered off and powered on a few times, but still nothing.  I disconnected everything and will wait for the APW3 PSU.  If when the good PSU comes I need help again, I'll post.  Thanks to all of you who replied to me.
legendary
Activity: 1624
Merit: 1130
Bitcoin FTW!
December 12, 2017, 05:57:09 PM
#8
You don’t have to but I usually remove the data cables for neatness on blades I’m not using. They’re sort of delicate so don’t just yank em off but it’ll be fine to just disconnect them. You probably won’t break the cables, the hardware will probably fail before them.
member
Activity: 277
Merit: 70
December 12, 2017, 05:55:39 PM
#7
Yeah, was hesitant.  I'll skip it.  Do I need to disconnect data cables or anything else?  I really don't want to ruin the s9, but my apw3 has been sitting in Singapore for a week...
hero member
Activity: 756
Merit: 560
December 12, 2017, 05:33:45 PM
#6
Each blade pulls 450w so I wouldnt try it if your PSU has no headroom.

Yes it will work fine with a single board as well.
member
Activity: 277
Merit: 70
December 12, 2017, 05:32:19 PM
#5
Great, thanks!  And yes, I'm waiting on a real PSU so thanks for answering the newbie as well I was about to say that...

Follow up question...Turns out one of my 750w is not truly 750w... It's 19a per rail (x2) on 12v.  That's only 38a at 12v so only 456w... Will that run a blade?  Seems tight.  Since it seems I can hash with just 2 blades, can I just run a single board with my good PSU?

Thanks again!
hero member
Activity: 756
Merit: 560
December 12, 2017, 05:26:58 PM
#4
If you are not going to use third blade, I will buy it off you.

He said he is just waiting on a large PSU to power them all. Plus removing a blade would void the warranty as well as mess up the cooling of the system.
bsp
jr. member
Activity: 40
Merit: 7
December 12, 2017, 05:25:06 PM
#3
If you are not going to use third blade, I will buy it off you.
hero member
Activity: 756
Merit: 560
December 12, 2017, 05:23:28 PM
#2
It will hash just fine with only 2 powered blades. You should see around 9 terahash total.
member
Activity: 277
Merit: 70
December 12, 2017, 05:12:46 PM
#1
Hi,
My apw3++ is trying to get here, but just doesn't seem to know the way...  In the meantime I have a brand new s9 paperweight until I can power it on.  I have 2 750w PSUs that will run 2 blades and the controller.  I know I can't mix blades, but can I just not connect the last blade?  Will it hash at 2/3 or not at all?  The nearest local retailer is almost 2 hours away so I'm kinda stuck.  Thoughts?  Advice?
Jump to: