Pages:
Author

Topic: [Announcement] Avalon ASIC Development Status [Batch #1] - page 8. (Read 155335 times)

hero member
Activity: 574
Merit: 500
Huh... 14th, then the 19th, now it's the 21st? 

Interesting...

You get very little irony in your diet, true...?


It's not irony when I'm pointing out that they are doing the exact same thing they have been vilifying us for.  So, yeah, I guess it's irony, but not on my part.

BitSyncom: We are shipping on the 14th! BFL you keep pushing your date back, it is dishonest to push your date back!
BitSyncom: We are shipping on the 19th! BFL you keep pushing your date back, you suck because you keep missing your date!
BitSyncom: We are shipping on the 21st! BFL you keep pushing your date back, we've only pushed it back two days!

I guess we'll see in another 7 days.  Irony indeed.


Be quite the adults are speaking
legendary
Activity: 4690
Merit: 1276
For an 'open source' project, Avalon is disappointingly light on details on the avalon-asic.com site,
Open source doesn't mean you just get the details/source. It means customers get it with the product.

If I cannot evaluate things to my satisfaction before I pull out my private key, the private key will remain in it's protected sheath.  Just sayin'.  If I hear back from credible sources that I have a hope of obtaining the control over the device that I want, that may be good enough though.
but as I understand things, the devices have at least the capability of being stand-alone units.  That means they have probably a full linux distro*.
IIRC, someone said it runs Openwrt.

That's a 'full Linux distro' to me.  (To be fair, I've not played with OpenWRT yet at this point.)

edit: quotes
legendary
Activity: 2576
Merit: 1186
It would not be hard to create a simulated network Test rig with a couple of servers
It would take all of 5 minutes on 1 server to setup a private testnet for any number of devices using GBT.
hero member
Activity: 574
Merit: 500

 

In my mind this is the point where BFL lost some major credibility.  Either they were lazy or they were greedy.  Take your pick.

Bitcoin itself is still 'experimental'.  I see twanging on the mining effort rates as a good thing.  Any data it adds to the body of knowledge about the behavior of the system is great with me.

I do remember Avalon's statements and thought they were stupid at the time.  It counted as a _negative_ toward their credibility in my mind.

BFL never had any credibility to damage as far as I am concerned.




I understand your sentiment and we can agree on some things.

But to extend the 'experiment' argument let's put AMD in BFL's (prior) position.  

Would it have been necessary, for experimentation reasons, for AMD to burn-in test the 7970 on main-net?

It would not.  It would not have been necessary.  It would have given no value towards understanding bitcoin's behavior.  Nothing that hadn't already been discovered during the CPU to GPU transition.

A full Main-net test is not needed... It would not be hard to create a simulated network Test rig with a couple of servers

About 5-8 days dev work for somebody who knows the code base

To do a live main-net test points to no knowledge of the needed process or what they are doing

legendary
Activity: 2576
Merit: 1186
For an 'open source' project, Avalon is disappointingly light on details on the avalon-asic.com site,
Open source doesn't mean you just get the details/source. It means customers get it with the product.

but as I understand things, the devices have at least the capability of being stand-alone units.  That means they have probably a full linux distro*.
IIRC, someone said it runs Openwrt.
legendary
Activity: 4690
Merit: 1276
I understand your sentiment and we can agree on some things.

But to extend the 'experiment' argument let's put AMD in BFL's (prior) position. 

Would it have been necessary, for experimentation reasons, for AMD to burn-in test the 7970 on main-net?

It would not.  It would not have been necessary.  It would have given no value towards understanding bitcoin's behavior.  Nothing that hadn't already been discovered during the CPU to GPU transition.

I'm definitely not trying to argue that appropriate burn-in could not be done without using the primary net.  Just that it is (in my opinion) pointless.  And even counter-productive.

For an 'open source' project, Avalon is disappointingly light on details on the avalon-asic.com site, but as I understand things, the devices have at least the capability of being stand-alone units.  That means they have probably a full linux distro*.  All kinds of real-world testing would be appropriate, and specifically hooking up to various pools, solo mining of some for perhaps, etc, since that is what a customer would wish to do. (Though actually to be fair, most of this kind of stuff only needs to happen for a random sample.  If that.)  But generally speaking, it becomes increasingly difficult to emulate real world conditions when things start to become complex.

(*) This reported design is a giant selling point to me.  If I can shit-can the base image and build my own, I very well may pay Avalon some money for some hardware at some point.

---

While I am at it here on this thread, here's a feature request for subsequent generations of gear.

I would like to see some technology (like TPM or some such) which would allow me to make the barrier to entry for unauthorized use high.  The use-case is that I would want to run units remotely and have them be under the care of non-fully-trusted parties.  By making the units as useless as possible to folks other than myself I would hope to encourage the minders to leave them alone (rather than to steal them.)

sr. member
Activity: 322
Merit: 250

 

In my mind this is the point where BFL lost some major credibility.  Either they were lazy or they were greedy.  Take your pick.

Bitcoin itself is still 'experimental'.  I see twanging on the mining effort rates as a good thing.  Any data it adds to the body of knowledge about the behavior of the system is great with me.

I do remember Avalon's statements and thought they were stupid at the time.  It counted as a _negative_ toward their credibility in my mind.

BFL never had any credibility to damage as far as I am concerned.




I understand your sentiment and we can agree on some things.

But to extend the 'experiment' argument let's put AMD in BFL's (prior) position. 

Would it have been necessary, for experimentation reasons, for AMD to burn-in test the 7970 on main-net?

It would not.  It would not have been necessary.  It would have given no value towards understanding bitcoin's behavior.  Nothing that hadn't already been discovered during the CPU to GPU transition.
newbie
Activity: 11
Merit: 0
Once this information was made public and was met with criticism BFL claimed that all profit resulting from burn-in testing with main-net would be donated to the miner app dev's.

Maybe I misunderstand but since BFL has released their android miner wouldn't they themselves now be the "miner app dev" mentioned?
legendary
Activity: 4690
Merit: 1276

 

In my mind this is the point where BFL lost some major credibility.  Either they were lazy or they were greedy.  Take your pick.

Bitcoin itself is still 'experimental'.  I see twanging on the mining effort rates as a good thing.  Any data it adds to the body of knowledge about the behavior of the system is great with me.

I do remember Avalon's statements and thought they were stupid at the time.  It counted as a _negative_ toward their credibility in my mind.

BFL never had any credibility to damage as far as I am concerned.

sr. member
Activity: 322
Merit: 250
think would you really want to start a trend of ASIC producing companies using their product and reaping the rewards first; increasing the difficulty while holding funds deposited by awaiting customers on a product that was delayed?

That is not good publicity and would NOT be good for bitcoin

Like I said, if the vendor wanted to they could discount the unit on the basis of any money generated during the burn-in period.  There is a total amount of money theoretically possible to earn during a few days, and it is not a huge amount.  Just does not seem like a big deal to me. 

As for damage to the Bitcoin network generally, what could it possibly do that is not going to be done several days later when customers receive their units anyway...assuming the units work?

Anyway, there is every bit as much reason to burn in the first generation of ASIC chips and PCBs as there is to test a car coming off the assembly line.  Again, I would almost demand that the vendor do this as one of the tasks I am paying them for (or would be if I were a customer.)




Hmmmmm.


TL;DR:  ASICs and MCU's do not implement the complete block solving protocol - so burn-in testing of all units with full protocol is not needed AT ALL.

The premise is faulty - so it's a non issue in terms of burn-in testing - but very much an issue in terms of vendor credibility.  

The Avalon people were correct when they blasted anyone who suggested that burn-in testing, a complete burn-in cycle, required a full reproduction of the block solving protocol.  It isn't required.  Main net testing is not required.  Testnet-in-a-box is not required.  As a proof of concept measure the first samples of chips would of course need to be confirmed by using a full reproduction of the protocol.  However, still main net testing is not a requirement.  And even then a testing protocol, independent of the full protocol, can be used (must be written) for large scale functionality and burn-in testing of specific purpose for which the ASIC and MCU was designed.

BFL was initially going to use main-net for testing.  Josh/Inaba said it himself.  That is, full burn-in cycle for all units produced.  I and many others blasted them for such a "silly" idea (I quote Avalon).  

BFL's argument was that:

1.  "The dev's" frowned upon using test-net for such large QA activities.  The consequence would be astronomically high difficulty that could interfere with the testing activities of others.
2.  It was not possible to perform testing in other non-impactful ways, so main-net was the choice.

Once this information was made public and was met with criticism BFL claimed that all profit resulting from burn-in testing with main-net would be donated to the miner app dev's.

When this claim of donation of profits did not assuage BFL's critics Josh/Inaba did some blasting of his own by making accusations against those critics that:

1.  Critics didn't care about the miner dev's.
2.  Critics didn't care about the network's security.  Bizarrely, Josh/Inaba twisted critics arguments (memory is hazy) in to one where critics held an irresponsible position and jeopardized network security by the fact that if BFL didn't burn-in test with main-net to establish an equilibrium the combined capacity of units where customers had taken delivery threatened a 51% situation.

Of course, point 2 doesn't hold much water since, at the time, BFL's 1/3 shipping plan called for mass assembly, testing, and shipping thereby largely eliminating the risk of 51% in the hands of either one or a relative few customers.


In my mind this is the point where BFL lost some major credibility.  Either they were lazy or they were greedy.  Take your pick.
legendary
Activity: 2856
Merit: 1520
Bitcoin Legal Tender Countries: 2 of 206
no single sign. this hurts me!  Cry
420
hero member
Activity: 756
Merit: 500
One entity with over 22 T/hash/s power at their disposal....I believe there's a phrase often used to describe such a situation
legendary
Activity: 4690
Merit: 1276
think would you really want to start a trend of ASIC producing companies using their product and reaping the rewards first; increasing the difficulty while holding funds deposited by awaiting customers on a product that was delayed?

That is not good publicity and would NOT be good for bitcoin

Like I said, if the vendor wanted to they could discount the unit on the basis of any money generated during the burn-in period.  There is a total amount of money theoretically possible to earn during a few days, and it is not a huge amount.  Just does not seem like a big deal to me. 

As for damage to the Bitcoin network generally, what could it possibly do that is not going to be done several days later when customers receive their units anyway...assuming the units work?

Anyway, there is every bit as much reason to burn in the first generation of ASIC chips and PCBs as there is to test a car coming off the assembly line.  Again, I would almost demand that the vendor do this as one of the tasks I am paying them for (or would be if I were a customer.)

420
hero member
Activity: 756
Merit: 500
think would you really want to start a trend of ASIC producing companies using their product and reaping the rewards first; increasing the difficulty while holding funds deposited by awaiting customers on a product that was delayed?

That is not good publicity and would NOT be good for bitcoin
sr. member
Activity: 462
Merit: 250
Clown prophet
Hehe... https://bitcointalksearch.org/topic/clown-prophet-prediction-for-asics-future-136880

They can get 2000+ coins daily in their blocks. In any point in World. This is $28000 daily income. Not being responsible for breaked customers. Did they sign contract with you?

So will they resist this temptation?
legendary
Activity: 4690
Merit: 1276
from what I remember all teams have said they will NOT test on any pools, bitcoin network, and avalon not even on the testnets, etc.

you won't be able to track them until customers are hashing
Just explain me at least one reason not to do that [having chips in hands].

As I understand things, the theory goes that they would jack up the difficulty and burn their customers (who are chomping at the bit to do the same thing.)  And/or damage Bitcoin generally by some non-nondescript means.  Neither has ever made much sense to me.

If I were buying early ASIC, I'd specifically request that my units were burnt in for at least a week ON the Bitcoin network.  If they wanted to be good guys they are welcome to split any profits with me, but I wouldn't request it.

The whole 'we will not mine' thing seems like one of those unimportant things which get moderately ignorant people all worked up and which vendors/scammers/re-sellers/whatever just throw up their hands over and state silly (but mostly harmless) policies because of just for PR reasons.

donator
Activity: 1419
Merit: 1015
Overhead is a good reason not to do it. They really don't care about mining, they just want to sell cards. They don't want to configure a pool, or make it look like they favor one pool over another. I mean, there's plenty of reasons to do so (proof, free coin, etc.), but the reasons not to are mostly ethical in nature. The reasons to do so run the risk of backlash.
sr. member
Activity: 462
Merit: 250
Clown prophet
from what I remember all teams have said they will NOT test on any pools, bitcoin network, and avalon not even on the testnets, etc.

you won't be able to track them until customers are hashing
Just explain me at least one reason not to do that [having chips in hands].
420
hero member
Activity: 756
Merit: 500
from what I remember all teams have said they will NOT test on any pools, bitcoin network, and avalon not even on the testnets, etc.

you won't be able to track them until customers are hashing
legendary
Activity: 1400
Merit: 1005
 just to REALLY beat a dead horse..
I'm pretty sure all that is left is an indent in the ground.  Maybe a few pieces of bone.
Pages:
Jump to: