Topic: [GLBSE] Introducing: Bitcoin Syndicate, a new mining op trading publicly! - page 6. (Read 23353 times)

This pained me to read. I hope you get it fixed somehow.

Yup John's miners are back up for now. The contracting still isn't done in his home yet, but it's at a point where they can run for now. Hopefully it will be permanent soon.

Anyway here is an update about the FPGAs. This issue is once again driving me insane.

After much troubleshooting I have learned the following:
- The software is locking up because USB communication at the driver level is failing.
- When the failures occur I occasionally (but not always) get errors in dmesg showing that the USB device refused to accept the ID being assigned it by the Kernel
- the "high end" 10port USB hubs I bought, internally are actually 3x 4Port hubs which are daisy chained (so port 1-3 is hub1 4-6 is hub2 and 7-10 is hub3)
- All the FPGA cards work fine when plugged in individually
- If I plug in cards to one of the usb hubs starting at port 1, and adding cards one at a time, when I reach port 7 the lockup problem begins.
- If I keep it to only 6 cards on port 1-6, it will run perfectly fine
- When I plug into ANY port 7-10 (individually or as a whole) the lockups begin. Which implies it's a problem with the 3rd "internal hub" on those 10port hubs.
- When I plug into port 7-10 and the problem starts. It affects ALL ports on the hub (the whole 10port hub goes nuts until it's been 100% power cycled and re-detected)
- Once the FPGAs are affected by the problem they will sometimes (about 25% chance) refuse to mine, they will detect, and show active, but report 0MH/s. Power cycling the FPGA solves this.
- Both 10port USB hubs exhibit the exact same problem, only allowing up to 6 cards only on the first 6 ports.
- I can run both hubs with 6 cards each (total 12 cards) just fine, and have tested this for 24h to confirm it works
- After that test, I plugged the other 4 cards into a seperate 4port hub (powered brand name hub which I had at home for my PC), and plugged that hub into a different PC altogether, installed fresh software and began mining there. As soon as I did that, the other 12 began locking up again. (which makes no sense because the 2 PCs were 100% seperated).
- The only common thread between the FPGAs at this point that could span multiple PCs like that is the power supply
- The power supply has tested as outputting clean power, the load is divided evenly between it's rails, and I'm running 16 cards on that PSU (the 17th is plugged into it's own supply for dev/testing). Each card draws 20W, of a 750W supply, that's only 320W of draw, evenly distributed, and the PSU ONLY supplies the cards, (and 3 fans which only draw a couple watt each).
- If the problem is the PSU, I don't have another PSU to test it with.

So at this point I'm a little frustrated lol. I spent all weekend fighting with that damn rig, When I had tons of other things I should have gotten done around the house. My wife is pissed at me now because I wasted the whole weeekend on this, and I STILL wasn't able to solve the problem.

We'll get it figured out one way or another, but for the immediate time being I'm at a loss. I'm back at work today so I can poke a bit in the evenings this week. But I have other things I have to do as well. I'll talk to ngzhang and see if he has any suggestions, as well as I'll discuss with TheSeven, and a few others who have worked with it a fair bit. Hopefully I can get a few more suggestions to try.

It's really troubling me why we are having so many problems with these FPGAs when everyone else is having such an easy time of it. Though from what I've seen, other than 1-2 other individuals, we are the only ones with this many cards at once.

If we only had several hundred more bitcoin, I'd almost be tempted to offload the Icarus boards and place an order for something like a Mini-Rig, (or at the very least invest the money in an alternative). The Icarus boards appeared to be the preferred solution, but after the problems we've had with them (for a device that ultimately should be "plug and play") I'm not so sure at this point.

Anyway, I'm done ranting now. If anyone has some suggestions let me know. I'll continue to poke at it over the next couple evenings. But I can't spend a lot of hours on it this week. We are travelling Thursday night this week, and I have things to get done before I leave. I'll be gone until Monday. And I've already spent at least 20+ hours this weekend fighting with these and researching solutions and so on. And other than learning a lot about the problem, I have yet to come up with a solution (short of ordering a bunch of individual "wall wart" power adapters for each card, and dividing them up between the founders in blocks of 4 to reduce the number of cards in one place, which seems to be the root of the problem) But that will still cost money, the cheapest I can find 12V 2A AC Adapters (including shipping) is nearly $10 each. We need 16 of them, which totals $160 (32BTC). We can consider that as a last resort. I still don't see why we can't have 16 of these in a single rig. ngzhang was running far more than that at once during testing with no issues. (and they worked beautifully for us for 2 weeks).

U R right, there was another reason for the falling mining rate ...

OTOH, catch of the month:


(FPGA rig mines on/off as it's being checked card by card so I'm glad to catch a moment when it's off and got a look at the founding 7 all mining and well above 6 Gh/s; by well above I mean adjusted for dead shares - those afaik are not included in the mining speed)

thanks, made my day

2 posts back:

@Glasswalker Did you installed UPS?

I see, thanks for clarifying. Best of luck and thank you for your dedication in pursuing this enterprise!

Modular Python Bitcoin Miner. It's the mining software I'm using to drive the FPGAs.

And yes I am leaning towards a corrupt file. I'm going to try reinstalling everything clean, and trying again. It appears to be a USB driver level lock up. So it could be something wacky in the software, or a corrupt OS file of some kind causing a problem.

Hopefully re-installing will clear up the issue. If it doesn't I'll have to continue to divide and conquer. For now my plan is to reinstall the software, then re-add one miner at a time to confirm it mines. If I can sustain that more than 10min then I continue. If it starts locking up again after a certain miner, I backtrack, and see if it mines longer on the previous miners. If that happens I can test that chain then (the fpga, usb cable, hub port, motherboard port, hub cable, and all other parts in the chain between the "triggering" FPGA and the software).

Failing that, a full OS reinstall might help. But I think that's a bit drastic.

To clarify the power outage did not affect the miner at all.

I have 3 UPSs, all 2KVA server grade UPSs in this rack. One drives my GPU miner, one drives the FPGA miner (the host server and the FPGAs themselves) and one drives my household server and network infrastructure (router, firewalls, switches, wifi and so on). When the power outage happened the one handling my household stuff failed. So I lost internet for like 5min while the power was out. The remaining gear kept running completely unaffected.

But when the internet connectivity went out, the FPGA miner locked up. After that it began "misbehaving".

Anyway, I'll keep you informed. But I expect the outage to last into tomorrow. Hopefully I'll have it resolved by then.

Thanks for your understanding and patience.

What is this MPBM you speak of?

In any case, seems strangely coincidental that it would stop working right after a power outage... A corrupted file, perhaps?

Well all miners appear to work, but something has gone terribly wrong with MPBM. It now locks up hard after anywhere from 30seconds to 10minutes of mining

No ideas why. I'm working with TheSeven now but there might be a more extended outage unfortunately. I'm trying to work with TheSeven (maker of MPBM) and do troubleshooting but this is a bizarre issue. I'll keep you all informed as I have more info.

Well not fixed yet, shortly I JUST got home. Working on it now.

My other miners came back up but for some reason MPBM on the FPGA miner is crashing. (It runs for a few seconds then locks up) I'm working on it now.

Glad you got it fixed, hopefully stats will come back up shortly.

Sorry actually there was a power interruption in my house and I had to get home to correct it. The FPGAs should be mining again shortly. Sorry for the confusion (and odd timing) lol...

Without a motion? Huh?

I guess the power is being redirected
I saw a moment when the FPGA rig was mining at 1 gh/s, as if the majority of boards was reconfigured ... it was dropping since then.

Syndicate hashrate down from ~12 GH to ~3. What's going on?

Those of you who own shares, please see this post on our main forums. Please read and respond ASAP if possible.

Thanks!

http://forum.btcsyn.com/viewtopic.php?f=7&t=69

(*) dividends are monthly
and are split 20 % payout as dividends and 80 % to reinvest in more mining gear

* https://bitcointalksearch.org/topic/m.761356
- We will grow in value rapidly due to 80% of mining power being re-invested
- We pay out 20% of all mining power to dividends monthly

& http://www.btcsyn.com/bylaws
- The "Growth Rate Percentage" is defined as 80%
- Each month, the remaining Earnings/Profit after deducting monthly operating expenses, and the Growth Budget, will be added in full to that months Dividend Disbursement.
- The dividend disbursement will be paid in full within the first 7 days of the following month, to the shareholders based on their volume of held shares in the Syndicate

I was searching through the posts but could not find the answer.  Are dividends released weekly?

Ahh ok, thanks nefario! That makes perfect sense now that I think about it lol

FYI the remainder left over is still sitting in the GLBSE account, so it will wait until the next dividend payment and tack onto the total then. I'll just let these tiny rounding error amounts accumulate and keep paying out each month.

It's a rounding issue, essentially the dividend payment doesn't split perfectly for all the shares, so it will pay the closest available.

Congrads on the first payment.