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

hope you have had a nice time in good old europe

New release: 3.3.2, 10th August 2013

First release since I got back from overseas, concentrating on bugfixes. I've posted a new firmware, 20130810 in http://ck.kolivas.org/apps/cgminer/avalon/20130810/ but bear in mind that batch 3 avalons have temperature sensors closer to the actual devices, leading a 20 degree higher temperature, and the default settings currently in cgminer are for the older batches. This means you will have to add --avalon-temp 70 --avalon-cutoff 90 for batch 3 devices for them to behave the same as earlier batches.


Human readable changelog:

- Windows builds contain a new libusb and libcurses library; the usb library update fixes a huge number of issues with multiple icarus devices (eg AMU) on usb ports/hubs.
- Hotplugging devices on windows now enlarges the device window again by recreating it, so the log display is wiped but at least all devices will display now.
- There are new sanity checks to prevent too high/low intensities for sha versus scrypt mining.
- Benchmarking, which didn't work on scrypt, is no longer allowed.
- New BFLSC command --bflsc-overheat allowing you to specify or disable the throttle temperature.
- Bitburner (BTB) avalon clone device support
- BTB voltage can be set
- Avalon frequency and BTC voltage can now be set via the API.
- Minor fix which could lead to less duplicate shares on avalons.
- More usb debugging information
- Fix a problem where a slow to respond pool would lead to cgminer simply disconnecting, leading to unnecessary disconnects. This has also sped up some communication operations when the other side doesn't respond.
- Extra BFLSC stats visible via the API.
- Numerous avalon changes improving dramatically its behaviour (compared to official 3.3.1 release, not the last firmware posted), and supporting new features:
 --avalon-auto       Adjust avalon overclock frequency dynamically for best hashrate
 --avalon-cutoff Set avalon overheat cut off temperature (default: 60)
 --avalon-fan Set fanspeed percentage for avalon, single value or range (default: 20-100)
 --avalon-freq Set frequency range for avalon-auto, single value or range
 --avalon-options Set avalon options baud:miners:asic:timeout:freq
 --avalon-temp Set avalon target temperature (default: 50)
- Made the 5 second hashmeter dramatically smoother, being a true exponential decay based on time now.
- Accepted and Rejected counts on screen now show shares scaled to difficulty, so each 10 diff share for example will increase accepted by 10. This should fix an awful lot of confusion regarding accepted/rejected/hw error ratios.
- Reclaimed screen real estate by doing away with increasingly irrelevant U: figure since so few people run diff 1 now.
- Numerous performance  and stability fixes under the hood .


Full changelog:

- Recreate curses windows on windows when a device is hotplugged to allow window
resizing without crashing.
- Update copyright notice.
- Limit intensity range according to whether scrypt is in use or not.
- Do not allow benchmark mode to be used with scrypt.
- Add a --bflsc-overheat command which allows you to set the throttling
temperature for BFLSC devices or disable it.
- Move bflsc defines to a header file.
- avalon allow frequency to be set via the API
- BTB voltage management via the API - and set default on startup
- Avalon BTB allow partial work to be transferred
- avalon_cts use correct buffer
- miner.php format Best Share
- remove unnecessary memcpy
- using more concise description
- using usb_ident
- forgot a return
- changes to Avalon driver for BitBurner boards
- Revert "Sleep after sending icarus work to emulate working at 115200 baud."
- api correct timeout stat display
- usb timeouts - min/max also
- log USB timeouts in API stats
- usbutils report failed timeouts
- usbutils ensure stats macros are using the macro arguments
- Check for negative wait time in socket_full.
- Fix extra argument passed to statline before.
- Adjust socket wait timeout in recv_line according to how long we've already
waited to avoid a 60 second wait dropping to 1 second due to a blocked socket.
- usbutils use a heap buffer for bulk read rather than stack
- usbutils only one bulk transfer call per stat
- set device_drv function noops when first add_cgpu
- usbutils - in init only change the config if needed
- bflsc nonce per work item stats
- bflsc increase flush count to handle parallel work
- force type checking on curses
- logging - size check sprintf
- usbutils - size check all sprintf
- cgminer - size check all sprintf
- size check get_datestamp/get_timestamp and remove unused cgpu->init
- make all statline overflow safe
- WU only needs +2 width
- Check for a timeout in avalon_scanhash and post to the write sem if we receive
one.
- Decay result count in avalon more slowly to not falsely detect idle periods as
low result return rates.
- Count the number of miners idled in avalon to account more accurately for when
its result return rate is too low.
- Fix potential dereference when starting avalon with all new work.
- Convert the decay_time function into one that truly creates an exponentially
decaying average over opt_log_interval.
- Only throttle avalon clockspeed in avalon_auto in non optimal temperature
settings if the fanspeed has reached maximum.
- Reinstate more aggressive <2% HW error target for avalon-auto
- Set avalon fan min and fan max to PWM values instead of percentage.
- Provide an --avalon-freq command line to give a valid range of frequencies for
avalon in auto mode.
- Set the avalon idle frequency to lowest if avalon auto is enabled and we have
an overheat condition.
- Decrease avalon frequency in auto mode if we are unable to maintain the
temperature in the optimal range.
- Don't count invalid nonces as hashrate for bflsc.
- Use a more conservative upper limit of 1% for hardware errors with avalon auto
frequency.
- Allow the avalon fanspeed range to be passed as parameter on the command line,
default to 20-100%
- Just display A: and R: for difficulty accepted and rejected to preserve screen
real estate and decrease decimal places for WU.
- correct device DR: and remove global U:
- Update all screen A/R to instead use DA/DR and device U to WU
- miner.php add ASC fields
- GPU fan rpm display 9999 when it overflows
- bflsc get volts stats needs its own GETVOLTS
- Support all avalon frequencies on the command line.
- Move to slightly more relaxed timeouts for avalon.
- MMQ turn on cps delays
- bflsc x-link header different to documentation
- Reset the other auto counters in avalon when idling a device.
- usbutils/icarus include more locking to usbdev access
- Icarus turn on cps delays by default
- usbutils cps correct time measurement

Useful answer: it's not a trojan. Ignore your AV. Now READTHEM and Google, then you won't be noob anymore

PS: the Bitcoin wiki was my good place to start when I was a noob. But you probably aren't that much of a noob considering the activity of your Bitcointalk account...

You can't be that new this situation.

Read the Q&A in the readme.

Search this thread and you'll see allot of these questions and answers.

Sorry if this is a noob question, I wanted to play with the 3.3.1 on windows, Problem is, Avast stops me saying it is a trojan.
As I have had this problem before, I just turn off avast to download and all works well.

I am assuming the code is detected as a virus as it does not recognize it?

I'm suggesting if you have 15 erupters, don't put anything.

If you have 20 erupters and only want to use 15 of them, use:

--usb :15

No, the space is not needed.

ya 3.1.1, you guys are too cool. Thanks for the tips. I'll give all that a go tomorrow

and ya the info says my hubs are 2.0 and 1.1 compatible so will see soon enough.

Yes, cgminer v3.3.1 the latest, I think?

ckolivas, (or anyone else,) are you suggesting that in the place of the first "-d " and everything after it, I should just enter:

"--usb 0-14 " for 15 Erupters?

Also, I always have a space after the last character, is this a requirement, or just my silliness, now?

Which version of cgminer? The syntax for devices changed recently and it would be -d 0-14, although you wouldn't even need to do that since it should just detect all erupters by itself, and -d was really designed for GPU usage. The only reason to pass specific numbers of devices is if you wanted to restrict how many devices it used, and it's better to use the --usb command for that kind of restriction.

Hi!  I'm running 10 Erupters { 5 @ 2x Vantec 10-port USB Hubs} and running cgminer on Windows Vista just fine.

My .bat looks exactly like:

(Where (()) has been omitted for privacy in this post.)

(I am using an independent fan that keeps everything cool just fine, I believe.)

-

My question/problem is that I have a 3rd Vantec with another 5 Erupters all ready for mining, but cgminer won't start.  I do add the following after "-d 9 " in the .bat quote above:


I can only speculate why it won't start, and I am continuing to read through this thread to try to find a solution, but I thought I'd ask straight away, regardless.

My speculation is that maybe cgminer can't handle so many Eruptors, maybe it doesn't like all 3 power connections from all the hubs, or maybe the syntax for "-d 10 " has to change for some reason - I really don't know.

Any ideas?  Help?  Thanks!

This thread, BTW, is super-awesome!!!!!  Still working through it!

My RPi works fine with a USB3.0 hub with 3 AMUs

Maybe some USB3.0 hubs have problems?

However, Rasbian has a bad version of libusb in it - if you have that - yes it will screw up.

If you use RPi Arch http://www.kano-kun.net/?p=87 the libusb problem is gone.
Minepeon also uses Arch: https://bitcointalksearch.org/topic/linux-mining-distro-for-the-raspberry-pi-minepeon-137934

Edit: and of course as I've posted in here many times over the last week - libusb verisons are screwed for AMU/ICA
Here's something like how to rebuild for windows and linux (though it's not the final version of the doc)
https://dpaste.de/a5TvN/

What happens when you plug it directly into a USB 2.0 port?

No not at all... and they have never gotten to 333/mh for more then a split second... avg-270mh?

___________________________________

I just put 1 directly into the usb3.0 port of the laptop and it ran over an hour @ avg270mh... it jumped to over 400 mh down to 30mh while keeping that average.

I have no idea what the issue is?

does the hub have enough power? is the hub's power supply hot?

Okay now from bad to worse....

The hub is brand new. the laptop is lass then 1 year old and the Erupters are brand new but after just a couple of minutes running they all go sick/dead.

I've had very cold air blowing on then from the start and they are not hot to the touch at all (warm of course.)

What the fuck is happening? I can't run them for over 3 or 4 minutes without them shutting down.

Unfortunately, the Raspberry Pi is known not to work well with USB 3.0 hubs. I believe it's a hardware limitation of the Pi, not an issue with any particular software or drivers.

having issues with raspberry pi so i thought i give windows a go but also problem...



any ideas what i'm doing wrong?

_____________________________

I have new aitech 3.0 usb hub... other saying usb 3.0 issue with latest cgminer. switching to older version will help?

________________________

Dang.. tried old hub and is working... now what? I have too many erupters for old hub...

___________________________

I only have 3 plugged in but cgminer seems to be only using 1 f them. the thirds light is not even on. blinks now and then. Maybe that is the one that is being used? Why not the others?

Some setting I'm missing?

___________________________

Okay sorry for being such a n00b i had to unplug and replug the light erupters and now they are recognized..

also some old tutorial had me install some com driver that was fouling stuff up.

still need to figure out how to use my new hubs...?

____________________________

Okay I have a laptop with a usb3.0 port and it's all running fine. That's good but now I have doubts that a pi will work...

It continued on for 20 min doing the same errors and not really hashing.

Yes the dll as well.  I fixed it by unplugging the hub from the USB3.0 port and plugged it into another USB3.0 port now everything works.  But I have to leave CGMiner running while I swap the ports. So far so good.

(Hopefully the dll as well). Some read errors like that are harmless and are more likely at startup, provided it goes on to hash at the normal rate. Can you describe exactly what the problem is?

thank you