 Show Posts
|
|
Pages: « 1 2 [3] 4 »
|
Question 1: Will you be pushing firmware updates without any manual component, meaning if I follow these instructions the firmware for my device will be updated without any warning and I will not even be notified?
Question 2: Will the updating of firmware occur for all devices that I have hooked up to a single Rpi? Meaning if I have 10 babyjets all plugged into one USB hub which hub is plugged into my RPi will the firmware for all 10 devices be updated?
Answer 1: Yes, we will push the firmware and software updates whenever they are ready. If you do not want to accept them, you can uncheck the "Enable HashFast updates" box on the settings page of your RPI's web interface and then at your choosing perform a manual update. Answer 2: We don't advise running that many units on only one RPI, it's likely a bit too much load for the little guy! We are going to test the update mechanism to be sure it will update everything reliably and won't break anything, though I don't think we'll test any more than 3 systems on one RPI. Worst-case is you might have to unplug some units and restart the RPI a few times with only a few units connected. Our goal is to get you the most uptime possible, so we're going to tune the update process to be a smooth as possible and require no hassles if we can help it. -Phil |
|
|
|
@HF Engineer,
So you can/will be pushing out software improvements to the physical chips/modules and so we should have a rpi handy to update it?
That's what I advise for the time being. We will be releasing an update utility as soon as possible for those not running on a RPI, but RPI users will be first to get the updates until that occurs. -Phil |
|
|
|
if im not running into any issues, should i still upgrade? i got shipped with the early version of minepeon (non hashfast version) and i updated to cgminer 3.10.
im hesitant to upgrade because of downtime and i dont want to start causing issue? are there any benefits for me in the newer version?
You will not be able to receive any updates using the default version of MinePeon, and also you'll soon find it's relatively unreliable. If it dies for any reason, it often fails to restart. Our version keeps trying if something stops, and it has a RPI's hardware watchdog enabled. -Phil |
|
|
|
Guys! If you compile cgminer yourself, please be sure you enable the HashFast driver! NO DRIVERS ARE ENABLED BY DEFAULT! Here's how: ./configure --enable-hashfast You should see this afterwards before you compile: ------------------------------------------------------------------------
cgminer 3.9.0h2
------------------------------------------------------------------------
Configuration Options Summary:
libcurl(GBT+getwork).: Enabled: -lcurl
curses.TUI...........: FOUND: -lncurses
Avalon.ASICs.........: Disabled
BlackArrowMinion.ASIC: Disabled
BlackArrow.ASICs.....: Disabled
BFL.ASICs............: Disabled
BitForce.FPGAs.......: Disabled
BitFury.ASICs........: Disabled
Drillbit.BitFury.....: Disabled
Hashfast.ASICs.......: Enabled
Icarus.ASICs/FPGAs...: Disabled
Klondike.ASICs.......: Disabled
KnC.ASICs............: Disabled
ModMiner.FPGAs.......: Disabled
Compilation............: make (or gmake)
CPPFLAGS.............:
CFLAGS...............: -g -O2
LDFLAGS..............: -lpthread
LDADD................: -ldl -lcurl compat/jansson-2.5/src/.libs/libjansson.a -lpthread -lm compat/libusb-1.0/libusb/.libs/libusb-1.0.a -ludev -lrt
Installation...........: make install (as root if needed, with 'su' or 'sudo')
prefix...............: /usr/local If not, you are missing something, and it likely won't work. Again, we recommend 3.9.0h2 for best performance for now until new firmware is released. (soon!) Here's the source code: http://setup.hashfast.com/cgminer-3.9.0h2.tar.gz (MD5: fdef15ae73b180deef74bc51df482eb0) 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 |
|
|
|
Yeah, I just got my BJ yesterday, I had the same issue. The brand new shipped BJ just does not start up. I have confirmed Raspberry Pi is defective, cause the HDMI has no output to the monitor at all. Do you know how to diagnose the Baby Jet itself? After I plugged in power cord and turned on power switch on the power supply, nothing happened. I can see there is power switch and two LED lights on each side, but they are just dark, do you those two LED light are supposed to be on after the power supply is turned on? Thank you!
Please reload your SD card, that is all that's wrong with your Raspberry Pi. Note that the monitor will not show anything for about 3-4 minutes when first plugged in, as it must get the current software and install it first. Then, it will reboot and you should get a display on any HDMI monitor or TV. Note that you do not need a monitor. The terminal screen is available from the web interface. Here's the SD reload instructions: http://hashfast.com/how-to-update-babyjets-raspberry-pi-sd-card-software/Please go here for setup instructions and to access your Miner's web interface after it updates (3-4 minutes): http://setup.hashfast.com/Sorry for the trouble, but you should be able to get up and running within about 20 minutes total if you follow these instructions. -Phil |
|
|
|
Hi,
Thanks for your awesome work.
Could you please let me know which is the initial script if I want to add something in it?
In MinePeon, the shell script that calls cgminer is: /opt/minepeon/etc/init.d/miner-start.sh However, there is usually no need to alter any scripts (and we advise against it) as you can add parameters to the cgminer command line from the settings page in the web interface. Also, If you do alter any scripts, it's possible that changes may be overwritten in an update. -Phil |
|
|
|
Hi Phil,
Since the last update a few days ago, my miner has been rock solid, and with lower temps. I'm running a very consistent 423GH/s reported in the console (though less at Eligius; 12hr is ~396GH/s), with cores at 66-69. Screen says cgminer v3.9.0h2. This is running stock, off the RPi.
And thanks again for all the tech help. We really appreciate it. I think everyone here is super-pissed at Hashfast management in general (specifically John and Eduardo), but I like to think that most of us can target our anger to where it's deserved, and therefore keep it *out* of *this* thread. So I just wanted to say thanks for putting energy into this thread. It's been super helpful, and you've really been the sole bright-spot in the entire organization from what I've seen thusfar.
And a question about overclocking (understood that it voids warranty (which is surprisingly short and up soon anyways)): Are there other concerns besides temp to watch out for, as far as potential damage goes? Can I suck too much power through the board/chip without getting indication thereof via temperature? Anything else to look out for?
Thanks again!
Thanks Melbustus. I can't specifically speak for management, but I can say that overall things are getting much better around here, and we are making even more progress on the engineering side that's going to make our systems much better soon! The modules protect themselves, so it's unlikely you can do something via software that could damage them. The on-board power supplies are likely the first limiting factor, as they will go into current limit and will drop the voltage if you attempt to draw too much current. If the die temperature gets too high there is both a software and hardware current limit that should prevent you from overheating the silicon to the point of damage. We will soon have a method to explore overclocking, and it will work on a per-die level. It's being tested now. I'll keep you posted and let everyone know as soon as there is anything interesting ready. -Phil |
|
|
|
you are the engineer.. why don't you build and release these scripts for your customers?
I already have. If you use the RPI that was shipped with your BJ, it works. I posted my test system for all to see on the last page, it works reliably 24/7. If you want to run a custom system, then there's no way you can expect me to write custom scripts for you. Would you really want me to take time off from working on the new firmware for something like this? -Phil |
|
|
|
Phil,
I'm a Sierra customer. Having problems with cgminer 3.12 crashing after a 12+ hour run on Ubuntu. Can't get multiple sierras to work well on the same host. Is I stop cgminer or it crashes I can't get them all to reattach by themselves and the whole power off and wait a coupe minutes thing is not easy in a data center or remote location.
I see a lot of this when its trying to reacquire the units.
[2014-02-04 09:11:39] HFA 0: OP_USB_INIT failed! Operation status 9 (Secondary board communi
cation error)
[2014-02-04 09:11:39] HFA 0 HFClearRead usb read err:(-1) LIBUSB_ERROR_IO
[2014-02-04 09:11:39] HFA 0 attempted reset got err:(-5) LIBUSB_ERROR_NOT_FOUND
[2014-02-04 09:11:39] FAIL: USB get_lock not found (2:42)
[2014-02-04 09:11:39] FAIL: USB remove not already in use (2:42)
Any help? New firmware needed maybe?
We have new firmware coming soon. But what I recommend is to set up a bash script to automatically restart cgminer if it crashes, and possibly something to monitor hashrate and kill cgminer if it falls off. When restarting "warm", it will appear to fail, but if you keep restarting cgminer, usually within a few tries it will eventually "take". This is basically how I've got the RPI set up to work, and it yields a reliable system. Sort of a "duct tape and bailing wire" solution for now, but it'll keep you mining, and hopefully the coming improvements to both our firmware and Con's cgminer will reduce the need for these tricks. -Phil |
|
|
|
[2014-02-04 09:45:09] HFA 0 NOTICE: ######################### WARNING: Work Watchdog Reboot Imminent!
[2014-02-04 09:45:11] HFA 0 HFGetHeader usb read err:(-99) LIBUSB_ERROR_OTHER
[2014-02-04 09:45:11] HFA 0 attempted reset got err:(-5) LIBUSB_ERROR_NOT_FOUND
[2014-02-04 09:45:11] HFA 0: device disappeared, disabling
[2014-02-04 09:45:11] HFA 0 failure, disabling!
[2014-02-04 09:45:11] HFA 0: hfa_send_frame: USB Send error, ret -4 amount 0 vs. tx_length 8
[2014-02-04 09:45:17] Hotplug: Hashfast added HFA 1 More then 30 times a day! This is not a problem, the watchdog is designed to reset a board that ends up in a strange state for any reason. This could be a USB comms glitch, a firmware bug, cgminer, etc. A few times an hour will not much effect on your overall hashrate. Be glad it's there, otherwise your system would probably have stopped working by now. Once some the bugs get worked out we should see that happen less and less. I know it's not ideal, but this way you get to have a system that mines instead of one that doesn't, or worse, one that we didn't ship until we decided we had a 100% glitch-free setup. (And if you've been in the mining game for any length of time, you know that is never gonna happen!) -Phil |
|
|
|
Guys, you've gotta understand that these errors, including the ones that cause firmware issues (triggering the work watchdog resets) are always going to happen, but statistically they happen more when you push a chip harder, on average. You need a longish sample period before you decide that one configuration or the other has better performance. Personally, I would allow at least an hour to pass, watching the hashrate reported at the pool (on Eligius only watch the 22.5 minute stats or higher, 128 and 256 seconds never seem stable enough). Write the average hashrate down, then make a change, noting what you did, and watch it for another hour. An even better way to do this is to write a shell script or a program to run different versions of cgminer, different hash clocks, etc, then you can come back a day later and look at the graphs. Taking a short sample period to assess your current configuration results in too much "noise" in your stats to be of any value. Back in this post I describe how to change the cgminer version on your RPI's if you want, though I recommend 3.9.0h2, which is what I personally am running, and it works best: https://bitcointalk.org/index.php?topic=426644.msg4919972#msg4919972If you are running on Windows or Linux and want to try 3.9.0h2, here's the source code: http://setup.hashfast.com/cgminer-3.9.0h2.tar.gz (MD5: fdef15ae73b180deef74bc51df482eb0) See README for build instructions, basically you'll need to run autogen.sh My test RPI's are running stable on eligius with 3.9.0h2. I've got one setup here that generates a typical amount of errors with this firmware, but has a good average hashrate. Here's the terminal if you'd like to take a look: http://setup.hashfast.com/rpi/And the pool results: http://eligius.st/~wizkid057/newstats/userstats.php/17ao2fT7gbnnKYpMd7x29E8p4oGdE87AhdAgain, I do not make policy at HashFast, and I cannot help outside of technical or engineering areas. I cannot tell you when MPP or anything of that nature is happening, I have no idea. If you aren't civil with me, I will ignore you. I'd like to help, so allow me. -Phil |
|
|
|
HashFast posts Raspberry Pi updated firmware on their blog. I took a new SD card, followed their directions and pointed it back to my mining wallet. After 1 hour, I cannot see any difference. It would be better to be notified of new updates, and to have the choice of whether to take it or not, depending on what was changed. This is what I do with Windows. If it ain't broke, don't fix it!
I wanted them to do this based on the number of reports of the wrong versions, corrupted filesystems, etc. This version has the firmware update capabilities built-in, and we are now testing new board firmware for release. We need to make sure it's absolutely solid and that the automatic update procedure we'll push to your RPI's are not going to break anything. If you are already running ok with our version of MinePeon (currently showing version 0.2.4.3hf8 or later), you DO NOT NEED TO DO ANYTHING! If you are running anything else, you will not get the updates! If you are running on something other than the RPI, I'll let you know when the updates are rolling out, and you can temporarily plug in your RPI so your units can get the updates. There is a list of a ton of bugs that will be fixed in the upcoming firmware, so it'll be worth it! Please be patient, we really want this to be solid and go off without any hitches. Con Kolivas is also working with us on the beta firmware to enhance cgminer, and hopefully we'll be able to push that out at the same time. I'll keep you posted! -Phil |
|
|
|
DEAD DEAD DEAD - this is what I see when I wake up this morning for the second day in a row, getting only about 12-18 hour uptime before my devices all go DEAD and cgminer does not restart itself, I have to manually restart.
I am having an issue with cgminer 3.12 on windows
Using 9 babyjets plugged into a 10 port usb hub, all are detected eventually, but it usually goes up into HFB 40 to HFB 50 so it takes about 4-5 disable/re-enable cycles per device on startup.
If I reboot cgminer, after the all DEAD status, then it works for just a few minutes before I start to see the miners drop again.
IDLE for more than 60 seconds - declaring SICK!
Attempting to restart
So hotplugging everything will give me another 12-18 hours (turn off and on USB hub), but this is crazy that I have to hard reboot so often.
I have the exact same issue with cgminer on windows. I had to switch back to the RPI to get reasonable uptime. Windows cgminer gives a bit faster hashrate, but not worth it if it's down for hours a day. There is a known problem with the USB stack on windows. This is a cgminer known issue, which is why we recommend a linux-based mining solution and provide the RPI with every BJ. The best you could do is make some sort of a script that restarts cgminer, or better yet windows itself, after mining stops or even just after 8 hours or so. Hopefully once we get cgminer and the firnmware stable, we can look at possible windows solutions. Windows in general is not a stable platform, which is why most servers on the internet don't use it. -Phil |
|
|
|
Au Contraire.
I downloaded your minepeon raspi image as soon as I learnt of it:
MinePeon Version
0.2.4.3hf8
Miner Version
cgminer3.9.0h
This has without a doubt, the "1969" date/time upon bootup problem and the daemon in part "ntpd -g" is not correcting the date/time as it should. I said to heck with it and wrote a small perl script that manually setup the time properly upon boot (I am too lazy to go treking thru arch linux hunting for whatevers, howevers.)
ntpd -g should correct things, but it doesn't. and because it doesn't, cgminer won't run. and because cgminer won't run then of course baby jet won't make any "noise". Initially this all puzzled me like I said in my post and I spent money and RMA requests in my initial attempt to "fix" it.
I downloaded the image about two days ago and maybe something changed in the meantime? If you could download your image yourself, load it on a mem card and then boot up off it, you will experience the year "1969" error, and not the more common/expected year "1970" reset. And how come ntpd -g doesn't correct a thing? Dunno why, you tell me?
Maybe I missed it, but what is the MD5 for your image? Remote outside chance that it got corrupted on its way to me here in Hawaii...
Did you restore from a backup? If so, this could be an issue. Just go to the GUI and set the timezone. If you do this, it will set it both for the web interface (PHP) and the Linux system TZ. Before version 4, the system TZ was left unset. (Stock MinePeon behavior) Here's the MD5 hash for each type: ff8139e711ab584f6ca4c4aa6bd4d5f1 hashfast-minepeon-1.0.img.bz2
3bc53fb621683d54a623678400e42a81 hashfast-minepeon-1.0.zip
7a608a094809d1e55f964ae01ddfb090 hashfast-minepeon-1.0.img We had a problem in early final stage at both factories, where the initial load of the SD was either outright wrong (standard MinePeon without HF customizations), or someone pulled the SD card out of the duplicator before it was finished and corrupted the filesystem. Be sure if burning the image on your SD under linux that the sync command completes before yanking your card. Keep in mind, many people here are not linux-experienced and have never visited a command shell. This is why we provide a customized version of MinePeon so it would be turn-key ready to roll. Our beta test results showed that many people were having trouble determining the IP address of their MinePeon systems, so this is why we came up with the http://setup.hashfast.com/ page that redirects them to the local IP. Please if you could, try setting the TZ in the GUI's settings page and see if that updates your system TZ properly. If it doesn't I'd love some help debugging it! Thanks! -Phil |
|
|
|
For all the people here that are running on something other than the RPI's, Here's the source code for cgminer 3.9.0h2 (same version we're currently using on the RPI). This version has somewhat correct hashrate reporting, and has a few other things, such as the per-die voltage and temperature readout. It seems to be the most stable during our testing. One of our top Engineers is currently working with Con Kolivas right now to get some of these things improved. Thanks Con! cgminer 3.9.0h2 source (can be complied on most Linux distros): http://setup.hashfast.com/cgminer-3.9.0h2.tar.gzI'd love reports back to see if this improves your mining performance/stability. Again; please ignore the strings of HW errors, this should not be a problem. -Phil |
|
|
|
Underclock it until you get a hold of someone.
--hfa-hash-clock 530 (find a rate below 550 that doesnt produce hw errors)
I've tried underclock but I have yet to find a frequency that doesn't produce a ridiculous amount of hardware errors. I think I just have defective hardware. We just brought several new support people on-board, and set up a new queue system. I'm CC'd on all the support emails and will look at each and every one. Know that one bad core out of the 384 that are in your BJ can spew a LOT of errors. New firmware that's being tested now will hopefully fix some of these issues. We will push it out as soon as verification & regression testing is complete. Don't let a spew of errors scare you off. Check the pool's reported work rate and go by that. Almost all of my test board here spew lots of errors, but it's usually just one or two "blabbermouth" cores doing this, and the overall hashrate is still good. If you are attempting overclocking, (not recommending you do) but ignore these errors and watch for the "Work Watchdog Timer Reset Imminent" messages. If you see these, then you've gone too high. Back off in 5mhz increments until most these go away (one on occasion is ok) and then check your hashrate at the pool. -Phil |
|
|
|
@Phil - Would it be possible to go back to 3.11? That is the only version that was stable for me. I know some folks complained about lower hashrates in minepeon (after halving the reported rate) but that is because ckolivas made some changes to discard invalid shares. 3.9 is causing full-tilt spikes again and also caused my RPi to crash completely. It also requires me to physically hot plug the miner to be detected... :/ https://i.imgur.com/d1P8FXR.pngI left both 3.11 and 3.12 on there for you guys. There is a symlink pointing to 3.9, just change it to 3.11 and you're rolling on 3.11. SSH into your RPI, the login is "minepeon" and the password is "peon" unless you've changed it, then execute these commands: [minepeon@minepeon ~]$ rm /opt/minepeon/bin/cgminer
[minepeon@minepeon ~]$ ln -s /opt/minepeon/bin/cgminer-3.11.0hf1 /opt/minepeon/bin/cgminer If you decide that 3.9 was better: (I think you will) [minepeon@minepeon ~]$ rm /opt/minepeon/bin/cgminer
[minepeon@minepeon ~]$ ln -s /opt/minepeon/bin/cgminer-3.9.0h2 /opt/minepeon/bin/cgminer I'm running 3 RPI's here with different configs of some our reject hardware, some very unstable, and 3.9 does seem to be great. Uptime is 2 day 3 min 2 sec on one. -Phil |
|
|
|
Gotcha:
Just a heads up to something I ran across while initially running my Baby Jet:
Make sure that the date/time of your raspberry pi minepeon is CORRECT. Mines was set to the year 1969 for some strange reason. If this is happening:
1. The Baby Jet runs just fine at first boot up. Mines great at eligius for The Foreman. Then after a few minutes, DISASTER.
2. Your Baby Jet SHUTS DOWN and will just sit there seemingly doing nothing --no fans on, nada.
3. From the minepeon web interface, it will say "no devices".
4. Clicking on "Restart Miner" will have no effect. Pressing "Reboot" in an attempt to restart cgminer will also have no effect. Upon further inspection via SSH, I found that cgminer was not running. Apparently there is something somewhere in the code that prevents it if the date/time is seriously wrong
5. Check "Server Time" (this can be found as the last line of any page of the minepeon web interface) and make sure it is more or less accurate
FYI: The Baby Jet initially is in a "wait state" at boot-up time. But there is a watchdog program running in the Baby Jet that, amongst other things, monitors the inputs at the Baby Jet USB port --if there is nothing communicating on it i.e. cgminer is not controlling the USB port, then the Baby Jet will not "TURN ON".
So, date wrong ---> cgminer refuses to run ---> no signals on the Baby Jet USB port ---> Baby Jet looks like it is down and broken. BUT IT IS NOT!
I spent a lot of time tracking this down (even bought another what is now a spare Seasonic SS1000XP power supply, requesting a RMA, etc.) as things are not immediately apparant. So hopefully this head's up will assist you if you're are experiencing the 1-5 symptoms above and maybe save you from spending $200 for no good reason.
TO set your raspberry pi's time/date properly:
1. SSH to the Baby Jet and switch to user root "sudo su" and enter in your password (by default it is peon)
2. Find out timezone values "timedatectl list-timezones" Choose your timezone from the list. For me it's Pacific/Honolulu
3. Set the timezone "timedatectl set-timezone Pacific/Honolulu"
4. Initially set date/time:
timedatectl set-time "2014-02-02 15:43:00" Military Time Format (also note the required quote marks)
5. Type "exit" so's to not break anything.
6. Be patient. In no more than 5 minutes, your Baby Jet will start mining again.
That's it. ntpd (bootup time daemon) will take over automatically. Note: ntpd will refuse to do its job if the date/time difference is way out of wack.
None of this is necessary if you are running our image instead of the "stock" MinePeon. I fixed the TZ bug 5 versions ago. You will also not get any updates whatsoever with the stock MinePeon, and you will see both the RPI hang as well as CGminer. I've fixed both of these hang issues. Again, to be clear, if your MinePeon version number does not show "0.2.4.3hf8", you are not running an ideal stable version, and if you want the best stability, you should try our image: 1. If you are already running MinePeon, first make a backup from the Settings tab (near the bottom). 2. Download this SD card image: Windows: http://setup.hashfast.com/hashfast-minepeon-1.0.zip Linux: http://setup.hashfast.com/hashfast-minepeon-1.0.img.bz2 3. If running windows, we recommend the Win32DiskImager: http://sourceforge.net/projects/win32diskimager/, If running Linux, you can simply type: bzcat hashfast-minepeon-1.0.img.bz2 | sudo dd bs=1M of=/dev/xxx && sync (Where /dev/xxx is the device name of your SD card. If unsure, type "dmesg" after inserting your card.) 4. Boot your RaspBerry Pi with the new SD image installed. Note that it may take up to 4 minutes or so to collect all the current updates from us before it will begin mining. Listen for the fans to start in your BabyJet. You can browse here to see when your system comes online and connect to it: http://setup.hashfast.com/. If for some reason it doesn't come up after five minutes, power-cycle it. (We've seen some brands of SD card cause it to hang on reboot) 5. Log into the web interface and restore your backed up MinePeon settings (if any). Note that the RPI will generate a new wallet when you first boot from the new SD image, and will begin mining using that wallet. It's important to switch your mining settings using the "Pools" tab or restore your backup so that your mining proceeds end up in the right wallet! If you don't want your RPI checking in for updates, you can disable this in the Settings tab, but I advise you to at least do it manually once in while. We hope to have some new firmware and software soon! We also advise you to set a password on MinePeon, especially if exposed to the outside internet. (not behind a router/firewall) -Phil |
|
|
|
Where can I download the 0.2.4.3hf8" for MinePeon version?
You will need to install a fresh copy of our custom MinePeon image for your Raspberry Pi: 1. If you are already running MinePeon, first make a backup from the Settings tab (near the bottom). 2. Download this SD card image: Windows: http://setup.hashfast.com/hashfast-minepeon-1.0.zip Linux: http://setup.hashfast.com/hashfast-minepeon-1.0.img.bz2 3. If running windows, we recommend the Win32DiskImager: http://sourceforge.net/projects/win32diskimager/, If running Linux, you can simply type: bzcat hashfast-minepeon-1.0.img.bz2 | sudo dd bs=1M of=/dev/xxx (Where /dev/xxx is the device name of your SD card. If unsure, type "dmesg" after inserting your card.) 4. Boot your RaspBerry Pi with the new SD image installed. Note that it may take up to 4 minutes or so to collect all the current updates from us before it will begin mining. Listen for the fans to start in your BabyJet. You can browse here to see when your system comes online and connect to it: http://setup.hashfast.com/. If for some reason it doesn't come up after five minutes, power-cycle it. (We've seen some brands of SD card cause it to hang on reboot) 5. Log into the web interface and restore your backed up MinePeon settings (if any). Note that the RPI will generate a new wallet when you first boot from the new SD image, and will begin mining using that wallet. It's important to switch your mining settings using the "Pools" tab or restore your backup so that your mining proceeds end up in the right wallet! If you don't want your RPI checking in for updates, you can disable this in the Settings tab, but I advise you to at least do it manually once in while. We hope to have some new firmware and software soon! We also advise you to set a password on MinePeon, especially if exposed to the outside internet. (not behind a router/firewall) -Phil |
|
|
|
Blah, Blah, Blah. RPi is NOT reliable. You had better make good on the Miner Protection Program. Maybe offering Ubuntu laptops on your website would help.
I know, you're tired, you're too busy... the fact that the Bitcoin we were FORCED to pay you is now worth at leat 8x what it was at the time of purchase has no impact. HashFast should be able to afford an entire TEAM of engineers to support a product that it released while it was in Beta-testing. I will be sending HashFast my invoice for beta-testing their hardware, and the consent was given at the time of sale. Look it up.
I'm sorry you are not happy. I do not make policy, nor can I change it. I did not collect any orders. I am just an employee, and I wasn't even working for HF until December! You can "shoot the messenger" if you like, but I'm only trying to help. If you, or anyone else here, doesn't like my advice, feel free to ignore it. I'm not doing a damn thing until I receive "official" notice from HashFast.
Sorry Phl, you could be any jackass on the Internet.
I've got 8 days left on my warranty, and I'm not going to risk it on somebody I don't know on BitcoinTalk. Ha! What a great way to void the warranties of unsuspecting HashFast customers.
Not this cowpoke. Feel free to ignore me. I've only ever suggested people run an image downloaded from http://setup.hashfast.com/, so that should constitute "official" for most people. You are complaining about reliability, which we are improving, and yet you want to ignore it. Sounds like you just want to suffer. I'm working all weekend on my own time, and I'm not paid for support at all, so I'm only here because I want to help. I could be doing any number of more fun things right now, so save your complaints, because I've got just as many! -Phil |
|
|
|
|
