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

Nah, using a raspi. 3.5.x and 3.6.x find the Jala, it's just 3.8 that won't. I think it might be because I have a shitty USB hub. But then it wouldn't work with 3.5 and 3.6...


Bitburner Fury, getting roughly 52~54 gh/s.

Well oddly enough cgminer used to also have CPU mining code in it.
Even more oddly enough, no we don't support CPU mining any more and that is also off topic in here.

Lulz sounds like: "I want help and you must give it to me coz I say so you jerk"

Let me respond appropriately "Go fuck yourself"

Thanks. Next test, 3.8.4 please.

Then this thread wouldn't belong here since this is the bitcoin mining software section, and it would be moved to altcoins, whereas I am maintaining cgminer as an ASIC bitcoin miner. Honestly, I suggest you go looking at the litecoinforum instead where they've forked the code and are developing on it.
https://forum.litecoin.net/index.php?board=3.0

It's not hard to start a new thread. That's what everyone else does. Your assistance isn't needed to keep the thread going. Plenty of people still use cgminer for gpu mining. Not to mention the software still refers to this thread and is still downloaded from here. I don't really care if you think it's on topic or not.

Quoted for posterity. Appreciated.

EDIT: I believe in bitcoin and I'm sorry but this is my thread for my software and I gave plenty of warning about GPU and scrypt being deprecated, and even helped and encouraged people to fork and take over the existing code. Amazing how quickly people turn to personal attacks when you don't support their cause (i.e. litecoin).

EDIT2: No I do not really appreciate being called names. It fucking hurts and my response was purely to try and deflect the pain.

It's still cgminer, so I would say that is on topic. What thread do you think I just downloaded it from. You should have renamed it and started a new thread. Then again you always were a jerk.

GPU and scrypt mining is no longer supported by cgminer and offtopic on this thread.

My first rig runs r9 290's great with TC 30592. I have several other pc's which have the same cpu and ram and they just give memory buffer size errors. I tried lowering the TC and using 13 intensity but that gives HW errors. I'm not sure why the memory size is different on this one pc. Is there a solution for this?

New release: Version 3.8.4, 1st December 2013

Another stable version update.


Human readable changelog:

- More fixes to make usb communications more forgiving and robust which may improve reliability and speeds.
- Timeout overruns won't show unless you have verbose mode on now.
- Voltage displayed for BFL SC devices is the 2nd voltage which is allegedly more relevant.
- API stats for BFL SC devices now show a nonce and hardware error count per core.
- Json API commands should work again.
- More fixes for upcoming hashfast hardware.
- Lowmem mode has been extended to use USB sync transfers
- BXF devices should align better with other devices on the display.
- Devices will now initialise before trying to connect to pools.


Full changelog:

- Deprecate the usb usecps function and just split up transfers equal to the
maxpacketsize on usb1.1 devices.
- Retry sending after successfully clearing a pipe error.
- Drop logging of timeout overrun message to verbose level.
- Use a much longer callback timeout for USB writes on windows only as a last
resort since cancellations work so poorly.
- Use vcc2 in bflsc voltage displayed.
- Increment per core errors on false nonces in bflsc and add per core statistics
to api stats, removing debugging.
- Store a per-core nonce and hw error count for bflsc.
- Fix json parsing in api.c
- Add debugging to hfa driver for how many jobs are being sent.
- Shut down the hfa read thread if the device disappears.
- Add debug output saying what frame command is being sent in hfa driver.
- Revert "Disable USB stats which were not meant to be enabled by default and
add extra memory for a memory error when stats are enabled."
- Reset work restart flag in hfa driver since we may check for it again in
restart_wait.
- Add more op usb init errors for hfa driver.
- Perform basic displaying of hfa notices received.
- Add hfa op usb notice macros.
- Update hf protocol header.
- Use sync usb transfers in lowmem mode.
- Go back to allowing timeout errors on USB writes to be passed back to the
driver without removing the device in case the driver wishes to manage them.
- Initialise more values for the hfa data structures.
- A USB control error must be < 0
- Simplify USB NODEV error checking to success only for writes and control
transfers, and success and timeout for reads.
- libusb error IO should be fatal as well if it gets through usb read and write.
- Allow IO errors in usb reads/writes to be ignored up to retry max times.
- Use correct padding for bxf temperature display.
- Initialise devices before attempting to connect to pools to allow their thread
prepare function to be called before having to connect to pools.
- Add hidden hfa options to set hash clock, group ntime roll and pll bypass,
fixing frame sent on reset to include extra data.
- Relax the timeouts for the slower usb devices on linux.
- Add big endian hf protocol header to Makefile
- Check for correct big endian macro in hf_protocol
- Use an absolute timeout in hfa_get_header to cope with buffered usb reads
returning instantly confusing the 200ms counter.
- Update hfa_detect_one to use the new detect function API.

Which fury did you use?

If you're getting hex2bin scan errors there is some kind of data corruption since it's only meant to have text characters and finding something else. One possibility is you're on a usb1 slot - are you using an ancient PC?

Got the Fury working with 3.8.3 and now getting nearly 2 gh/s more per device.

That's nice. 

You get all the excitement. My "tok" run is zombie-free after 26+ hours. My other machine is running 3.8.2 and is getting occasional zombies, all re-pluggable now.

Edit: The tok run finally got a zombie after about 38 hours. I switched both machines to 3.8.4. Uneventful so far, about 6 hours into the run.

Got hex2bin scan error with 3.8.3 on a Jalapeno, pretty sure I compiled everything correctly.

Gonna try again.

Edit: I still can't get Bitburner Fury (with BFF firmware) to work on 3.8.x

OK, here are the results.  All arrived at fairly quickly because they all produced a zombie - some sooner rather than later.

Test of cgminer-tok     started at 11:36. First zombie (AMU26) appeared after 20 minutes.
Test of cgminer-cb5k   started at 12:06.  First zombie (AMU27) appeared after 30 minutes.
Test of cgminer-t5cb5  started at 12:39. First zombie (AMU11) appeared after 38 minutes.
Test of cgminer-t20cb5 started at 13:26. First zombie (AMU23) appeared after about 4.5 hours.

Turned on debug and let run for a few more minutes in each case, then hit 'Q'

Logfiles here:
  https://dl.dropboxusercontent.com/u/44240170/logfile-tok.txt
  https://dl.dropboxusercontent.com/u/44240170/logfile-cb5k.txt
  https://dl.dropboxusercontent.com/u/44240170/logfile-t5cb5.txt
  https://dl.dropboxusercontent.com/u/44240170/logfile-t20cb5.txt

And... back to 3.5.1. ...  :/

Well as I said it was never designed with that in mind so if it works at all it's coincidence.

I'm not using it to start and stop cgminer, I'm using it to quit at a certain time every day. It does exactly this when I don't have any AMUs plugged in, but seems to hang when I have multiple AMUs.

It's not meant to shut down cgminer. It's meant to be given a start and stop time for when it should be mining during the day and when it should be idle.

Hi there. I'm playing with the --sched-stop command. I'm not using the --sched-start command, and I want it to quit at a certain time.

I entered in a time into my .bat file (--sched-stop 00:20) and it doesn't seem to work. It mines, and then when it reaches 12:20am it says this:
But it never actually closes. It just sits there, and I can hear the fans on my Singles continue to ramp up.

Then I closed the window manually, and re-ran my bat file. It never starts mining, saying the above two lines, but with whatever the current timestamp was. Example: I used (--sched-stop 00:20), but opened the .bat at 00:23, and it still says

Win 8.1 64 bit, CGMiner 3.8.3, 3 SC Singles, 1 Little Single, and 2 AMUs.

I tried it without the AMUs, and it worked fine. One AMU on a USB 3.0 hub, and it works. One AMU on a USB 2.0 port, and it works. Both AMUs plugged in, and it fails. Consistently.

I have no problems just removing the AMUs; the AMUs aren't really earning my anything anyways, but I figured I'd report this in case it helped you identify whatever was not working.