Bitcoin Forum
August 08, 2024, 06:36:37 AM *
News: Latest Bitcoin Core release: 27.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 268 269 270 271 272 273 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 ... 571 »
6341  Bitcoin / Hardware / Re: HashFast Sierra's Owners Thread on: February 28, 2014, 10:35:28 AM
Posted cgminer 4.0.1 which has major fixes for these devices.
Great work.
All we need now is the sierra's!
* ckolivas puts a few sierras up for download
6342  Bitcoin / Hardware / Re: Avalon ASIC users thread on: February 28, 2014, 10:19:45 AM
Con Kolivas <kernel@kolivas.org> also develops firmware for the Avy, so I am surprised he hasn't come out with an update. But I have alerted him to this post so hopefully he comes out with something soon; I find his updates are better than YiFU's. Smiley
My avalon fell below profitable mining so it's gone. Hence I'm not doing any more firmware.
Actually I still have all my automated scripts for building it lying around, so if you're brave, here is firmware that is done completely blindly and totally untested for 55 and 110nm avalons with cgminer 4.0.1

http://ck.kolivas.org/apps/cgminer/avalon/20140228/openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory.bin
6343  Bitcoin / Hardware / Re: HashFast BabyJet users thread on: February 28, 2014, 08:25:00 AM
Mine is running with rasperry py at 615 which gives me 460 at the pool. With 660 I get more than 500 at the pool, but thats not stable. Hope with the new firmware we get more OC potential ...
There's nothing in the new firmware that is likely to do that...
6344  Bitcoin / Hardware / Re: HashFast announces specs for new ASIC: 400GH/s on: February 28, 2014, 07:45:38 AM
Ask to buy some more hardware and see how fast they get back to you.

Well, everybody can just write them with some inane question about a possible hardware purchase and then, when they reply, say "Ok, so, while I have you, I wanted to ask about... [insert problems with existing orders here]."

I tried that and they respond with "I'm not authorized to discuss that topic but I will pass your request along and a representative will call you back". Nothing happens after that.
See, they responded quickly!
6345  Other / Meta / Re: It's Time For Theymos To Kill The Alt Section on: February 28, 2014, 05:16:55 AM
Whilst we are limiting people places to find information on a whole sub section of the next generation currencies, could we also start campaigns (1) to limit free speech (2) to start hunting whales again!  (3) to Stop being dicks (4) raise funds for me, to help with my sarcasism


If you dont like reading something, then dont type in the address, click on the link, and read it, just stay in the bitcoin section. its fairly simple really.


Just for referrence

Statistics for Altcoin section
921397 Posts
25870 Topics


Statistics for Bitcoin Section
355901 Posts
24614 Topics


Fairly clear winner if you ask me for shear usage, it doesn't make sense to remove the most active section.

my 2 cents ;-)
Amazing how this discussion can keep going round in circles. This is not a popularity contest. This forum was created to serve the bitcoin community. Altcoins are not that, even if you want them to be, or interpret it to be. Saying what the forum owners should care about based on popularity and what you care about is rich.

One could argue exactly the opposite: If three times the posts on this forum are about offtopic stuff, then removing irrelevant discussions would decrease the already overloaded forum to only 1/4 its load.
6346  Bitcoin / Hardware / Re: HashFast BabyJet users thread on: February 28, 2014, 05:02:32 AM
Me got no pi, no 0.4, no 4.0.1 that sees my BJ

 Sad

Then you in serious poo
6347  Bitcoin / Hardware / Re: HashFast Sierra's Owners Thread on: February 28, 2014, 03:45:56 AM
Posted cgminer 4.0.1 which has major fixes for these devices.
6348  Bitcoin / Mining support / Re: Bitmain AntMiner U1 Tips & Tricks on: February 28, 2014, 03:45:17 AM
Posted cgminer 4.0.1 with fixes for these.
6349  Bitcoin / Hardware / Re: HashFast BabyJet users thread on: February 28, 2014, 03:03:39 AM
Okay I've finally released cgminer 4.0.1 which is complementary to the 0.4 firmware

See:
https://bitcointalk.org/index.php?topic=28402.msg5418621#msg5418621
6350  Bitcoin / Mining software (miners) / CGMINER ASIC miner monitoring RPC linux/win/osx/mips/arm/r-pi 4.0.1 on: February 28, 2014, 03:00:24 AM
New version: 4.0.1, 28th February 2014

A few fixes for most users on top of 4.0, and some major improvements for hashfast users that hopefully will run in tandem with their 0.4 firmware release.


Human readable changelog:

- Fixed cgminer getting stuck at startup when no pool is valid and getting itself into an endless loop
- Fixed AMUs being detected as failing and resetting them too early
- Made the check for failing devices proportional to hashrate to not get false positives
- Queue size is now adjusted up dynamically when it bottoms out regularly which it may on very high hashrates/many devices
- Fixed ANU and other icarus devices falsely showing higher hashrates by calculating hardware errors - NOTE this means if you were seriously overclocking it before, your hashrate will appear to be lower now, but it was simply reporting wrong before.
- Changed the priority of various threads to bias towards work generation instead of giving the mining threads priority.
- Fixed a crash when a device drops out during an attempt to initialise
- Ava2 voltage detection
- Show the device number on the left without padding
- Fixes for devices that ended in OFF state instead of dropping out to allow them to hotplug
- Hashfast changes:
Multiple devices are now added one by one by hotplugging according to name and then initialising instead of trying to initialise them together which made them fail previously.
Dropping the clock speed on a device failure is limited to default clock speed of 550 and the amount of drop per failure can be configured or disabled with:
Code:
--hfa-fail-drop <arg> Set how many MHz to drop clockspeed each failure on an overlocked hashfast device (default: 10)

If you overclock your hashfast device with --hfa-hash-clock and cgminer detects
it failing to return hashes, it will restart it at a lower clock speed if
possible. Changing this value will allow you to choose how much it will lower
the clock speed or to disable this function entirely.
Devices with newer firmware can be named using the op name feature, or cgminer will generically choose a suitable name for them and display it at startup
Code:
--hfa-name <arg>    Set a unique name for a single hashfast device specified with --usb or the first device found

This command allows you to specify the unique name stored in nvram on a single
hashfast device. This name can be queried from the API stats command and comes
up as "op name". Discrete names are used by cgminer to try to maintain settings
across restarts, unplugs/hotplugs and so on. If this command is used by itself,
the name will be given to the first hashfast device it encounters and then
cgminer will proceed to go back to regular mining. If you have multiple devices,
it is best to discretely choose the device you wish to use with the --usb
command. For example
'lsusb' on linux shows the following devices (297c:0001 is a hfa device):
 Bus 001 Device 079: ID 297c:0001
 Bus 004 Device 042: ID 297c:0001
If you wished to name the second device Slug you would add the commands:
 --hfa-name Slug --usb 4:42
Devices that are re-hotplugged are recognised by their name or serial number if possible and appear back as the same device number on screen
More information in API stats
Updated udev rules file to allow regular users to update firmware
Fixes for corrupt message reading and runs of crc errors
Ability to disable the core shedding feature in new firmware:
Code:
--hfa-noshed        Disable hashfast dynamic core disabling feature

Newer firmwares on hashfast devices dynamically disable cores that generate
invalid data. This command will disable this feature where possible.
Numerous low level fixes


Full changelog:

- Refresh the log window on pool failure message at startup.
- Rework the pool fail to connect at startup to not get stuck indefinitely
repeatedly probing pools with new threads and to exit immediately when any key
is pressed.
- Fix for crashes with a failed startup.
- Use an early_quit function for shutting down when we have not successfully
initialised that does not try to clean up.
- Add more information to a hfa bad sequence tail event.
- Increase the work queue at the top end if we've hit the bottom as well.
- Set the work generation thread high priority, not the miner threads.
- Bringing each hfa device online takes a lot of work generation so only ever do
one at a time.
- Increase the opt_queue if we can hit the maximum amount asked for but are
still bottoming out.
- Keep the old hfa device data intact with a clean thread shutdown to allow it
to be re-hotplugged with the old information.
- Cope with the API calling hfa on partially initialised devices having no info.
- Show only as many digits as are required to display the number of devices.
- Cold plug only one hashfast device to get started, and then hotplug many to
minimise startup delays and possible communication delays causing failed first
starts.
- Send a shutdown and do a usb_nodev if hfa_reset fails.
- Null a device driver should thread prepare fail.
- Add a function for making all driver functions noops.
- Don't try to reinit a device that's disabled.
- Disable a device that fails to prepare.
- Check for lack of thread in watchdog thread for a failed startup.
- Make all device_data dereferences in the hfa driver safe by not accessing it
in statline before when it's non-existent.
- Add an option to disable dynamic core shedding on hashfast devices.
- Do not remove the info struct on a failure to hfa prepare.
- Detect an hfa device purely on the basis of getting a valid header response to
an OP_NAME query, leaving init to hfa_prepare which will allow multiple devices
to start without holding each other up at startup.
- Store the presence and validity of opname in the hfa info.
- api - buffer size off by 1 for joined commands
- minion - clean up statline
- Only break out of usb_detect_one when a new device is found.
- Use usb_detect_one in the hfa driver.
- Provide a usb_detect_one wrapper which only plugs one device at a time,
breaking out otherwise.
- Issue a usb_nodev on a bad work sequence tail in hfa
- Read in hfa stream until we get a HF_PREAMBLE
- Add shed count to hfa API stats output.
- Display the base clockrate for hfa devices with a different name to per die
clockrates to be able to easily distinguish them.
- Use op_name if possible first with hfa devices to detect old instances and be
able to choose the starting clockspeed before sending an init sequence,
reverting to setting op name and serial number as fallbacks.
- Make hfa resets properly inherit across a shutdown.
- Don't break out of hfa_old_device early if there's no serial number.
- Fix harmless warning.
- Allow the drop in MHz per hfa failure to be specified on the command line.
- Icarus - ignore HW errors in hash rate ... and fix detection of them
- Enable the hfa shed supported feature by default.
- Add to udev rules hfa devices for firmware writing.
- Remove ENV from hashfast udev rules.
- Add a --hfa-name command that allows one to specify the unique opname for a
hashfast device.
- Ava2 decode the voltage, get the temp_max
- Set the clock rate with a work restart instead of an init when changing to old
clocks for hfa
- Set opname on hfa devices without a serial number to a hex value based on time
to not overflow the field.
- Add op name to hfa API stats output if it exists.
- Set the actual op_name in hfa devices if cgminer is choosing it itself due to
it being invalid.
- Re-init an hfa device to its old data before setting up info structures as
their sizes may change.
- Remove the usb device whenever we do a running shutdown on hfa and do a
shutdown as the imitated reinit  to allow it to hotplug again.
- Reset opt hfa dfu boot after it's used.
- Comment out windows only transfer on hfa startup.
- Clean up structures unused in case of all failures in hfa detect common
- Clear all structures should we fail to hfa reset on adjusting clock on a
hotplug.
- Set master and copy cgpu hash clock rate for hfa when dropping it on a
restart.
- Set the master hfa clock speed to lower when shutting down a copy.
- Do a clear readbuf on any hfa reset in case the device  has not yet cleanly
shut down.
- Increase hfa fanspeed slightly more when it's rising in the optimal range than
falling.
- Always decrease hfa clock speed on a running shutdown and don't try sending an
init frame since it will be dropped regardless.
- Match hfa devices to old ones based on OP_NAME values before serial numbers if
possible.
- Read off the OP_NAME if it exists and is supported on hfa devices, setting it
to the device serial number or a timestamp if it is invalid.
- Updated hf protocol
- Check for an amount along with no error in hfa clear readbuf
- Hfa clear readbuf can return a nonsense amount when there's a return error so
ignore the amount.
- Running resets always cause a shutdown on hfa meaning the device will
disappear with modern firmware so always kill off the threads to allow
re-hotplugging.
- Reset the hfa hash clock rate to the old one if we find an old instance, only
setting the device id in hfa_prepare
- Keep the device_id on the original zombie thread for HFA in case of further
resets.
- Break out of hfa inherit if there is no device data.
- Inherit the hfa zombie instance after the device id has been allocated.
- The list_for_each_cgpu macro will dereference when there are no mining threads
yet.
- Make hfa hotplug inherit some parameters from a previous instance if the
serial number exists and is matching, avoiding dropping the clock on all
devices.
- Per device last getwork won't work if the device stops asking for work.
- Use the share_work_tdiff function in the driver watchdogs.
- Provide a helper function for determining time between valid share and getwork
per device.
- Store last_getwork time on a per-device basis.
- Limit the decrease of hfa clock rate on reset to the default clockrate.
- Base the hfa failure time on the current expected hashrate instead of a static
15 seconds.
- We shouldn't be trying to read from the hfa_send_shutdown function itself.
- Reset the icarus failing flag only when a valid nonce is found.
- Transferred value is corrupt on a NODEV error in usbutils.
- Set each miner thread last valid work just before starting its hash loop in
case there are delays at startup.
- Only memcopy *transferred data in usbutils if we have received only success or
a non-fatal error.
- Increase to 25 nonce ranges on icarus fail detect.
- Set icarus device fail time to be dependent on device speed to avoid falsely
detecting failure on slower AMU devices.
- Updated hf protocol header.
- Updated BE hf protocol header.
- Take into account shed cores on hfa devices when determining how many jobs to
send.
- Fix compilation error with two avalon types.
- Fix missing A1 files from distribution.
6351  Bitcoin / Hardware / Re: HashFast BabyJet users thread on: February 27, 2014, 11:42:48 AM
This link now contains a newer firmware for those who have tried the previous one:
http://ck.kolivas.org/apps/cgminer/temp/uc3.cropped.hfu

Found and debugged some more issues in cgminer and it should be much better with multiple devices attached at once in git, so I'm just trying to fine tune that before the 4.0.1 release.

The latest git compile still won't connect, but (like before) it can see it...

$ ./cgminer -n
 [2014-02-27 01:19:11] USB all: found 11 devices - listing known devices
.USB dev 0: Bus 6 Device 50 ID: 297c:0001
  Manufacturer: 'HashFast LLC'
  Product: 'M1 Module'                   
 [2014-02-27 01:19:11] 1 known USB devices   


FW: 0.2
HW: 1.1
Looks to me like you desperately need new firmware.

Today was another hot day in git land, so there was a period of instability. Hope to have the next version released tomorrow if no bugs show up overnight here.
6352  Bitcoin / Mining support / Re: AntMiner USB Overclocking? on: February 27, 2014, 04:03:28 AM
None of those commands mean anything in cgminer
For cgminer (assuming you're running the official one and not a fork), add: --anu-freq 250

Should give you 2GH
6353  Bitcoin / Mining software (miners) / Re: CGMINER ASIC miner monitoring RPC linux/win/osx/mips/arm/r-pi 4.0.0 on: February 27, 2014, 03:53:43 AM
Finally received my terraminers. After set up, I checked and found it running cgminer 3.12.0.

Am I OK running this version? Since you all are talking about 4.0

Thanks for any info regarding this matter.
It's extraordinarily difficult to update the cgminer on the beaglebone TerraMiners are distributed with, and you would void your warranty if you opened the box to connect them via PC, so you don't really have any choice but to depend on cointerra releasing new firmware with a newer cgminer. On the other hand, there are not a lot of code improvements that affect the CT devices after 3.12 so it should be okay, if not the best.
6354  Bitcoin / Hardware / Re: HashFast BabyJet users thread on: February 27, 2014, 01:27:59 AM
Did anybody else receive an E-Mail from hashfast with a 0.4 RC? Is this the same 0.4 posted earlier by ckolivas, or the newer one posted by ck just before? Or even newer 0.4?
That's the same as the one I just posted, but I only posted the firmware, not the tools.
6355  Bitcoin / Hardware / Re: HashFast BabyJet users thread on: February 26, 2014, 11:24:27 PM
This link now contains a newer firmware for those who have tried the previous one:
http://ck.kolivas.org/apps/cgminer/temp/uc3.cropped.hfu

Found and debugged some more issues in cgminer and it should be much better with multiple devices attached at once in git, so I'm just trying to fine tune that before the 4.0.1 release.
6356  Other / CPU/GPU Bitcoin mining hardware / Re: 3x7950 rig running time on: February 26, 2014, 09:44:33 AM
its a good idea to have your system autoreboot every 12-24 hours for increased uptime

Nonsense. Downtime to improve uptime? Windows may be less reliable than linux, but seriously it's no longer windows 95 days. Current windows is stable long term, and there's no excuse at all on linux.

Downtime will cause thermal contraction and after enough cycles you could have some traces fail requiring a reflow.  Let them run 24/7 and don't push them.  Slow and steady....

Correctness
6357  Bitcoin / Mining software (miners) / Re: CGMINER ASIC miner monitoring RPC linux/win/osx/mips/arm/r-pi 4.0.0 on: February 26, 2014, 03:38:41 AM
Hello, is this the right thread to talk about getting my 5 GC3355 5 chip USB miners, mining?
Alas no, the official mainline cgminer code does not support these devices, so you'll have to seek help from whoever is maintaining a fork that does.
6358  Bitcoin / Mining / Re: Mining ASICs Technologies (MAT) Announces 6TH/s Miner And Scrypt Miners on: February 26, 2014, 02:37:02 AM
Alleged hardware is impossible. Add this to the scam list and move on.
6359  Bitcoin / Pools / Re: [ANN] Stratum mining protocol - ASIC ready on: February 26, 2014, 12:25:44 AM
ckolivas, are you aware of cgminer bug (in ver 3.7.2) that causes cgminer to crash - it is related to stratum networking. When there are network issues, it can happen.
I have no interest in bug reports for old versions.

I know, I am just asking if it was reported and fixed in later versions.
Check the changelogs, I recall a few stratum patches.
6360  Bitcoin / Pools / Re: [ANN] Stratum mining protocol - ASIC ready on: February 26, 2014, 12:22:55 AM
ckolivas, are you aware of cgminer bug (in ver 3.7.2) that causes cgminer to crash - it is related to stratum networking. When there are network issues, it can happen.
I have no interest in bug reports for old versions.
Pages: « 1 ... 268 269 270 271 272 273 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 ... 571 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!