Con is there a way to show the temps of the individual dies without turning on debug?
Check API output. Plenty of info there. |
|
|
|
you can't mine with that miner that way.
there is no other way.
That's wrong. Avalons work fine plugged into a PC with a USB cable. |
|
|
|
New version: 3.12.0, 29th January 2014
- Another even number, so it's gotta be stable!
Human readable changelog:
- Antminer U1 support
- Numerous fixes for behaviour surrounding USB errors - pipe and IO errors, and no more attempting to reset the device since it's rarely helpful and occasionally harmful.
- Add support for AntminerU1 devices with the icarus driver.
- Add antminer U1 to comment in udev rules.
to 90 degrees.
Just to be a pain in the butt, but are you still working on making the antminer on its own driver so its own settings can be used. Still awesome step getting it to work. Jimjags version had it in a separate driver. I cant confirm or deny if its better since he only compiles in mac but hopefully its possible. Are you asking if antminer U1s work with other icarus devices? Of course they do. Are you asking about the S1 miner? That doesn't use regular USB so can only be run on the included tplink router hardware as far as I understand it. So I'm not sure what your question is? |
|
|
|
|
New version of cgminer 3.12.0 I just posted has some communication improvements for usb errors that hopefully should help the reliability of these.
|
|
|
|
|
Just posted a new version of cgminer, 3.12.0 which hopefully copes better with transient USB errors on these.
|
|
|
|
Good day,
thanks for the really fast FIX for the Antminer, but is with the ICARUS driver also overclocking possible?
regards
Not from cgminer itself, no. |
|
|
|
|
New version: 3.12.0, 29th January 2014
- Another even number, so it's gotta be stable!
Human readable changelog:
- Antminer U1 support
- Numerous fixes for behaviour surrounding USB errors - pipe and IO errors, and no more attempting to reset the device since it's rarely helpful and occasionally harmful.
- Libusb and libusbx have finally reconciled their differences and merged all their fixes together into a new official libusb release, so the main change in this version is updating the core code to include this latest libusb. Hopefully this might increase compatibility with some USB3 hubs on windows and make it more reliable (based on the changelogs I can see in libusb). This is the reason for the minor version number update to 12 as it's quite a substantial code change, hopefully only for the better!
- Increased the hashfast overheat limit default to 90 after extensive discussions with the engineers who designed the devices.
- Fixed a crash in the nanofury USB stick code.
- Fixed the displayed diff shown being wrong when solo mining.
- bab driver fixes courtesy of Kano.
Full changelog:
- Add support for AntminerU1 devices with the icarus driver.
- Add antminer U1 to comment in udev rules.
- Do away with usb resets entirely since we retry on both pipe and io errors now
and they're of dubious value.
- Retry on usb IO errors instead of faking success.
- Check that we've cleared the pipe error after a clear request, not the err
value which is unchanged.
- Update to libusb-1.0.18
- Change hfa overheat limit to 90 degrees.
- Relax timeout in hf get header to 500ms to match the usb timeout.
- Minion - check/clear interrupts for all chips
- Set info work to null after it is freed in nf1 after a restart to prevent
double free later.
- The second_run bool in libbitfury should be per device. Microoptimise its and
job_switched usage, removing the unused results array for NF1 devices.
- Fix displayed diff when solo mining at >2^32 diff.
- bab - stop stale work accumulating
- bab - set the default SPI speed back to 96000
|
|
|
|
|
You don't have any mining equipment so it eventually disconnects you since you're not actually doing anything. cgminer now only mines on dedicated ASIC bitcoin mining hardware, not CPUs or GPUs.
|
|
|
|
I have cgminer-3.10.0 on Fedora 19 with AntMiner. (I had to add --enable-bitfury to configure for it to compile - otherwise it would miss mcp2210.c.) It is mining at 600Mh/s, not the vaunted 1.6Gh/s, and it is barely warm (unlike the block erupters, which get quite hot in operation).
(5s):631.4M (avg):378.7Mh/s | A:349 R:9 HW:32 WU:0.0/m
Also, it is detected as USB1.1, not 2.0 (other 2.0 devices plugged into the port are detected as 2.0).
There is no official Antminer U1 support in cgminer yet, since the creators of Antminer never contacted the cgminer devs with code and/or hardware before it was released. The developers just recently received units they can develop for, and so Antminer support is likely eventually forthcoming. There are some forks of cgminer out there that have implemented an Antminer driver already though, though you'll have to look around for 'em and they're generally unsupported. Ah, well I am impressed that with no software changes it does the work of 2 Block Erupters at less than half the power. So with a little code merging and/or waiting, it should do the work of 5 Block Erupters. Someone want to point me to the best current cgminer code for them please? |
|
|
|
and again a miner that fails on p2pool  20% rejected shares anybody tried with cgminer 3.11 is this getting better performance? I'm not seeing anything like these reject levels. Only when I first start p2pool and first connect the device. After a while diff rises, p2pool stops chewing up CPU and then it all calms down to very normal reject and DOA rates and good efficiency. |
|
|
|
|
It is not unusual that even experienced miners and forum members are taking great risks at times by sending money to companies as soon as possible in order to be first simply because that's the only chance they'll get at making a profit, for all ASIC mining is a loss game by design thanks to this self perpetuating phenomenon.
|
|
|
|
I finally was able to reproduce this bug with nanofury usb sticks and have debugged it. The fix for this crash is now in git master and I suggest all users with these devices upgrade. Given the prevalence of these devices, I've also uploaded updated windows binaries denoted 3.11.0-1 with the bugfix.
Nice, thanks. Did this affect p2pool also? p2pool is working now here. Bug occurred with nanofury usb sticks during a restart message, and p2pool's restarts are 20 times more common. |
|
|
|
ok, but altcoins are gunna be profitable...
That's fine, but then this thread is in the wrong place. |
|
|
|
|
It will not be profitable to mine bitcoin with any GPU.
|
|
|
|
Con is it possible to Bypass the Rpi that is controling the BJ's and Sierra's and run the boards entirely controlled by a PC or Laptop, maybe it is the pi that is causing the unstable nature of the systems
sure , you can run it directly from a pc or a laptop, where cgminer is running , that's not a problem. You can run it off any PC, and that's preferable anyway since the RPi is a piece of shit. Just plug in a USB cable. The sierras don't even have one so you have to run them via USB. Any instability still around is firmware related and remember it's still early days since release (even though release was late) but once my sierra is running it does not miss a beat. |
|
|
|
Also I have further information that up to 90 degrees is safe so if you are struggling to keep it under 85 with the overclocking and cgminer's throttling is kicking in regularly, you can kick the overheat temp up to 90. I will be changing the default to that in the next version. The device internally sheds cores transiently anyway if it thinks it's overheating, and trips a thermal overload flag should all fail which makes cgminer shut it down so there are countless ways the device is protected.
Further instrumenting shows that 85 is actually safer because the board temperatures are only slightly lower than the core temperatures, and they can't handle much more so for now I'll leave the default at 85. Note that this is one of the gotchas with water cooling that PC users experienced: the fan for air cooling usually also provides lots of cooling for the motherboard. Don't take the cover off for the boards then stop getting as much airflow. |
|
|
|
The RPi is a toy and a piece of shit. Why anyone would run thousands of dollars worth of equipment off it is beyond me. Toss it and connect your devices to a real PC or laptop.
Trying to do exactly that with Karin's 3.11 build for Mac. Unfortunately, I'm getting a "Hashfast detect (6:3) failed to initialize (incorrect device?)" error. Update: It's hashing using 3.11 PC build. Must be a Mac driver issue. Never been tested on a mac. I build for linux and windows. Mac might need permissions with sudo and might need driver unloading to work. |
|
|
|
Then apparently that is called from ws2tcpip.h which is what cause the struct addinfo error but if I put it back in I get compatibility errors with at least the icarus device driver [since that was the first driver I set to enable if that makes any sense]. I'll put it back in and then go from there.
I enabled the issue feature on my experimenting if you find something and want to mention it off here.
Do you do any compiling through the windows version on minGW or is there something different you use link like the link you did above. I'm just making sure your not using a new compiler and didn't change it in the instructions.
I only cross compile with mxe for mingw on linux myself. Those instructions were done by a helpful member of the forum over a year ago and probably no longer apply. My cross compiler gcc version is: i686-pc-mingw32-gcc (GCC) 4.8.1 |
|
|
|
Is stratum hints in the winsock headers? This is what gotten so far. You have something more helpfull I'll try your way.
struct addrinfo is what's missing |
|
|
|
For people trying to cross compile ming on linux, start here: http://mxe.cc/ |
|
|
|
|
Show Posts
