Bitcoin Forum
June 29, 2024, 09:09:43 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 [324] 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 ... 570 »
6461  Bitcoin / Mining software (miners) / Re: CGMINER ASIC FPGA miner monitoring RPC linux/win/osx/mips/arm/r-pi 3.12.3 on: February 08, 2014, 08:51:05 AM
who can gvie me a cgminer(AMD) for  MAX??   
You're in the wrong place. cgminer is a bitcoin miner ONLY and has no GPU code any more. Try sgminer.

where can I download Sgminer??
http://lmgtfy.com/?q=sgminer
6462  Bitcoin / Mining software (miners) / Re: CGMINER ASIC FPGA miner monitoring RPC linux/win/osx/mips/arm/r-pi 3.12.3 on: February 08, 2014, 08:42:42 AM
who can gvie me a cgminer(AMD) for  MAX??   
You're in the wrong place. cgminer is a bitcoin miner ONLY and has no GPU code any more. Try sgminer.
6463  Bitcoin / Mining software (miners) / Re: CGMINER ASIC FPGA miner monitoring RPC linux/win/osx/mips/arm/r-pi 3.12.2 on: February 08, 2014, 06:58:35 AM
Uploaded 3.12.3 with the correct fix now, reused same announce post.
Thank you Con!
I will give it a shot and report back if get work locks are gone.
However I see that you still write in last_device_valid_work get_work without a lock. Is it ok? Every where you use locks when writing to it but not in get work
Thank you
For that particular statistic it's pretty harmless and it's in get_work() for which the code needs to be as lean as possible. The lock protecting it elsewhere, stats_lock, is a global  lock potentially contended by quite a few threads so I decided against it.
6464  Bitcoin / Mining / Re: Its time to switch from CEX.IO? on: February 08, 2014, 06:36:45 AM
A preorder from BFL? Think about it...
6465  Bitcoin / Hardware / Re: HashFast BabyJet users thread on: February 08, 2014, 01:21:37 AM
Con,

Already found a bug, if the pool "goes away" it will never resume mining.  Getting this:
Code:
 [2014-02-07 16:44:34] Failed to getaddrinfo for stratum.mining.eligius.st:3334                                                 
 [2014-02-07 16:44:34] Testing pool http://stratum.mining.eligius.st:3334                                                      

The machine can access the pool, and DNS is fine, but cgminer gets stuck.  Any way you can put something in to exit if pool isn't active (like it used to work)?

This is precisely why we don't recommend anyone run new code until it's vetted.

-Phil
Actually none of the pool management code has been touched in ages so if you think there's a bug there, it's been there since long before any hashfast sanctioned release. Are you saying it never tried to reconnect?
6466  Bitcoin / Hardware / Re: HashFast BabyJet users thread on: February 08, 2014, 12:34:30 AM
Meh I screwed something up on 3.12.1 that would make cgminer just go idle eventually, so I've posted a hotfix 3.12.23.12.3 release.
There are good days and bad days  Roll Eyes
6467  Bitcoin / Mining software (miners) / Re: CGMINER ASIC FPGA miner monitoring RPC linux/win/osx/mips/arm/r-pi 3.12.2 on: February 08, 2014, 12:29:58 AM
Uploaded 3.12.3 with the correct fix now, reused same announce post.
6468  Bitcoin / Mining software (miners) / Re: CGMINER ASIC FPGA miner monitoring RPC linux/win/osx/mips/arm/r-pi 3.12.2 on: February 07, 2014, 11:32:11 PM
Okay I'm just  going to go cry in the corner for a bit, for it appears the fix in 3.12.2 didn't fix it.  Cry (Sorry Karin)

EDIT: Hit it in a debugger so I finally know what the problem REALLY is now... wait for a hotfix to the hotfix.
6469  Bitcoin / Hardware / Re: HashFast BabyJet users thread on: February 07, 2014, 10:34:51 PM
Meh I screwed something up on 3.12.1 that would make cgminer just go idle eventually, so I've posted a hotfix 3.12.2 release.

Thanks! I still get an insanely long reset time though (minutes instead of seconds), while cgminer 3.12.2 is contemplating pages of these messages:
I believe you are not on new firmware? I strongly advise people wait till they have new firmware as the new cgminer code is optimised around it and vice versa.

HI Ckolivas
That is all we can do . Still what Gh/s are you getting at the 600 clock range ?
I didn't get a BlowJob, I have a Sierra which is giving me >1.3TH @625 clock. I guess that translates to about 435GH for a BJ @ 625.
6470  Bitcoin / Hardware / Re: HashFast BabyJet users thread on: February 07, 2014, 10:28:53 PM
I've finally posted an official version that is designed to make the most of the new firmware coming up, cgminer 3.12.1

Announce and details here:
https://bitcointalk.org/index.php?topic=28402.msg4989440#msg4989440

This should also fix the windows reliability issues for those poor souls mining with their BlowJobs on windows.

ckolivas: I'm assuming your units have the beta HF firmware flashed on them? It seems like per-die frequency control could be very useful. How much faster speeds are you getting with the new firmware + cgminer per-die control?
I don't get any higher hashrates as a baseline - that's still dependent on the amount I overclock it and is basically unchanged. The difference is I can maintain much closer to my maximum hashrates when it's hot and it's much quieter and uses less power with the fans lower when it's cool. Previously I had to overclock it less because it was just too hot here. So on a hot day I get about 15% more hashrate now, but on a cool day it's the same as it was previously.

EDIT: To give you an idea of what I mean by hot, today it's going 40 degrees C.
6471  Bitcoin / Hardware / Re: HashFast BabyJet users thread on: February 07, 2014, 10:24:43 PM
Meh I screwed something up on 3.12.1 that would make cgminer just go idle eventually, so I've posted a hotfix 3.12.2 release.

Thanks! I still get an insanely long reset time though (minutes instead of seconds), while cgminer 3.12.2 is contemplating pages of these messages:
I believe you are not on new firmware? I strongly advise people wait till they have new firmware as the new cgminer code is optimised around it and vice versa.
6472  Bitcoin / Hardware / Re: HashFast BabyJet users thread on: February 07, 2014, 09:45:50 PM
Meh I screwed something up on 3.12.1 that would make cgminer just go idle eventually, so I've posted a hotfix 3.12.23.12.3 release.
6473  Bitcoin / Mining software (miners) / CGMINER ASIC FPGA miner monitoring RPC linux/win/osx/mips/arm/r-pi 3.12.3 on: February 07, 2014, 09:34:43 PM
New releases: 3.12.3 - 8th February 2014

Palindromic double hotfix release...  Embarrassed

Human readable changelog:

3.12.3:
- Fix for the sitting idle doing nothing bug.
- Add temperature to API devs call for hashfast devices

3.12.2:
- Brought back USB reset attempts on communication errors.
- Fixed the need for adding icarus-timing when overclocking antminer U1devices.


Full changelog:

3.12.3:
- Put the hashfast temperature into the cgpu structure so that it shows up in
the devs API call.
- We shouldn't block on no work situations directly from the getwork scheduler
itself.

3.12.2:
- Adjust antminer U1 timing according to command line frequency set, fixing the
need for icarus timing on the command line.
- Read pipe errors that don't clear are worth attempting to reset the usb.
- Revert "Do away with usb resets entirely since we retry on both pipe and io
errors now and they're of dubious value."

6474  Bitcoin / Mining software (miners) / Re: CGMINER ASIC FPGA miner monitoring RPC linux/win/osx/mips/arm/r-pi 3.12.1 on: February 07, 2014, 08:41:23 PM
WARNING:  There may be a problem with cgminer 3.12.1 that makes it stop retrieving work. I will investigate further and possibly release a fix in the next 24 hours. In the meantime I suggest users do not upgrade.

Sigh.

The Antminer U1 support isn't very stable either, mine all crapped out after an hour or so, I ended up with 50-odd as they dropped out and came back on.  I have 10 of them on a Anker hub, running off a PC running Debian Wheezy.

ANU7: Comms error (werr=-9 something something)

Then it disables, and a few seconds later the miner reappears using Hotplug and gets a new number.  Then I get a load of ANUxx Re-estimate: blah blah spam.

Same hardware runs the U1 on bfg perfectly for weeks on end.

I'll update the error messages when they happen again, I'm on an intermittent SSH connection through my phone from work at the moment.
Hmm I can try reinstating the attempted reset but I'm not sure it's going to fix that... How much were you overclocking them?
6475  Bitcoin / Mining software (miners) / Re: CGMINER ASIC FPGA miner monitoring RPC linux/win/osx/mips/arm/r-pi 3.12.1 on: February 07, 2014, 02:08:57 PM
WARNING:  There may be a problem with cgminer 3.12.1 that makes it stop retrieving work. I will investigate further and possibly release a fix in the next 24 hours. In the meantime I suggest users do not upgrade.

Sigh.
6476  Bitcoin / Hardware / Re: HashFast BabyJet users thread on: February 07, 2014, 08:27:15 AM
This should also fix the windows reliability issues for those poor souls mining with their BlowJobs on windows.

Hey now.  I never thought I'd be the Windows Defender(tm), but in the interest of fairness, the hashrate graph from Eligius for my Blowjobs is hard solid as a rock.  Really.  Cranking along at about 430gh each with no problems to speak of for what, almost 10 days now?  I can't complain a single bit about that aspect of the BlowJob experience.
I'm pleased to hear that. There are two camps with the windows people: everything's hunky dory and everything's funky shit - and that group is more common with 3.12.0. I'm hoping to get more of the former with the latest release.
6477  Bitcoin / Mining support / Re: Best Share (CGMiner) vs Difficulty? on: February 07, 2014, 08:20:48 AM
Well, I don't understand exactly why, but the relation appears to be 65536. So if the network difficulty is 0.063387, that times 65536 is 4154, so a share has to be greater than 4154 to be a block. Or, from a freshly restarted cgminer, the "best share" has to exceed 4154 to have found a block.

With current Bitcoin difficulty of 2,621,404,453.0646, a miner needs a best share of 1.718e14 to find a block, which would probably be represented as 172T (because it's 172 tera-somethings. Terradifficulties?).
65536 has nothing to do with bitcoin - that's altcoin crapulence. If the diff is 2.6 billion, you need a share of 2.6 billion difficulty with bitcoin.
6478  Bitcoin / Hardware / Re: HashFast BabyJet users thread on: February 07, 2014, 05:54:04 AM
I've finally posted an official version that is designed to make the most of the new firmware coming up, cgminer 3.12.1

Announce and details here:
https://bitcointalk.org/index.php?topic=28402.msg4989440#msg4989440

This should also fix the windows reliability issues for those poor souls mining with their BlowJobs on windows.
6479  Bitcoin / Mining software (miners) / Re: CGMINER ASIC FPGA miner monitoring RPC linux/win/osx/mips/arm/r-pi 3.12.1 on: February 07, 2014, 05:40:31 AM
Quote
By default, Antminer U1 devices run at a clockspeed of 200. This command allows
you to specify a chosen frequency to attempt to run all ANU devices at and the
value must be in increments of 25. Note that cgminer reports hashrate ONLY
FROM VALID HASHES so if you increase the frequency but your hashrate does not
increase or it decreases and hardware errors start showing up, you have
overclocked it too much. In the worst case scenario it will fail to start at
too high a speed.

Note that adding --icarus-timing=short is basically mandatory if you overclock them at this stage. The requirement for this should be fixed in a future version.
6480  Bitcoin / Mining software (miners) / CGMINER ASIC FPGA miner monitoring RPC linux/win/osx/mips/arm/r-pi 3.12.1 on: February 07, 2014, 05:26:15 AM
New version: 3.12.1, 7th February 2014

Mostly lots of bugfixes and heaps of new features for hashfast devices with upgraded firmware (due out soon).

Human readable changelog:

- Dynamic temperature based fanspeed and per-die clockspeed control for hashfast devices with the following new commands.

--hfa-fan <arg>     Set fanspeed percentage for hashfast, single value or range (default: 10-85)
--hfa-temp-target <arg> Set the hashfast target temperature (0 to disable) (default: 88)

Defaults chosen are based on extensive discussion with the design engineers responsible for the silicon and boards and basically it will keep your hashfast devices as close to the starting clockspeed as possible while keeping under~95 degrees by initially increasing fanspeed, and then decreasing the clockspeed on the hottest dies discretely. The output can be watched via the API. Enduring sweltering temperatures of up to 44 degrees here has made for an excellent real world test for this code.
- Numerous startup/reset/shutdown reliability improvements for hashfast
- Send a ping to the hashfast device at regular intervals if we don't have any work for it just so it knows cgminer is still alive to try and minimise the dreaded watchdog reboots.
- Lots of extra information in the hashfast API stats output.
- Hashfast serial number is shown as a hex value now.
- Better hashfast flushing of work on restarts - new firmware will build further on this.
- Antminer U1 overclocking support with --anu-freq note:
Quote
By default, Antminer U1 devices run at a clockspeed of 200. This command allows
you to specify a chosen frequency to attempt to run all ANU devices at and the
value must be in increments of 25. Note that cgminer reports hashrate ONLY
FROM VALID HASHES so if you increase the frequency but your hashrate does not
increase or it decreases and hardware errors start showing up, you have
overclocked it too much. In the worst case scenario it will fail to start at
too high a speed.
You basically must use --icarus-timing=short additionally to get the maximum benefit out of the overclocking (at this stage).
- Keep taking a trickle of work even if it's not being used just to keep an eye on pools and to keep the most recent work time up to date
- Make the top "window" wider since hashes these days come in the many millions and don't fit into 80 characters
- In verbose mode, the share above target message shows for which device
- Rolled back to the last good working libusb - the alleged libusb/x merge did not bring improvements and added windows instability with spontaneous exiting
- Handle better numerous non-terminal errors (the cgsem ones) that were leading to cgminer exiting
- BAB improvements courtesy of Kano
- Verbose mode will now show if it takes time to submit a stratum share, or it takes a long time to get a response from pools due to them lagging substantially, to help debug where latencies might be causing high stales.
- Added a way to zero other stats within each driver when the zero stats command is given (though no driver currently uses it).
- Fix one stale work item being passed to drivers after a block change.
- Fix a rare usbutils crash
- Pool diffs that are fractions only show one decimal place now.
- In debug mode a message will show up if there are substantial delays in getting work.
- Fix for massive data over the API
- Other random fixes.


Full changelog:

- Document new features for antminer U1 and hfa devices.
- Add support for ANU overclocking.
- Increase hfa fanspeed by more if we're rising in temp above the target than if
the temp is staying the same.
- Add debug output when get_work() is blocked for an extended period and add
grace time to the device's last valid work to prevent false positives for device
failure.
- Issue a shutdown prior to a reset command for hfa devices and lock access to
reads awaiting the response if the device is already running.
- Do not register as successful a hfa init sequence that reports the clockrate
as zero.
- Show device info in noffset nonce share above target message.
- Widen lines in top menu to fit extra large share values.
- Only show one decimal place if pool diff is not an integer.
- Show serial number as a hex value in hfa verbose startup.
- Slowly remove work even if it's not being used to keep the getwork counter
incrementing even if work is not used and as a test that pools are still
working.
- Increase the maximum diff between hfa dies to 100Mhz.
- Show which hfa die is bringing down all the others when decreasing all the
clock speeds.
- Increase the decrease when temp has increased more and we want to decrease it
on hfa.
- Give device info with share above target message.
- Allow throttling of hfa dies more frequently and increasing of speeds less
frequently.
- Wait after sending a hfa shutdown to allow the device to properly shut down
before possibly sending it more commands.
- Minimise the die clock differences in hfa to no more than 50Mhz.
- Check for when errno is set on windows as well as the windows variant for
errors.
- Revert "Update to libusb-1.0.18"
- Disable fan/die clock control in hfa if the firmware does not support it, with
notification.
- Add ability to enter ANU frequency as a multiple of 25 from 150-500.
- Decrease hfa clock by 10 if a reset is attempted due to the device remaining
idle.
- ifdef out icarus options unused without icarus built in.
- Reorder command line options alphabetically.
- Add no matching work to hfa API output.
- Change various logging message levels in the hfa driver.
- Only adjust clocks if there is no restart in hfa to avoid 2 restarts back to
back.
- Ensure we iterate over all dies adjusting temperate for hfa by starting
iterating after the last die modified.
- Clamp initial hfa fanspeed to min/max if passed as parameters.
- Allow hfa fanspeed to be set via command line.
- Further relax the target temperatures on hfa driver, targetting 88 degrees.
- Try one more time to get the hfa header on init since it can take 2 seconds
for all 3 boards on a sierra.
- Update authors for removal of gpu/scrypt.
- Wait for 5 temperature updates in hfa before adjusting fanspeed.
- Have some leeway before starting to throttle hfa dies.
- Use increments of 10 when increasing hfa clock since it may not have 5 MHz
granularity internally.
- Only perform a hfa fan speed update if we have new temps to work with.
- Correctly measure the hfa max temp and smooth out the changes in its value.
- Choose better defaults for min/max/default fan settings for hfa driver.
- bab - reduce def speed, fix speed staying in ranges and report bank/chips in
ioctl() errors
- bab - add info about number of boards/chips to each Dead Chain
- These may not be longs (eg: OSX)... fo a safe cast to ensure.
- bab - add dead boards and dead chains to stats
- Add fanspeed to hfa api output and set initial fanspeed to 10%
- Add hfa fanspeed control to try and maintain a target temperature.
- API-README correct new text format documentation
- API allow multiple commands/replies in one request
- Add op commands necessary to control hfa fanspeeds.
- Add OP_FAN to hf protocol header.
- Always show the stratum share lag time in debug mode.
- Add stratum share response lag time to verbose output if it's greater than 1
second.
- Add stratum share submission lag time to verbose information if it's over 1
second.
- Check for more interrupted conditions in util.c and handle them gracefully.
- Send a ping to hfa devices if nothing is sent for over 5 seconds.
- Add OP_PING to hfa commands
- Display the hfa serial number as a hexadecimal value.
- Add the ability to display a hexadecimal 32 bit unsigned integer to the API.
- Limit all hfa restarts for temperature control to no closer than 15 seconds
apart.
- Allow the hfa temp target to be disabled by setting it to zero.
- Handle interruptions to various select calls in util.c
- Add sanity check for silly overflows in hfa die temperature readings.
- Add per-die throttling control for hfa driver based on each die's temperature,
issuing a suitable reset to maintain the temperature below a configurable target
temperature.
- Update hf protocol
- Do not memcpy in usbutils unless data was transferred.
- Send a full allotment of jobs to the hfa device after a restart instead of
reading the status.
- Export the flush_queue function for use by drivers.
- Remove wrong goto
- Remove the unqueued work reference when we discard work from get queued as
well.
- Wake the global work scheduler when we remove a work item from the unqueued
work pointer.
- Discard work that is stale in the get_queued() function, returning NULL
instead.
- Add a call to a driver specific zero stats function when zero stats is called
to allow each driver to reset its own stats as well if desired.
Pages: « 1 ... 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 [324] 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 ... 570 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!