|
Yeah, its certainly too risky for money tied up in ASIC pre-orders, if you can't get it within a week or two of placing your order better to cancel and stay liquid until we see if BTC is going to stabilize again.
|
|
|
|
How high did you overclock it to test. I'd think default would use regular port power. Whatever Angus and tk are doing the 3.8.5 version seems to fix where I was getting alot of errors regardless of what they were. I've got 8 eroupters and an recommended overclock setting thumb with a fan with 8 HW errors back from 300 or so with 3.8.4.. I know Kano and ckolivias will commit suicide again but if the version of libusb has so many problems why not get a newer version (yes I said that  , its probably like updating visual basic to visual studio code ) The previous libusb problem I sorted out before, a few months ago, was in pretty much every version. The libusb problems ckolivas has been spending a lot of time sorting out over the past month or so are in the windows libusb version (not a linux issue) There is no newer windows version that handles these problems - the linux kernel already handles them - that's why they aren't an issue on linux. I am getting the USB timeouts with the Drillbit 3.8.4 cgminer build on Ubuntu 13.10 which is up to date, it's actually a clean machine I built just for the Drillbit board a week ago. They are pretty intermittent, like once or twice a day. |
|
|
|
|
Thanks kano for the update, now that we know you have a Drillbit board in hand to play with, it makes me a lot happier. Will official Drillbit support be included in a future cgminer release?
|
|
|
|
I think you seem to be missing the point, or rather avoiding it... The issue with LIBUSB is not drillbit related in any way shape or form (hence why OTHER products which are officially supported by CGMiner have the issue as well). It's blatantly obvious that you want to keep ignoring this fact just so you have something to bitch and run your mouth about, so nothing anyone says here will help you. The issue has been around since before the Drillbit 8 Boards were manufactured, since before Drillbit developers ever wrote code, etc... So how about you do some actual reading for once and learn what LIBUSB is... it's a library written in C for USB communications, which omfg, has bugs, not to mention the implementation CGMiner uses it in, had & has bugs with it. http://www.libusb.org/Not_a_damn_thing_to_do_directly_with_drillbit. Granted I understand if you're mentally incapable of understanding logic, I won't make fun of you for being mentally handicap, so if that is the case please speak up. However I'll gladly point out how much of an idiot someone is when all the facts are right in front of their face yet they choose to still ignore them. So which is it with you? I am not missing that point at all, I just don't agree with it for even a second. Just because the parent code you choose to copy to make your fork, has something in it that is not quite right for you product, doesn't mean that you are suddenly not responsible for fixing it. You choose what use or discard when you fork someone else's code, they don't. There is absolutely no reason to stick with the version of libusb in the parent code, could have used many other usb library versions. libusb in cgminer is not some external dependency which is simply linked to, it's part of the code Drillbit forked and distributed This is just a poor attempt at externalizing the problems with the cgminer-drillbit code, to even suggest it's someone else's responsibility is ludicrous. Don't bother to reply as your personal attack means you are now on my ignore list. For those that need it, I am using this program on Linux to reset the usb when the Drillbit board disconnects: http://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line |
|
|
|
You seem to be missing an important point. Drillbit support is not part of the standard cgminer release, I am quite sure it could have been if you sent Kano a board to develop on. Nevertheless, the Drillbit devs took it upon themselves to fork cgminer and patch it for Drillbit boards, but they didn't do it properly, there are issues with libusb disconnects, if Drillbit requires a certain version or configuration of libusb then that should have been done, it is not up to the cgminer devs, trying to deflect the blame back to them for managing problems in the Drillbit fork of the code is rather childish.
I think "irk" would be a more appropriate alias.  If you were paying attention to the appropriate forum you would have seen this thread: http://drillbitsystem.com/forum/index.php?topic=235.0I have read the thread many times, stop trying to deflect the blame back onto the cgminer devs for code problems with a non-supported product. If you are going to fork someone elses code for your product, then you suddenly take on responsibility for every line of that code to be right for your product. If it were me I would have made a Drillbit board available to ckolivas, Kano, Luke-jr and let them take care of making their mining software work with the hardware, a small price to pay for the work involved. |
|
|
|
I have never seen the issue on BFL, I have seen the issue on Erupters when I got up to 122 erupters on one rPi, which caused me to switch to BFGMiner (CGMiner wasn't very stable after 30 erupters anyhow). I didn't see the issues on Blue/Red Fury devices until CGMiner 3.8.0/3.8.1; If you want to browse through the hell that is the CGMiner thread here on the forums, you will find other people with LIBUSB errors on other random hardware.
I did have a look at the thread before, didn't see all that much. I see in last weeks release 3.8.5 they have added - Attempt a libusb reset device on usb devices that have stopped responding. Which of course is attempting to correct a symptom rather than the problem which caused the device to stop responding. When I say go back through the thread, I mean like back to 3.1.1, lol, the biggest issue with CGMiner (from what I can tell and in my own personal experiences) is how it interacts with USB devices. Hot-plugging is great to have however, not always the best, I think the want to always have hot-plugging while using libsub is CGMiner's biggest down fall... which you don't really have with BFGMiner, as it doesn't support hot-plugging... You seem to be missing an important point. Drillbit support is not part of the standard cgminer release, I am quite sure it could have been if you sent Kano a board to develop on. Nevertheless, the Drillbit devs took it upon themselves to fork cgminer and patch it for Drillbit boards, but they didn't do it properly, there are issues with libusb disconnects, if Drillbit requires a certain version or configuration of libusb then that should have been done, it is not up to the cgminer devs, trying to deflect the blame back to them for managing problems in the Drillbit fork of the code is rather childish. |
|
|
|
I have never seen the issue on BFL, I have seen the issue on Erupters when I got up to 122 erupters on one rPi, which caused me to switch to BFGMiner (CGMiner wasn't very stable after 30 erupters anyhow). I didn't see the issues on Blue/Red Fury devices until CGMiner 3.8.0/3.8.1; If you want to browse through the hell that is the CGMiner thread here on the forums, you will find other people with LIBUSB errors on other random hardware.
I did have a look at the thread before, didn't see all that much. I see in last weeks release 3.8.5 they have added - Attempt a libusb reset device on usb devices that have stopped responding. Which of course is attempting to correct a symptom rather than the problem which caused the device to stop responding. |
|
|
|
And by the way... Blue/Red Fury devices, flooded CGMiner 3.8.0 and 3.8.1 with "LIBUSB" errors until the day after 3.8.1 was released, ckolivas updated the repository with code that pulled back on the timing to make it "not as trigger happy". However since I got all those errors on CGMiner, I just said fuck it and stuck with BFGMiner for those devices, as it worked perfectly fine.
**cough, cough, I wish Luke-Jr or someone would add-in support for Drillbit devices on BFGMiner.. **
Interesting, I have several Block Erupters and BFL devices with no LIBUSB errors, I was not aware that Drillbit was part of cgminer distribution, I thought it was it's own fork so I didn't try the drillbit version to see if the other gear gave problems. |
|
|
|
It has been stated many, many times that specifics will be discussed on the drillbit forum. Yes, it is in a thread over there. Of course you're free to post here, but don't expect an answer.
Stuff that, I WANT people who bought the 8 board from this thread to know there is a USB problem, and to have access to the solution. It's common courtesy. |
|
|
|
I have seen at least half a dozen reports of people with these USB disconnects on the 8 boards. Anyone closer to a solution? (no it's not the cable or hub)
Seriously... it's been discussed to death in the Drillbit forums. They know about it... it looks like some USB transfer issues that were supposedly fixed in CGMiner 3.8.1, but seem to have cropped back up in 3.8.4. There's even C code snippets on some of the threads pointing out where the problem should be. You'll get a better idea about it talking directly to the engineers and developers for Drillbit over there than you will in the generic Group Buy thread here. The people who bought from this thread have a right to know there are issues and the answers. I am not talking about some configuration issue, but a bug in the product which many users have reported. It's not my fault that the thread was in group buys and not custom hardware. I fail to see why something important has to be buried in the corner of a tiny product specific forum. I can't see any thread about the USB timeout problem over there, so I guess the issue is buried in some other thread. How about a simple link to the discussion/solution to the problem? |
|
|
|
|
I have seen at least half a dozen reports of people with these USB disconnects on the 8 boards. Anyone closer to a solution? (no it's not the cable or hub)
|
|
|
|
[...]
nothing is wrong with selling.. a lot is wrong with panic selling.. and that is a majority of what I see pushed
And this is what makes me a little sad. Distribution of bitcoin is already quite unequal, but that's ok. But manipulators actually reach their goal (I didn't expected that...) and make it even worse. I think that is one of the biggest threats to bitcoins future. I would imagine China and other whales are snapping up cheap Bitcoin as western noobs dump because they don't understand any of the Chinese announcements regarding Bitcoin. |
|
|
|
CoinEx ... You really should think about adding BetaCoin (BET) to your exchange ... seems to have a lot of support in the mining pools There are a lot of things they need to do before adding more coins, like make the sell order list work with Firefox, get the API ticker running again so miners can calculate profitability etc. users reported that the latest firefox version is working with CoinEX regarding order list. I am running Firefox 26.0 on Windows 7 and the problem with the Sell Orders is sill there. |
|
|
|
CoinEx ... You really should think about adding BetaCoin (BET) to your exchange ... seems to have a lot of support in the mining pools There are a lot of things they need to do before adding more coins, like make the sell order list work with Firefox, get the API ticker running again so miners can calculate profitability etc. |
|
|
|
I am in Australia and just one one of the Prospero X-1 units to play with, who should I be buying it from? |
|
|
|
|
Doe anyone have a working source code, or a patch to add the checkpoint to the github source?
|
|
|
|
I wanted to buy just 1 Prospero X-1 and it only wants me to buy 10 of them minimum. Sigh...
Doesn't the US reseller have an option to buy just a single unit? Dunno, I am in Australia so I doubt if we have a reseller, hence I went to the main site. |
|
|
|
|
I wanted to buy just 1 Prospero X-1 and it only wants me to buy 10 of them minimum. Sigh...
|
|
|
|
and I see that this connected and do not reply to the pm
are you stealing my money I want to get it back
BTCBTCBTCBTC
I would suggest that the red " Warning: Trade with extreme caution!" next to your name means you are more likely to do something dubious than Cryptsy with coins. |
|
|
|
|
It will amazes me how Cryptsy have overlooked DEM, it's not like the devs haven't asked for it to be added. All you have to do is look at the difficulty to see there are many TH/s mining it, it's higher diff than TRC, so it could easily be the 3rd most mined sha256 coin behind BTC an PPC.
|
|
|
|
|
Show Posts
