OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[Roy Badami]

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)

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

Thanks, Con.

[-ck]

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

[jamesg]

mofarcher

Preserved for posterity. 

[ZaraxLtd]

I cant get it to work. 

[Roy Badami]

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

Code:

  idVendor           0x0403 Future Technology Devices International, Ltd
  idProduct          0x6014 FT232H Single HS USB-UART/FIFO IC
  bcdDevice            9.00
  iManufacturer           1 BUTTERFLY LABS
  iProduct                2 BitFORCE SHA256

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?

[-ck]

mofarcher?

Code:

  idVendor           0x0403 Future Technology Devices International, Ltd
  idProduct          0x6014 FT232H Single HS USB-UART/FIFO IC
  bcdDevice            9.00
  iManufacturer           1 BUTTERFLY LABS
  iProduct                2 BitFORCE SHA256

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?

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.

[Roy Badami]

mofarcher?

Code:

  idVendor           0x0403 Future Technology Devices International, Ltd
  idProduct          0x6014 FT232H Single HS USB-UART/FIFO IC
  bcdDevice            9.00
  iManufacturer           1 BUTTERFLY LABS
  iProduct                2 BitFORCE SHA256

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?

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.

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

roy

[-ck]

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

[hurricandave]

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?

[kano]

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?

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 ...

[hurricandave]

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?

[-ck]

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?

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.

[hurricandave]

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?

[-ck]

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?

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

[hurricandave]

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!!!!!

[nwoolls]

Why can't manufacturers just provide the data and let the programmers merge it properly!!!!!

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.

[PatMan]

Quickie for kano - did you ever get around to fixing the p2pool problem with your S2 update image?

Peace 

[kano]

Quickie for kano - did you ever get around to fixing the p2pool problem with your S2 update image?

Peace 

No.
But now that my pool is up and running http://www.kano.is/
https://bitcointalk.org/index.php?topic=789369.0

... I'll hopefully find time this week to get the S1/S2/S3 driver sorted out and ask everyone who has one to point it at my pool

[PatMan]

Quickie for kano - did you ever get around to fixing the p2pool problem with your S2 update image?

Peace 

No.
But now that my pool is up and running http://www.kano.is/
https://bitcointalk.org/index.php?topic=789369.0

... I'll hopefully find time this week to get the S1/S2/S3 driver sorted out and ask everyone who has one to point it at my pool

That would be excellent kano - many thanks again 

[nexus99]

Hi guys - Are there any plans to put technobit Hex drivers into the main cgminer distribution?