Bitcoin Forum
June 21, 2024, 08:20:14 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Economy / Lending / Re: CoinLenders depositors: Reimbursement available (please read!) on: July 13, 2018, 09:09:15 AM
TF contacted me via email and refunded me the remaining 70% of my CL balance a couple of days ago.  I have removed the negative trust rating I placed with his account years ago.   

I didn't see this thread until just now.   So he wasn't refunding me in response to a request from my end.  The CL debacle (and TF's "disappearance" shortly thereafter) was far from what anyone would consider "handled in an ideal way," but the fact that he's trying to make good on the mistakes of the past is really encouraging.  There have been so many scams and so much greed in the cryptocurrency community over the years...this result is practically the very last thing I would have expected to happen, today or any other day.

I had long written off the BTC I lost at CL as a "hard lesson learned," and nothing much more to say/think/hope for.  To say the least, this was a happy surprise indeed.


For reference purposes:

Back in 2013, TF offered a refund of approximately 30% of my CL balance...and I begrudgingly accepted.   (I had placed far too much of my BTC balance into Coinlenders, so after it was clear that we weren't going to have our balances refunded -- "cutting bait" and getting something rather than nothing seemed like the only viable option.)   

My balance was less than 10 BTC -- not much by some standards, but it was almost all of the BTC I had back then.   (Ah, the follies of youth.)  I can confirm that the amount TF refunded to me was (AFAICT) the correct amount to "make me whole" for the BTC that was lost on his service.   


2  Bitcoin / Group buys / Re: [PRICE REDUCED] DPS-2000BB 2000W Server PSU Interface Board on: November 13, 2014, 03:55:24 PM
sidehack,

Is the price still "reduced" -- or does the thread title / OP just need to be updated?   (I saw conflicting info -- one post said through the end of October, another suggested the sale would last until the Prisma group buy had concluded...  Etc.)

If things are still on sale, could you maybe...say what the prices are, because the original prices, the dropped price, the discount amounts, and the recent sale -- it just...um...seems kind of scattered about all over the place and it's  kind of hard (for me at least) to figure out what the actual *price* is.

I realize I should be capable of locating this information -- but I formally admit defeat and would kindly request a current price list, just whenever you get the time...not a rush or anything.  Thanks!
3  Bitcoin / Group buys / Re: [PAUSED] ASICMiner Prisma 1.4th/s - 1.47 BTC on: November 13, 2014, 03:39:27 PM
The one thing I did notice is that these are not enclosed like the Antminers S3, I have an idea for those of you running Prisma to add a layer of safety. Perhaps you could find an old screen and screen in your miner. This way the air could flow, yet any exploding caps would be contained. I have a screen door I will use above the unit, while I continue to test my miner.

Hmm, that's really not a bad idea.  (Assuming a hot cap couldn't just melt its way through the mesh -- screen doors are pretty thin stuff, right?  

But that's the easiest and cheapest idea I've heard so far...a lot better than buying $50 of sheet metal and having to return it to Home Depot, with what I assume my excuse will be: "I'm sorry I bought this but I needed nonmetallic...sheet metal.  So this won't work.  Because it's metal." Smiley


Quote from: phil
Shout out to the cap poppers what were the psu's on your gear.

Two IBM/Delta DPS-2000BB server PSUs, operating in current-share mode (so two 2000W PSUs acting as one big 4000W PSU, which should have been more than plenty for the 3 Prismas, IMO).   I should point out that in my case, no circuits blew -- until I threw the breaker and killed the subpanel that feeds my mining stuff.  It was just happily mining and burning along...and as I told CrazyGuy, I noticed (just because I was near my laptop at the time) that cgminer didn't show any errors or unusual activity when the alarm went off.  (No, I don't expect cgminer to somehow say "look out the board is on fire!" -- but I would have expected melted burning charred exploding chips to ...you know...throw the occasional HW error, lol.)

And I take offense at the term "Cap Popper."  I demand you call us "People who through no fault of their own became victims of cap popping phenomena" ... nah just call it whatever, I'm kidding of course.
4  Bitcoin / Group buys / Re: [PAUSED] ASICMiner Prisma 1.4th/s - 1.47 BTC on: November 13, 2014, 03:22:29 PM
Arcing is not possible in the senerio.  The voltages are WAY to low. You would need hundreds of volts or even thousands to jump even a small amount.

http://en.wikipedia.org/wiki/Paschen's_law

This was current runaway.  These chips are most likely a "chained" design used to obtain maximum efficiency.  If one chip in the series "chain" shorts internally, it can

cause a great increase in current through the other chips in the chain thus causing the temperature to rise suddenly and dramatically.  This would literally set them on fire!

Somewhere on here I have seen a picture of a heavily burned "one string miner" that used Bitfury chips.  These use 14 chips and run directly off the 12Vdc feed in series. 

So if one ship shorts, it starts an overcurrent condition that very quickly pops all of the others.

Thank you for taking the time to explain the concept -- I was familiar with "thermal runaway" and "runaway brides" but not "current runaway."  So this was very educational for me, so thanks for posting it. 

That said, the explanation (above) strikes me so far as the most likely cause...in both fires. I'm basing this not just on "looks" but also on the fact that I recall Asicminer informing shareholders (last week maybe?) of a "Chip Popping" problem that had plagued the BE200 chip, causing failures for various OEMs --  so please correct me if  I'm way off base, but is it possible this "chip popping" could trigger the current runaway you described?

And if that *is* true, then (not trying to cause a panic, just asking the question) -- if there's no known way to identify chips with this defect, and they can run for several days/weeks before they "pop" -- is there any way a regular user (without access to absurdly advanced tools etc) could detect or otherwise know if their unit is at risk?  Wouldn't that mean (to some degree) that all Prismas are at risk for this kind of behavior?


BTW: Please note, I am not trying to push an agenda -- my 2 RMA Prismas are arriving today, and I still have one running (the one that wasn't damaged by the fire) so I'm not trying to worry people or discourage new sales or otherwise hurt ASICMiner.  I honestly just don't know the answer to the questions above, and they seem significant, so I thought I'd ask.  Not a fanboy, not a hater.  Just a miner. Smiley

EDIT:  One other question:  I had all my miners connected via the USB/UART connectors.  But I realize I could have "daisy chained" them together...  This is probably a dumb question but -- when you daisy chain boards, is it kind of like "extending the one string" ... meaning, could a chip pop on one board and then just follow that "string" back from one board to another and another, damaging more than one board (or more than one Prisma)?  That's my main question -- because if daisy chaining makes it possible for ONE popped chip to potentially damage everything that's connected to it, it seems to me like it might be safer to just connect each prisma to a USB hub (rather than chain them together and the connect the last one via USB).  Or is that just such an unlikely scenario that it's not worth worrying about?
5  Bitcoin / Group buys / Re: [PAUSED] ASICMiner Prisma 1.4th/s - 1.47 BTC on: November 13, 2014, 05:31:45 AM
"Mister InvalidSnack" ...lol. 

At least you sent me to bed with a smile on my face, Mr. CrazyGuy.  (Or do you prefer Dr CrazyGuy, PhD?) 

And as for the 5 MW facility --  Phillip you read my mind, I've literally spent the last few days reading about that and looking at the pictures you referenced and going..."well, I only managed to burn up 2/3 prismas, and the antminers were safe...so it LITERALLY could be much much worse."  But this wasn't supposed to be a pity party for me -- I was (perhaps prematurely) trying to alert people to a possible dangerous flaw ... and as I told Mr. CrazyGuy, it's entirely possible I just saw that picture of the other users' "blast pattern" and thought "oh fuck, you've gone and done it now...you never mentioned this and you know his post is going to say something about 'losing seven family members in the blaze,'"  -- in other words , guilt might have turned me into Chicken Little.  It's too late for me to really tell -- need to sleep on this.


But regardless, I would still strongly suggest people "keep an eye" on these miners.  Mine worked fine for 3 days.  No irregular temperature readings anywhere.  (Well, it was probably "irregular" about the time the fire was eating everything...but you get my point.)  I followed Dogie's guide so every screw was tightened, checked every cap to see if it was wobbly -- so , just, "be mindful of that middle area, and keep checking it for more than a few days before you start assuming everything's fine." 

There, those are my adjusted, far more reasonable "suggestions" for users.  Off to sleep now -- if I wake up and realize I'm a moron and embarrassed myself for no reason, I will go back and remove the more "excitable" language from my previous posts...because I never meant to cause a panic or fuss.  G'Night folks.

6  Bitcoin / Group buys / Re: [PAUSED] ASICMiner Prisma 1.4th/s - 1.47 BTC on: November 13, 2014, 05:02:59 AM
as for the second person talking about burning up a tube ..   both had the same thing in common close to a solid metal plate.    a  power surge then an arc to the plate then pop.    as a point of safety do no rest your tube miners near metal plates.  use other safer ways to stack them
  it is common sense an open set of ciruits .25 inches away from a metal plate = danger.

look at the tube design .  I told more then one person do not use it on metal. I used wood.  now on this the long tube I rest it on


I apologize for not being clear.

I purchased sheet metal from Home Depot 3 days ago, in anticipation of the NEW RMA REPLACEMENT Prismas -- because I wanted to make sure there was *something* fireproof and projectile-proof beneath the miner this time.  (If metal is a bad choice, then I made a bad choice.  But that's not the point.)

The fires do *not* have this in common -- because my fire was 2 weeks ago, not 2 days ago.  When my unit caught on fire, it was sitting on a piece of wire shelving, which was in kind of a "sandwich" -- two pieces of wire shelving with some "slices" of thick PVC pipe between them.  In other words, the Prismas were on NON-CONDUCTIVE, plastic-coated wire shelving -- suspended a good 3 inches above the MDF/whatever shelf below.

The fire was *not* caused by an arc -- there is no metal near any of my miners -- it's actulally all stacked next to the wall, because I was hoping to try to use it to PROTECT in the future against this kind of thing -- and if that's stupid (which apparently it is) then so be it, but please understand the fire I discussed involved *zero* chance for any "arcing" of any sort -- unless it occured within/between mining boards.  No metal was present and more than adequate airflow was available to the bottom unit.

I will try to post pictures tomorrow--apologies, its' late in my timezone and I need to be up early.  But I am eager to "make amends" as I told Crazyguy in a series of questions he just asked over PM, which I gave him full permission to quote or paraphrase as he likes....whatever needs to happen in order to make sure nobody else is potentially put in danger.

Again, and I apologize for beating a dead horse but I regret sending the wrong message in my previous post: The first guy's post, where he shows the metal plate beneath his miner... whether it's a "best practice" to use metal or not, the fact remains:  that metal plate saved his house from burning down, assuming the flames happened when he was asleep or not at home.  It deflected / blocked the exploding capacitors and other components that (in my case) simply bounced through the giant holes in the wire shelving and were hot enough to set a slice of PVC pipe on fire...along with parts of the shelf itself.

It is not a "metal arcing issue" that caused this damage -- though that might be a valid concern, I don't claim to know otherwise.  It's just *not* the reason this particular "blast pattern" happened.  By all means, use ceramic tiles to protect your shelving and not metal -- I couldn't find any light (and not super expensive) tiles myself, and I didn't want to triple the weight of my shelves with the cheaper heavy tiles...  And other devices (like the Antminers) have a metal exterior shell, so I thought it would be possible to "box in" one of the Prismas to keep other things safe.  Maybe this was a stupid idea.  Unfortunately, stupid ideas made *after* the fire don't really serve to explain why the fire happened in the first place.

I would write more, but like I said I just wrote it all to Crazyguy who in theory was asking so he could share the info with you guys.  -- oh, and please don't misunderstand the "tone of voice" in my message here, I'm trying to type quickly and sometimes I come across like an ass or argumentative, and I assure phillip, you I don't disagree with your statement that metal might not be the best firepoof material to use -- I just wanted to clear up the misunderstanding that led you to believe there was any metal, anywhere near the fire that I experienced last month.

I hope that makes more sense this time?  Crazyguy can you help me explain this better?  (I'm tired as fuck and possibly not making any sense to anybody...hopefully CG can swoop in for the rescue and put this into normal human words that people can understand ...sorry for the confusing first post.)
7  Bitcoin / Group buys / Re: [PAUSED] ASICMiner Prisma 1.4th/s - 1.47 BTC on: November 13, 2014, 12:32:06 AM
Ok, found a few minutes to look closer... I think I found the problem. I am really glad I put some scrap 10ga steel underneath these miners. This was the board facing down and it was running only 220MHz.


Wow, okay now I'm a bit concerned.

I had the exact same damage -- in the exact same area your picture shows.  In my case, it actually started a fire which took out a second Prisma (blew all the caps off one side , popping like popcorn kernels before I could hit hit the power and grab the extinguisher).  But I didn't want to panic people and told ASICMiner and Canary I was assuming it was a fluke, and was focused mostly on getting my RMA completed.   I'm really glad you're safe and didn't burn your house down, man -- because in the back of my mind I've been thinking "what if the problem *ISN'T* a fluke and hits someone else, when he's not home?"  

I told Canary (who presumably told FC) that I wasn't really interested in trying to "publicly embarrass AM" and was happy to keep things between us -- so long as two conditions were met: (1) they replace the damaged Prismas in a timely fashion (which didn't happen unless you consider weeks to be "timely") and (2) "unless it appears to be a widespread problem and not a random component failure."

So both #1 and #2 have hit at this point;  when i saw your pictures in my browser, I swear I thought "Wow, FC is posting the images of the damage that happened?  That's really honest of him..."   I mean, it's like looking at a duplicate of mine ... though you seemed to get things under control faster than I did (the fire charred the entire bottom of mine, and there were no capacitors "unpopped" on the Prisma where this damage occurred).

So let me be clear since I've been silent (and OBVIOUSLY should not have been)  -- I can't calculate the odds of *two* random manufacturing defects causing the *exact* same damage in *exactly* the same spot (center -top of one board, or center-bottom depending on how you look at it, and causing enough damage to affect the adjacent corner board as well).  Maybe the odds aren't so bad.  But I'm inclined to think that there is something amiss with whatever component blew in both of our Prismas -- is it a vreg?  

All I can say for certain is that if I had not been home (just arrived back from errands about 5 minutes before I heard the alarm) and if I hadn't put a smoke alarm on my mining "shelf" (the main one in the hallway took a good 10 minutes or so to finally go off) then there's no doubt in my mind that the fire caused by a Prisma just like yours, would have done an *enormous* amount of damage.  Even putting it out as fast as I could, it took practically all night with all the windows open and like 5 box fans trying to pump all the smoke out of my apartment and it took all night sifting through charred parts of the wire rack that it *melted* before I could finally get enough of the debris out of my office ...but then I took a shower (and I guess washed the smell out of my nose) because it was sure as hell still there...  Took *days* to finally stop smelling like melted plastic and...

Anyway, I'm not going to lie here -- I'm a mixture of embarrassed and sincerely horrified to see another customer affected by the *exact* same damage, which I could have sounded the alarm about ~2 weeks ago -- and I'm so sorry to you, and so very glad that you had a metal plate under your Prisma to contain the damage and not lose things in a fire.  What's more, you're doing *exactly* what I should have done (and didn't) -- I sent my pictures in and asked for an RMA, and *you* posted the pictures here and warned people to help avoid more damage/injuries/etc.  

I've never met you before in my life, but you are the better man (or woman) and I am pretty certain I'm a selfish piece of shit right now.  I apologize to you, and to everyone else for not saying something sooner -- and I hope others will *please* take this threat seriously and put some kind of metal protection around/under their Prismas...



...and to be honest,  I feel like someone just punched me in the stomach -- I know I should probably post more and add details and etc, but I need a drink or something.  I don't know how I would have lived with myself if someone had been injured, or worse...  I don't know what the fuck I was thinking assuming it was a "fluke" -- that's not my job to determine, I have no qualifications to assume that, I should have done like you just did....  Fuck, I ... will come back and post more if needed, but I'm literally floored by this and -- I'm just VERY glad that nobody was hurt by my failure to report this, and I fear I'm just repeating the same shit over and over...so again, let me come back to this and post a bit less freaked out a little later, but I'm truly sorry and very ashamed of my inaction; my main goal in writing this (admittedly hastily and shittily written) message ASAP was just to make sure I got that message across as soon as I saw this had happened, but I apologize for not being able to cobble together a slightly better post than this.  

Friends/fellow miners, please take this danger seriously. While I don't have any way to know how many Prismas are affected by this, it seems hard to imagine that *only* our two are capable of this very specific type of failure -- so it seems clear to me at this point that it's not an isolated problem.  (Well, it's isolated in that it apparently happens in the same spot ... but not isolated in terms of people, or Batches, or etc.)  And for the record, I never overclocked *anything* -- everything was running at stock speeds, and running well, for about 3 days, with zero warning signs before it happened to me.  I can't believe I didn't say something sooner.



PS: The exploding capacitors were so hot, they actually *embedded* themselves into areas all over my office.  When I was finally getting the mining rigs (other than the Prismas) up and running the next day, I found several of my S3s were seemingly dead ... but it turns out they just all had dead network cables.  I swapped them out and didn't notice until later that day that somewhere on each of the 3 ethernet cables was either a cap (melted halfway through cable, through the exterior protective sheath, embedded right where all the individual data connections are) or a small "cap-sized hole" melted far enough into the cable to leave a recognizable impression (and a clear view to the data connections that it had severed).  So this probably is the most obvious statement in the world but: "The exploding capacitors can and will start fires or damage other equipment," it's vital people take serious care in terms of *where* they choose to store Prismas, because they will want something protecting other equipment from damage if it's all on the same shelf, for example.
8  Bitcoin / Group buys / Re: [OPEN] Prisma 1.4Th/s group buy @ 1.42 btc with coupon on: October 30, 2014, 06:59:42 PM
Is there anyway to replace the fans with a quieter one?  Do you happen to know the CFM of the fan used?

In reply to your first question, my answer would be "Sure, but you'd better make sure it's a damned good one."  I don't know the CFM/Static Pressure info on these (I think the labels were removed -- kind of like filing the serial number off a handgun, lol) but I think if you go to Dogie's review of the ASICMiner Tubes, he has some info on the fan THEY use -- and I bet it's similar.  

In that same Tube thread -- or it might be the main, ASICMiner/Friedcat announcement thread -- look for a post by phillipma1957.  He went into great detail discussing some mods he'd made to the tube which worked well (and should work here, AFAIK).  IIRC, he had quite a bit of luck replacing the super mega hyper loud one with a pair of slightly less super mega hyper loud fans.  So that's an option, I suppose.


Personally, I found the noise *really* annoying not due to the volume but the *pitch* of the fans.  They just have a loud, high-pitched ... well, literally the exact same sound as a hair dryer (there's a reason people keep using that comparison).  Unlike the other fans which just all kind of fade into the background as a low-pitched "hum" they are absurdly loud and cut through walls and brain-tissue alike.  lol   I think the primary issue (Someone knowledgeable please correct me if I'm wrong) is that even though they're 3-pin fans, they're being run flat-out (100%).  Seemingly no "throttling" like you have with Bitmain fans, for example.  And almost any fan if you run it at 100% is going to be obnoxious.

I'm not sure if that's a mistake, or a design flaw, or if ASICMiner was just lazy...or if they did careful math and concluded that they needed exactly 100% of the fan 100% of the time to cool the chips (although that last one seems a bit unlikely).  Others have hooked up fan controllers (in between the prisma and the fan).  And if you felt like "60% of the fan was sufficient" (and you thought that was going to be the case 24/7) you could always just put a resistor in-line with the ... um... again, let me defer to other websites and/or people who can tell you exactly what kind of resistor and between which wires you want to put it.  But the point is, you can *usually* slow fans down...either crudely (with the resistor method, though that might not work with PWM fans) or with a fan controller, or ideally by doing *something* with the blue wire to throttle the fans appropriately.


Oops.  Sorry, I'm a bit longwinded -- now that I re-read your questions, apparently the normal human reply would have been:

1. Yes.
2. No, I don't know the CFM off-hand, but see Dogie's thread because it's not JUST CFM, but also static pressure you'll want to match.




PS, I should point out that I have an exhaust duct sucking hot air from the back of my shelf/rack/whatever and blowing some/most of it out the window.  (Doing my part to destroy the planet...because I'm a complete dick, I guess, but that's beside the point.)  Anyway, I had the Prismas sitting on a different shelf when i was first messing with them -- and the noise was terrible, I could hear it on the other side of my apartment, with two closed doors in-between!   However, yesterday I finally made some room on the rack/shelf/thingy and moved all three Prismaux in there...and since it's partially enclosed (to funnel the hot air out the back vent/duct) the noise just magically vanished overnight.  

Okay, it didn't *vanish* but I can sit here in the living room without clawing at my face and begging to die like previous days.  So if you can enclose/muffle the units just a little bit, that helps a *lot*.  I wouldn't recommend doing that unless you have a duct or fan evacuating that heat, of course--otherwise you'd be creating your own little Bitcoin Greenhouse, which IIRC is *not* a Best Practice if you want things to function longer than a few days. Smiley

Hope that helps and if you try something new, be sure to share with the group...  I can still just *barely* hear those obnoxious fans (nothing like it was before, but the AC kicked off just now so I can barely make them out) and the more solutions the better, because I think more than a few people are going to be having to choose between "Mining" or "Divorce" if they can't get these bastards to run a bit quieter.  
9  Bitcoin / Group buys / Re: [OPEN] Prisma 1.4Th/s group buy @ 1.42 btc with coupon on: October 30, 2014, 05:53:08 PM
At this point, it's pretty difficult to imagine anyone questioning whether it's "safe" to trust Canary or not -- but it still feels that a quick note/fyi is appropriate:

Ordered 3 Prisma (Prismas? Prismi?  Prismaux?  Prismoxen?) and received 2 in the first batch; the third showed up yesterday.  My experience with Canary was excellent -- considering I've never participated in a group buy before (only direct purchases from manufacturers, eg, Bitmain and the like), the process was smooth sailing the entire way.  

Everything arrived on-time -- in fact, I had mine in hand before certain other GBs announced they'd received their first "batch."  (No disrespect to any other GB intended -- just pointing out that Canary's "All mail comes here first, before anywhere else" claim seems to be pretty damned accurate.  My current suspicion is that he's secretly like the Brother-in-Law of the Postmaster General or something.  In fact, if you look closely at his user pic, it's *clearly* a photoshop job -- I don't think he's even a bird at all.)    People were still debating in the main Prisma thread "whether or not any Prismas are in the wild yet" at least 2 days after I'd already received mine and placed 'em into service.  

And all three sound like enormous "industrial hairdryers" (if such a thing existed) -- so yes, I can confirm they arrived undamaged, with absurdly loud fans functioning per the manufacturer's specs.  What's that?  NO, I SAID THAT THEY ARE FUNCTIONING PER MANUFAC-- oh nevermind. :)

It has been a pleasure doing business with you, Canary; I still might grab a couple more of these from you later on...if and when I'm able to adjust the exhaust setup in my spare room enough to lower the ambient temp a few degrees...anything cooler than the surface of the sun will do for now. :)

But back to my main point -- I highly recommend Mr Yellow Bird of Happiness to anyone out there (especially any GB-newbies like myself...unless I was the only one left, which could easily be the case):  If you're in the market for an Avian-Managed Prismaux Group Buy, this one's your best bet.


[ Noted one more time for clarity:  No disrespect to the other Prisma Group Buy, which AFAICT appears to be handled in an equally professional manner. ]



--- EDIT ---

I was asked to include some setup details, which I'm happy to do:

So, 3x Prismaux...currently supported by:
  • 2x Delta/IBM DPS2000BB Server PSUs (in current-share/load-balance configuration)
    • Not using the breakout boards -- I would have loved to, but they weren't in stock when I set these guys up; but Sidehack makes quality stuff so I'd recommend them to anybody even though I never used 'em.  
    • A previous poster earlier in the thread mentioned that he can be grumpy sometimes...I don't know him well enough to dispute that statement (although it's probably true about anybody, myself included, depending on when you happen to catch me), but the fact is he makes quality stuff, right here in the USA, and -- most importantly:  if I could pay $50-60 today and get back all the hours it took me to solder those damned wires to those bastard PSUs a few weeks back ...I'm pretty sure I could just *sleep* for all those extra hours and still find the tradeoff well worth it.  So definitely worth considering, IMO.
  • BeagleBone Black (the development board, not the Porn Star -- and if there isn't a porn star by that name, I will *happily* eat a Prisma.  Some things in life are just guaranteed.
    • Running Debian 7.7 (image downloaded from the elinux.org site)
    • cgminer version $whateverCurrentVersionIs with --enable-blockerupter
  • Rosewill USB 2.0 Powered hub, take your pick they all seem to work great.
  • Um, afaik that's it...?  
  • oops, almost forgot: A lovely heaping handful of Klondike_Bar's 16AWG PCI-E cablesNice and friendly and conductive...all the things you look for in a bundle of wires... Made in Canada, which is almost the same thing as "Made in the USA" ... just much more polite. :)

Anyway I hope that helps...someone...somewhere.
10  Bitcoin / Group buys / Re: [OPEN] Prisma 1.4Th/s group buy @ 1.42 btc with coupon on: September 30, 2014, 07:20:17 PM
Canary,

Please sing me a song of "successfully received your PM / Payment and reserved your spot in line" -- assuming you take requests, you wonderful little yellow bird, you. :)

Thanks for running this GB, btw.

{EDIT:  Ordered 2 in total.  Second PM sent, fyi.  That should be it for me this round.   Thanks! }
11  Bitcoin / Group buys / Re: Prisma group buy on: September 26, 2014, 10:31:10 PM
Looks like pricing will be ~1.47 per prism. (Subject to change if costs change with manufacturer)
No BE controller included since its been causing you more grief than it's worth.

A USB interface will be provided which you can connect to anything capable of running cgminer.

Based on my experience with ASICMiner chips through USB interface, I do not recommend rPi for set it and forget it operations.

I'm certainly interested in grabbing (at least) one.   I assume a BeagleBone Black would fit your definition of "not a RasPi," yes?

Any idea how people are intended to get these working -- like, is there going to be a driver released for cgminer, so we can be getting the little boards ready?  Or is it a "hope and pray they at least put a download of a custom cgminer somewhere" kind of thing?
Edit, nevermind you clearly already answered this in your previous post, my broken internal parser must *still* be pretty broken, sorry!

Final question:  FCat originally said the system would work with a RasPi, and he said you could control >2 devices from that -- so am I safe in assuming that multiple Prismas connect via a standard usb hub (since the RasPi only has 2 USB ports anyway)?  

The wording they chose seems almost deliberately confusing...something about "they are all controlled by ethernet...you will use usb to connect them" ...I think that's the part where my internal parser thew an exception and refused to continue. :)
12  Bitcoin / Group buys / Re: [OPEN] ASICMiner Prisma 1.4th/s - 1.54 BTC - Group Buy Batch 2 on: September 26, 2014, 02:06:57 PM
CrazyGuy,

I already have a RasPi (actually I think I have two around here somewhere) that used to be stratum proxies for BE Blades/Cubes/etc.  If I purchase one a Prisma from you, I won't need the controller or a new RasPi -- but a copy of the image you're planning to use (that I could flash onto my SD card) would likely get me up and running a lot faster.

Any chance you could offer customers of your group buy (who have the RasPi already) a download link where they could grab a copy of sd card image?  (I don't mean right now -- I mean like, after the purchase is completed and you're shipping the devices out, naturally.)

Thanks and apologies for the oddly worded, longwinded question. :)
13  Bitcoin / Hardware / Re: ANTMINER S4 Discussion and Support Thread on: September 25, 2014, 10:47:22 PM
I have 2 coupons available if anyone wants to buy them.

0.1 BTC each.   PM me if interested. { Edit, 1/2 remaining. 0.1 BTC each. PM me if interested. }
14  Alternate cryptocurrencies / Mining (Altcoins) / Re: [CLOSING DOWN] ScryptGuild Auto-Switching Pool on: September 25, 2014, 09:24:47 AM
...will leave you with nothing.

...other than gratitude for another excellent pool (albeit short-lived) borne from the extraordinarily high standards we've all come to appreciate and expect from BTCGuild, and you, Eleuthria.

Please accept the generous donation of coins I haven't the faintest idea what to do with, but one day I hope they are worth MILLIONS -- just do me a favor and never tell me if that happens, okay?  Smiley

Clicked "donate" weeks ago, but came back one last time to wave g'bye before you turn the lights out and lock the doors to the place.  Man, I *really* hope we don't end up with a sense of deja vu in a few weeks due to the Bitlicense bullshit.  But I digress.

Ladies and gentlemen -- earlier this week you saw how to *not* have your business closed down (US Marshals and FTC swarming the place, as the entire community cheered them on!).  Now witness a "graceful, orderly shutdown."  Back to you, Eleuthria...

15  Bitcoin / Hardware / Re: 【ACTIVE】AntMiner S2 Tech Support- 4300 units powering a stable 4Peta GHS on: September 07, 2014, 01:54:35 AM
Congratulations! You've just discovered complimentary HASH RATE!


Worth a shot  ;) PM Sent.

Yeah, I'd might as well join the Stampede To The Promised Land Of Thus Far Unseen Hashrate, too. :)
16  Bitcoin / Hardware / Re: Announcement: Bitmain launches AntMiner solution, 0.68 J/GH on chip on: June 30, 2014, 06:04:27 PM
Order expired despite having sent funds to Bitmain address on order. Can someone at Bitmain look into this for me?

Same thing happened with my order.  This happened fairly often 6 months ago or so.  You would hear people mention/complain about it fairly regularly.  Has something to do with the Blockchain API. 

I *thought* they fixed it, or at least, I thought they updated the site so if you had at least *one* confirmation on the blockchain before your "hour deadline" was up, the system gave you more time instead of demanding 6 confirms in an hour...or whatever...but yeah, the problem appears to be back at a particularly unfortunate time.

Anyway, like I said, you're not alone -- I ran into the same problem.  In my case, I got 6 confirmations in about 50 minutes; but the Bitmain website still moved me to "paid/expired" anyway, so I don't know *what* the threshold is at this point.  But in the past, Bitmain always was good about fixing this -- just PM him and email webmaster@bitmaintech.com or info@bitmaintech.com and tell them your order and transaction ID.  This is the first time I've had this problem actually affect me personally, but I've seen it happen to more than enough people to not start panicking quite yet. Smiley

Also remember that it's 01:58 in China right now, so you need to give Bitmain a few more hours to wake up and read/reply to all the PMs and emails.  Sometimes it helps to post your order in the thread; so I guess we'd might as well do that part so the Bitmain rep can let us know we're confirmed/okay when they get back online.

Bitmain: Can you please confirm my "expired/paid/valid/invalid" order #00120140630135825601wjzCCJF50696 (see my PM for transaction ID and other details) is okay and still scheduled to ship with everyone else's? Thanks!
17  Bitcoin / Hardware / Re: [Guide] Dogie's Comprehensive Bitmain AntMiner S2 Setup [HD] on: May 16, 2014, 02:51:44 PM
I hope that gets you started, freebit13.  If it's not obvious, you can use different values other than "50/50/0" for the quota -- anything like "25/25/50" works too.  And it doesn't even need to add up to 100%; I just do that because it's easier for my feeble brain to keep up with the math.  (Again, see the cgminer README file for explicit instructions on how this is supposed to be done -- but if you're anything like me, what you *really* needed was an example showing you a version that actually works...so here you go!)  Good luck and let me know if you run into problems; I cut and pasted most of the above, so I don't *think* there are any typos, but obviously you should back up your old config file just in case.  

Hope that helps!
Thanks for the tips InvalidSnack, it's helped me learn a few things, but I can't get my S2 to work with your code, it just seems to erase the url from the Miner Configuration in the GUI. I've tried a few other things to no avail, but I'll have a look at this on the weekend when I have a bit more time.

Oh, yeah, I'm pretty sure the Miner Config page is hard coded to expect certain types of values -- and if it doesn't see them, it resets them or erases them or whatever.  I don't use the GUI all that much (just the status page sometimes to check on the "oooooo" status of the chips) but I remember people with custom configs on the S1 (eg, with more than 3 pools set up -- when there was only room for 3 to display on the GUI web form) would run into lockups or various problems as the GUI tried to deal with all the extra data that it didn't think ought to be there...

So your problem might be that the GUI is screwing with your config when you try to look at it to "confirm" your config is working.  It probably doesn't expect to see any weird ass "number-then-a-semicolon-then-a-url" shenanigans in the "url" field...  Oh, and actually now that I think about it, we are REMOVING the url field and replacing it with a quota field so I can imagine the web form *might* be assuming we left those values blank or that the file is corrupt ...or whatever random assumption it might make, it seems safe to assume it's probably not all that great for what we're trying to do. :)

Instead, try setting up your configuration file (per my previous post), restart cgminer (/etc/init.d/cgminer restart or it might be /etc/init.d/cgminer.sh restart sorry not in front of the machine right now so I can't check) while you're still logged in via SSH.  It will reload your config file and should start hashing again -- but without a reboot, and without having to go click anything on the web form...so we can eliminate those two possible variables for the time being.  That way you can at least confirm you don't have a typo in the config file, or something along those lines.

So long as you keep your changes confined within the /config directory, it should survive any reboots, because that's the only directory that actually persists between sessions.  Try it one more time, and (instead of rebooting) restart cgminer, then once you see the box is hashing again (flashing green lights) enter the following:
Code:
screen -r
That should reconnect you to the screen session and you should be able to diagnose any problems from there....assuming you've used cgminer in other situations and you know what it "ought to look like" (otherwise it'll be no more or less confusing than anything else!).  For reference, here is a shot of what mine looks like when I issue the command above.  I'm leaving out the unimportant "job xxx accepted" crap, yours will have all kinds of extra data too.  We're just focusing on the top third of the screen:

Code:
cgminer version 3.12.0 - Started: [2014-05-16 05:03:15]
--------------------------------------------------------------------------------
 (5s):1.049T (avg):1.014Th/s | A:7141632  R:20224  HW:18260  WU:14170.5/m
 ST: 252  SS: 0  NB: 65  LW: 8516915  GF: 106  RF: 0
 Connected to multiple pools with block change notify
 Block: 1da7dd6c...  Diff:8.85G  Started: [13:31:22]  Best share: 0
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 BTM 0: 45/ 52C 2040R | 1.120T/1.014Th/s | A:7141888 R:20480 HW:18260 WU:14174.3/m
--------------------------------------------------------------------------------

The first thing to look for is on the 5th line from the top, where it says "Connected to multiple pools with block change notify."  If you don't see that, then you have a typo in your config somewhere (perhaps you're still using "url" and not "quota" lines in the pool definition section?) or you failed to add "load-balance" : true, to the file.  

Alternatively,

Note this is different from just setting "balance" : true -- which is what you were doing in your previous post.  If you just want 50/50 load balancing and you don't care about telling cgminer how much quota to give a particular pool, then you can actually just do things a bit easier -- take your original code (no "quota" lines or whatnot) and simply add "balance" : true, to your configuration file.  There should be zero difference in doing that -- vs changing the init.d script to include --balance in the cgminer commandline.


Anyway, if you don't have load-balance or balance set in your config file, then that line I referenced above will say something akin to "Connected via Stratum to stratum.btcguild.com:3333 with diff 512..."  

Assuming you *do* see the lines about "connected to multiple pools" then you can hit the 'P' key (for some reason I had to hit it five or six times before cgminer actually showed me the menu -- so don't worry if it is sluggish to appear) and you should see something like the following, but with your pool data of course:

Code:
 cgminer version 3.12.0 - Started: [2014-05-16 05:03:15]
--------------------------------------------------------------------------------
 (5s):1.068T (avg):1.014Th/s | A:7244800  R:21248  HW:18531  WU:14171.2/m
 ST: 309  SS: 0  NB: 66  LW: 8680461  GF: 108  RF: 1
 Connected to multiple pools with block change notify
 Block: 3f8d1861...  Diff:8.85G  Started: [13:36:41]  Best share: 0
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 BTM 0: 46/ 52C 2040R | 1.045T/1.014Th/s | A:7244800 R:21248 HW:18531 WU:14171.2/m
--------------------------------------------------------------------------------
0: Enabled Alive Quota 50 Prio 0: stratum+tcp://stratum.btcguild.com:3333  User:SomeUsername_SomeWorker
1: Enabled Alive Quota 50 Prio 1: stratum+tcp://us1.ghash.io:3333  User:SomeUsername.SomeWorker
2: Enabled Alive Quota 0 Prio 2: stratum+tcp://uk1.ghash.io:3333  User:SomeUsername.SomeWorker

Current pool management strategy: Load Balance
[F]ailover only disabled
Pool [A]dd [R]emove [D]isable [E]nable [Q]uota change
[C]hange management strategy [S]witch pool [I]nformation
Or press any other key to continue

Again, refer back to my first post (1 or 2 pages ago) to see the config file that corresponds to this screen.  But you'll note that the numbered list shows that pool 0 and pool 1 both have a quota of 50, while pool 2 has a quota of 0 (failover only).  Also, here is a good place to confirm that your config file has no typos -- note that the 5th line from the bottom says "Current pool management strategy: Load Balance."   So that shows my cgminer.conf file is indeed set up for load-balance and is working fine...and this is fresh from a reboot (well, fresh as in "I rebooted late last night") to make sure I wasn't leading you astray about the file persisting across sessions/reboots.  

Note that (4th line from the bottom) it says: "[F]ailover only disabled."  That's the way it should look (if you're unfamiliar with cgminer -- if not, then I apologize for what probably seems like I'm talking down to you -- certainly not my intent!) and if it doesn't look that way, make sure your config file doesn't have any additional parameters that could be screwing with stuff -- eg, I have no clue what "failover-only" : true, would do if combined with "load-balance" : true, in the conf file, but it seems safe to assume one of them would "overrule" the other.  Or at least confuse things!

(Obviously if you decide to use regular "balance" instead of "load-balance" as your management strategy, then the line 5th from the bottom would say "balance" and you wouldn't see all that quota crap in the numbered list of pools.)

Now -- again, apologies if you know all this already -- if you're ready to get the hell out of that screen, or anything running under a GNU screen session for that matter, you hold the control key and press A...then you release both keys...and then you hit 'D'.  So "Ctrl+A, D."  [spoiler]lol, I tend to catch myself thinking "And...Disconnect" so I guess that's how I tend to remember that combo.  Fans of Emacs will remember that combo because they use that, plus tons of other similar combos, all the time.  Fans of vi will think that's crazy, why not just type "Escape, colon, q, exclamation point, enter" -- something intuitive like that?! :)   Fans of sanity will think both of these hypothetical guys are crazy...but they'll also be wise enough to never say such heresy out loud![/spoiler]

If you disconnected from the screen session successfully, you'll find yourself dumped back at a normal/familiar root@s20~# prompt, at which point it's safe to exit...assuming things are working okay.

Now, if they *are* working okay, you can experiment to see if it's really the GUI that is mucking up your config file.  First, make a copy of your (currently functional) cgminer configuration file:
Code:
/tmp$ ssh s20
root@s20:~# screen -r
[detached]
root@s20:~# cp /config/cgminer.conf /config/cgminer.conf.WorkingLoadBalance.sillyLongFilename.bak
/tmp$
Now load up the web GUI, just cruise over to the page and view the page.  (Don't change anything, and certainly don't *apply* anything from the cgminer config page on the website -- if you did that before, then that's probably what wiped out your load-balance config and replaced it with a standard failover setup.)  Does it look okay?  Broken?  Same as before?  

Alt+Tab over to your ssh window and type
Code:
root@s20:~# cat /config/cgminer.conf 
...and see if the file has changed.  If you're unsure, check the last time the file was modified:

Code:
root@s20:~# ls -Flash /config/cgminer.conf
     4 -r--------    1 root     root         538 May 14 06:01 /config/cgminer.conf
root@s20:~# date
Fri May 16 14:03:04 UTC 2014

Note that the clock is running on UTC time by default, so it might be worthwhile to check the current time as I did, just to make sure you're not comparing apples and oranges.  So if you look at the stuff above, you can see that the last edit to my config file was roughly a day and a half ago...so it definitely persisted through the reboot yesterday.  But more importantly, you can see that nothing has gone behind my back and changed it AGAIN since I edited it....however, I didn't go mess with the web GUI, since I don't use it to set up configuration stuff (it's easier for me to just scp over known-good config files that I've saved from another system, or edit the image when I first prepare the sdcard for the S2...plus you never know what kind of weird stuff the GUI might overwrite) and I don't have immediate access to the system right now so I didn't want to (potentially) do whatever it is you're doing and reset my own file, because that would be annoying. :)

I'm pretty sure you can use the "Status" screen all you want in the GUI.  It's the "Miner Setup" page that has the potential to screw with your configuration file, I *think*.  So none of this prevents you from using that to monitor your system, if that's how you roll.  Note however that you can use other methods (from the command line while logged in via ssh, or even via your local machine if you have the API set up correctly) to check your work.  So, one final example before I go -- and let's hope *some* of this helped you, since apparently my last message failed to do anything but annoy and frustrate you further!  Kind of like going "hey look at what I can do...hahahahaha...this is what it looks like when your settings persist!"  But I assure you that wasn't my intention! :)

When you think you have load-balance working and you want to check from the command line, enter the following, and then use enter or spacebar to page through the results.  I'm doing this via ssh on to the S2, but you can also do this remotely if your API is set up correctly -- which I will leave as an exercise to the reader.
However, I won't leave curious parties *completely* in the dark; head over to cgminer's github page and check out the API-README file for more info on this particular topic.
 
The command is:
Code:
cgminer-api pools|less

As you page through the info that is displayed, you should see all the stuff we set up in the configuration file -- there should be at least two pools (or three, depending on your configuration setup.  I suppose there could be *one* but load-balancing *one* pool server would be...a questionable use of one's time.), zero indexed, so you'll see info for POOL0, POOL1 and so on.  The main thing to look for here is -- assuming you just restarted cgminer a few minutes ago -- are your (different, load-balanced) pools each completing work successfully, or are you (mostly) still just submitting work to POOL0?  

You can also see (if your config file is setup correctly) there will be entries like [QUOTA] => 50, showing that your quota setup in the config file is being applied correctly.  But mostly if you see that POOL0 and POOL1 have approximately their "fair share" of work listed under their [Difficulty Accepted] => xxyy sections, then you can rest easy that things are working properly.  (Double check by going to your pool's site -- eg, btcguild or wherever -- and make sure that it is estimating your hash speed to be somewhere in the neighborhood of what it *should* be getting.  Obviously the pool's estimate is an approximation -- but if something is really screwed up (say your rejected shares are really high on one pool only, due to using the wrong username or something like that) it's possible for cgminer and the GUI to show that you're happily hashing away at 1015Gh/s ...even though as far as the pool is concerned, you're doing *nothing* or very little!  I know that seems obvious, but when I was experimenting around with some of the settings a few days ago, I managed to find a terribly unfortunate combination of config options that resulted in BTCGuild rejecting the vast majority of my shares, while the GUI and API and cgminer ncurses display all implied I was hashing just fine.  It wasn't until I checked and noticed that the *pool* thought i was running around 50 GH/s (and not 500GH/s) that I realized I had "load balanced" myself in such a way that half of my hashrate was going to one pool...and the other half was going down the drain!  

But, oops, I digress.  Again.  (Because it's what I do.)

But, freebit13, I sincerely hope this helps you troubleshoot your "mysterious resetting issue" and I really am sorry that my earlier effort led you down the path of "lots of time invested, with zero return!" :)  Hopefully we can get this figured out for you...since (as i mentioned in the previous post) I was hunting around for info on this exact same thing a few days ago, so I assume there are others who will want to do it, too.  And since everyone knows "Dogie's Comprehensive(TM) is the most trusted brand of forum-based documentation for ASIC configuration," I'm sure some of them will come to this thread...
...and 500 pages from now, we'll be glad we figured this out...otherwise how will we be able to (honestly) act all self-righteous when we instruct people to "learn to use the search button" after the 60th post asking us "How do I set up load-balance on my S2? I don't have time to read any of this thread, it is too long, please hold my hand and type the commands for me? I have the Teamviewer thing, that makes you fix it for me right?  Damnit, I paid good money for this equipment, now one of you members of the community needs to quit bitching about how entitled I'm acting and come fix my hardware for free, goddamnit!  (BTW, send tips to ...)"   :)  

But I'm kidding of course.  Nobody would act that way around here...this is an internet forum, for chrissakes!  Never will you find a more appropriate and reasonable crowd of calm, rational individuals, than when you make them all anonymous, set the topic to 'technology+finance' and then allow them to ask each other for help.  What could go wrong!?  :)  
[/color]


edit: PS, this *might* not be strictly relevant, freebit13, but if you continue to have trouble duplicating (on your box) the setup I have working on mine, it might be useful to know some info about your setup, eg: What batch S2 do you have, is it the stock SD card or did you upgrade it to a Class 10, what firmware are you running, do you have a sister and is she single and if not does she have any hot friends?  (You know, standard "background" stuff.  it's important for the whole "troubleshooting" process.)  

Because when you post a question on Dogie's Comprehensive(TM) you know you can expect thoroughness ... even (and perhaps especially) if we don't actually solve your question or help you at all.  Which, I guess, so far would be the case here...um...I guess I will hit submit and hope things go better this time! Good luck!
18  Bitcoin / Hardware / Re: [Guide] Dogie's Comprehensive Bitmain AntMiner S2 Setup [HD] on: May 15, 2014, 06:43:45 PM
If anyone is interested in load-balancing their machine or adding any other cgminer parameters, here's how to do it:

ssh into your S2 with putty or similar software (root,admin)
...

Unfortunately, a reboot will set this all back to the default, so if anyone knows how to actually save any of the settings changed, please let me know.

I was actually trying to figure this out a couple of days ago and ran into the same problem you did.  We were both trying to modify the /etc/init.d/cgminer startup script; it's just a bad habit we picked up from modifying our S1s.  (By "bad habit," I mean we learned to do it that way because the S1 used a non-standard configuration file for cgminer -- so we couldn't just plug the values into the conf file without hacking around in init.d first.)  

I don't follow (at all) why Bitmain decided to "lock down" the S2 so much, making so much stuff reset automatically -- it seems like they went out of their way to make this thing difficult to customize for my tastes.   For example, on all my S1s, I used to have a couple of scripts installed locally to grab quick values from the API I was frequently looking for...and I had a couple of (very simple) cron jobs that ran twice a day, nothing earth shatteringly impressive -- but at least I could put a damned script file in my path, and modify my .profile, and at least cron was INSTALLED.  (And speaking of installation -- I will always have a fondness in my heart for vi, since that's what I first learned to use on the first UNIX-based system I ever came in contact with.  But nano is easier; and on the S1 it could easily be installed from the GUI.  I haven't really bothered to try to figure out how to install nano via opkg -- because I assume the damned thing would just lose any changes on reboot anyway.)

And what about my damned ssh pubkeys?  Every time that stupid thing reboots I have to ssh-copy-id my pubkey over *again*....unless I want to type the password every time I log in to do anything...which is annoying because (as anyone reading this has figured out) it would seem I am lazy as fuck. :)

*ahem*  but I digress.

Fortunately, the "how do I load balance" question is easier than you think -- because the  S2 (as far as I can tell) uses a standard cgminer.conf file structure in the /config/cgminer.conf file.  If you type
Code:
 ps www
you'll see that cgminer is loading directly from that file, so if you cruise over to the cgminer thread in this forum, or grab a copy of the README from github, you can see all the myriad options available...  almost any option you *could* put in the cgminer commandline can be placed in the JSON-formatted cgminer.conf file (located in /config/)...including those needed for load balancing.

Okay okay, enough prefacing.  Here's a practical (working) example taken from my S2.  First, let's look at the original (NON-LOAD-BALANCED) cgminer.conf file, which is just the original one that shipped with the machine (edited with my pool info, etc):

Code:
/tmp $ ssh s2
root@s20:~# cd /config
root@s20:/config# ls
asic-freq.config               dropbear                network.conf
dropbear_rsa_host_key   shadow                  cgminer.conf
lighttpd-htdigest.user      cgminer.conf.bak    lost+found
root@s20:/config# cat cgminer.conf.bak
{
"pools" : [
{
"url" : "stratum+tcp://stratum.btcguild.com:3333",
"user" : "sampleUsername_SampleWorker",
"pass" : "x"
},
{
"url" : "stratum+tcp://us1.ghash.io:3333",
"user" : "sampleUsername.SampleWorker",
"pass" : "x"
},
{
"url" : "stratum+tcp://uk1.ghash.io:3333",
"user" : "sampleUsername.SampleWorker",
"pass" : "x"
}
]
,
"api-listen" : true,
"api-network" : true,
"api-allow" : "W:127.0.0.1,W:192.168.1/24",
"bitmainbeeper" : true,
"bitmaintempoverctrl" : true
}
root@s20:/config#


Okay, so nothing special -- other than the mining pool details and the changes I made to the "api-allow" line so my monitoring script could reach/query the thing, that's pretty much stock.

If you want to modify this to work in load-balance mode, per the cgminer README, you'll need to do the following:
  • Add the parameter "load-balance" : true, to the conf file
  • Change all the "url" lines (under the "pools" section) to "quota" lines, and modify the URL string so it contains the percentage of time you want the system to devote to each pool, then a semicolon, then the URL, like this: "quota" : "50;stratum+tcp://stratum.btcguild.com:3333",
  • Look at the example below, since this explanation probably doesn't make any sense at all (but once you see an example you'll realize it's easy and you'll have yours up and running in a couple of minutes, tops).


So let's head back and look at my current (load balanced) file -- compare it with the one listed above, and you should be able to apply the same differences to yours with no problems.  Note that I just want to split my S2's time between two pools -- so the third pool gets a quota of "0."  That doesn't disable the third pool; it just sets it to be a backup/failover pool:

Code:
root@s20:/config# cat cgminer.conf
{
"pools" : [
{
"quota" : "50;stratum+tcp://stratum.btcguild.com:3333",
"user" : "sampleUsername_SampleWorker",
"pass" : "x"
},
{
"quota" : "50;stratum+tcp://us1.ghash.io:3333",
"user" : "sampleUsername.SampleWorker",
"pass" : "x"
},
{
"quota" : "0;stratum+tcp://uk1.ghash.io:3333",
"user" : "sampleUsername.SampleWorker",
"pass" : "x"
}
]
,
"api-listen" : true,
"api-network" : true,
"api-allow" : "W:127.0.0.1,W:192.168.1/24",
"bitmainbeeper" : true,
"bitmaintempoverctrl" : true,
"load-balance" : true
}
root@s20:/config#


Now, if anyone out there knows anything about Dropbear -- I'm assuming the reason the dropbear config file is in /config (and thus will exist across reboots) is that there must be a way to tell the ssh daemon "authenticate using the ssh keys located in /config/authorized_keys , instead of the default, because I would like to quit copying them over every time I issue a shutdown or reboot command!"  I'm assuming there must be a way to say that in the /config/dropbear file, I just haven't had the time to go look up all the various dropbear options...so if anyone knows how to do this off the top of their head, please share!


(Or for that matter, if anyone knows how to make a larger portion of the S2's filesystem "persistent" without having to go through the trouble of writing a custom firmware for it -- that would be GREATLY appreciated.  Because I would like to be able to update cgminer (and other files) when/if Kano starts releasing updated binaries for this platform, as he did with the S1.  And I would like to install cron...and nano...and "whatever I damned well please" because surely the BeagleBone supports this kind of "crazy advanced behavior" ...right?  Right?  Anyone?  I admit I know next to nothing about modifying firmware images ...this seems like *such* a step backwards from the way the S1s were setup, I wonder why?  Okay, diatribe over.  For now...!)


I hope that gets you started, freebit13.  If it's not obvious, you can use different values other than "50/50/0" for the quota -- anything like "25/25/50" works too.  And it doesn't even need to add up to 100%; I just do that because it's easier for my feeble brain to keep up with the math.  (Again, see the cgminer README file for explicit instructions on how this is supposed to be done -- but if you're anything like me, what you *really* needed was an example showing you a version that actually works...so here you go!)  Good luck and let me know if you run into problems; I cut and pasted most of the above, so I don't *think* there are any typos, but obviously you should back up your old config file just in case.  

Hope that helps!
19  Other / Off-topic / Re: what should I wear to work in the server room on: April 25, 2014, 06:58:11 PM
My server room is very hot, 99 degree F.  Can I work in the server room naked or is there a cool suit for me?

Like Dogie, I'm not sure if this was a serious question or not -- but just in case it was:

Background:

I have a family member with a medical condition (which I won't try to remember how to spell) that basically amounts to "his brain doesn't regulate his body's temperature very well."  So he has to be very careful about getting heat stroke, dehydration, stuff like that.  He described it to me saying it was basically like he's just missing the part of his brain that normally would tell us: "Hey, we're thirsty, go drink some water!" or "Okay, this room is REALLY hot, we need to sweat more and drop our blood pressure and try to cool off."  It's apparently a pretty serious condition; I've seen him at holidays playing basketball, looking normal one minute...and then a half hour later he looked like he was on the verge of death or something.  Fortunately he has a very loving wife who he asks to "keep an eye on him" at times like this...but...scary, you know?

So I'm probably more likely than others to take this question seriously, since I know there could be a serious reason you're asking it -- and since he works on old cars, he runs into this problem sometimes working in his garage during the hot summer months.  And so he started looking for exactly what gallery2000 called it "a cool suit."  And that's actually what it was called, I think -- maybe it might be "cooling suits," but it's the same kind of language.  Basically it is just a special kind of fiber that has a couple different layers and it's supposed to aid in evaporation and make sweating "more efficient" in cooling you off.  He used to have to order that stuff off the Internet, and it came in like 2 colors, lol, and it never really fit right, and was expensive as all hell.


Fortunately, you've probably *seen* this kind of material in the past and not even realized it--because in recent years it's being used for football (both the international and US version), basketball, and other sports...and particularly for runners/joggers.   You don't have to buy it online anymore, and it's not expensive at all.  I actually saw a sale at Wal-mart maybe 6 months ago and we grabbed a few shirts/shorts for him because it was maybe $9.99 for each; they just called it some dumb name like "High Tech Activewear" or whatever, but the smaller print on the tag said it "aided in the body's natural cooling" and blah blah blah, I think I'm probably going *way* too much in detail and answering WAY more than you actually needed, because the part inside my brain that should say "Shut up you're talking too much" apparently doesn't regulate my rate of speech very well. :)

tl;dr:  They sell it everywhere now, it's not very expensive; I know Target and Walmart carry it in the men's activewear/sportswear sections; it looks like anything else but if you feel it you'll be able to tell it's 2 layers of very, very fine mesh material.  Also, you can look at the label and see what materials are used:  normally I wouldn't want to work out in something made of polyester or other artificial materials, since they tend to get very hot...but this stuff will feel very cool to the touch and be made of *entirely* artificial stuff, no cotton or anything like that.  (I think it was like 30% nylon, 30% polyester, 20% rayon, 20% lycra ... some crazy combo of stuff you'd normally not want to wear in hot weather.)  The brand I've seen sold at Wal-mart and Target was "Under Armour," if you're having trouble finding it.

So if this wasn't a joke, and you actually wanted some info, then there you go.  If it was a joke, then...there you go, anyway.   :)

Someone insert that GI-JOE "Knowing is half the battle" youtube clip here, please and thank you...and I believe our work here is finished. :)
20  Bitcoin / Hardware / Re: AntMiner S2 1TH/s Miner (1w/GH/s) on: April 17, 2014, 05:35:02 PM
Question for people with Batch 2 units: 

{{Edit: Turns out this is not a question so much as a series of questions, statements, and then a vague request for your input near the end.  Just fyi.}}

Earlier in the thread it seems like a lot of Batch 1 owners were reporting issues with the unit losing all (or some) config data upon reboot.  (I think the gist was that some people just had EVERYTHING overwritten/reset, and others were just losing specific parts of their customizations, like IPs and changes to initscripts or passwords, etc.)  Are Batch 2 units showing this same problem?  If not, then do we know if that's because the new firmware fixed the problem...or if it's just magic...or if it's just that not enough Batch 2 units are out there yet to know for sure?


The reason I ask, is I was looking at the Beagle Bone Black (the embedded device that's always exactly 1 slip of the tongue away from like, 3-4 different probable titles for porn films, but I digress) wiki and I found something that *might* be germane to the discussion:

Quote
Known Issues / Software
1) The microSD card cannot be used as a storage device when booting from microSD in the 3.8 kernel.
...

I don't have one of these in front of me to toy with, but going by what others were saying I got the impression that the -- how should I phrase this -- "the cost-reduced, simplified BBB version" being used by Bitmain in the S2 units lacks any eMMC/internal memory...so it doesn't have any choice but to boot off the SD card each time...so if it's running the 3.8 kernel, could this be the reason why people are having trouble getting certain changes to "stick?"

Just an educated guess, here, but following the same logic -- could this also explain perhaps why a number of people have reported success fixing various problems, by replacing the (Bitmain) S2 BBB with their own spare/OEM/Official version --  ie, one that has all the parts one would expect a BBB to have, including internal memory...?   

Apologies if this is just way off course and not useful to anyone troubleshooting the matter; I was just trying to "think aloud" on what might or might not be causing that issue...  Perhaps replacing the cheaper/stock BBB with a standard/OEM BBB might be a potential "upgrade" worth considering for people with special needs, like those who *know* they are going to run stuff on a different subnet and use SSH keys and ...I don't know, need the system to play Ms Pac Man on the display or something. :)

And I think I just realized -- there are either 8 questions in there, or none...  Not quite the "one question for Batch 2 owners" that I advertised above.  Sorry about that...  Need more caffeine, talking a bit too much in "stream of consciousness" format, I'm afraid!

So I'll cheat and use the generic question: 

          "So, Batch 2 owners:  Any thoughts regarding any of this?" 

haha, there, I've condensed everything to one question vague enough that anyone can "interpret it for themselves" and answer it in some form or fashion.  :)



PS,  just so this post adds some actual 'value' to the discussion instead of just vague questions about things I may or may not actually know anything about, for the people discussing the SD card image and its filesystem/partition structure (around 5-8 posts ago), here's the breakdown/sizes of the 3 partitions (with thanks to the kind individual who provided the image):

Code:
/tmp$ file bitmain.img

bitmain.img: x86 boot sector; partition 1: ID=0xc, active, starthead 1, startsector 63, 144522 sectors; partition 2: ID=0xc, starthead 0, startsector 160650, 144585 sectors; partition 3: ID=0x83, starthead 0, startsector 305235, 3534300 sectors, code offset 0x0

/tmp$ fdisk bitmain.img

Command (m for help): p

Disk bitmain.img: 1965 MB, 1965841920 bytes
255 heads, 63 sectors/track, 239 cylinders, total 3839535 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

      Device Boot      Start         End      Blocks   Id  System
bitmain.img1   *          63      144584       72261    c  W95 FAT32 (LBA)
bitmain.img2          160650      305234       72292+   c  W95 FAT32 (LBA)
bitmain.img3          305235     3839534     1767150   83  Linux

/tmp$ cfdisk bitmain.img

                                                  cfdisk (util-linux 2.20.1)

                                                       Disk Drive: bitmain.img
                                                   Size: 1965841920 bytes, 1965 MB
                                         Heads: 255   Sectors per Track: 63   Cylinders: 239

      Name                Flags              Part Type         FS Type                     [Label]                 Size (MB)
 ------------------------------------------------------------------------------------------------------------------------------------
      bitmain.img1        Boot                Primary          vfat                        [BtmBoot]                   74.03         
                                              Pri/Log          Free Space                                               8.23
      bitmain.img2                            Primary          vfat                        [BtmBootBak]                74.03
      bitmain.img3                            Primary          ext4                        [Config]                  1809.57


Partition Table for bitmain.img

         ---Starting----      ----Ending-----    Start     Number of
 # Flags Head Sect  Cyl   ID  Head Sect  Cyl     Sector    Sectors
-- ----- ---- ---- ----- ---- ---- ---- ----- ----------- -----------
 1  0x80    1    1     0 0x0C  254   63     8          63      144522
 2  0x00    0    1    10 0x0C  254   63    18      160650      144585
 3  0x00    0    1    19 0x83  254   63   238      305235     3534300
 4  0x00    0    0     0 0x00    0    0     0           0           0



Anyway, ... for those who were asking what sizes and how many partitions to look for on their SD cards, ... um...there you go!

Note, for your convenience, all readers and posters to this thread have automatically been invoiced for the 407 hours it took me to generate the data, above.  You're welcome.  And no worries: I bill out WELL BELOW any competitor's price (at a mere $49.9999998051 an hour) so I'm basically just giving it all way for free, you lucky freeloading helpful-as-hell community of bastards! :)
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!