Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 70. (Read 5805508 times)

I'd love to have that answer from Rockminer, and Bitmain, and ZeusMiner, and GridSeed, and ASICMINER, and BTC Garden, and, and, and...

I've personally given up hope. Most manufacturers have proven that, once something hashes and ships, that's good enough for them.

They have something screwed up. Trying to write a .conf from within the console, crashes cmd.exe and closes the window. The other choice is to use official cgminer and its not entirely the right driver so performance is hurt more.
 Sorry, I'm feeling a bit frustrated since I usually can get the software to work but this device (Rockminer R-Box 100GH/s) just needs the gods to tweak the last bugs out. Why can't manufacturers just provide the data and let the programmers merge it properly!!!!!

Just run it from an open command prompt window instead of clicking on the bat file?

Thank You Ckolivas, is it possible to gleam anything useful from the debug? I mean with respect to selecting enable work details but the console closing when I press[Q]uit? I am afraid it may have more to do with Rockminer tinkering than not but if there was a call to add in the .bat to list work details after receiving the [Q]uit instruction and "pause?" -maybe?

Because there is no support for the 100GH R-Box in the official version. If it works at all it's coincidence so I would pay zero attention to how well or otherwise it works. I wrote the driver for the 32GH R-box because that was offered to me so that I would support it. The details you're quoting from the cgminer versions are all to do with the original R-Box only. Why does the unofficial version support other devices? Because they write their own drivers for it continually and never try to contribute their code back to mainline cgminer. We do accept code from other sources, it's just that they all want to do their own thing. They're free to do that, and it becomes entirely their responsibility to support their driver.

Version 4.4.0 - 16th June 2014

- Tidy unused rockminer variables
- Tidy rockminer defines
- Make rockminer driver compatible with other icarus drivers being present
- Import basic rbox driver
Version 4.4.2 - 17th July 2014
- rbox - add lotsa stats, tidy up a bit more
- icarus - tidy up rbox code, remove statics, and add rocketbox

Version 4.5.0 - 29th July 2014
- rockminer frequency is between 200 and 400 MHz

   There is more, but I don't want to seem like a jerk, I realize the Rockminer version is not the same as the Official CGMiner from page 1. I don't recognize another device that would equate to LIR and if the rbox driver was imported I in my limited knowledge of programming guessed wrong that the device could be identified as RMU, or misidentified as LIR, hence the reason why I asked.

   Secondly, the official build is reporting a 4c increase in reported temp. for a given Frequency as well as a significant increases in hardware errors both in the console work details and the pool, nevermind the duplicates.

   When I [Q]uit from the "Rockminer Version" the console closes immediately even with [W]ork details enabled.

   The Official Version will allow me to read the details after [Q]uit. But the two are giving me such a mix of unequal performance and functionality, making it difficult to make any comparison between them. The unit I have in the end, is only averaging 83GH/s at BTCGuild. Changing the Frequency from 270,290,320,350 Mhzs seems to have very little effect at all.

  I did not buy mine from Eyeboot but he did post a video clip and you can clearly see that he is using CGMiner Version 4.5.0 and his device unit immediately begins reporting 125GH/s + with very low hardware errors in comparison to mine for the exact time frame. But it is identified as an LIR. Once again part of what made me ask why?

 So would there be any fruit to running a debug version to see if a single chip is at fault?

The 4.3.3 you download from them is (obviously) not the official cgminer code or driver.
" http://ck.kolivas.org/apps/cgminer " is the official source of cgminer.
That's why it's listed in the first post here ...

Why does cgminer version 4.3.3 downloaded from Rockminer identify R-box 100GH/s as RMU, but versions downloaded from the .org\apps\cgminer directory that are run from the cmd console list it as LIR as well as averaging 4C higher temps. reporting?

New version: 4.6.1, 20th September 2014

Mainly mofarch updates.


Human readable changelog:

- Fix the BFL Monarchs with their updated firmware naming not being recognised.
- Fix the BFL Monarchs' overheat throttling not working.
- Updated avalon2 driver to support nonce2 of 3 bytes' length.
- On very slow uniprocessor devices (eg RPi) some shares would appear to have "no response from pool" and then later on there will be a response from an "untracked share". This is due to the response coming in from the pool even before the share has been added to cgminer's local database. This change minimises this effect (but does not eliminate it entirely).
- Fix case sensitivity in API.java
- Fix ava2 fixed speed option not working on gen2 devices.
- Api-example fix.
- Other low level fixes.


Full changelog:

- Throttle bflsc28 devices when they hit the overheat limit
- Add whitelisting of firmware used in final bflsc28 products
- API.java - remove lowercase of all data sent
- Avalon2: Add 3 bytes nonce2 support
- Avalon2: MM needs n2size length <= 4
- Use fan min as fan speed when run with --avalon2-fixed-speed
- Clear the pool submit fail bool after adding shares to the stratum hashtable
to minimise window the share is not in the table
- api-example unlimited socket works
- Add custom strcasestr and use custom gnu type functions in bflsc
- Fix windows build of bflsc driver
- Fix possible deref in bflsc28

Awesome, thanks Con!  My Monarchs are being detected, and throttling and thermal cutoff seems to be working correctly.

roy

Nah no one in their right mind will be mining with the fpga any more and I don't even build support for it into cgminer binaries, so it doesn't matter if I let the sc28 driver take hold of them. If it doesn't work it will just drop the devices anyway. Thanks.

EDIT: Actually the iManufacturer is different so that's enough to distinguish them for now, though they have a habit of changing these. Try the latest git master to see if that picks it up.

EDIT2: Git master should also check for overheat and throttle before cutoff now.

EDIT: If I'm not mistaken, this appears to be the same iProduct string that was used in the FPGA Singles that are handled by the bitforce driver.  Is this clash problematic?

I cant get it to work. 

Preserved for posterity. 

@Roy, what does the iProduct and iManufacturer string return on your final release mofarcher?

Thanks, Con.

I'll look into it, along with the product string.

Another Monarch problem.  I've been testing the thermal throttling, and it seems not to work.

If I set --bflsc-overheat to a low value then cgminer logs a message saying that the cutoff temperature has been reached and it's stopping work.  But it doesn't seem to actually throttle...

EDIT: Meaning, it carried on hashing at full speed (and temperature continues rising above the overheat cutoff)

roy

I'm working on a hack of the S1 to use the hashing boards without the proprietary control unit.
Actually, using either an older CGminer or the one for U1/U2, I can have the board hashing, but at 1/4 of max speed expected.
Looks like all chips are working (hot), but I'm only getting 1/4 of results.


Using a newer cgminer build (starting in june or july), my interface with CP2102 is recognized as a LIX and not hashing at all.
I'm not a coder, but could you point me at what to look for the 1/4 speed issue?


Changing the Vid/pid to match my cp2102 and compiling with bitmain support didn't help.

here is what I'm getting when changing the vendor and product id from usbutils to match m cp2102 and compiling only with enable-ants1

 USB scan devices: checking for ANT devices
 [2014-09-18 01:33:31] ANT looking for and found ANT 10c4:ea60
 [2014-09-18 01:33:31] USB lock BitmainAntS1 1-5
 [2014-09-18 01:33:31] RES: BitmainAntS1 (1:5) lock=1
 [2014-09-18 01:33:31] USB res lock BitmainAntS1 1-5
 [2014-09-18 01:33:31] RES: BitmainAntS1 (1:5) lock ok=1
 [2014-09-18 01:33:31] USB unlock BitmainAntS1 1-5
 [2014-09-18 01:33:31] RES: BitmainAntS1 (1:5) lock=0
 [2014-09-18 01:33:31] ANT looking for ANT 10c4:ea60 but found 0424:ec00 instead
 [2014-09-18 01:33:31] USB res unlock BitmainAntS1 1-5
 [2014-09-18 01:33:31] ANT looking for ANT 10c4:ea60 but found 0424:9512 instead
 [2014-09-18 01:33:31] ANT looking for ANT 10c4:ea60 but found 1d6b:0002 instead
 [2014-09-18 01:33:33] Discarded work
 [2014-09-18 01:33:33] Selecting pool 0 for work

Listing known devices returns this

Bus 1 Device 5 ID: 10c4:ea60 Silicon Labs CP2102 USB to UART Bridge Controller inactive
1 total known USB device
Hotplug interval:5
0 USB devices, 0 enabled, 0 disabled, 0 zombie

Ah, alright, thanks for the explanation.