I am running 0703 and kind of scared to update to 0813/0814. One person got bricked, several others report decreased hash rates. Anyone got positive results yet?
Me? I let 20130810-1 run overnight. The frequency dropped until it was about 304 MHz, and was steadily dropping when I stopped it. The stable frequency under 20130703 is 345-347. I am mining under eligius, and the recent behavior is online. I returned to 20130703 an hour or so ago. My temperature ran at 49°C and I had the idea that there was a "<" vs "<=" problem somewhere, or it's evil twin ! > vs if "<" then . However, I tried to raise the temperature set-point to 51, and this did not help. Wrong one. 10-1 is known to be slow. He is asking about 20130814. |
|
|
|
Watch out, the 2013-08-14 image seems to get rid of the temp cutoff settings in the Avalon GUI, make sure you add the appropriate command-line settings, especially for batch 3.
A reminder that I've said in my announces that there is no specific batch3 support in my firmware images. Luckily the default settings are too cold for batch3 so it will not harm your device, just crank the fans up to maximum. Add your parameters to the More Options box as I said in the 3.3.2 announce. Hopefully there will be new firmware from xiangfu soon which includes all my changes as well as his batch3 interface changes. |
|
|
|
guys quick question.
I have 2 identical 7970 cards. When my cards are cold, I see that fan speed is displayed differently for each of my cards:
GPU 0: 68.0C 50% | 620.3M/683.2Mh/s | A:3 R:0 HW:0 WU: 7.1/m I: 9
GPU 1: 55.0C 1815RPM | 620.3M/680.6Mh/s | A:5 R:0 HW:0 WU: 11.8/m I: 9
Eventually when they get warmer, they % value gets replaced with a RPM value in the 3000-3100 range.
Maybe I am wrong bu tthis seems like a recent behavior change. As far as I know, previously fan speed was always displayed in RPM...
That code hasn't been changed in a long time. Each device reports whether it can detect RPM speed or only report the set fan percentage speed. cgminer tries to show the actual RPM speed if it can (since that's safer than a device that thinks it's set to 100% but the fan isn't spinning), and falls back to percentage only when the device reports it doesn't support RPM. If something is changing while your machine is running, your driver/hardware is doing some funkiness  |
|
|
|
|
Block erupters use the icarus protocol for communication. There is no other way to talk to them. cgminer specifically detects erupters and treats them differently to other icarus devices. Older software versions did not know what an erupter was but worked with the regular icarus driver - however you had to add timing information for it to work optimally.
There is no such thing as an "erupter specific driver". Erupters use a serial usb interface chip between you and the device and your choice is to talk to that via a serial interface driver emulating the old serial communication port (invented 30 years ago) or directly via usb communications. The former approach (non-cgminer) requires an external 3rd party driver whereas the latter approach requires an driver to talk directly to usb (WinUSB) which is a Microsoft developed driver to use USB - no driver at all is needed on Linux or OSX to talk directly to USB.
Software changes will not get you a faster hashrate with these unless they're not working properly with one type of software.
|
|
|
|
Latest cgminer 3.3.3 on usb be is not working on p2pool - all rejected.
In p2pool log i see some startum errors.
Hence 3.3.4 |
|
|
|
A box of fans! Oh the irony... I take it you and Kano never got the "prototype" devices to test cgminer on? Nope |
|
|
|
A box of fans! Oh the irony... |
|
|
|
I am running 0703 and kind of scared to update to 0813/0814. One person got bricked, several others report decreased hash rates. Anyone got positive results yet?
Me? |
|
|
|
|
The fork of my miner uses the original stratum code I wrote for cgminer which used libcurl to set up the stratum socket connection. When this problem originally occurred, it would crash in libcurl. After tons of debugging I had so many crashes due to libcurl bugs that I decided to abandon using libcurl and just use raw socket code for all stratum code. That fixed the crashes (on both linux and windows) but on windows for some reason a socket just hangs up and never returns without any meaningful failure that should normally happen instead. That's why this bug manifests in two different ways. Older versions of cgminer would also crash during this interruption if you read back through this thread. However so many other crashes were fixed by abandoning libcurl that it was worth it. It's worth noting that improvements to this code keep going in and as recently as 3.3.2 another stratum disconnect issue was fixed, so if you're on an older version I highly recommend upgrading to 3.3.4 (the latest).
|
|
|
|
|
Unique 3.3.3 bug, upgrade to the 3.3.4 hotfix.
|
|
|
|
want to move past 3.1.1 on my pi with BE's but i really dislike arch. does 3.3.4 still have usb issues with rasbian wheezy? Is there a custom libusb that works with it yet?
Sorry if this is posted elsewhere i did a few searches and could not find anything. Thanks.
As we discovered, it's not cgminer that has usb issues, it's the libusb included with the distributions, so - yes you will need a custom libusb installed if you wish to use raspbian and not move to arch (which has the new libusb). You'll have to compile it yourself. Maybe some generous soul here will create a custom libusb package for raspbian? |
|
|
|
|
Cannot be used for anything else but mining sha256 coins.
Novel uses: doorstop, paperweight, bookends, boat anchor.
|
|
|
|
Maybe I misunderstood something I read earlier, I'm a bit confused with the different batches wanting different temperatures.
I thought with the new firmware that "70 was the new 50" for Batch 2 Avalons. Did I get that totally wrong?
For batch 3 Avalons, so yes you got it wrong. Remove those lines ASAP. |
|
|
|
Hi all,
Just saw the new firmware 20130813-1 and thought I'd upgrade from 20130703, which was giving me ~78Gh/s on my batch 2 Avalon. I was using just --avalon-auto to achieve this.
I'm getting less Gh/s now, probably about 72 or so. I'm using these options:
--avalon-auto --avalon-cutoff 80 --avalon-freq 300-360 --avalon-temp 70
Am I doing something wrong, do these numbers look completely off base?
Should batch 2 Avalons just stick to the 20130703 firmware?
Thanks,
_theJestre
Interesting. I uploaded a 20130814 (which is basically the same as the 20130813-1 firmware, just with the cgminer 3.3.4 tag). What I've found with the changed code is that my (batch2) avalon hovers at a lower frequency of 345 instead of 352, but ends up with the same hashrate. If there was something I'd recommend for you on batch 2, it is NOT setting your temperature so high. That is almost certainly contributing to your hardware errors and may damage your chips. If you really want to run them high, I'd suggest 60/70 instead of 70/80, but the defaults are there for a reason. |
|
|
|
Well I do apologize for anger directed at a person that made a simple error. I have been frustrated over mining issues that were not of his making. I understand everyone's nerves are frayed with the hardware/investment/profit/difficulty situation. Apology accepted and issue forgotten. Now we can get back to the serious business of complaining about hardware manufacturers. |
|
|
|
|
New version: 3.3.4, 14th August 2013
Hotfix release.
Human readable changelog:
- Fixed the breakage when mining on bitminter.
- Fixed the performance regression on avalons
- Added extra % counts to devs fields in API
Full changelog:
- API/miner.php add some % fields
- Nonce2 stratum submission is not working with nonce2 lengths >4, revert the
buggy __bin2hex function and use bin2hex.
- The write thread in avalon is only ever actually woken up by timeout so remove
the write semaphore and use a simple sleep poll.
- Fix warning.
- Interrupting reads on the avalon to start writes loses data so remove the
cgsem_post in the read code.
- Add room for the null byte at the end of the nonce2 string on stratum share
submission and zero the allocated ram.
|
|
|
|
yeah , but how many coins did you cost the doctors pool?
Not to sound nasty but the doc has 16-20th on line and if 10th of it was using your client. you 1/2 our real hash thus the bad luck was directly caused by your error.
I also realize that maybe only 1th , 2th of our pool was using your bad software. Your admittance not mine. I also realize that your bug was introduced at the end of the 37 mill difficulty.
Making it all the worst. I would say that none should do any update of working mining clients near the next adjustment. We will go from 37 mill to 50 mill in a day.
If your error was done on day one of an adjustment instead of day nine of an adjustment it would always cause less damage. I mine mining a while and I am tired of all the little slip ups made costing myself and others money.
So I ask you how much hash power did you take out on our pool > How long has the damaged occurred for 1 day 2 days. Does it match very closely our so called bad luck streak?
Let be generous and say it was an accident. It goes to show miners that even a slip thing like an update by a client can be used as a weapon against a pool.
So always be careful about updating your gear . The last 30 hours we have 2 blocks should have 8-9. If your error did damage which it did, how many of the 6-7 lost blocks are on you. care to guess?
I do not like to sound or read so nasty but after a long list of poor btc companies and the like I am tired.
All I can say is wow to that sort of response... just plain wow... I mean what proportion automatically upgrade without checking what happens on upgrade... seriously... wow I mean wow. The new version wasn't even up for 12 hours before I posted a fix. Seriously wow... You got some anger towards someone but it is seriously fucking misguided if directed at me. |
|
|
|
|
Apologies to bitminter miners if you upgraded to cgminer 3.3.3 which uniquely only broke this pool. I will be releasing a hotfix release today, 3.3.4, designed to mainly address this issue (if you are building from git the fix is already available).
|
|
|
|
2x 4 module with 1250W PSU and firmware 20130723.
I'm using --avalon-auto --avalon-fan 90-100 and Chip Frequency: 350M, MHS5s shows ~105000 for both.
Questions:
1) Is there a way to determine if the chips are really hashing and not just producing what I know as "Hardware Errors"?
2) One of the machines only shows a number under "Fan3", the other one under "Fan1" and "Fan3". Need I be worried?
1. Hashrate is only calculated from non-HW errors on the avalon driver 2. No |
|
|
|
|
Mixing them would confuse the software temperature targets of the different modules too since B3 modules read 20 degrees higher due to being closer to the chip.
|
|
|
|
|
Show Posts
