erk
|
|
December 17, 2013, 11:37:03 PM Last edit: December 17, 2013, 11:58:22 PM by erk |
|
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
|
|
|
|
tk1337
|
|
December 17, 2013, 11:45:21 PM |
|
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 is not some external dependency, that is simply linked to, you are taking about, it's part of the code you forked. 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. You don't agree with it when the libusb issue predates any drillbit devices? Seems ignorant to me. The shitty thing about the ignore list, is most people will still click the 'show post', since you are very very ignorant, my bets are you'll click on the 'show post' just for the hell of it. And yes, it is an external dependency, as are a lot of things included in the CGMiner code base, just because they are included there doesn't mean their not from an external source, but given the competency level you have displayed thus far, I can see where you wouldn't understand that. Not only that but now you are saying it was up to Drillbit to realize the code base in CGMiner (a software not created by them) is poorly handled and that they should fix CGMiner, when really all they did was add in their driver files and make it so you could compile with said driver files. They didn't re-write CGMiner, nor should they have to, lol. If I wanted to personally attack you, I don't think I would need to at this point, you've already shown your intelligence (or lack there of).
|
|
|
|
kano
Legendary
Offline
Activity: 4620
Merit: 1851
Linux since 1997 RedHat 4
|
|
December 18, 2013, 12:56:29 AM Last edit: December 18, 2013, 01:40:55 AM by kano |
|
lulz drama. Anyway I got a board and USB from Jesse when I went to visit on Thursday. I was going to be busy all day Friday (and was) so on Thu night when I got home from drillbit ... around midnight? I just tried to plug them both in and run the drillbit git version on my linux desktop but it kept failing - and by 1am I gave up. On Sunday I had some time to try and get them at least running. The problem of course was the opposite of what I thought it was ... the USB 1 chip needing power was the problem, the 8 chip board wasn't. Anyway, I simply rolled the drillbit git back a few steps, only connected the 8 chip board, pointed an Arctic USB fan at it and off it went. Been OK mining on default settings at 19.3GH/s since then (though something went wrong one day since then, but since the temperatures here have been around 30C a couple of times since then I think that was the problem) Anyway for a single board I'm running git commit: commit f366474dcde322aebd4a3f0ffada1b2a0a789017 Author: Angus Gratton <> Date: Tue Dec 3 18:19:58 2013 +1100 Fix driver-drillbit to correspond with 3.8.3 driver api changes Later this week I will hopefully have more time to sort out what's up with the diver version and see what's in the commits after that and work out what's going on ... and also work out if my USB3 hub is able to run the thumb properly or if I need to get another one. I've just been really short on time at the moment working on another driver for a company I'm employed by ...
|
|
|
|
erk
|
|
December 18, 2013, 01:26:43 AM |
|
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?
|
|
|
|
kano
Legendary
Offline
Activity: 4620
Merit: 1851
Linux since 1997 RedHat 4
|
|
December 18, 2013, 01:39:46 AM |
|
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?
Yes
|
|
|
|
techman05
|
|
December 18, 2013, 02:00:53 AM |
|
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 )
|
|
|
|
kano
Legendary
Offline
Activity: 4620
Merit: 1851
Linux since 1997 RedHat 4
|
|
December 18, 2013, 07:53:38 AM |
|
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.
|
|
|
|
erk
|
|
December 18, 2013, 08:07:40 AM |
|
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.
|
|
|
|
kabopar
|
|
December 18, 2013, 09:22:43 AM |
|
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. erk, There is a new 'test' release of firmware and windows miner s/w at http://drillbitsystem.com/forum/index.php?topic=235.0. While you may not be using Windoz, the test version of cgminer fork (3.8.5, but only windows version at this point) seems a lot more robust in regards to USB errors in my case. Cheers
|
|
|
|
JBT
|
|
December 19, 2013, 04:50:14 AM Last edit: December 19, 2013, 09:31:59 AM by JBT |
|
any word on the 8board coming to South Africa yet?
ED. ok so they on the way, but no tracking yet.
|
|
|
|
HellDiverUK
|
|
December 19, 2013, 09:33:06 AM |
|
Newflash! cgminer and libusb being shit again, and man reinvents wheel in new 4 sided shape, possible link? More news at 10!
|
|
|
|
picbb1
Newbie
Offline
Activity: 20
Merit: 0
|
|
December 19, 2013, 12:18:40 PM |
|
any word on the 8board coming to South Africa yet?
ED. ok so they on the way, but no tracking yet.
How many days on the road? I have in Russia> 10 (
|
|
|
|
kano
Legendary
Offline
Activity: 4620
Merit: 1851
Linux since 1997 RedHat 4
|
|
December 19, 2013, 01:06:19 PM |
|
Newflash! cgminer and libusb being shit again, and man reinvents wheel in new 4 sided shape, possible link? More news at 10!
Lulz moron - it would help if you actually knew what the problem was ........... which you don't.
|
|
|
|
Goldshredder
|
|
December 19, 2013, 04:45:01 PM |
|
Newflash! cgminer and libusb being shit again, and man reinvents wheel in new 4 sided shape, possible link? More news at 10!
|
|
|
|
JBT
|
|
December 20, 2013, 03:56:18 AM |
|
any word on the 8board coming to South Africa yet?
ED. ok so they on the way, but no tracking yet.
How many days on the road? I have in Russia> 10 ( no idea how long got a email saying they on the way but sadly no tracking number..... normally for me once it's processed in usps it takes 7working days......but being this time of year who knows.
|
|
|
|
|
erk
|
|
December 23, 2013, 11:59:31 AM |
|
Nice work, thanks for that.
|
|
|
|
picbb1
Newbie
Offline
Activity: 20
Merit: 0
|
|
December 23, 2013, 04:38:35 PM |
|
any word on the 8board coming to South Africa yet?
ED. ok so they on the way, but no tracking yet.
How many days on the road? I have in Russia> 10 ( no idea how long got a email saying they on the way but sadly no tracking number..... normally for me once it's processed in usps it takes 7working days......but being this time of year who knows. CTATУC: COPTИPOBКA ДEHЬ INF ДATA BPEMЯ TEPPИTOPИAЛЬHOE OTДEЛEHИE ИHДEКC CTATУC OБPAБOTКИ PACШИФPOBКA 1 Иcтoчник инфopмaции 07.12.2013 02:59 Mocквa PCI-1 104001 Импopт 1 Иcтoчник инфopмaции 07.12.2013 04:55 Mocквa PCI-1 104001 Пpинятo тaмoжнeй 1 Иcтoчник инфopмaции 07.12.2013 05:03 Mocквa PCI-1 104001 1 Иcтoчник инфopмaции 07.12.2013 11:23 Mocквa PCI-1 104001 Oбpaбoткa Пoкинyлo мecтo мeждyнapoднoгo oбмeнa 1 Иcтoчник инфopмaции 07.12.2013 19:21 Mocквa-Bнyкoвo MMПO цex-1 102976 Oбpaбoткa Copтиpoвкa
|
|
|
|
rocks
Legendary
Offline
Activity: 1153
Merit: 1000
|
|
December 23, 2013, 05:57:29 PM |
|
So now that the boards are back and happily hashing away, what is the status of future batches? Does drillbit plan future batches or indivdual sales? Also are you guys looking at designing boards around future chips, for example black arrow or others?
And thanks to barntech and team, after being burned in an Avalon GB (very badly) I appreciate how you guys stuck with it and made things right. Sure it was disappointing to lose time, but new HW designs sometimes have issues and you guys went out of your way to quickly solve them.
|
|
|
|
eman5oh
Newbie
Offline
Activity: 57
Merit: 0
|
|
December 23, 2013, 08:26:40 PM |
|
Barn said on the other forum that they would be doing a 16 chip Avalon gen 2 board. They won 5000 chips in the Avalon design contest.
|
|
|
|
|