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

[-ck]

--sched-start <arg> Set a time of day in HH:MM to start mining (a once off without a stop time)
--sched-stop <arg>  Set a time of day in HH:MM to stop mining (will quit without a start time)

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.

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.

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.

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

[jmc1517]

This is the next set of tests please

http://ck.kolivas.org/apps/cgminer/temp/cgminer-tok.exe

then
http://ck.kolivas.org/apps/cgminer/temp/cgminer-cb5k.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-t5cb5.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-t20cb5.exe

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

[chr0me]

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

[aigeezer]

This is the next set of tests please

http://ck.kolivas.org/apps/cgminer/temp/cgminer-tok.exe

then
http://ck.kolivas.org/apps/cgminer/temp/cgminer-cb5k.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-t5cb5.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-t20cb5.exe

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

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.

[chr0me]

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

That's nice. 

[-ck]

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

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?

[Zich]

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

That's nice. 

Which fury did you use?

[-ck]

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.

[Beans]

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?

[-ck]

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?

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

[Beans]

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?

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

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.

[-ck]

Then again you always were a jerk.

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.

[Beans]

Then again you always were a jerk.

Quoted for prosperity. 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).

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.

[-ck]

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.

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

[-ck]

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

Thanks. Next test, 3.8.4 please.

[kano]

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?

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

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.

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"

[chr0me]

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

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?

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

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

That's nice. 

Which fury did you use?

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

[giveBTCpls]

I dont know if anyone reported this, but I left my computer on all night like i've been doing for weeks mining, then I woke up and I saw Malwaresbyte reporting cgminer-nogpu.exe as a trojan, specifically "Trojan.Bitminer". Im CPU mining with 3.7.2 so I was using cgminer.exe. Anyway, I disconnected and ran a complete scan, I detected Trojan.Winload on Winload-Loader-v2.2.1.zip which I guess is a false positive from Daz's Windows activator for Win7, and that's about it.
To be sure, I downloaded again http://ck.kolivas.org/apps/cgminer/3.7/cgminer-3.7.2-windows.7z scanned it and found again "Trojan.Bitminer" on cgminer-nogpu.exe.

Im asuming Malwarebytes has included that exe as a trojan because people has been installing it around to secretly mine with other people's computers. False positive?

[kano]

I dont know if anyone reported this, but I left my computer on all night like i've been doing for weeks mining, then I woke up and I saw Malwaresbyte reporting cgminer-nogpu.exe as a trojan, specifically "Trojan.Bitminer". Im CPU mining with 3.7.2 so I was using cgminer.exe. Anyway, I disconnected and ran a complete scan, I detected Trojan.Winload on Winload-Loader-v2.2.1.zip which I guess is a false positive from Daz's Windows activator for Win7, and that's about it.
To be sure, I downloaded again http://ck.kolivas.org/apps/cgminer/3.7/cgminer-3.7.2-windows.7z scanned it and found again "Trojan.Bitminer" on cgminer-nogpu.exe.

Im asuming Malwarebytes has included that exe as a trojan because people has been installing it around to secretly mine with other people's computers. False positive?

README FAQ answers that.

[jmc1517]

Thanks. Next test, 3.8.4 please.

Happy to oblige as always.  Test ran for just under 2 hours before a zombie (AMU16) appeared.  Did the usual thing with debug, then stopped the test.

Logfile here:
  https://dl.dropboxusercontent.com/u/44240170/logfile-3.8.4.txt