Pages:
Author

Topic: [GUIDE] BitFury Miner Support/Tuning - page 31. (Read 148049 times)

member
Activity: 87
Merit: 10
September 27, 2013, 07:37:33 PM
Hello people,

I cleanly shutdown my Rasp Pi, and started it back up but then I noticed I wasn't able to connect to it any longer.... So I hooked up a monitor and it craps itself during boot with the following message:

PANIC: VFS: Enable to mount root fs on unknown-block(179,2)

Does this mean I have some sort of corruption with my SD card? Should I just go out and replace this one instead of trying to reflash this existing card?

I'm heading to the store now. Let me know what you think. Thanks for your help.

did you use the RPI's shutdown or sudo shutdown command? The last (and only) time i did that it started up mining just fine, but SSH was a no-go until i gave up and re-did the SD card.

try reimaging the card before going out to buy one

I did the "shutdown now" command while logged in through PuTTY via SSH.... I'm already downloading the V1 rPi image now... I went out and bought a 8GB SD Card and a USB keyboard for the heck of it. We'll see how this goes.... I noticed the basic USB keyboard isn't working for me though. Maybe not enough juice going to the rPi to power it...
legendary
Activity: 2128
Merit: 1005
ASIC Wannabe
September 27, 2013, 07:22:14 PM
Hello people,

I cleanly shutdown my Rasp Pi, and started it back up but then I noticed I wasn't able to connect to it any longer.... So I hooked up a monitor and it craps itself during boot with the following message:

PANIC: VFS: Enable to mount root fs on unknown-block(179,2)

Does this mean I have some sort of corruption with my SD card? Should I just go out and replace this one instead of trying to reflash this existing card?

I'm heading to the store now. Let me know what you think. Thanks for your help.

did you use the RPI's shutdown or sudo shutdown command? The last (and only) time i did that it started up mining just fine, but SSH was a no-go until i gave up and re-did the SD card.

try reimaging the card before going out to buy one
member
Activity: 87
Merit: 10
September 27, 2013, 06:38:48 PM
Hello people,

I cleanly shutdown my Rasp Pi, and started it back up but then I noticed I wasn't able to connect to it any longer.... So I hooked up a monitor and it craps itself during boot with the following message:

PANIC: VFS: Enable to mount root fs on unknown-block(179,2)

Does this mean I have some sort of corruption with my SD card? Should I just go out and replace this one instead of trying to reflash this existing card?

I'm heading to the store now. Let me know what you think. Thanks for your help.
legendary
Activity: 2128
Merit: 1005
ASIC Wannabe
September 27, 2013, 05:36:33 PM
Just took a look at the results from 12+ hours of logging yesterday after pulling chainminer v1.2. The board looks quite stable and error rates dropped significantly (~1% over the entire peroid). I'm looking at 36 GH/s sustained over long periods just dc fans and no heat sinks. I've manually clocked all chips at 54 and have not noted any benefit in using the auto feature in v1.2. Now someone push the board up to 40 Wink


how are you making that sort of log? Im moving to manual tuning now, since most chips are stable at 54/55 with 1% errors and 36Ghash/37Ghash-nonce.

if it runs well for the next few hours i will consider moving the resistance from 1.178 to 1.165 (before it gave me issues, but that was prior to chainminer update)

https://bitcointalksearch.org/topic/m.3108736

Send Isokivi a tip for saving you the headache.

ooh, not being a linux guy that still looks like a headache! (massive respect for the method/result though!). I can see 1.5hr averages at bitminter that work okay, but a longer-spanning solution would be nice. maybe the next sd update ill try to get the logger set up.

right now, im seeing a very steady 36.5 Ghash at the pool over the last 3 hours, with the bitfury page suggesting it might be closer to 37

EDIT: after about 16hrs, looks like 36.8Ghash is the average hashrate, with the last 3hrs above 37Ghash
EDIT 2: some new tweaking, and it looks like i am averaging 37.7Ghash

I have gotten 43-44GH/s frome one board.  Only 1 of my 5 h-boards did this for 24+ hours.  My assumption is the chips were from a good bin.  What I also notice is there is a HUGE variance in the performance of these chips.  My question is:  why?


most of mine appear to run between 2.2-2.6 GH/s right now, so i suppose it could be an issue where some chips are just a little more cleanly packaged and operating. for 43GH/s, how is the heat/stability, and what voltage/resistance are you getting? (pencil mod i presume?)
sr. member
Activity: 434
Merit: 265
September 27, 2013, 03:21:36 PM
Added:

Newest Image from punin

...
Raspberry Pi SD Image
...
- 2013-Sep-27_BFSB_GM2.img (Magnet-Link)
  + some changes in the web stuff /www/*.* (Link)
...
hero member
Activity: 924
Merit: 1000
September 27, 2013, 03:19:03 PM
Just took a look at the results from 12+ hours of logging yesterday after pulling chainminer v1.2. The board looks quite stable and error rates dropped significantly (~1% over the entire peroid). I'm looking at 36 GH/s sustained over long periods just dc fans and no heat sinks. I've manually clocked all chips at 54 and have not noted any benefit in using the auto feature in v1.2. Now someone push the board up to 40 Wink


how are you making that sort of log? Im moving to manual tuning now, since most chips are stable at 54/55 with 1% errors and 36Ghash/37Ghash-nonce.

if it runs well for the next few hours i will consider moving the resistance from 1.178 to 1.165 (before it gave me issues, but that was prior to chainminer update)

https://bitcointalksearch.org/topic/m.3108736

Send Isokivi a tip for saving you the headache.

ooh, not being a linux guy that still looks like a headache! (massive respect for the method/result though!). I can see 1.5hr averages at bitminter that work okay, but a longer-spanning solution would be nice. maybe the next sd update ill try to get the logger set up.

right now, im seeing a very steady 36.5 Ghash at the pool over the last 3 hours, with the bitfury page suggesting it might be closer to 37

EDIT: after about 16hrs, looks like 36.8Ghash is the average hashrate, with the last 3hrs above 37Ghash
EDIT 2: some new tweaking, and it looks like i am averaging 37.7Ghash

I have gotten 43-44GH/s frome one board.  Only 1 of my 5 h-boards did this for 24+ hours.  My assumption is the chips were from a good bin.  What I also notice is there is a HUGE variance in the performance of these chips.  My question is:  why?
legendary
Activity: 2128
Merit: 1005
ASIC Wannabe
September 25, 2013, 07:55:20 PM
Just took a look at the results from 12+ hours of logging yesterday after pulling chainminer v1.2. The board looks quite stable and error rates dropped significantly (~1% over the entire peroid). I'm looking at 36 GH/s sustained over long periods just dc fans and no heat sinks. I've manually clocked all chips at 54 and have not noted any benefit in using the auto feature in v1.2. Now someone push the board up to 40 Wink


how are you making that sort of log? Im moving to manual tuning now, since most chips are stable at 54/55 with 1% errors and 36Ghash/37Ghash-nonce.

if it runs well for the next few hours i will consider moving the resistance from 1.178 to 1.165 (before it gave me issues, but that was prior to chainminer update)

https://bitcointalksearch.org/topic/m.3108736

Send Isokivi a tip for saving you the headache.

ooh, not being a linux guy that still looks like a headache! (massive respect for the method/result though!). I can see 1.5hr averages at bitminter that work okay, but a longer-spanning solution would be nice. maybe the next sd update ill try to get the logger set up.

right now, im seeing a very steady 36.5 Ghash at the pool over the last 3 hours, with the bitfury page suggesting it might be closer to 37

EDIT: after about 16hrs, looks like 36.8Ghash is the average hashrate, with the last 3hrs above 37Ghash
EDIT 2: some new tweaking, and it looks like i am averaging 37.7Ghash
hero member
Activity: 924
Merit: 1000
September 25, 2013, 05:22:38 PM
If all of this good news holds true across the board I would expect to get close to 600GH/s out of my rig if I ever receive a v2 board.



I have 2 extra version 2.3 M boards right now.  I might be willing to trade.
newbie
Activity: 18
Merit: 0
September 25, 2013, 04:14:31 PM
If all of this good news holds true across the board I would expect to get close to 600GH/s out of my rig if I ever receive a v2 board.

newbie
Activity: 51
Merit: 0
September 25, 2013, 02:19:19 PM
Wow, the new version of chainminer is magic. With stock version one of my chips was always with zero nonce rate, no mater what speed I set, so I disabled it. With the new version all my chips are OK and autotune is working fine.
newbie
Activity: 55
Merit: 0
September 25, 2013, 02:09:34 PM
Just took a look at the results from 12+ hours of logging yesterday after pulling chainminer v1.2. The board looks quite stable and error rates dropped significantly (~1% over the entire peroid). I'm looking at 36 GH/s sustained over long periods just dc fans and no heat sinks. I've manually clocked all chips at 54 and have not noted any benefit in using the auto feature in v1.2. Now someone push the board up to 40 Wink


how are you making that sort of log? Im moving to manual tuning now, since most chips are stable at 54/55 with 1% errors and 36Ghash/37Ghash-nonce.

if it runs well for the next few hours i will consider moving the resistance from 1.178 to 1.165 (before it gave me issues, but that was prior to chainminer update)

https://bitcointalksearch.org/topic/m.3108736

Send Isokivi a tip for saving you the headache.
legendary
Activity: 2128
Merit: 1005
ASIC Wannabe
September 25, 2013, 02:05:43 PM
Just took a look at the results from 12+ hours of logging yesterday after pulling chainminer v1.2. The board looks quite stable and error rates dropped significantly (~1% over the entire peroid). I'm looking at 36 GH/s sustained over long periods just dc fans and no heat sinks. I've manually clocked all chips at 54 and have not noted any benefit in using the auto feature in v1.2. Now someone push the board up to 40 Wink


how are you making that sort of log? Im moving to manual tuning now, since most chips are stable at 54/55 with 1% errors and 36Ghash/37Ghash-nonce.

if it runs well for the next few hours i will consider moving the resistance from 1.178 to 1.165 (before it gave me issues, but that was prior to chainminer update)
sr. member
Activity: 434
Merit: 265
September 25, 2013, 01:51:09 PM
I had mine pushed to 37-38 with one dead chip ... heatsinks & fan ... but it was unstable so .. i went back to 32 ... :-) ...
newbie
Activity: 55
Merit: 0
September 25, 2013, 01:47:21 PM
Just took a look at the results from 12+ hours of logging yesterday after pulling chainminer v1.2. The board looks quite stable and error rates dropped significantly (~1% over the entire peroid). I'm looking at 36 GH/s sustained over long periods just dc fans and no heat sinks. I've manually clocked all chips at 54 and have not noted any benefit in using the auto feature in v1.2. Now someone push the board up to 40 Wink

legendary
Activity: 2128
Merit: 1005
ASIC Wannabe
September 25, 2013, 01:08:38 PM
just ran the above chainminer gitpull, up and hashing again now, at auto 54 and decent rates (still climbing)

Previously, i had about 34ghash average poolside using 2 workers at difficulty 16, autotuning, and pencil mod of 1.178k. The actual hardware hashrate was closer to 37.5 but 2-15% error rates on the chips. aftermarket cooling includes a fan on each face of the board, as well as multiple heatsinks (tiny one on each chip, and then 5 small heatsinks on the backside, 1 opposite each capacitor cluster)

EDIT #1 (5min): 1 worker, diff=16 (bitminter), autotuning is 54 across the board, hashrate: 35.86Ghash, noncerate: 35.03Ghash.  This is looking really good with the chainminer update!
EDIT #2 (15min): hashrate: 36.5Gh, Noncerate: 35.0Gh,   autotuning is moving most chips up to 55 now
EDIT #3 (30min): hashrate: 37.4Gh, Noncerate: 36.3Gh,   autotuning is about 50/50 between 54 and 55 on all chips. Several chips running at 54 have no errors, and a chip at 55 is 7% errors (hopefully fixed by next autotune)
hero member
Activity: 924
Merit: 1000
September 25, 2013, 12:19:15 PM
I think step #9 on the front page should be revised as it is not rookie friendly.  Following those steps will result in errors on a Verision 2.X  September 16th kit as it will not reach a git repository without the steps I laid out.
hero member
Activity: 493
Merit: 500
Hooray for non-equilibrium thermodynamics!
September 25, 2013, 11:47:23 AM
Is everybody compiling stuff on the pi, or has anybody had any success cross-compiling from a more powerful machine?

Why would anyone want to bother to build a cross-compilation environment?   That would require a great deal of effort to duplicate something that is already trivial to perform on the RPI...

To make repeated testing of new versions faster. Or to make the compile time on git-bisect bearable for finding bugs. I already have a cross-compiling environment for ARM, to compile cgminer for my other raspberry. Only reason I haven't added chainminer to it is because there's so far been only one update.

Exactly, and some things are so slow to compile on a pi that it's just unbearable.

-Redacted-, I haven't tried compiling chainminer on a pi yet, so I'm afraid that I'm rather ignorant of the reality. However, I got the sense from darkfriend77's post that it takes a while, which is when I think it starts to become worth thinking about putting the effort in to cross compile.
full member
Activity: 148
Merit: 100
September 25, 2013, 11:39:22 AM
plz make "how to" step4step frob back up to chainminer upgrade manual for noobs like me)

ChainMiner for M Board Version 2.X boards
DO not use this guide for Version 1x m-boards.
It will fry your chips.  This is only meant for Version 2 of the M-board.

I apologize for grammar as I took 2 sleeping pills and I can barely feel my fingers.

1.login as pi or root

2.  type "nano /run/shm/.stat.log"   if you wish to see the performance of all the chips on your board before upgrading chain miner.
(optional step)
3.(backup your chainminer version)  (this creates a copy of the folder)
a. sudo cp -a /opt/bitfury /usr/bitfury.backup
b. cd /opt/bitfury/
c. pwd  (make sure you are in /opt/bitfury)
d. ls -al (or type dir)
e. rm -rf chainminer  (this removes everything in the chainminer folder)
4.  make sure you are in the /opt/bitfury directory and not in /opt/bitfury/chainminer (it should be deleted anyway
5.  type "git clone https://github.com/bfsb/chainminer.git"
6.  it should now start getting the chainminer git.
7.  now type "cd chainminer"  you should now be in the chainminer directory
8.  type "make"
9.  Its going to take 5-10 minutes to create the chainminer...maybe longer.
 I got some warning but everything was fine after it all finished.
 it will go back to a  bash prompt when done.
9a.  Just wait...this is the longest part of doing this change..
10.  sudo reboot


very nice! thank you very much! )

Thank you!  Went from 17 to 25 gh/s noncerate on a stock starter kit.  MISO errors from 40s to 0. 
sr. member
Activity: 658
Merit: 250
September 25, 2013, 10:57:35 AM
Is everybody compiling stuff on the pi, or has anybody had any success cross-compiling from a more powerful machine?

Why would anyone want to bother to build a cross-compilation environment?   That would require a great deal of effort to duplicate something that is already trivial to perform on the RPI...

To make repeated testing of new versions faster. Or to make the compile time on git-bisect bearable for finding bugs. I already have a cross-compiling environment for ARM, to compile cgminer for my other raspberry. Only reason I haven't added chainminer to it is because there's so far been only one update.
hero member
Activity: 574
Merit: 501
September 25, 2013, 09:21:33 AM
Is everybody compiling stuff on the pi, or has anybody had any success cross-compiling from a more powerful machine?

Why would anyone want to bother to build a cross-compilation environment?   That would require a great deal of effort to duplicate something that is already trivial to perform on the RPI...
Pages:
Jump to: