Ah, gotcha. You're just making things up, like that 7x performance increase and the 2 months prior shipping date. I guess the reality is Avalon is faster and will ship sooner. Thanks for clearing that up. This statement is not false, 66Gh/s > 60Gh/s That statement is false. The statement is "Avalon is faster and will ship sooner." Avalon will not ship sooner, therefore the statement is false.
No, AVALON is 400w at 60 GH/s. Ours is 60w... now, what is 400/60? Tell everyone, please.
BFL is scheduled to ship end of November, Avalon, sometime in January. How many days are between December 1st and January 31st? Tell everyone please?
Now, with your answer, how many days are in a month? Divide that by the answer you got above. Tell everyone, please?
Are you really so stupid that you need me to hand hold you through basic math? I had given you more credit, but I see that credit was misplaced.
This statement is false, 66Gh/s != 60Gh/s, In addition Avalon is scheduled to ship all their units out before Jan 31st. I am sorry, you are correct. Avalon is scheduled for 66 GH/s at 400w, my mistake. |
|
|
|
|
How is that twisting the announcement? That is the number they released, am I suppose to just pull numbers out of my ass? Fine, the Avalon will use 900w and hash at 800 MH/s, hows that? What did I twist for bASIC? Tom still hasn't released numbers and he's suppose to ship in a couple weeks.
|
|
|
|
Ah, gotcha. You're just making things up, like that 7x performance increase and the 2 months prior shipping date. I guess the reality is Avalon is faster and will ship sooner. Thanks for clearing that up. No, AVALON is 400w at 60 GH/s. Ours is 60w... now, what is 400/60? Tell everyone, please. BFL is scheduled to ship end of November, Avalon, sometime in January. How many days are between December 1st and January 31st? Tell everyone please? Now, with your answer, how many days are in a month? Divide that by the answer you got above. Tell everyone, please? Are you really so stupid that you need me to hand hold you through basic math? I had given you more credit, but I see that credit was misplaced. |
|
|
|
|
You can't, the serve decides what your appropriate share difficulty is based on how many shares you return (which is usually indicative of your hashrate).
|
|
|
|
|
Hmm... I remember I ran into this same problem in the quick stats a long time ago but I can't remember what caused it specifically...
I made a change to how that is handled, did it fix the problem? I can't duplicate it on my test accounts on command.
|
|
|
|
When is the Jalapeno getting FCC approval?
Maybe two weeks? We are waiting for the test lab to issue the test report. With the bump in power requirements on the MR and the new screen, we had to make changes, although the new screen is already certified. We are doing all the devices at once, since they all share the same board. |
|
|
|
Avalon is on an ancient 110nm technology while the BFL chip is the most advanced bitcoin mining ASIC in on the planet by several orders of magnitude, performance is 7x better than Avalon and the release date is 2 months prior to Avalon... yeah, exactly the same!
I suggest you read up on the definition of Orders of magnitudeOr... I suggest you look up the term vernacular before you try to educate me with grade school trolling. I'll give you a freebie, too: My use of "ancient" isn't technically accurate either. You might also want to look up hyperbole since you are unfamiliar with both it and "vernacular". They are useful words that you should have learned in grade school. Both of these lessons are free of charge, the next one will cost you though. PS - You should have a period after "magnitude" above. (Something else you should have learned in grade school.) |
|
|
|
|
Where are you seeing that?
|
|
|
|
|
Hah. That's a joke, right? You need to get your eyes examined, then.
Avalon is on an ancient 110nm technology while the BFL chip is the most advanced bitcoin mining ASIC in on the planet by several orders of magnitude, performance is 7x better than Avalon and the release date is 2 months prior to Avalon... yeah, exactly the same!
|
|
|
|
What gives you the impression ASIC will not be mass produced?
In addition, Avalon will be the only company so far to have an option to purchase ASIC chips directly from us if you wish to design your own PCB and controller. the details will be revealed in a later time.
(disclaimer: The following message express the opinion of Yifu G. and Yifu alone. It does not reflect Avalon ASIC in any way or form.)
I personally got into the ASIC game in the first place for network contingency. Business and profits aside, I realized the community was practically beat in the head and robbed blind by the existing competition after I gotten our ASIC simulation results.
before Avalon announced our unit, the market looked like this, ~$1000 for 27Gh/s and ~$1300 for 40Gh/s
Avalon announcs their unit $1300 for 60Gh/s.
after Avalon announced their unit, the market looked like this within a week, ~$1000 for 54Gh/s(+200%) and ~$1300 for 60Gh/s(+150%)
It really makes me wonder what our competitors' profit margin was before, and what would have happened if Avalon decided against the ASIC project.
Revise history! GO! You offered a "pre-order" of $1300 with a "regular" price of $1900! There was no magnanimity there; if you could have stuck to your original $1900 price point, I have absolutely no doubt you would have. It was Cablepair and BFL that forced you to stick to your "preorder" price just to compete. To be perfectly honest, the Avalon pricing played basically no part in our pricing structure and I'm pretty confident that it played very little if any part in Tom's either. We responded to Tom's offering, as Avalon is frankly not really competitive due to power consumption issues. |
|
|
|
|
Hour sixteen says YES... all you other hours: Piss off!
The pool isn't really unlucky. Just look at the bottom of the block stats page, we are within 4% of the median for the last 50 blocks, and it swings back and forth within 5% or so most of the time. It's pretty much exactly where you'd expect it to be over time.
|
|
|
|
|
When Luke was working on GBT and we were working on implementing a working vardiff, I had some concerns from a security standpoint. The Stratum get_transactions also raises some red flags for me, can you address security/throttling measures in place to prevent get_transactions being used a DoS method to overload a pool? Anything that leaves arbitrary data requests up to the client is an avenue for exploit and it is one of the reasons I have been so adamantly against user defined difficulties. If I want to DoS your pool, I crank up a couple of 1.5 TH minirig, set my difficulty to 1 and ask for getworks.
Same kind of problem with get_transactions: I'm pissed at you, so I just request all the get_transactions you'll send me over and over and over.
|
|
|
|
|
Package size. Do I get half a bounty?
|
|
|
|
|
EMC tracks difficulty per job, not per user. So it works on both the getwork and GBT side, so it doesn't matter which protocol you use or when you submit the work, as long as it's not stale, it will accept it if it's under the difficulty for a particular job. If you're discarding work when you receive new work without submitting it then yes you'd lose shares, but if you submit it even after you get new work, it's likely still valid within the stale window.
|
|
|
|
|
Ah, got it... no, it just uses a sliding window. Is there some drawback to bouncing around? The work is accepted for old difficulty work, so it doesn't matter if there is a difficulty change, since the difficulty is tied to the work sent out. You might be currently working on Difficulty 3 and sending back difficulty 2 shares from an older set of work that hasn't been sent back yet.
|
|
|
|
|
Well, the sliding window is currently set at 180 seconds, so, if I understand what you're asking, then yes to a limited degree.
|
|
|
|
|
Craigslist.
Wanted: ASIC designer. Apply within.
|
|
|
|
|
All of our contest winners have shipped, thanks!
|
|
|
|
|
Show Posts
