Bitcoin Forum
January 29, 2023, 04:44:45 PM *
News: Latest Bitcoin Core release: 24.0.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 »
161  Bitcoin / Mining software (miners) / Re: Unified miners communication protocol on: September 02, 2013, 04:55:02 PM
Users don't want different applications and interfaces for each of their devices.
That depends. If the two devices are completely different in their feature set, I'd rather have two applications open, than one common one that shoehorns everything into the same format that either throws away a lot of features, or requires an overly complex specification to capture all possibilities.
162  Bitcoin / Mining software (miners) / Re: Unified miners communication protocol on: September 02, 2013, 04:14:27 PM
Here we go....

The problem is that the information from the hardware is unstructured. One piece of hardware may have a board temperature sensor, another piece of hardware may have two. Or, maybe one for the board, and one for the power regulator, and maybe one integrated into each of the 512 chips. It's going to be impossible to find a common way to bind all these different kinds of properties, and find a nice way to format them all in a single line on a screen.

And the bizarre thing is that all the information about LEDs, clocks, voltages, error rates, and chip temperatures goes into the mining software, which doesn't really have a clue what to do with that. So, you need equally complicated config files to tell it that LED A needs to turn color B when temperature sensor C is >= D degrees.

Really, this information is something that only concerns the mining hardware and the user. There's no need to standardize it all, just for the benefit of the middle man who doesn't really care anyway.  A better approach would be to create a mining library that's responsible for reliable network communication, and provides a standard get/put work interface. That way, the vendor can just write his own application, communicating with it's own hardware, and just call the mining library to get fresh work and submit the results.
163  Bitcoin / Mining software (miners) / Re: Unified miners communication protocol on: September 02, 2013, 10:16:56 AM
What i mean is that each nonce can be a solution and skipping just one may cause you to miss a valid solution.
Instead of 'skipping', think of it as 'replacing'. The hardware is still looking for valid solutions, just using different combinations of coinbase/timestamp/nonce. You are just as likely to find a solution if you only search half the nonce space, increment timestamp, and search the same half again in the same time as another miner searches the whole nonce space once.
164  Bitcoin / Hardware / Re: [ANN] Bitfury is looking for alpha-testers of first chips! FREE MONEY HERE! on: September 02, 2013, 06:20:57 AM
Very nice, very colorful!
165  Bitcoin / Mining software (miners) / Re: Unified miners communication protocol on: September 01, 2013, 10:13:00 PM
+1 There is actually a drawback - you may miss a valid solution. It may not be important if you only care about your shares from the pool, which are always paid, but as a solo miner I DO CARE if i miss my chance, because of that
It makes no difference whether you scan 1 full range, or 2 half ranges. The only thing that matters is how many hashes per second you can do.
166  Bitcoin / Mining software (miners) / Re: Unified miners communication protocol on: September 01, 2013, 08:29:35 PM
Why stop scanning at all? There's no benefit to ignore the rest of the nonce space.
It's a limitation of the hardware. The bitfury chips have 756 separate hashing cores, all working in parallel, with each core hardwired to search a fixed 1/1024th of the nonce space.
167  Bitcoin / Mining software (miners) / Re: Unified miners communication protocol on: September 01, 2013, 08:03:21 PM
Quote
why to calculate twice the block header (new work) and waste cpu time, when you can simply pass the same one to two chips?
With partial scans, you just introduce a lot of extra complexity. Before you can use it, you need to know if the hardware has options to set the nonce range, and you need to know the exact limitation of the hardware. For instance, the bitfury chips only scan 756/1024 of the nonce range, but the hole is not contiguous, and not user-settable. To match this limitation with other hardware is very complicated. Even if you wanted to try, it requires extra commands to obtain the information from the hardware.

To generate some new work is simple. You just call the code you already have, except a little more frequently. Sure, it wastes some CPU time, but I'd like to see that this is a problem before creating a solution.
168  Bitcoin / Mining software (miners) / Re: Unified miners communication protocol on: September 01, 2013, 07:30:58 PM
cscape your use case perfectly fits the current draft without the optional parameters, so this is good. Please note, that the idea is not to limit it to the current hardware only, but to be able to support future hardware and its oddities. A good example would be that BF chips do not scan the entire range, but you may have another hardware, which is able to scan the rest, so nonce range is useful option.
Why would you care about scanning the rest of the nonces ? It's much easier to ignore that part of the nonce space, and create some new work instead.

169  Bitcoin / Mining software (miners) / Re: Unified miners communication protocol on: September 01, 2013, 06:13:02 PM
The way I have it implemented in my USB firmware is:

work job_id block_header

The block header includes the time stamp, and the hardware is allowed to increment it. The job_id is just a number. There is no nonce range (hardware always searches full range), ntime rolling is always permitted, difficulty is set through separate command but I like your idea of including it in the work command. I don't really see a need for a nonce range. With fast hardware, the entire 32 bit nonce range is searched in just a few seconds max, and with slow hardware (what's the point ?) you can always cancel old job when a new one comes in.

To submit a valid nonce, the firmware responds with

submit nonce job_id timestamp

I have no 'needwork' command. The idea is that the host provides work quickly enough to satisfy the hardware. In case the work doesn't come quickly enough, the hardware starts incrementing the timestamp. So, if the host does not want to accept ntime rolling, it is responsible for supplying fresh work before the hardware needs it. 

I also don't have cancel job mechanism. The hardware detects that prevhash field has changed, and automatically cancels old work as quickly as it can. Of course, it doesn't hurt to include an explicit cancel command. Another option would be to include a cancel flag in the 'work' command, which is nice because when you cancel old jobs you must provide new work at the same time, otherwise the hardware has nothing to do.


170  Economy / Service Announcements / Re: [ANN] Bitfury ASIC sales in EU and Europe on: September 01, 2013, 11:33:06 AM
- SSH into your Raspberry Pi with user pi (default password = raspberry)
And you should also change your default password, otherwise the unit can still be accessed.
171  Bitcoin / Hardware / Re: [ANN] US/North American Bitfury sales now open ***full prototype pics*** on: August 31, 2013, 06:48:46 AM
Here's pinout diagram of the RPi I/O connector. There's a +5V pin that can be used to power the RPi. On the m-board is a 12V->5V regulator that feeds into that pin.
172  Bitcoin / Hardware / Re: [ANN] US/North American Bitfury sales now open ***full prototype pics*** on: August 31, 2013, 05:30:08 AM
I'm reasonably sure the RPi is powered off the header on the M-card.
Correct. The M-board has a regulator that provides power to the RPi connector.
173  Bitcoin / Hardware / Re: [ANN] US/North American Bitfury sales now open ***full prototype pics*** on: August 30, 2013, 04:16:02 PM
If one H-card dies in the M-card chain (v1), the whole (400GH) miner is out, no?
No, just remove the bad h-card, and reorder the cards so that the unused sockets are all at the end. Likewise, a single partially broken h-card can be moved to the end of the chain.
174  Bitcoin / Hardware / Re: [ANN] Bitfury is looking for alpha-testers of first chips! FREE MONEY HERE! on: August 30, 2013, 04:03:33 PM
The spitest program was announced here:

https://bitcointalk.org/index.php?topic=228677.msg2515472#msg2515472
175  Bitcoin / Hardware / Re: [ANN] US/North American Bitfury sales now open ***full prototype pics*** on: August 30, 2013, 03:43:13 PM
I, at least, would be interested if it was relatively inexpensive, but I think they are wanting an m-board adapter to eliminate the RPi...
You mean a board to interface to the current m-board ? That's basically only a RPi replacement, but less powerful, and at least as expensive.

I was thinking more of a small PCB with an edge connector, where you plug in a single H-CARD. This replaces both the big m-board and the RPi, and would be useful for people only interested in mining with 1 or 2 H-CARD attached to a PC.  For more H-CARDs, the m-board is the more practical solution.
176  Bitcoin / Hardware / Re: [ANN] US/North American Bitfury sales now open ***full prototype pics*** on: August 30, 2013, 03:21:42 PM
I guess it would not be impossible for someone to create a USB to RPi GPIO/SPI adapter board.
If there's enough interest, we wouldn't mind drawing up an adapter board for a single H-CARD to USB and/or ethernet.
177  Bitcoin / Hardware / Re: [ANN] US/North American Bitfury sales now open ***full prototype pics*** on: August 30, 2013, 03:18:14 PM
will future revisions of the H boards potentially have native USB connectivity so we won't have to rely on a $40 throw away SoC RaspPi to run our miners?
Our S-HASH board has a native Ethernet connection and can connect directly to a pool.

See this thread for more info

178  Bitcoin / Hardware / Re: [ANN] Bitfury is looking for alpha-testers of first chips! FREE MONEY HERE! on: August 29, 2013, 07:15:14 PM
Holy thats pretty impressive Smiley  Any news on full production/cost?

Like with the S-HASH design, we're not looking to mass produce this ourselves, but we're open for licensing agreements with 3rd parties to build them. It's hard to estimate a cost. It all depends on volume and what kind of deal you can make with the bitfury ASIC sellers.
179  Bitcoin / Hardware / Re: [ANN] Bitfury is looking for alpha-testers of first chips! FREE MONEY HERE! on: August 29, 2013, 01:23:58 PM
The 5 parallel resistors on the back are (counting from corner): 220k, 147k, 187k, 220k, 100k. Did they put silk screen on the back ?
180  Bitcoin / Hardware / Re: [ANN] Bitfury is looking for alpha-testers of first chips! FREE MONEY HERE! on: August 29, 2013, 12:49:38 PM
Or wrong value. Most likely in compensation loop.

Or in the (over)current sense resistors. I assume the resistors are all unmarked ?
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!