Once you two have put your handbags down and kissed and made up, could we get this thread back on topic please?
Who also thinks, as I have hinted at, and Bargraphics said recently, 'we shareholders won't know anything until there is a physical device ready'?
If indeed Ken's strategy is to keep schtum, what advantage's might this bring, or otherwise?
Anyone have any ideas about the next gen. asics in terms of moving to a smaller manufacturing process? If there was potential for this in the future, would this rule out eASIC?
Anyone have the energy to speculate on the likely scenario which would see the leveling off or even retracting of 'difficulty'?
Unless the price of BTC goes MUCH higher than it is today, the NRE for a smaller node in 2014 wouldn't be worth it. 28nm is the end all be all currently until you start seeing ASICs sell off the shelf for $0.35/GH At that point it still will be unlikely that the jump from 28nm to 14nm (This is assuming 14nm is even fully ready by then for anyone besides very large companies to use) would only bring margins of extra hashrate. The market so saturated at that point that to recoup their NRE on this would take many many batches. Some companies may want to take this risk but it doesn't seem liable currently. eASIC wasn't the first company to offer 28nm (They are actually kind of late in the game considering) So I doubt they will have the next node available before anyone else does it if it was indeed worth doing. As far as burn ins are concerned, Crumbs is correct. There's no law that states how long one is, hell there's no way you would even know if it was Used or Not. From what I'm hearing, some of you would prefer to receive it off the assembly line without any testing at all hah. (Plug and Pray) Either way, like I said before as long as the company delivers as promised on the dates as promised for the money as paid the receiver will have no issues if the units was previous hashing before, as long as it has the same warranties. "New" is made up from the manufacturer, guess who that is. |
|
|
|
True but you might need to sell the units as 'nearly new' if we had used them?
I know many suspect BFL for doing this with machines that were ready to ship. I guess if you do go this route and make it clear the machines have been 'run in' and give a guarantee AND no one is waiting for these units it's OK.
What do you think a burn in is? The units have to be tested working. I doubt anyone cares if their machine was used for mining prior as long as it works as described and is sent by the date promised when they ordered. This is only an issue that trolls try to pick apart because of some morally binding obligation they believe companies should have. Having a product that isn't a pre-order but ready now would be a key selling point for ActM. But I'm fairly confident that ActM will sell out of the unit allocated to sell to the public very quickly once they have a working prototype so this discussion is probably not even valid. |
|
|
|
Since Vbs is no longer around you've been a handy asset Bargraphics.
And we can sell excess chips right?
Why would you want to, The machines are not branded for customers. Any excess we would mine with and then as orders pop up we could just take it off the mine and ship it. Ken may not want to do this for bookkeeping purposes since he's technically "Selling" the machines to VMC from AMC but this makes the most sense as more money will be made from mining with them (Generating Income instead of the machines just sitting there) and then selling the units (Money in Hand Now to buy more chips in the next batch) |
|
|
|
25th October 2013 is today's date.
Within the next six days Ken will release the much anticipated quarterly accounts.
Ken might also reveal the status of the first chip batch order, as from the P&L and Balance sheet, we should be able to know if there was enough money raised to pay eASIC. One would expect that part of the NDA restriction may be lifted once the money has been transferred, so this would indeed be a good time for Ken to update his shareholders, if we are in pre-production.
Conversely, consider that this money has been paid already and the chip run has started in earnest. If that's the case then I'd expect Ken to continue to withhold information while advancing the production schedule behind closed doors. This is certainly a strategy that Ken has hinted at recently.
P.S. Thanks for the spell check idea finfloss. My browser now has the squiggly lines popping up although it's set to US spelling, eek!
I'm off to get me a donut, cowboy.
At last some serious discussion. What is going on today? The quarterly accounts will show how much we can take from the web orders and pump into further industrial miner production - obviously after making the retail units and shipping them on time. However once we start shipping, orders will flood in, it will be like turning on a tap and there is nothing preventing us from shipping just development time now. I was under the impression eASIC were paid in full for development. Anyone else agree? Then we just make orders with eASIC for batches and pay for them when we have funds available? Yes, you are correct. The $1,000,000 NRE we paid includes eveything apart from the production of the chips themselves. So if we need another $1,000,000 for the first batch and have only raised $800,000 in sales, then we are in big trouble. I would love someone to take an education guess of a price for X number of chips as I just plucked the above numbers out of thin air. Let's try and get a decent discussion going guys. Any takers? I'm sorry but I'm not understanding what you are trying to say here. The NRE for eASIC is the backend design of the chips and PROBABLY a small batch run. The cost for the Chips Themselves (Wafers) is probably around $10k-$15k per Wafer with a minimum of 10 or 25 wafers ($100,000 - $300,000) You don't pay $1,000,000 every time you want more chips..... you just pay for the wafer cost (There is usually a minimum amount of wafers that can be ordered) The more Wafers you order the cheaper the PER WAFER price is. If Ken gets the Small Batch Run in, they work, he will likely order as many Wafers as his pocketbook allows to get better pricing and have the chips ready. |
|
|
|
Two out of them is harder to get them start mining, at the very first beginning. and it become harder and harder with each reboot. These two eventually cease to operate yesterday, until now (but still viewable in cgminer console)
I got 2 boards that won't boot up (2nd led keep blinking) but once I turn on the AC to cool the room they boot up in about 1 minute. After that they will hash just fine even with AC off. When a board first starts up, the firmware makes sure the board and chips are cooled down before it starts the self test. This helps ensure the maximum number of engines (cores) will pass self test. LED decoder ringThe LEDs are numbered 1 to 8 with #1 closest to the USB connector and #8 closest to the power and fan connectors. During first power up, LEDs 5, 6, 7, and 8 will light up and LEDs 1, 2, 3, and 4 will indicate a failure code if anything is wrong with the hardware. This happens VERY quickly - in less than a second. If the initial hardware checks are good, #7 will blink indicating it is waiting for the board to cool down. This will always blink for a few seconds even if the board is cold. Then #7 and #8 will blink indicating ASIC self test. After that, 1, 2, 3, 4 will indicate how many jobs from cgminer are waiting to run in the input queue. LED 5 is just a debug output for me but it roughly indicates a job has completed - but sometimes blinks too fast for the human eye to see. Just ignore LED 5. I am working on some firmware updates that will fix most (or all?) of the problems the boards are having. For example, one failure I think I have figured out is occasionally a board will jump to more than 100 GH/s but have 100% hardware errors. I have one board that does this once per day or so and needs to be rebooted. After chasing this for a while, I believe I have finally figured out what is going on and will have a fix in the next release. Great! Will you also be updating to the latest BFL Protocol? |
|
|
|
|
Regardless of what Lab_Rat says or doesn't say.
Words are just that, Words.
I would take this time as a shareholder to just relax and wait for Lab_Rat to make an announcement when he has a clear and precise estimate of the Hashrate incoming.
He mentioned that Tytus has control over pricing and that he met with Dave to discuss this.
He mentioned that he held the BTC until just recently giving a nice boost to the BTC/$ conversion enabling more hardware.
Dave is likely now talking with Tytus to see what deal Lab_Rat can get from them especially since they are 3 weeks late.
I imagine the numbers will be very good but again why would Lab_Rat want to jeopardize anything with False Statements before they were known to be true?
You can't sell your shares and you can't make him work faster or harder than he is or is willing to do (which I believe he's giving 110%) so just sit back and enjoy the ride, it won't be much longer most likely but filling this thread with Fear, Uncertainty, and Doubt does no good for anyone.
|
|
|
|
now bargraphics you did exactly what these younglings wanted you to. you are an enabler. give a man a fish or teach a man to fish. everyone has their own strategy. i aspire to teach a man to teach others to fish, but dont quite make it most of the time.
Sorry it blew my mind that these "supporters" of ActM since the beginning can't even remember what is or was being done by their beloved company. Hopefully my post helps people that don't have the time to look up everything as well. |
|
|
|
Because for whatever the fuck reason you can't quote a locked thread. https://bitcointalk.org/index.php?topic=158806.msg2752290#msg2752290July 17, 2013, 09:56:48 PM Ah ok, so my information is accurate:
20k chips already paid for
The 68 boards, at 16 chips per, 1088 chips and assembly paid for
Now the coming expense on the quote with the Engineering firm for the remaining chips to be assembled onto the Avalon clone boards
Is the above accurate?
Yes We have 68 Klondikes ordered with full assembly which is ~306 GH/s, we are ~3rd customer in batch 1. Here is an email from steamboat. Chip status:
Batch 1 and 2 have arrived, and have been sent to the assembly house. Those with a chip only order will be sent an email shortly confirming their information. Shipping will be provided free of charge for all chip only purchases.
Assembly status:
We have successfully determined the source of the hardware issues, as well as a portion of the software/firmware conflicts, and are now hashing on all 16 chips at 4.6-4.8GH/s, at 350mhz. We are still receiving high hardware error rates, which we believe is a combination of the on board PIC and suboptimal firmware, and are in the process of optimizing the driver to reduce the error rates. Overclocking testing has also shown the thermal vias were not being fully filled due to the way they were designed. The assembly house has developed a two-step process to address this, and will be ready to assemble today pending final verification after we have tested and approved the process. During testing the 3.3v regulator was operating over spec, using more amps than it is rated for. While the unit functions and the component appears to be stable, we have chosen to replace it in order to ensure there are no failures during extended long term operation.
There are several firmware issues which need to be addressed before the units are ready for end use. The first priority is a USB bootloader. This is necessary to flash the units with firmware updates via USB without the need for additional hardware and software. Additionally, there is an issue with cgminer which does not allow multiple units to be connected to the same instance without severe performance degradation. This is not essential to shipping the units so long as the USB bootloader is properly programmed, but does increase the amount of time required to test the units as the ktest utility remains unfinished. We are also working on auto-serialization code to allow us to step-program the units with a unique serial number without the need to rebuild the hex file for each board. Lowest on the priority list is I2C implementation to allow chaining between boards. While it greatly reduces the amount of USB cables and hubs necessary to connect multiple units, it is not necessary for the unit to function.
September 16, 2013, 04:59:02 PM We have received the Avalon refund and we are holding it in reserve for expenses for engineering the PCIe boards. |
|
|
|
Klondikes have been shipped, should be hashing in about 5 days.
Great news Ken. Should be hashing at what GH/s ? - An order of Avalon chips from steamboat's batch #1, for 68 Klondike-16 boards, rated at 68*16*282 = 307 GH/s;
I guess it's "something" Check the screen: https://bitcointalk.org/index.php?topic=190731.msg3405524#msg3405524from klondike thread. Ok Sorry, ~350GHish |
|
|
|
|
An Idea: If the shares are not claimed then LRM should buy back the shares at market price and put the money aside to be claimed.
But how do you claim the shares if you can't sign with the address on bitfunder? These shares are lost forever anyways. Unverifiable.
|
|
|
|
Bfg miner have threse type of hashing speed which of the 3 is the avg speed of chilli
The first second or third?
Third is the Hashrate reported by the pool back to BFGMiner I believe (this is the one that matters) |
|
|
|
Klondikes have been shipped, should be hashing in about 5 days.
Great news Ken. Should be hashing at what GH/s ? - An order of Avalon chips from steamboat's batch #1, for 68 Klondike-16 boards, rated at 68*16*282 = 307 GH/s;
I guess it's "something" |
|
|
|
anyone that is thinking about buying one of these, they are awesome. Mrteal and Chipgeek are terrific to deal .
Agreed! |
|
|
|
... I would agree that at present there is little they can do to 'sabotage' things.
Yeah, like killing a zombie. How do you kill that which has no life  Weekend at Bernies - Dead or Alive we party! |
|
|
|
I never contribute to the thread generally speaking, but jeez kids, can you quit it? Nobody wants to read your spammy mud slinging back and forth. Just shut the hell up if you don't have anything constructive to say.
Valiant effort, but this is the internet and trolls will troll and whiteknights will whiteknight. Just sit back and make your bets on when their posts get deleted, it's more fun that way. Mate, the only reason I'm doing any of this and happy to put myself in the firing line is because unlike yourself and others, I won't sit idly by and allow people to actively sabotage my investment. If you believe that anyone in this thread can "sabotage" this investment then you have bigger worries. Any investment that fragile is doomed to fail. Thankfully I don't believe any of the clowns that populate this forum have any power on this company. There's no liquidity because US was banned so the share prices on all investments are artificially low. You either have faith in the company or you don't at this point. However the pointless banter does pass the time nicely. |
|
|
|
I never contribute to the thread generally speaking, but jeez kids, can you quit it? Nobody wants to read your spammy mud slinging back and forth. Just shut the hell up if you don't have anything constructive to say.
Valiant effort, but this is the internet and trolls will troll and whiteknights will whiteknight. Just sit back and make your bets on when their posts get deleted, it's more fun that way. |
|
|
|
|
Come on guys I was waiting for another epic Knybe Quadra post or Penta Post, why ruin his streaks?
PS: where did that Mabsark guy go? (lol)
|
|
|
|
32 bit windows version
That would be your reason, That versions for 64bit windows, I just went and made a 32 Bit for you http://www.speedyshare.com/vgRJy/BFGMiner-Chili-32.zipThis is a workaround version of BFGMiner until a new firmware update for the chilisHere's a modified version of BFGMiner, I also included the driver inside of it as well that should fix your problem. (I don't know much about CGMiner though) http://www.speedyshare.com/vgRJy/BFGMiner-Chili-32.zipOpen up bfgminer.conf and change the Pool and Username to whatever you want (It currently uses mine so make sure you change it) Run CDM v2.08.30 WHQL Certified.exe to install the correct driver for windows Once you do both of those, just open up bfgminer.exe and it should read from the config automatically and start hashing for you. If it doesn't see the Chili, all you have to do is keep BFGMiner open, unplug the USB, Plug it back in, press M then + then type all or auto and enter. It should find it. Please note if it still isn't working then you need to exit BFGMiner, unplug you chili power, plug it back in and wait for all the lights to stop blinking. If you try to find the miner while it's "Booting up" it will have issues. "Booting Up" is the two most right LEDs (Closer to the Power) blinking back and forth. Again once all the LEDs are not blinking anymore it should be ready to start hashing, start your BFGMiner and follow the above steps. Let me know if this helps  |
|
|
|
ok i do and then wihich file i run? bfgminer does not run? at windows why?  BFGMiner.exe? Do you have 32 or 64bit windows? |
|
|
|
|
Show Posts
