-Redacted-
|
|
October 09, 2013, 08:36:03 PM |
|
No offence taken. The thing on the bottom is just a space heater This IS a Bitfury thread after all..... Been in the business long enough to know that a few of anything new are going to have problems. Once got back 100 boards from an assembly house and discovered - the hard way - that they'd installed all the tantulum caps with the wrong polarity. Luckily we tested the boards for long enough to catch the problem - it took 3 or 4 minutes before they blew, and it sounded like a string of big firecrackers going off when they did. Talk about magic smoke - it was so thick you could hardly see in the shop - and it sounded like a running gun battle was taking place - when the first batch of 20 boards on the test beds blew almost all the caps on all the boards, all within seconds of each other. There were bits of the epoxy coatings flying everywhere... Then there's always the trick of installing a voltage regulator backwards so that the top of the chip blows clean off when you apply power....
|
|
|
|
darkfriend77 (OP)
|
|
October 09, 2013, 08:38:58 PM |
|
- added... Mining Software Repositories: (use with caution, work in progress!)... - CGMiner by KNK Anyone willing to help testing a cgminer fork changes with a full kit or at least one board in each bus (A-D)? In sync with the latest Legkodymov's miner. For BFSB master boards you should leave BITFURY_MUX_OE undefined in bitfury-config.h and change: #define BITFURY_MAXCHIPS 100 #define BITFURY_MAXBANKS 1 #define BITFURY_BANKCHIPS 100
to #define BITFURY_MAXCHIPS 256 #define BITFURY_MAXBANKS 4 #define BITFURY_BANKCHIPS 16
By default the GPIO pins are defined (in tm_i2c.c) for BFSB boards, so no need to change anything there
|
|
|
|
KNK
|
|
October 09, 2013, 09:10:35 PM |
|
Mining Software Repositories: (use with caution, work in progress!)
Also note, that I don't have a BSFB board, so it may not work at all! I am aiming at having a single version to support all/most hardware mutations - for now it should support Metabank (MUX_OE) and NeedBMW (undefined MUX_OE and single bank) boards
|
|
|
|
zurg
|
|
October 10, 2013, 03:05:54 AM |
|
well, looks like my mining is dead with ext4-fs errors again will be down for another 7 hours until i can get to work and reload the sd card.. again. ugh!
|
|
|
|
KNK
|
|
October 10, 2013, 06:52:08 AM |
|
Mining should not need to access the SD card at all. I don't have the image, but is the swap disabled? There is no need of swap with revision 2 available memory. Another reason could be that chainminer is storing data to often in it's logs on the file system. Not sure which logs are important and how big they get, but turning some of them off or storing all on a small ramdisk, may solve the dead SD problems.
|
|
|
|
zurg
|
|
October 10, 2013, 10:30:38 AM |
|
Mining should not need to access the SD card at all. I don't have the image, but is the swap disabled? There is no need of swap with revision 2 available memory. Another reason could be that chainminer is storing data to often in it's logs on the file system. Not sure which logs are important and how big they get, but turning some of them off or storing all on a small ramdisk, may solve the dead SD problems.
If you can tell me what and how to check it I can. I am just a Linux n00b a bit. Came to work.., rebooted Pi, it came up with no errors. I do have a power switch that I can make Pi power cycle remotely by pinging it periodically. Help@!, lol.
|
|
|
|
jlsminingcorp
|
|
October 10, 2013, 10:57:32 AM |
|
Mining should not need to access the SD card at all. I don't have the image, but is the swap disabled? There is no need of swap with revision 2 available memory. Another reason could be that chainminer is storing data to often in it's logs on the file system. Not sure which logs are important and how big they get, but turning some of them off or storing all on a small ramdisk, may solve the dead SD problems.
If you can tell me what and how to check it I can. I am just a Linux n00b a bit. Came to work.., rebooted Pi, it came up with no errors. I do have a power switch that I can make Pi power cycle remotely by pinging it periodically. Help@!, lol. Anybody got any tips for network accessible power switches (EU available) for remotely power cycling the pi, as this sounds like it's worth while?
|
|
|
|
zurg
|
|
October 10, 2013, 11:02:09 AM |
|
Mining should not need to access the SD card at all. I don't have the image, but is the swap disabled? There is no need of swap with revision 2 available memory. Another reason could be that chainminer is storing data to often in it's logs on the file system. Not sure which logs are important and how big they get, but turning some of them off or storing all on a small ramdisk, may solve the dead SD problems.
If you can tell me what and how to check it I can. I am just a Linux n00b a bit. Came to work.., rebooted Pi, it came up with no errors. I do have a power switch that I can make Pi power cycle remotely by pinging it periodically. Help@!, lol. Anybody got any tips for network accessible power switches (EU available) for remotely power cycling the pi, as this sounds like it's worth while? We use http://www.digital-loggers.com/dli.products.htmlThey are a very nice and saved me more then once.. lol just not last night.. for some reason the port the Pi was on was not set to be accessed remotely. Fairly reasonable if you have multiple devices.
|
|
|
|
tom99
|
|
October 10, 2013, 02:21:40 PM |
|
well, looks like my mining is dead with ext4-fs errors again will be down for another 7 hours until i can get to work and reload the sd card.. again. ugh!
try to use sd boot up and usb flash drive for store FS. ps: I am going to get usb 8GB flash drive to do it. I got second time and waste few hrs too.
|
|
|
|
KNK
|
|
October 10, 2013, 03:07:17 PM |
|
Mining should not need to access the SD card at all. I don't have the image, but is the swap disabled? There is no need of swap with revision 2 available memory. Another reason could be that chainminer is storing data to often in it's logs on the file system. Not sure which logs are important and how big they get, but turning some of them off or storing all on a small ramdisk, may solve the dead SD problems.
If you can tell me what and how to check it I can. I am just a Linux n00b a bit. Came to work.., rebooted Pi, it came up with no errors. I do have a power switch that I can make Pi power cycle remotely by pinging it periodically. Help@!, lol. type free on the command prompt - if swap is used you will see it as the last line returned. 'dphys-swapfile swapoff' to turn it off and 'dphys-swapfile uninstall' to disable it EDIT: to disable the service on startup use: sudo update-rc.d -f dphys-swapfile remove
|
|
|
|
-Redacted-
|
|
October 10, 2013, 03:16:00 PM |
|
That's very good info. Thanks...
|
|
|
|
Isokivi
|
|
October 10, 2013, 04:51:42 PM |
|
Still some manual work to be done so that autotune can be turned indefinetly off, but Im fairly certain there is not much more to come out of these. [edit] Oh and thats a stable and constant hashrate. ...and before someone asks, each board is pencil modded individually with trial and error method. Rev. 1 boards as low as 1.15k and rev. 2 at as low as 1.6k.
|
Bitcoin trinkets now on my online store: btc trinkets.com <- Bitcoin Tiepins, cufflinks, lapel pins, keychains, card holders and challenge coins.
|
|
|
KNK
|
|
October 10, 2013, 05:30:54 PM |
|
Has anyone tested my fork? Does it work with all chips? The problem is i am not sure how are the banks connected and is '#define BITFURY_BANKCHIPS 16' OK or it should be '#define BITFURY_BANKCHIPS 64' I need to have a working version before i can add some additional options without braking backward compatibility. Hint: channels A-F instead of A-D on single RPi
|
|
|
|
jlsminingcorp
|
|
October 10, 2013, 05:54:41 PM |
|
Mining should not need to access the SD card at all. I don't have the image, but is the swap disabled? There is no need of swap with revision 2 available memory. Another reason could be that chainminer is storing data to often in it's logs on the file system. Not sure which logs are important and how big they get, but turning some of them off or storing all on a small ramdisk, may solve the dead SD problems.
If you can tell me what and how to check it I can. I am just a Linux n00b a bit. Came to work.., rebooted Pi, it came up with no errors. I do have a power switch that I can make Pi power cycle remotely by pinging it periodically. Help@!, lol. Anybody got any tips for network accessible power switches (EU available) for remotely power cycling the pi, as this sounds like it's worth while? We use http://www.digital-loggers.com/dli.products.htmlThey are a very nice and saved me more then once.. lol just not last night.. for some reason the port the Pi was on was not set to be accessed remotely. Fairly reasonable if you have multiple devices. Thanks, that's very helpful.
|
|
|
|
klondike_bar
Legendary
Offline
Activity: 2128
Merit: 1005
ASIC Wannabe
|
|
October 10, 2013, 06:00:08 PM |
|
Still some manual work to be done so that autotune can be turned indefinetly off, but Im fairly certain there is not much more to come out of these. [edit] Oh and thats a stable and constant hashrate. ...and before someone asks, each board is pencil modded individually with trial and error method. Rev. 1 boards as low as 1.15k and rev. 2 at as low as 1.6k. personally, i measure the voltage across the caps rather then pencil mod resistance, since that can change as the unit heats up and its hard to measure the resistor when running and plugged in.
|
|
|
|
darkfriend77 (OP)
|
|
October 10, 2013, 06:10:57 PM |
|
Can you make a photo where to measure ... the current ... ?
|
|
|
|
klondike_bar
Legendary
Offline
Activity: 2128
Merit: 1005
ASIC Wannabe
|
|
October 10, 2013, 08:20:50 PM |
|
Can you make a photo where to measure ... the current ... ?
beside each chip there is a bank of 8 small capacitors. most of these (seems like half of them in my situation) carry the voltage to the chip (0.73-0.85v = 1.5-2.7GH depending on tuning) and can be easily checked with a multimeter. I usually check at least 2 caps to verify that all chips receive similar voltage and ensure accuracy. I find that on startup from cold pcb i have around 0.805v, which climbs to 0.825v after the system is running and getting toasty over an hour or so. during this time, error rates decrease slightly and hashrate climbs to optimal speeds of about 40-41GH for the board ps: current (amperage) is different from voltage
|
|
|
|
jddebug
|
|
October 10, 2013, 08:43:19 PM |
|
Can you make a photo where to measure ... the current ... ?
beside each chip there is a bank of 8 small capacitors. most of these (seems like half of them in my situation) carry the voltage to the chip (0.73-0.85v = 1.5-2.7GH depending on tuning) and can be easily checked with a multimeter. I usually check at least 2 caps to verify that all chips receive similar voltage and ensure accuracy. I find that on startup from cold pcb i have around 0.805v, which climbs to 0.825v after the system is running and getting toasty over an hour or so. during this time, error rates decrease slightly and hashrate climbs to optimal speeds of about 40-41GH for the board ps: current (amperage) is different from voltage Does 40GH require you to use heat sinks or just fans blowing across the cards?
|
|
|
|
klondike_bar
Legendary
Offline
Activity: 2128
Merit: 1005
ASIC Wannabe
|
|
October 10, 2013, 10:38:32 PM |
|
Can you make a photo where to measure ... the current ... ?
beside each chip there is a bank of 8 small capacitors. most of these (seems like half of them in my situation) carry the voltage to the chip (0.73-0.85v = 1.5-2.7GH depending on tuning) and can be easily checked with a multimeter. I usually check at least 2 caps to verify that all chips receive similar voltage and ensure accuracy. I find that on startup from cold pcb i have around 0.805v, which climbs to 0.825v after the system is running and getting toasty over an hour or so. during this time, error rates decrease slightly and hashrate climbs to optimal speeds of about 40-41GH for the board ps: current (amperage) is different from voltage Does 40GH require you to use heat sinks or just fans blowing across the cards? i have heatsinks in use, and plan to upgrade them to slightly larger ones (35x35x6mm) soon. however, today i have had some issues in the past 3 hours when i lost hashrate at ghash.io and system reboot and start/stop miner ommands seem to only be temporary fixes where it returns to 40Gh, then slowly drops. error rates are within reason (slightly higher than normal), and chip 1 has 3 miso errors that dont seem to be replicating in any other chips. (typically it had 1 per 5min sample before) Its hard to troubleshoot without >20min of data, but i might have to check and/or back down the voltage slightly as im unsure whether the issue is the card or the pool (the initial problem seems to correlate with my blockerupters acting similarly, but they recovered and run fine now) edit: voltage is reading around 0.838V and this seems to be causing the chips to switch off or clock down towards default speeds (how would/does that work?) I think if it does not improve in the next hour i will take the system offline and try to tune down the pencil mod slightly. Ambient room temps are up 2-3 celcius in the last 24hrs now that heat in the building is on, and this may be the cause of lowered resistence=higher voltage
|
|
|
|
jddebug
|
|
October 10, 2013, 11:37:41 PM |
|
Can you make a photo where to measure ... the current ... ?
beside each chip there is a bank of 8 small capacitors. most of these (seems like half of them in my situation) carry the voltage to the chip (0.73-0.85v = 1.5-2.7GH depending on tuning) and can be easily checked with a multimeter. I usually check at least 2 caps to verify that all chips receive similar voltage and ensure accuracy. I find that on startup from cold pcb i have around 0.805v, which climbs to 0.825v after the system is running and getting toasty over an hour or so. during this time, error rates decrease slightly and hashrate climbs to optimal speeds of about 40-41GH for the board ps: current (amperage) is different from voltage Does 40GH require you to use heat sinks or just fans blowing across the cards? i have heatsinks in use, and plan to upgrade them to slightly larger ones (35x35x6mm) soon. however, today i have had some issues in the past 3 hours when i lost hashrate at ghash.io and system reboot and start/stop miner ommands seem to only be temporary fixes where it returns to 40Gh, then slowly drops. error rates are within reason (slightly higher than normal), and chip 1 has 3 miso errors that dont seem to be replicating in any other chips. (typically it had 1 per 5min sample before) Its hard to troubleshoot without >20min of data, but i might have to check and/or back down the voltage slightly as im unsure whether the issue is the card or the pool (the initial problem seems to correlate with my blockerupters acting similarly, but they recovered and run fine now) edit: voltage is reading around 0.838V and this seems to be causing the chips to switch off or clock down towards default speeds (how would/does that work?) I think if it does not improve in the next hour i will take the system offline and try to tune down the pencil mod slightly. Ambient room temps are up 2-3 celcius in the last 24hrs now that heat in the building is on, and this may be the cause of lowered resistence=higher voltage Many of my cards are at 20GH. It sounds like I could try to get them to 30 without adding heat sinks?
|
|
|
|
|