 Show Posts
|
|
Pages: « 1 [2] 3 4 »
|
Hi Everybody who has a BJ running
I have got my BJ(400GB) up and running for about 1 day, I am using Eligius as the pool. I can mine about 0.08BTC a day(Which I think it will take very long to get my investment back). Is this a good profit? What is your profit a day? Is there any other more profitable pool you recommend? Thank you very much!
I personally use Eligius. Mine is showing a 3-hour average hash rate of 408.35 Gh/s which is worth 0.07834091 BTC per day at the present difficulty, which amounts to about $56 and change per day at the present (declining) exchange rate on coinbase. -Phil |
|
|
|
|
Several things:
1. I see this a lot: "it keeps rebooting". If the RPI reboots, it will show a "rainbow" image on the monitor (if you have one connected), and if you check the status page on your web interface, you'll see the "System Uptime" value reflect this reboot. You should not be seeing the RPI reboot often, if at all. If you are, it indicates a problem possibly with your SD card, it's filesystem, or possibly the power supply for the RPI. For instance, plugging in some USB periperals are known to overload the RPI. We recommend to only keep the BJ plugged in when mining. Some people have installed WiFi adapters, and some of these can draw more power peak than the RPI can output, resulting in a reboot. Now, cgminer restarting is somewhat normal. We've set it up so that in the event of any problems it restarts cgminer. Until all the bugs get worked out, this is so you at least keep mining. You'll see this reflected in the "miner uptime" on the status screen. Mine usually lasts a day or 2. Sometimes when cgminer restarts it can take up to a minute to get going again. This seems to be due to a USB locking problem, which we are aware of and are trying to fix. If you unplug your USB cable from the RPI and plug it back in, this delay is usually reduced, but either way, it will start mining again if left to it's own devices. If you believe it really is your RPI rebooting, then maybe it's best to backup your settings and reload the SD card. It's also a good idea to go get a spare SD card so you have on on hand, and this way you can test a "virgin" image if problems develop. Please be clear when you post here in the future as to the difference between RPI system reboots and cgminer restarts. This will help me to help you if I better understand exactly what's happening on your system.
2. Errors and "work watchdog resets" are not an indication your system is broken. Most of these are due to bugs which are being worked on and will be fixed in upcoming software/firmware releases. Please be patient! As long as your average hashrate as reported by the pool is around 400Gh/s, you are ok. The point of the watchdog is to ensure, regardless of glitches, you keep mining. If your average pool reported hashrate is below 400Gh/s, then there may actually be a problem. Post it! Be clear about the symptoms, and post a log in verbose mode if possible. All the engineers here want to see them!
3. If your die temps vary from each other more than about 4 degrees C, there is likely something up with your cooler. Note that you must be running the custom hf version of cgminer to see all 4 die temps at once. The standard version only shows the max per board in the status. The temps seem to prefer being in the 70-80C range. Don't think cooler is better, because it usually isn't! (Though this varies somewhat from die to die) Get a tube of hi-quality (grey) thermal compound, remove your cooler head, re-apply the compound (read online how to do this, but a little goes a long way!) and re-install the cooler head. There should be washers under each screw, and the screws should be tightened until the stop. Do not force them beyond snug!
4. Unfortunately we cannot support you if you are running Windows or some other miner program. We only officially support you mining with the RPI, but if you are running our version of cgminer (right now it's 3.9.0h2) on a Linux box, I'll still try to help you. If you are running anything else, don't bother asking, as there are plenty of known issues that we are aware of that can cause problems. If you want to make the most BTC and not have your miner dead when you check it, you should be running what we recommend. If you are looking at this post and it's more than a week old, this information may be out of date. Read newer posts!
5. Tech Support. I plan to remain active here as much as I can. I'll help if I can. But we are also improving tech support. We have hired new people, developed new procedures, and engineering is monitoring TS and providing guidance. If you didn't get good help, try again! Please be patient and CIVIL. Everyone wants to help, make easier for them not harder.
6. Warranty; I am not authorized to give you any information on what voids it or how long it lasts, etc. But if you have a broken system, most likely we can get you going again. Don't panic, be patient!
-Phil
|
|
|
|
No, that is a 2.54mm pitch connector, whereas the chaining connector uses a 2mm pitch. I think we use a Samtec 2x8 IDC connector in the cables. It's the same pitch as the old 2.5" laptop IDE drive cables were. So if you had one of those laying around, you might be able to cut it down. (They were 44 pin IIRC) -Phil |
|
|
|
So, when daisy-chaining boards together, the 5 pin power connector needs to be attached to the LAST board in the chain?
If multiple boards are being supplied with enough power, how many could be PRACTICALLY chained together?
We have not tested the firmware with chains longer than 3 boards. This is the configuration present in the Sierra product. Practically, the limit is getting all the boards powered. If the Sierra, there are 2 PSU's, and the left side of each board is connected to one PSU, and the right sides are connected to the other. It's important that the grounding be the same on the left side to ensure reliability. This will be what ultimately limits how many you can practically chain. -Phil |
|
|
|
To overclock (may void your warranty!), add the following parameter to the cgminer command line: Where xxx is the speed in mhz you'd like to run. Valid values are 125 on up, and default is 550. If you are running a RPI with our image, you can add this line to the "Extra cgminer parameters" section in the settings page of the web interface. In a perfect world the hashrate is mhz X 768 (the total number of hashing units built into the ASIC). Each of the 4 die has 96 cores, and each core has two hashing units, for a total of 768. Note: It's normal to have a few defective cores per die, and it's also considered normal for some cores to produce occasional errors. This means the maximum possible hash rate is 422.4 Gh/s when running at 550mhz, but in the real-world it will typically be lower due to the reasons I just mentioned. Some boards will like certain clock rates and some will like others. If you do experiment with values, and I'm not recommending you do, try small increments and watch the error rates and/or if the ASIC stalls. When it attempts to draw too much power, the power supply can momentarily dip and cause it to stop sending work. This is when you'll see the watchdog timer get invoked. On an average board, the buck converters (take 12V down to core voltage) are usually the limiting factor for ASIC performance. They put out over 400 amps of low voltage power for the ASIC's cores to operate with. Right now in the present version of the firmware and cgminer, the regulators cannot be adjusted, but soon we will release firmware that supports adjustment of these regulators as well as independent clock speed adjustment per die. We are also presently performing lab qualification of the silicon, so I'll soon have some numbers for you guys as to what the silicon is capable of. The on chip programmable PLL is capable of pushing the clock rate to well over 1ghz. (You would need about 2X the power and cooling to hit this rate though!) -Phil |
|
|
|
Hi Phil, I would like to OC to 600MHZ, but does that void the warranty? Anyway since the warranty is only 10 days(which does not make sense for such an expensive device), do you see at what chance I will need it since it is running smoothly for about a day already? Or should I call the warranty under the reason device does not perform as described and let Hash Fast "FIX" it for me? If the official fix is to OC it, then I don't think that will void the on going warranty right(even it's not long)?  I'm not allowed to comment on what constitutes overclocking and/or what particular events will void the warranty. As far as I am aware, (my personal opinion alone, and not constituting legal advice or that of HashFast.) is that "Overclocking COULD void your warranty". I can tell you from personal experience that I have seen zero boards damaged by anything you might be able to do externally via software. If you don't physically mess with the board, I don't see how you can harm it. Sorry, I wish I could give you better answers, but the lawyers will probably then tell me I have to stay out of the forums. -Phil |
|
|
|
Hi Phil,
Yes, I compiled cgminer with --enable-hashfast on my xubuntu. It can detect HF device but can not enable the device, that's why I think it's permission issue.
You'll need to follow the instructions for enabling the udev rules if you want to run as a non-root user: Create a file called "01-hashfast.rules" in the /etc/udev/rules.d/ directory containing the following lines: ATTRS{idVendor}=="297c", ATTRS{idProduct}=="0001", MODE="0660", GROUP="plugdev"
ATTRS{idVendor}=="297c", ATTRS{idProduct}=="8001", MODE="0660", GROUP="plugdev"
You will have to be root or sudo'd to create the file. -Phil |
|
|
|
I am here working at the DataCenter working on the BJ's. I have 12, want to put 2/case.
Where do I plug the motherboard power for the 2nd BJ into on the Power supply?
There is one port labeled "MB" on the power supply. It is already taken by the first BJ.
Thanks
On the BJ, there should be 2 sets of PCI-E cables coming out of the PSU, and one 5-pin control cable. One of the sets of the PCI-E cables along with the 5-pin connector are already connected to the existing (top) board. The other set is zip-tied up by the PSU. You'll need a chaining cable (16 pin ribbon) and the screws/standoffs to add 2 boards to one BJ. Once you have that, simply mount the second board, connect the chaining cable from the top to the bottom board (using the 2 closest 16 pin connectors), MOVE the 5-pin cable to the second board, and then connect the spare set of PCI-E cables to the new lower board. -Phil |
|
|
|
Thank you ckolivas. I figured that it's the permission issue. And I followed the guide and added current user into plugdev group by issuing:
sudo usermod -G plugdev -a `whoami`
But it does not fix the problem. In this case does that mean I can only run cgminer under root user? Or you think it's not the issue of permission? Please kindly point out.
Also I logged into my RB Pi and can see cgminer is running under minepeon user and that user belongs only to minepeon group.
Anyway thank you for you help, I have made my RB Pi working now, so have no chance to test BJ on my linux box for now. Will report when I get a chance.
That wasn't all the instructions that were in the readme, you need the udev file installed. That other command is usually not needed in fact - but I don't know how permissions are set up on minepeon as the instructions revolve around regular PCs running regular PC distributions of linux and I'm no RPi distribution expert. It is always a permissions problem if it goes away as root. Thanks Con. The RPI is set up to run cgminer as the user "minepeon". By default it is correctly set for this, no changes to UDEV or permissions. Targetalk: If you are compiling your own version, you need to be sure you have enabled the HashFast driver support before compiling: ./configure --enable-hashfast You should not need to do anything else if you have correctly run the autogen script. Of course none of this is needed if you use the default version we supply. We will be sending out Con's latest as soon as everything is finalized and tested. -Phil |
|
|
|
Also Phil, I have two more questions:
1. I can see some errors in cgminer out put, how to fix them?
[image snipped]
As you can see the hardware error is keep going up, is this normal?
Also the first line of the scroll-able zone there is an error message:
HFA 0 attempted reset got err:(-5) LIBUSB_ERROR_NOT_FOUND
How to fix it?
2. Second, with default configuration, from cgminer's interface I can see the hash rate is always around 400GH/s. But from pool statistics average is only between 320 to 380. How to explain that? Can I say my BJ does not perform as described in specification?
Thanks you!
[image snipped]
In both these cases, we hope the new firmware will help correct these issues. It's absolutely normal to have some hardware errors. We have fixed the source of some of these in the upcoming firmware. Con Kolivas is also working with us to make many improvements in cgminer, so we will release both together as soon as we can. You should be able to get about 400Gh/s at the pool (average) though you might have to clock to 600mhz to get it at present. My test system at http://setup.hashfast.com/rpi/ is running at 600, it's got a bunch of errors, but as you can see from the pool stats on Eligius it's cruising along at about 428Gh/s for the 12 hour average: http://eligius.st/~wizkid057/newstats/userstats.php/17ao2fT7gbnnKYpMd7x29E8p4oGdE87AhdThe longer timeframe stats on Eligius tend to be more accurate and useful. The stuff under 3 hours is hit-or-miss. -Phil |
|
|
|
, I was getting great performance when my 3 BJ's arrived. At least on two of them, there was one that seemed a bit flakey and seems to be getting worse. All 3 seem to be getting worse. One of them keeps shutting down and restarting grabbing a new ID each time. I posted a small capture from my monitor so that maybe if others have had this and fixed it they can help. This one that is flaky was delivered in poor condition, all but one screw was sliding around the inside of the box and 4 risers that prop the board up were also floating around. I though the board was damaged and it may be. Worst assembly I have ever seen and I used to build PC's. That point is mute if they all work but they don't.
Here is what I need help answering.
1. How do I get back to my 400+ GH performance. All three of these were pushing +-420GH.
2. Worse case scenario is how do I raise the clock speed to get up to the 400GH range? I was promised by Erin at Hashfast that it would not void the warranty but the delivery paperwork stated otherwise. I will have to deal with that warranty issue separately, I know.
3. I seem to be getting huge error rates, I think it is on the flaky board but not 100% sure that is the only place. 70% to 80% errors are common. Elgius reports I am only getting 900 to 950 GH/s AVG with 3 boards and I should be getting closer to 1200. Not good for profits. Any help would be appreciated. I hate to try and send a board back under warranty since I might be stuck for months. I still am waiting on my 3 upgrades, I would hat to be down to 2 processors if I can avoid it.
Sorry about the loose parts. The problem wasn't bad assembly, it was the parts coming loose during shipping. They are using threadlock now to stop that problem. It's unlikely your boards are damaged if they are hashing on all 4 die, which sounds like they are. What are your die temps and voltages? (if you run the "hf" version of cgminer it reports all dies/voltages) Since your unit obviously had quite a ride during shipping, I'd look at each die temp and see if there is a discrepancy. You might need to take the cooler head off, re-grease the thermal interface, and re-tighten the cooler. Apparently some of those earlier orders that had loose standoffs have a high chance of having a loose cooler. Also, what hash clock speed are you using? Have you tired other speeds? -Phil |
|
|
|
Hi Phil,
Yes the defective SD card is the default RB Pi card with the log on it. I can not say it's the card's issue because it works fine on my computer, I think it just does not fit well with the slot in the Pi. But the fix is definitely use a thicker card.
I don't really understand the collection from the default wallet? Do you mean there is a default wallet created on the Raspberry Pi and there could be BTC already generated during the test? In my case cause I have never get original card boot successfully, and just created new card from downloaded image, does that mean I lost the original wallet already? And I also don't understand how to use that wallet and transfer the BTC out? Is there a wallet application on RB Pi? Or I just recover this wallet on another computer using the key pare? Thanks!
This is why I always ask people to make a backup. Yes, a new wallet is generated the first time each new image is booted on the RPI. It then begins mining with that wallet, it's yours to keep. We test all BJ's at the factory like that, and some machines end up mining overnight, so there's sometimes a good bit of coin in there! I absolutely hate "orphaning" any BTC regardless of amount, as it's forever lost. See if you can get that old card to boot, even if you have to take the case off the RPI and hold down the card. We've yet to see that particular problem. Maybe it's just a bent contact on your RPI's socket? A closer inspection may reveal why. If you can get it to boot, the wallet is visible on the "Wallet" page from the web interface, and if you make a backup from the settings page, it will contain the wallet. -Phil |
|
|
|
|
Anyone else getting forum errors? Can't seem to reply to existing threads. Seems like the SQL DB is corrupt or something.
-Phil
|
|
|
|
I don't know how to get a message to ckolivas, but I'm testing the current master branch of cgminer and one feature that was added is fan speed control (OP code 143). However, I keep getting the error that OP_CODE 143 is unhandled.
Is it possible that I have an older revision of the board/firmware something that doesn't support controlling the fan speed using that op code?
That's in the new firmware that's coming soon. Sorry, until we complete testing we cannot release it. I'll say it again; Until the new firmware comes out, you're best bet is to run 3.9.0hf2 that I've posted here. -Phil |
|
|
|
Any Windows binaries available? Sorry, we don't officially support windows as a platform. I don't run it either, so I can't even unofficially help you out. Maybe someone here you trust can compile it for you? I firmly believe the RPI is a better platform your average windows machine, and the monitoring and remote capabilities MinePeon brings is nice to have. I can pull up my miner on my phone and get text messages if it ever goes down. (has yet to happen unless I unplug it!) -Phil |
|
|
|
If you use our RPI image as configured, you will have a reliable mining system and will get updates as they are made available. Here's my personal system mining away: http://setup.hashfast.com/rpi/-Phil Just curious, what core clock are you running this at? I ran mine at default (550) for a day and it got about 400GH/s, 0.37% rejects, and 1.83% errors and showed 360GH/s on eligius. Overnight I started it at 560 and it shows 412GH/s, 0.36% rejects, and 9.26% errors with 388GH/s showing on eligius. Should I be worried about 9.26% error rate? They run at 80C/80C/70C/72C right now. It's running at 600. You can see that it's not totally stable at that speed, it gets the "work watchdog restart" often, but overall the hashrate is higher because it resumes hashing almost immediately if it stops. MinePeon's stats page looks silly, but that matters is the pool's reported hashrate which you can see here: http://eligius.st/~wizkid057/newstats/userstats.php/17ao2fT7gbnnKYpMd7x29E8p4oGdE87AhdOnly worry about the error rate if it starts to lower your overall rate. -Phil |
|
|
|
Hi Phil, It seems that it is the issue of the SD card you shipped. I replaced that card with my sandisk which is working now. I think the SD card you provided is too thin so that the pins do not contact properly in the slot in the RB Pi. My sandisk card is much thicker and after I plug it in, I can feel solid contact. Anyway, thank you for your help. I can see it's hashing at 415G/s but for your default BTC address, will switch to my address and see. Awesome, Glad to hear it! Is the original SD card we shipped actually a "no name" Micro SD inside an adapter with the Raspberry Pi logo on it? We got those specifically because they are "official" RPI cards, so they'd be the most likely to work well, but it's turning out that they stink. We'll test some different ones for the next batch. BTW, any time you build a new image, the first time it boots, it makes a new bitcoin wallet (viewable on the "wallet" page of the web UI), and begins mining with that wallet. Be sure if it made any BTC that you don't forget to collect it! If you make a backup from the settings page, the wallet is also backed up and restored. If you want to change to a new wallet or mining username, that's done on the "pools" page of the web UI. If you ever restore from a previous backup, it puts all your original settings in, so it's a good idea to make a backup once you get things dialed in like you want. (In case an SD card dies or something.) -Phil |
|
|
|
Thank you Phil. Actually I did what the instruction says. The issue is that the LED indicator of the port on my switch does not even show the internet connection is every enabled on RB Pi. So I think it has no chance to download any uploads. Are you sure the reload can fix the NIC issue? Anyway, I am trying, will update soon. Thanks again!
We've shipped tons of these things, and I have yet to see one with a bad NIC. There have been plenty of bad SD cards though. Note that a bad SD image will fail to initialize the NIC and there will be no ethernet lights or link. Follow the reload instructions and then be sure you can see a 94meg partition with the following files: total 24M
18K bootcode.bin
2.0K cmdline.txt
2.0K cmdline.txte
2.0K config.txt
2.0K config.txt~
20K COPYING.linux
4.0K fixup_cd.dat
6.0K fixup.dat
10K fixup_x.dat
9.4M kernel_emergency.img
8.3M kernel.img
2.0K LICENCE.broadcom
470K start_cd.elf
2.4M start.elf
3.4M start_x.elf If not, see if you can grab another SD card (2G min) and try the image there. Seems like some people have had difficulty installing the image, so be sure to uncompress the image first and then use the proper method to write the card. Tech support can send you one if you like, simply send an email with the subject "Replacement SD card request" as the subject. -Phil |
|
|
|
What is the status of your support ticket? I just checked the one I made yesterday where I asked if I could return or exchange my BJ underwarranty and I noticed it was marked as CLOSED with no response from HashFast at all.
I'm pretty angry about this. I don't understand how they could deny a warranty claim made just hours after I received the unit. Its still hashing now, btw, but averaging just around 220 GH/s :-/.
I made it a point to get in our the support queue now. Send an email (do not call, this is not working well), and I'll see what I can do to make sure you get taken care of. We also just hired new people specifically to deal with support, so please try again and be patient. Most of the support queue is clogged full of things such as questions about shipments, MPP, etc. Please title your request "BJ only doing 220 GH" and I see if I can dig it out. -Phil |
|
|
|
|
