What do you think?
Did I find a bug?
So I was thinking about getting a UPS protector for my RPI & computer system.
Now If I have a UPS on my computer system & monitor, linksys hub, RPI, usb hub and gridseed/gridseeds. Not on the router.
So I did an example of a power outage. Left my system and everything above mentioned on as if they were on a UPS.
So I pulled the uplink cat5E out of my linksyshub as example if power went out all over the house where there is no protection, but only protection is my setup.
Now, by doing this, I can connect to minera browser based welcome screen with the digital time, but I try to log in nothing happens, I keep getting loading circle in my tab.
Now, the ip is already assigned to the RPI & minera, I can connect to the welcome screen but why not login?
Do a test yourself, you should find the same results.
For this reason, I did this test is, If I had a power outage, the UPS would give me enough time to login to Minera to correctly shutdown, so sd corruption does not happen.
Is this a bug that I found that is in bold letter?
I am thinking it won't allow me to login, because the system is under hard load maybe trying to identify network or something?
Can you SSH into it? Try a different browser? I suspect that what you are seeing is actually the cached login page of minera and your miner either has a new ip or no connectivity. Just a hunch. |
|
|
|
Any chance of someone compiling a RasPi binary of the custom CGminer  ? I know it should be easy but my skills in this area are lacking. |
|
|
|
Is there any way to manually edit the json?
I don't know if you can within the environment, but there's always SFTP :-P |
|
|
|
Yes, now you can connect your Minera system to the awesome MobileMiner app! (still in beta and only to collect data, no remote commands, they will be added next releases). Awesome - you guys rock! Thanks for your support Very Rad. Now I can ditch my third-party uptime monitoring in favor of mobileminer's alerts. I have it set up so that: Downtime Alert Email->Labeled by filter in gmail->IFTTT rule for Label->Power Cycle WeMo outlet This way if the system goes down and I'm asleep or unavailable the whole rig power cycles itself! |
|
|
|
Can you see the legend below the table? "Colours based on last share time: <green> Good <yellow> Warning <red> Critical <gray> Possibly dead" I have a suggestion for a future version: The colors seem based on a static expected share time, but for instance, clevermining has me at 230diff with 5x 5chip units and in this case 120 seconds isn't unheard of between shares. I wonder if there's a way to make the thresholds for these color codes somewhat dynamic based on current difficulty? Unrelated question - should I be worried about debug-level logging filling up the disk? I have it turned on because I was having stability issues - (The web server was turning up 404's, even on the lighttpd default page, weird right?) - It's running stably now for over a day but I'm worried about the debug level logs getting huge. Do they rotate? |
|
|
|
Considering the amount of money invested and the number of people involved, I would think that folks should actively try and track down who is behind this now while they are still on the radar. Because once they do vanish, threads like this will be filled with folks asking how to get ahold of them. And there is just one foreign Ebay account to work through, which is likely a dead-end.
Nah they fucked up. I have the doxx on PBMining. I would publish it but I'd rather wait til all the PBMining disciples who called me asshole/scammer/jealous are desperate when their money disappears and beg me for it..... I am the person who exposed one of the largest btc scammers to date..i've doxxed multiple scammers, I love doing it I know who PBMining is. You can quote ths if you want. They made a DPR style mistake....lol Do you have proof it's a scam though? I've ROI'd. Even if they disappeared I wouldn't be begging for the dox. But I'm curious. |
|
|
|
read the following sentence. "Small balances are payed out weekly, on sundays."
I missed that then. Thought when I first joined it was just weekly. My fault for not reading clearly. All good...we all make mistakes..part of being human. Happy mining! Indeed, all good. Sorry if I was harsh. In other news - 6 hours, only 2 rejects. 0.1%. The new server seems awesome |
|
|
|
if it looks like a duck, etc... When I first looked at them, i thought "wow, what a great place to mine" but when I started to look into it, every red flag went up. They cant even show you that they are actually mining!!! This smells very very bad. If it seems too good to be true, it probably is.
The fact that they obscure the transactions by mixing was the big one for me. They claim that if they show you a tx of a newly generated block going to a certain address and signing a message from that address with compromise their security and privacy which is rather improbable claim. Really, all it seems is that it is a ponzi that using the mixing to hide this fact so they don't get called a scam from day one. I'll eat my shorts if they truly meet the five years they promise. I am going to hold you to this. If I get a payout five years from today I will send you a PM requesting a video of you eating your shorts. If you don't do it, then who is the scammer huh??? Anyway - There's no real evidence for this being a scam, there's not enough evidence for it being legit. The operator however is 5000x more traceable than the admin of any ponzi I've ever heard of though, and all I've been saying is "It has potential to be legitimate" and even that is distasteful to people. I bought 100gh in feb which have already ROI'd.  Terribly run for a scam if you ask me. I guess time will tell. I just wish people would shut up with the "OMG THIS LOOKS LIEK A SCAM" when they bring literally no new information or no new extrapolations or deductions to the table. |
|
|
|
Different rig than the one you're used to seeing me on(that one has actually shrunk a bit), I built out another farm and it runs on a different address. Just PMed it to you, but I have already switched back to EU(it's also leased right now, so it's not submitting shares). What was killing me was that I was monitoring individual blades locally, if they didn't submit a share for 240 seconds they got restarted(which makes sense at 512 diff) but when I was spiking up over 10000(at one point i saw 19000) my miner was just restarting my blades all the time, took a little while to figure out why my hashrate was all over the place.
I adjusted vardiff settings to consider longer time period. This should result in difficulty not jumping as low and high as previously. I didn't know you'd turned on vardiff, that took me by surprise.
I wasn't going to launch the new stratum server until the weekend but issues with servers this morning pushed me to do this. I was going to make a proper announcement, but yes: The new stratum server has vardiff working again. It's also much more efficient so it should result in much lower rejects ratio when mining fast coins (we already had low rejects when mining big coins, but our rejects when mining low difficulty coins were a bit higher than should be). This is a very optimised software and it should give us all great results. All your feedback about how it works is appreciated. Terk - This is working great. Before I had 5-10% rejects, now I'm at a steady 0%. With vardiff working again things are much more consistent as well. Kudos. You've got me back on your pool. Oic. May terk change that from weekly to every Sunday in the description  . Whether mining started on a saturday and anything @0.001BTC it get payed in one to two days? Weekly and sunday conflicts. Because I could start mining on a Thursday, thinking i have till Thursday to get payed "week" "7 days" not till sunday "3 days". As my coins been sitting for a "week "7 days" whether payout is sunday-monday or not, they are in there a week. It's no big deal but it's lieing. Not sure if trolling? Are you serious? Something that happens "Weekly" happens once a week, usually on a given day. For instance, my recycling is picked up weekly on friday mornings. Your saying that if I put out my recycling on friday afternoon and it sits there for a week until being picked up that I should call the city and complain about pickups not happening weekly? Weekly and every sunday do not conflict. For example, read the following sentence. "Small balances are payed out weekly, on sundays." There is no conflicting information there. Nobody is lying to you. |
|
|
|
|
IIRC the company mentioned they were also working on a "blade" model.
|
|
|
|
michelem, after auto update i also tried manual update
minera@minera /var/www/minera $ sudo git pull
Updating 1f5814f..727d1fa
error: Your local changes to the following files would be overwritten by merge:
conf/index.html
Please, commit your changes or stash them before you can merge.
Aborting
That is the error I got. For better or worse I just ran "sudo git stash" and then I was able to update manually. |
|
|
|
When I punch in the update manually it throws an error saying I had locally modified /conf/index.html (I hadn't) Anyway, did a git stash and then a git pull and it seems to have gone through. Worth noting the reboot page shows the following error: A PHP Error was encountered
Severity: Notice
Message: Undefined variable: onloadFunction
Filename: views/sysop.php
Line Number: 1 |
|
|
|
sure
I un-tick auto tune, keeo auto detect and -
copy this from Minera's saved frequencies--gc3355-freq=6D83117A4857:925:0,6D83117A4857:950:1,6D83117A4857:950:2,6D83117A4857:925:3,6D83117A4857:950:4,6D7514984857:950:0,6D7514984857:950:1,6D7514984857:925:2,6D7514984857:950:3,6D7514984857:950:4,6D7530A64857:900:0,6D7530A64857:925:1,6D7530A64857:950:2,6D7530A64857:950:3,6D7530A64857:950:4,6D7F1F8B5148:1200:0,6D7F1F8B5148:1200:1,6D7F1F8B5148:1200:2,6D7F1F8B5148:1200:3,6D7F1F8B5148:1225:4,6D74265F5148:950:0,6D74265F5148:950:1,6D74265F5148:950:2,6D74265F5148:950:3,6D74265F5148:1000:4,6D8716905650:950:0,6D8716905650:950:1,6D8716905650:975:2,6D8716905650:1000:3,6D8716905650:1025:4,8D74205B5654:950:0,8D74205B5654:925:1,8D74205B5654:925:2,8D74205B5654:950:3,8D74205B5654:900:4,6D6F11924857:925:0,6D6F11924857:950:1,6D6F11924857:950:2,6D6F11924857:925:3,6D6F11924857:950:4,8D7747694849:1000:0,8D7747694849:950:1,8D7747694849:950:2,8D7747694849:1000:3,8D7747694849:950:4,8D9717784849:950:0,8D9717784849:950:1,8D9717784849:950:2,8D9717784849:950:3,8D9717784849:925:4,6D81348C5157:1225:0,6D81348C5157:1225:1,6D81348C5157:1225:2,6D81348C5157:1225:3,6D81348C5157:1250:4,6D7D178D5148:1150:0,6D7D178D5148:1175:1,6D7D178D5148:1175:2,6D7D178D5148:1200:3,6D7D178D5148:1175:4,6D9113A05455:1200:0,6D9113A05455:1200:1,6D9113A05455:1200:2,6D9113A05455:1175:3,6D9113A05455:1200:4,6D741F944857:1200:0,6D741F944857:1250:1,6D741F944857:1200:2,6D741F944857:1225:3,6D741F944857:1225:4,6D6E17925148:1225:0,6D6E17925148:1200:1,6D6E17925148:1200:2,6D6E17925148:1175:3,6D6E17925148:1200:4,8D6F427D5654:1200:0,8D6F427D5654:1200:1,8D6F427D5654:1175:2,8D6F427D5654:1200:3,8D6F427D5654:1200:4,6D8843954857:1225:0,6D8843954857:1250:1,6D8843954857:1200:2,6D8843954857:1200:3,6D8843954857:1175:4,6D8A27914857:1225:0,6D8A27914857:1200:1,6D8A27914857:1200:2,6D8A27914857:1175:3,6D8A27914857:1200:4,6D6D1F984857:1175:0,6D6D1F984857:1250:1,6D6D1F984857:1225:2,6D6D1F984857:1200:3,6D6D1F984857:1225:4,6D7630584857:1175:0,6D7630584857:1175:1,6D7630584857:1200:2,6D7630584857:1200:3,6D7630584857:1200:4,6D912F675455:1225:0,6D912F675455:1200:1,6D912F675455:1225:2,6D912F675455:1200:3,6D912F675455:1200:4,6D78158B5355:1200:0,6D78158B5355:1225:1,6D78158B5355:1225:2,6D78158B5355:1250:3,6D78158B5355:1225:4,6D855F8F5650:1250:0,6D855F8F5650:1200:1,6D855F8F5650:1225:2,6D855F8F5650:1250:3,6D855F8F5650:1225:4
into extra options and then save and restart.
Ill note that I have this ame problem, albeit with only 3 miners. |
|
|
|
I'll say it again:
Replace The Backplane with Wires
As in 1 (one) SPI channel PER HASHBOARD going direct to a controller. I hope to god you didn't have all the hashboards sharing a common bus on the backplane before - because I can't imagine trying to get that to work.
Dear Jonny, The PCIE connector has 98 pins and there are 5 connectors in each case. If you still believe that this can be done even on one X3 (not to talk about mass production) you are welcome to come to our office and try to do this yourself. Regards! The PICE connector has 98 pins but many of them are bussed together for power. In the photos on your website I count 18 data pins on one side of the card and the rest - bussed together for power. An 18 conductor ribbon cable isn't that hard to come by, and then it would just be a matter of getting enough power to the board. I could be wrong - and I can't say I still believe this is possible because I don't have a full understanding of the PCB layout - only what I've seen in scattered photos. A few questions before I "book my ticket": 1) What is the pinout of the hashboard? 2) Does the board create 1 SPI link between the raspberry pi when it is working, or 2 (one for each chip)? 3) Does the backplane now bus together all the SPI links from the hashboards, or is there a single isolated link between each hashboard and the controller? 4) Does the SPI "Daisy Chain" - that is to say go from the first hashboard to the backplane and into the second hashboard then back out to the backplane so on and so forth. If so has the ability of the hashboard to support this daisy chain link been verified? I'm honestly trying to help, not trolling, and I'm a little dismayed by your dismissive response to my sincere suggestion - especially considering you guys openly asked for help. Oh, one more thing. Even if it was all 98 conductors active there are commercially available parts for that. http://www.frozencpu.com/products/20753/cab-1908/PCI-Express_PCI-E_x16_Extension_Cable_Riser_-_7.html |
|
|
|
That's just great. The second my deposit confirms: "NiceHash web frontend is currently down for maintenance. We expect to be back in a couple hours. Thanks for your patience. Stratum servers are not affected and are running as usual. "  |
|
|
|
"The issue is the SPI communication fails on the current backplane as soon as you attach more than 1 hashboard."
To put a finer point on it, from the article above (beginner's guide to SPI lol): SPI's full duplex communication capability and data rates (ranging up to several megabits per second) make it, in most cases, extremely simple and efficient for single master, single slave applications. On the other hand, it can be troublesome to implement for more than one slave, due to its lack of built-in addressing; and the complexity only grows as the number of slaves increases.
So, Black Arrow, as it appears your backplane did not adequately address the lack of an addressing mechanism (surprisingly, but that is water under the bridge .. though I think at least one engineer ought to walk the plank for that f-up)... It is impossible, even for a very sophisticated customer, to address the feasibility of your second option (getting hashing boards for a DIY solution) without some further information. To wit: (1) We need ALL technical specifications and interface protocols for the hashing board. Is SPI the only control mechanism? Can the boards be used with USB instead or would an SPI - USB bridge need to be implemented by us poor customers? (2) Are you supplying power through the backplane, or does each board (hopefully) instead have its own power connection? Either way (individual power through board, or backplane) we need detailed specs on the types of connectors available on the hashing boards to supply power, and the power requirements, tolerances, etc. (3) For a customer that might be interested in the DIY solution, it is essential to have a ready to go mounting solution. The X-3 cases would provide such, so why not send us the cases and power supplies together with the extra hashing boards. Ideally, you would provide an 5 Prospero cases with power supplies for each X-3 order (enough to mount and power the full 4.5 Th/s of boards you are proposing to send). At a minimum, you should provide 4 cases (for 4 Th/s solution) and the extra hashing boards can be left to our creativity to mount and power. Without cases and power supplies, any engineer working on solving your problems for you would be hobbled by first having to rig up power and mounting solutions .. that would delay any solution by at least a week. How can you expect your customers to pitch in our time and creativity to solve **your** problem if you don't at least give us what we need (and for that matter, what we paid for) ? (4) You must release the board specs and some warranty that the boards hash if you are going to offer such a degraded solution. If I blow a board by providing too much power or damage the boards in some way, its my fault. But if I power them according your spec, mount them in the nice X-3 case that you should provide, and use your power supplies, they should hash at least invidually at the .7 watts/Gh/s that you announced earlier. Right? (5) When the backplane is fixed, you should provide it to us free of charge. We paid for it, and now we are helping you fix your engineering problems... why wouldn't we get the backplanes when fixed??? The "extra" .5 Th/s in hash boards does not even begin compensate for the pain of having to assemble the system, much less debug and provide communication and control mechanisms ourselves ... and you are asking is to do much more than that. So the backplanes are part of what we paid for and you have to provide those when ready. It is offensive that you would not offer that to early adopters who might try to fix your issues. (Oh, and yes I know you have only announced compensation of 3 Th/s for each X-3, but as addressed previously the "current" market price puts required comp at 4 Th/s to be equal with Spondoolies .. and it will get much higher in comp when you are really ready to ship so the offer of 4.5 Th/s in hash boards is hardly enough even by itself). Black Arrow, if you can't at least offer the foregoing (and preferably a lot more), how can you expect us to help you? I (and everyone else) will be **forced** to ask for a refund. Or, if we do elect to wait it out, your required compensation will skyrocket... by August Spondoolies will be shipping SP30's at $1/Ghs and under .7 watts/Gh/s - and those in the know say Spondoolies will beat their August ship date. So do you (Black Arrow) really want to chance that? If you cannot ship by the time Spondoolies starts shipping the Sp30, you will owe EACH customer 6 Th/s in a complete, power supply included, system. Or refunds now. So what I am asking (demanding really) for those of us willing to try to fix your issues, is very minimal. Others may want even more. But you AT LEAST have to offer something that is workable .. and you haven't done that. I'll say it again: Replace The Backplane with WiresAs in 1 (one) SPI channel PER HASHBOARD going direct to a controller. I hope to god you didn't have all the hashboards sharing a common bus on the backplane before - because I can't imagine trying to get that to work. |
|
|
|
|
Black Arrow:
You asked for technical solutions. I might have a very simple one.
DITCH THE BACKPLANE
Run wires from the connector to an SPI controller. Similar to the SPI controller you use for the bitfury boards. It works for KNC, It worked for your bitfury, probably simpler than trying to smash all that data over serial through a board.
JUST USE WIRES
Or, if you can't do that, put in a controller for every hashboard. You'd lose some money and a tiny bit of power would be wasted but it's time to ship.
|
|
|
|
I've had enough I've asked MS to change my order to s1's F this.
Let me know if they approve that request. I am going to wait a little longer but come june I may do the same thing. |
|
|
|
|
Is the barrel connector the same size as on the gridseed 5-chip units?
I still have a few spare of those coming off my PSU. Thanks.
|
|
|
|
Great job!
One suggestion: how about adding an option to move up/down your pool settings (or at least setting priority for them, so we can easily change to more profitable coin/pool just by movind for example 3rd pool to 1st place?
Think that's in the newest release. On the dashboard scroll to pools. Select the Select this button and it will move to mine on that pool. This is just awesome!!! Indeed it is. Don't even need to restart your miner or lose your autotune settings! Also, on the settings page you can drag around the pools exactly like that. Looks good!
What the chances of getting this to work on a vanilla ubuntu/debian linux x86/64 installation?
Probably about 99.9%. Before there were image files available I had built it on top of raspbian from git in about 5 minutes. |
|
|
|
|
Show Posts
