|
.0071 ?!?! damn, now I'm sad I dumped....
|
|
|
|
... actually im not doing anything with the btc i have because i dont see a solid opportunity now.
its money in the bank... sometimes btc goes up when silver goes down, in that instance id convert btc>cash>silver ...
I pm you. Where do you buy silver best ? I buy at bullionvault sometimes  I just recieved 5 new gridseed miners, 70$ each , which i think is a good price? (ordered from minereu 09.05. , got them today ) http://i59.tinypic.com/213qee.jpg70's a good price, at least in comparison to what's out there - but it will be hard to make ROI. If you have a raspberry pi, Minera is the best management software for them I've found yet. https://bitcointalk.org/index.php?topic=596620.msg6741349#msg6741349 |
|
|
|
I just don't understand why a company would treat customers like this. Surely you would understand that it isn't good for business and that your name/brand is going to suffer badly unless you turn this around right now, give us some good news and stick to your promise! For once !!
I don't think there's intentional malice on their part. They aren't sitting around watching the forums laughing as the pre-orderers squirm. I'd imagine they are trying to ship a product. However late they are, however more late we think they're going to be, however bad the ROI is, and however better the compensation is I feel like at this point we just have to see what happens when they ship. More of the same complaints is just adding to the noise. |
|
|
|
Awesome! Not that the installation was hard, but I bet usage will take off now that there's an image. |
|
|
|
hey you guys rock! Thanks for all your support!
Minera 0.1.8a is out
* Added save frequencies button
* Log viewer bug fix
* Added debug option
Running great so far! I finally gave up with my wonky install last night and did a clean image of raspbian and then installed 0.1.8 on it. 0.1.8a upgraded without issue. (sudo even still works  ) I've intentionally not changed any of the default passwords yet, and tonight I'm going to backup the card before tinkering with the system. I'm happy to share this image as a "plug and play" solution for anyone who's interested. You'll just have to log in and put your own pool information in place of my own. |
|
|
|
Glad to hear that  Well, live pool switching is cool but before I can get it on Minera Sandor needs to put a API command to cpuminer, I don't think there is one now. We can talk about this. In the interim, it might be worth while to be able to reorder the pools in the list and then have a "save and restart miner" button that would relaunch cpuminer with the new configuration. Not as cool as live pool switching, but a serviceable substitute if you don't mind losing your autotune progress. Although, there's a nifty idea for a feature - "save autotune results". Basically you pull from the api the per chip frequency setting once the autotune process is done per chip. I don't know if it would be a pain to parse the log for the autotune complete messages. You could also just have it save autotune results after 12 hours or so. Then you add those per chip settings to the miner's startup command. There was a message in the cpuminer-gc3355 thread about a php script to output those frequencies formatted correctly for the startup command: I didn't want to do autotune every time the miner restarted and manually entering the values every time was tedious. For some reason, the device names changed after upgrading the miner version. I wrote a little PHP script that will query all the frequencies for the chips and format them into a command string to use with cpuminer. Now I can just wait for the autotune to finish and then copy and paste the output into the command string. <?php
if(!($fp = fsockopen("127.0.0.1", 4028, $errno, $errstr, 0)))
{
echo("Failed to open socket");
}
stream_set_blocking($fp, false);
$out = json_encode(array("get" => "stats"))."\n";
fwrite($fp, $out);
usleep(100000);
$out = "";
while(!feof($fp))
{
if(!($str = fgets($fp, 2048))) break;
$out .= $str;
}
fclose($fp);
$arr = json_decode($out,true);
$cm_string = "--gc3355-freq=";
foreach(array_keys($arr['devices']) as $devices){
foreach(array_keys($arr['devices'][$devices]['chips']) as $chips){
$fr = $arr['devices'][$devices]['chips'][$chips]['frequency'];
$cm_string = $cm_string."/dev/".$devices.":".$fr.":".$chips.",";
}
}
echo rtrim($cm_string,",");
And the output: --gc3355-freq=/dev/ttyACM0:875:0,/dev/ttyACM0:875:1,/dev/ttyACM0:850:2,/dev/ttyACM0:875:3,......etc You'd be wise to include something that correlates ttyACM0,ttyACM1 etc to a given serial number so if for some reason the miners change com ports it reverts back to autotune. Or at least warns the user that his/her custom per-chip frequencies are incorrect. Anyway - that seems like a lot of work, or maybe it isn't - I only know how to code bash scripts. But I think a heap of users would enjoy it. I know I would. And now that I'm thinking about it, I should be able to just pop that php in the settings page so it shows me the string right above the manual miner startup command settings. Once I have my rig tinkerable I might just do that. |
|
|
|
Now that I know the X-3 will hash with just a single dual hashing board plugged into it, why not offer an option to the X-1 customers of getting half an X-3 with the equivalent number of boards to match our X-1 order? Additionally you could then offer upgrade packages to add more hash boards to the X-3 at a later date.
Interesting idea, though you'd probably lose a lot of efficiency to the PSU overhead, no? Also, cheers to BA for getting .75w/gh at 100gh/s. That is, after all, the specifications originally advertised, and the ones we all bought into. bobsag - thanks for the information. safe travels and once again much gratitude for making the trip. |
|
|
|
thank you very much for sharing this, I checked every commits made on install/upgrade scripts but I cannot find the problem, so I'm thinking about a bad "git pull" or something like that which placed bad chars on them.
Hope it doesn't happen anymore.
thanks
Don't sweat it. Like I said I had hastily deployed minera to a pre-existing system so who knows where the problem came into play. I duplicated the SD card and edited the sudoers file on the original to remove the offending -e, but then the Pi failed to boot fully. Who knows why - maybe macfuse borked the filesystem. Dupe of the original SD still boots fine. I didn't have time (and/or was too drunk to code) last night so I didn't build a system from scratch yet - and at this point since it's still happily mining I may just wait until you release img files. If you're unfamiliar with it, apple pi baker is a great tool for making and deploying properly partitioned img files for the raspberry pi: http://www.tweaking4all.com/hardware/raspberry-pi/macosx-apple-pi-baker/Way faster than the dd command I used to use. Anyway I very much appreciate you looking through old commits - your software is great and even if it had been your error - you wrote free software that helps make me money, what complaint could I possibly have. Expect a donation once I reach ROI in a week or two. Well, Minera 0.1.8 is out
What's next: I finally have a RPi to start build Minera images (pretty exciting), but I still have to put Json config and start/stop daemon.
One question for you all:
What do you think about you will not be able anymore to "screen -r" into cpuminer from Minera? This is because there is some issues playing with screen sessions and daemontools/supervisor, so if we opt in for one of those daemon tools we have to leave the screen solution.
But before doing this I would like to hear your opinion or may be if you have some solutions to run screen with a daemon tool. (The problem I saw is that you can run the screen session within the minerd command, but you cannot quit it, and this is the main problem).
I didn't try this too much, but looking around the web it seems a common problem, so please let know what do you think about this.
Thanks
I mean, this might be overly basic but you've tried screen -dmS miner [command] Im not familiar with daemontools but when I was writing daemons for launchd on the mac this would detach the screen session from the daemon so it would run when the daemon quits. This was a while ago on a different flavor of *nix so, not sure if that helps at all. Personally, I wouldn't be too busted up about not being able to screen -r into the miner as long as there are some logs to review in the event of troubleshooting. The entire reason I'm using minera is so that I don't HAVE to screen -r into the miner - which is how I was operating before just using cpuminer-gc3355 and a basic startup script. If the last 'n' lines of miner output were available in a log file somewhere it would satisfy my needs at least, where 'n' is an arbitrary amount of logging that goes far back enough to enable troubleshooting but doesn't just fill up the disk ad infinitum FOR BONUS POINTSIt would be really sleek if you could download the available logs, maybe even as a zip file, from somewhere within the minera interface. Far from a requirement, also I feel like the interface might not be working in the hypothetical situation where I need to get at the logs - but still. I think that would be a worthy tradeoff for losing screen TUI access. I just noticed you added a log viewer already, which is basically even better. I can't upgrade till I fix my sudoers issue but when I do I'll let you know if that has the logs i'm referring to. |
|
|
|
Here you go, here's the Minera Settings portion of my sudoers file. The offending line is line 37, the one with the -e on it extraneously #Minera settings
minera ALL=(ALL) NOPASSWD: ALL
www-data ALL = (ALL) NOPASSWD: /bin/kill
www-data ALL = (ALL) NOPASSWD: /usr/bin/screen
www-data ALL = (ALL) NOPASSWD: /sbin/reboot
www-data ALL = (ALL) NOPASSWD: /sbin/shutdown
www-data ALL = (ALL) NOPASSWD: /usr/bin/killall
-e
www-data ALL = (ALL) NOPASSWD: /usr/bin/git
|
|
|
|
|
Oh, here's a question: How far away are we from seeing the X1? they said the cases arent ready but how far back are they?
|
|
|
|
I didn't defend a scam. Read my post again. Exact words: "Could it be a scam? Sure." I merely attempted to debunk bad information. In response I got more bad information. Lets get more detailed. They claim to be hosted in saskatchewan. Here's saskatchewan's power costs: http://www.saskpower.com/wp-content/uploads/saskpower_supplied_transformation_rates.pdf(14500*.11335)+((540720-14500)*.05952)+27.43=$32991.91 Less than my original calculation. All I'm saying is yes-there is the possibility that this is not a scam. |
|
|
|
It's not even close to that cheap for an S1. Bitmain has them for $2.59 per GH as of right now. PBMining is mining at $2.20 per GH. You're saying that PBMining worked out some kind of deal that got them a price lower than that, that factored in the 1100watts per unit power charge and somehow gives them a profit that pays for the management of this operation for a bunch of full time workers?
Use your head. It's a scam.
You're entitled to your opinion and I won't try to change it. I will correct your facts though. The S1 is BTC0.484 per 180gh/s. 0.484/180= BTC.002688888/gh/s .00268*439=$1.17/gh/s Draw of the unit is 360 W at the wall - not 1100. If we were to assume their whole facility were antminers, that would put their total electric consumption per hour as follows: ((TotalHashrate/HashratePerUnit)*WattsPerUnit)/1000 ((375500/180)*360)/1000=751 So in a given month thats ((30*24)*751)=540720 I think they said they were in canada: the average electric price in canada (1) for an industrial facility is $.0732/KWh CAD or $.07USD 540720*$.07=$37,850.4 Monthly Power Cost Per GH that's 37850.4/375500=$0.1008 Cost per month. Over 5 years that's $0.1008*(12*5)=$6 So - we can deduce that in order to maintain profit, they'll have to upgrade their hardware after a year assuming they are running S1's. But, customers have paid up front. So they have the capital to get new hardware. Furthermore, since they are charging double the hardware cost, they could buy double the hardware, basically using the customer as a loan for them to build a huge mining farm half of which is mining for them. Power consumption aside - baseline - they are basically doubling their money on hardware. Further profit can be derived from merged mining. Even further profit can be derived from the fact that their fixed payment calculator accounts for avg 10 minute blocks. As difficulty increase approaches blocks are solved faster, and then when difficulty increase arrives they pay out less. They are mining more than they are paying out. Users, like me, are okay with this because of their guaranteed fixed payout rate. At 375TH/s they are making about $4,423.36 per month just in NAMECOIN. There's room for profit. Could it be a scam? Sure. Does it scream scam from the hilltops? Nah. There's a risk involved. There's a risk in pre-ordering hardware. But if you're going to say it has to be a scam - at least try to back that point up with correct figures. |
|
|
|
Really? Where?
The Antminer S1 is nearly that cheap, for one thing. I'm sure if you're buying them in bulk you can get a discount as well... |
|
|
|
Had a strange transaction recently, only noticed as my account now has a negative BTC balance. So usually after a block is rewarded I see the block reward in my account history and a maintenance fee, a % of the block reward, but this time I see:
Mining: 0.00010283 BTC
Maintenance: -0.00045417 BTC
Maintenance is over 4 times the block reward? Is this a known issue?
The maintenance fee is calculated per-share, so for long blocks your shares will cost more than they make, but on the "a few seconds" blocks you'll barely pay any maintenance. While frustrating and somewhat opaque, the same would be true if you were using your own gear mining at home. Long blocks would use more electricity than your reward from them, but short blocks would use barely any electricity for the same reward. |
|
|
|
say hi to your jetlag
Im so jetlagged I tried turning on my macbook pro by shaking it. IN seriousness I hope to have a metric ton of pictures and information over the next few days, so bear with me Best of luck. I think it's really fantastic that you flew halfway around the world to get "feet on the ground" answers for your customers, and I just wanted to thank you for doing so. |
|
|
|
Uh - it's worth noting that the method I described works - but something borked my sudoers file. Get this when trying to run sudo anything sudo: parse error in /etc/sudoers near line 37
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin I'm at work and the pi is at home and not being able to sudo creates the recursive issue of not being able to access the sudoers file. Probably going to image a new card when I get home and start from scratch. Do'h. At least it's mining. well, I'm sorry for that but until you can't find what /etc/sudoers contains I can't understand the problem, may be you run a bugged (old) installer, don't know. It could be very useful to find out what /etc/sudoers contains. May be you could mount the SD Card on your PC and look at the file <mount-point>/etc/sudoers Hi i think its a list of users that are allowed to use the sudo command but i might be wrong pjc - Yes - it is supposed to contain the list of users allowed to sudo. In this instance it has something garbled in it apparently and the pi can't parse it. Michele - I'll see if I can get at the sudoers file and relay its contents. Not sure if it's on the partition I can see on a mac. I built my minera install on top of a version of the zoomhash image that I had modified to run sandor's miner, and then went about the upgrade in a nonstandard way - so any number of things could have borked it. I doubt its the fault of your code, I was more relaying that just in case anyone else was having issues and was going to follow my steps. I also noticed your instructions on git for troubleshooting upgrade problems after I had gone about the steps I took so - yeah. On my future install I'll make sure to "passwd root" so that I can get around issues like this if they happen in the future. Also - one must question my wisdom for mucking around with the system of a machine I wont have physical access to for a number of hours. |
|
|
|
Uh - it's worth noting that the method I described works - but something borked my sudoers file. Get this when trying to run sudo anything sudo: parse error in /etc/sudoers near line 37
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin I'm at work and the pi is at home and not being able to sudo creates the recursive issue of not being able to access the sudoers file. Probably going to image a new card when I get home and start from scratch. Do'h. At least it's mining. |
|
|
|
Had the same issue and from what I could tell the failure for me was due to my modifications of the install script originally to get it installed. This caused the web based update to fail.
I deleted the install script, did a git pull, then ran the upgrade script successfully..
to clear the update notification, per michelem, run the following:
redis-cli del minera_update
redis-cli del minera_version
I hadn't modified the install script, but I did get the update to work by doing a git pull first. If anyone else has trouble here's what I did: cd /var/www/minera
sudo git pull https://github.com/michelem09/minera
sudo sh upgrade_minera.sh Saw you added in postfix.... I suppose email alerts are on the roadmap  Temperature widget is awesome! |
|
|
|
|
Noticed the little exclamation point and saw an update was available. Very cool! Didn't know this was a feature.
The only rub is - I can't get it to work.
It counts down and says system updated, but then it still says update available and the version number doesn't increment.
Tried forcing a reboot. Even tried logging in over ssh and running /var/www/upgrade_minera.sh
This throws some errors but works if you sudo it...
Afterwards - the version number still hasn't incremented...
EDIT: got it. see below.
|
|
|
|
|
Show Posts
