Quote from: vs3 on February 02, 2014, 03:11:56 AM

Quote from: utdrmac on February 01, 2014, 06:37:39 AM

Quote from: vs3 on February 01, 2014, 05:15:30 AM

By the way I think Con did incorporate exactly those changes into the mainstream cgminer (I think as of version 3.11 everything should be stable, he also added a speed override option)

Hrmm. I didn't see any references to this patch in the main branch, which is why I created my fork (https://github.com/utdrmac/cgminer). If I clone ckolivas's main branch, and compile, I have to use hidapi and I get hardware errors or I get no detection of NFY at all.

Using my fork, with the patch from technobit, there's no need for hidapi (known to be cumbersome with RPis), YellowJackets are detected, run more efficiently and produce 0 hardware errors.

Take a look here: https://github.com/ckolivas/cgminer/network
Go back to Jan/2 and follow the branch that Con split off at that time, and which branch got merged back into the trunk on Jan/8. That's when majority of the work was done.

Also, I suspect Con based his work mostly on the changes that Marto did (which were based on LukeJr's code who reworked to a significant extent my nf_spidevc.* library). The reason being is - Luke used the hidapi library (which was something inherited from my code) while Marto's version switched to libusb and that's what Con used. I don't know whether Con or Marto was first with libusb though - it might be that Marto has just shown the way to Con and he has redone the entire library himself.

I haven't done a diff to see what are the differences between Marto's version and Con's, but I suspect I'll find many common blocks of code

(which however might be just a coincidence as both of them used LukeJr's code as a base)

And just for the record - I would be a bit suspicious about the zero hardware errors. No bitfury chip (to the extent of my knowledge) has ever worked ideally flawlessly in that regard.

i might have 1 "flawless" at least at 54 bits. been running for over 1.5 weeks with no hw errors. this would mean its been through 2.091 × 10^15 hashes in that time period at 2.2 Gh/s which i would think is enough for a hit on each of the 756 cores.

and now i have to wonder why Bitfury chose 756 instead of a full 1024. silicon die sizing constraints?