I always thought the name came from the fact that in the earliest integrated circuits the masks were produced by hand using an opaque sticky tape on a transparent film.  A process known as tape-out, which you obviously didn't start until you'd completed the design.

roy

Yeah, OK, you're right.  So assuming (for ease of maths) 2^10 transaction per block, you need 10 hashes per Merkle root, so you need a host CPU capable of 3.75kH/s.  Hell, my first gen EEEPC would do that more than comfortably (although it wouldn't surprise me if that's 10% CPU or so - I'm sure enough to make the CPU fan come on, even if only at low speed

Ok, so you've convinced me, we've got a little time before ASICs are fast enough to worry about this.... :-)

roy

ETA: But in 2 years time, when we have $99 600GH/s coffee warmers, then I'm going to be asking for rollntime support :-)

Yes, that's an interesting point.  All the more reason to make use of that support rather than having the host it's connected to calculating Merkle roots at a high rate of knots.

ETA: if cgminer running on my EEEPC 701 driving a couple of ASIC miners can keep the CPU load low enough that the CPU fan doesn't come on, I'd be very happy.  My guess is that it would need the miner to roll ntime to accomplish this.

Hmm, are you saying that the need with getwork for the pool to explicitly permit rollntime (and to tell the miner how much it's allowed to roll ntime) is just a quirk of how traditional pools generate work?  And that the assumption is that a Stratum pool will just accept any valid block, regardless of the value of the ntime field within the block header (within reason)?

roy

Yes, but it increases the size of the work unit at the expense of complexity.  Incrementing ntime extranonce and computing a new Merkle root is something that probably can't easily done in a hardware miner without increasing hardware cost, hence requiring work (and communication) by the host that the hardware miner is attached to everytime the nonce wraps.  On the other hand, ntime rolling could trivially be done in hardware (in the MCU, or even in future designs in the ASIC) massively reducing the work done by the host.

My thought is that you would do both: you'd incrememnt the nonce, naturally (this is done in hardware in the FPGA or ASIC).  Then when the nonce wraps round, you increment ntime (which could be done in the hardware miner's microcontroller, or longer term, in the ASIC).  Once ntime has been rolled by some configurable amount (30 seconds, 60 seconds, whatever), then ntime is reset, the host PC incremements extranonce, calculates a new work unit, and gives this work unit to the hardware miner.

Bottom line: the work unit for the protocol may be 4.2 billion times larger, but the work unit for the hardware miner will probably be unchanged in the short term.  ntime rolling is a far easier step for the hardware to take then full merkle branch support in the hardware.

I have a question re Stratum, namely: does Stratum support rollntime? - I skimmed the spec and couldn't see a mention (and apologies if this has already been discussed and my search missed it).

What I'm thinking is this:  a 60GH/s miner (which we have every expectation is going to be pretty run-of-the mill once ASICs hit) is going to consume 14 work units per second, and it's reasonable to assume that they will continue to get faster over time.  Over time, as mining hardware improves, then on low-end hardware the CPU load on the mining host will start to become more significant, particularly if hosting a large farm of ASIC miners.  The USB I/O load may start to become significant, too, particularly if the mining host is actually an old laptop that only does USB 1.

ntime rolling can trivially be implemented in the hardware miner (even if in the microcontroller rather than in the ASIC), and doing so would reduce by almost two orders of magnitude the number of work units that have to be generated by the mining host and communicated to the hardware miners.

Longer term, I imagine that the microcontroller in ASIC miners will roll extranonce itself, but the extra CPU and memory requirements placed on the microcontroller, not to mention the extra firmware complexity, probably means this won't be a popular approach with hardware manufacturers until it becomes unavoidable.

Even once we get to that point, I can imagine that as ASIC cores get faster, and smaller (so one microcontroller potentially driving more of them) then hardware designers might opt for an architecture where ntime is incremented in the ASIC, with the microcontroller only rolling extranonce and calculating the Merkle root, just to reduce the CPU and IO requirements within the hardware miner.

This is all just me thinking aloud, and it might be that we really are convinced that the usefulness of ntime rolling is so far away that it's just not worth thinking about, but I just thought I'd throw it out there....

Thoughts?

roy

Thanks, Con, it's working nicely now.

roy

Ah, OK, so you can enter it without any scheme prefix (http: or stratum+tcp:) in either cgminer.conf or in pool management.

But, either way pool management just displays it as http: (regardless of what it actually is).  And when you resave your config file the URLs just get saved to cgminer.conf as http URLs (even if you entered them without the http and even if they're really stratum).

It is a bit confusing, but it doesn't cause any real problems.  It seems that in cgminer http: seems to actually mean autodetect... (ETA: and stratum+tcp: seems to be broken and best avoided)

roy

Yep, seems to work - don't know what I did wrong when I tried that in the past...

Thanks

roy

Hmm, I thought I tried that - lemme give it another go....

Still seeing backup pools that use stratum+tcp URLs detected as down by cgminer (2.9.6)

e.g. neither of these seem to work right as backup pools :

stratum+tcp://us3.eclipsemc.com:3333
stratum+tcp://eustratum.ozco.in:3333

However specifying them as http (even though they're not) seems to work:

http://us3.eclipsemc.com:3333
http://eustratum.ozco.in:3333

(Note I only see this problem for backup pools - specifying stratum+tcp for my first pool seems to work fine)

roy

Ah, OK, that sounds plausible.  Still, there has to be some reason why Molex chose to specify different ratings for different wire gauges and for whatever reason, they've rated an 8981 on 18AWG (the ATX standard) at 8A.   It's difficult to know exactly how the current density will be distributed in the crimp region...

roy

@MrTeal:

Also, just did the math and the figures match perfectly.  18AWG has almost exactly 20% smaller diameter than 16AWG, and hence 20% smaller circumferance.  I don't know exactly how 8981 connectors are crimped, but wouldn't that result in 20% smaller contact area?

And Molex derate the connector by 20% (i.e. from 10A to 8A)

No, sorry, that's pure speculation on my part; I just couldn't think of any other reason why Molex would derate the connectors for 18AWG and smaller...

roy

It's not the wire run I'm worrying about, it's the reduced contact area between the wire and the connector when you crimp it.

Molex only rates the connectors for the full current draw when you use 16AWG - see http://www.molex.com/pdm_docs/ps/PS-8981-4M4P.pdf

roy

Ah, OK, so that's where the Seasonic's 7A limit comes from - I should have spotted that.


Perhaps true for a premium quality non-modular PSU, but the ATX standard specifies 18AWG on the 8981 so you certainly can't rely on being able to draw 120W from the Molex on a low end PSU.

Good to know that there are PSUs out there that could power the bASIC directly from a peripheral connector - but notwithstanding that I think my point is still somewhat valid.  Many (most?) PSU's will not be able to power the bASIC and remain within spec without the use of custom cables.

I'm also wondering what the current draw of BFL is going to be.  If it's on the high side I may end up deciding to stay with the 13-14V wall wart to minimize the current through the barrel connector.

Right now it's true that we really have no hard information on power requirements for either product - and I imagine we may not for several weeks.  I guess all we can do is wait and see.

roy

It looks like stratum backup pools aren't detected as alive when specified with a stratum+tcp:// URL (though, strangely, they work fine if you put in an http:// URL pointing to the stratum port).

At least with EMC.

ETA, unless I don't understand what a stratum URL is supposed to look like.

With the default (failover) strategy, if I specify my pools as follows then only whichever pool I put first is detected as alive (and if that's down it *doesn't* failover).

stratum+tcp://us1.eclipsemc.com:3333
stratum+tcp://us2.eclipsemc.com:3333
stratum+tcp://us3.eclipsemc.com:3333

If I specify them as follows then it connects with stratum, detects all pools live, and failover seems to work:

http://us1.eclipsemc.com:3333
http://us2.eclipsemc.com:3333
http://us3.eclipsemc.com:3333

ETA again: Although to be fair some of the evidence that lead me to the above conclusion was collected from a version of git master HEAD somewhere between 2.9.3 and 2.9.4.  But I'm certainly seeing backup pools report as down in 2.9.4 - can't say for sure that failover is actually not working.

Is there any means of making this optional, at least for GBT?  I'm not particularly keen on this from a bandwidth point of view - I think I'd rather lose a small amount of work if I have to failover rather than permanantly double or triple my bandwidth usage

Right now I guess my only options are to force getwork or remove my backups.

roy

My electronics knowledge is probably a couple of decades out-of-date, but surely a traditional voltage regulator would be less power-efficient under over-voltage conditions (i.e. same current draw, but greater voltage drop across the regulator)?

That wouldn't apply to a DC-DC converter, of couse (and the chips obviously don't run on anything near 12V so presumably there's a DC-DC converter in there) but any reason why it'd be more power efficient at 13V or 14V than at 12V?  I'd expect it to be about the same.

BTW, where does 14V come from - not seen mention of BFL products being 14V before.

roy

ETA: I agree, though, that it's possible that their bricks have poor regulation, and although 13V nominal are really 12V under load.

Though it's unclear what voltage the ASIC Singles will want.  Inaba has said the ASIC singles will ship with a 13V power brick rather than 12V, but that they should also work with a 12V supply.  Which seems a bit of an odd state of affairs.

https://forums.butterflylabs.com/showthread.php/116-Trade-Ins-Notice-of-sending-back-FPGA-Singles?p=2283&viewfull=1#post2283