If the current growth is amazing and surprising, buckle up, because you havent seen anything yet. The current spike was achieved by a single small company that by its own admission, is struggling to get its goods out of the door and looking for ways to speed up production. Still, KnC can produce ~4PH per month. What do you think these guys will be able to pump out: Thats Ciara, the plant Hashfast will use. So now imagine what will will happen once HF, Bitmine, cointerra, BFL and all the others join the race.. Its going to be a bloodbath. yes you're right, you can find good estimation of the hashrate by march 2014 here: https://bitcointalk.org/index.php?topic=283820.0one thing I would not have included BFL in the ASIC vendors list you made
|
|
|
BITCOIN HASHING RATE IS GOING THROUGH THE ROOF....WOW
I'm surprised that you are surprised, as well as about the fact that we are still below 500M diff on Oct. 15th. Didn't you do your daily homework on a $k investment? One thing is sure If KnC had delivery on time all the first batch miners we would have at least 400TH/s more i.e 56mil more diff
|
|
|
So ... 40% diff increase in a few hours Oh yeah and when I say a few I mean about 3 ... not double that did kncminer finally send you a piece of hw to develop a cgminer driver?
|
|
|
it's a good thing measuring theoretical max production, but you have to find someone that will buy your product then (at the price you've chose). I think that every ASIC vendor will need to lower their product price inevitably. I just don't know what will be the price equilibrium, my gut tells me something along 0.5 to 1.5 GH/s should be correct, but I'm just guessing.
You mean $0.5 to $1.5 per GH? yes, but for a full working plug'n'play miner I think its even lower. The more cost effective asic designs would be below $0.1 per GH for the bare chip: https://bitcointalk.org/index.php?topic=295270.0PCB, cooling, case etc may double or triple that, but not more than that in large volumes. Another thing that will determine the price is the power consumption, but I think they'll be able to lower it significantly as well.
|
|
|
so let's say they are 4 days behind that means 350 * 4 = 1400 boxes. On avg each box should meant at 300GH/s (if they are going to ship also mercury(s)). That means that in next few days we will have an increase of at 420 TH/s only from KnC.
It also means KnC alone could produce and ship 4PH per month if they can source enough components. If KnC can do 4PH today, imagine what Ciara (Hashfast) could do. Those saying exponential growth has to taper off will be proven correct eventually, but probably a lot later than they thought. it's a good thing measuring theoretical max production, but you have to find someone that will buy your product then (at the price you've chose). I think that every ASIC vendor will need to lower their product price inevitably. I just don't know what will be the price equilibrium, my gut tells me something along 0.5 to 1.5 GH/s should be correct, but I'm just guessing.
|
|
|
from the news post After yesterday’s factory output we can now say we are currently 3-5 days behind in the factory and the hosting setup at current speed which we are trying to increase in all ways possible.
...
Yesterday the factory produced and shipped 350 boxes and we expect the same number to be shipped per day over the next coming days.
so let's say they are 4 days behind that means 350 * 4 = 1400 boxes. On avg each box should meant at 300GH/s (if they are going to ship also mercury(s)). That means that in next few days we will have an increase of at 420 TH/s only from KnC.
|
|
|
Order #23xx Shipped (Payed)
Just to make sure no body is going to steal your miner: Did you originally choose Stockholm pick-up as delivery method ?
|
|
|
Firstly I'm not a native english speaker then I've had a few difficulties to parse your post, so I just want to say sorry in advance BitBuster said that doing an hard reset could be beneficial for miners running 0.95 I've dig a little and I found that on BB there seems to be a process that will take care of resetting to factory default, namely: 1710 root 1496 S /usr/bin/monitor-pwbtn /usr/bin/factory_config_reset.sh
it seems that every time we perform the magic sequence (press five - wait five - press five) monitor-pwbtn will excute factory_config_reset.sh. The script simply restore a few configuration files (pwd,webserver,etc) nothing fancy, if you're interested in more detail look at /etc/init.d/kncminer_setup.sh. My question is: do you think that other than doing aforementioned tasks it will do something else at FPGA/PCB? I've extracted strings from /usr/bin/monitor-pwbtn and the only interesting thing I saw are: echo low >/sys/class/gpio/gpio71/direction echo high >/sys/class/gpio/gpio71/direction
There is a clearup of the database of the disabled cores. But... the disabled cores are disabled ON CHIP, not in the linux. This makes sense and fit with the results of further research I've made. That is, their clock is disconnected by a command and maybe also power supply, but I believe only the latter as some chips took 15A while being disabled. KnC demonstrated the best clock distribution network I have seen in a long time, IMHO.
Sorry but as I already said lack of knowledge and rusty english just don't let me grasp the meaning of your statement fully. Anyway I'm more than glad to read good "review" of KnC work. So, it seems the dual cores don't have an "enable" option? maybe it is easier to re-set all the clock gates at once.
still can't parse an you direct me how to unpack or mount the u-boot rootfs.cpio file? I believe I have found a method, but I'm out during the day so I ask if you have a quick solution to that. Then I will enable to explain A LOT! (Can't wait to get inside, knock! knock!)
did you already solve this problem or do you still need help?
|
|
|
Back when they were doing margins on margins maybe it seemed a potentially useful margin to be able to run six boards if that turned out to be what it would take to meet their target number of hashes per second per unit...
-MarkM-
I've always thought that will use all the 6 plug in the control board for custom case they deploy for hosted miners at KnC DC. I still think this is the case, still I wild guess thou.
|
|
|
Email reply from KNC this morning UK time 10:00am.
Hi,
Your order is in the current production queue and should have been completed this morning. We are still waiting for the latest update from the factory. But as far as I can see on the system it has been made and it will be leaving the factory with DHL at 17:00 Swedish time today
Should you have any further questions please do not hesitate to contact us.
Thanks
Emilia
My Order #2389 paid 19th June , 1 x Jupiter.
peace ;-)
They switched to DHL? If memory serves 'orama already mentioned this a few days ago while telling us how DHL saved KnC ass with the mess Fedex did with the BeagleBone, but surely this change all of sudden surprise me.
|
|
|
Email reply from KNC this morning UK time 10:00am.
Hi,
Your order is in the current production queue and should have been completed this morning. We are still waiting for the latest update from the factory. But as far as I can see on the system it has been made and it will be leaving the factory with DHL at 17:00 Swedish time today
Should you have any further questions please do not hesitate to contact us.
Thanks
Emilia
My Order #2389 paid 19th June , 1 x Jupiter.
peace ;-)
DHL ? this + security check at customs .... something is going on here.
|
|
|
my unit is on hold Malmo Sturup, Sweden 15.10.2013 8:53 Pkg delay-add'l security check by Gov't or other agency- beyond UPS control Same Malmo Sturup, Sweden 10/15/2013 8:53 Pkg delay-add'l security check by Gov't or other agency- beyond UPS control Malmo Sturup, Sweden 10/14/2013 22:35 Arrival Scan Jonkoping, Sweden 10/14/2013 18:45 Departure Scan Sweden 10/14/2013 8:00 Order Processed: Ready for UPS Yep my Order #16xx says exactly the same thing: Malmo Sturup, Sweden 15/10/2013 8:53 Pkg delay-add'l security check by Gov't or other agency- beyond UPS control Malmo Sturup, Sweden 14/10/2013 22:35 Arrival Scan Jonkoping, Sweden 14/10/2013 18:45 Departure Scan Sweden 14/10/2013 7:59 Order Processed: Ready for UPS Murphy is really angry with KnC. They had way too much luck with chip's yeld so he's trying to balance. Stupid jokes apart I'm very sorry for all are experiencing this further delay.
|
|
|
PKG DELAY-ADD'L SECURITY CHECK BY GOV'T OR OTHER AGENCY- BEYOND UPS CONTROL my info ups is the final destination in EU ?
|
|
|
I was skimming through knc forum and I found this: http://forum.kncminer.com/forum/main-category/hardware/7111-core-x-was-disabled-due-to-10-hw-errors?p=7121#post7121BitBuster said that doing an hard reset could be beneficial for miners running 0.95 I've dig a little and I found that on BB there seems to be a process that will take care of resetting to factory default, namely: 1710 root 1496 S /usr/bin/monitor-pwbtn /usr/bin/factory_config_reset.sh
it seems that every time we perform the magic sequence (press five - wait five - press five) monitor-pwbtn will excute factory_config_reset.sh. The script simply restore a few configuration files (pwd,webserver,etc) nothing fancy, if you're interested in more detail look at /etc/init.d/kncminer_setup.sh. My question is: do you think that other than doing aforementioned tasks it will do something else at FPGA/PCB? I've extracted strings from /usr/bin/monitor-pwbtn and the only interesting thing I saw are: echo low >/sys/class/gpio/gpio71/direction echo high >/sys/class/gpio/gpio71/direction
opinions?
|
|
|
Sitarow I just want to thank you for thorough tests. Really appreciated.
|
|
|
I have 4vrm boards on my saturn running .095, and I can lay my fingers right on them, they are just warm to the touch, not hot by any means. They were the same with .091, .093, and .094
Saturn seems to perform better then Jupiters. Not sure as to the reasons. Perhaps the fact that hot air from the front two ASIC modules are not being pushed onto the back two units as they are none existent on the Saturn units. also there is a theory going around that the Control Unit/Beagleboard is happier with just solo or pairs. I've ran two modules together for ~270 and another at ~135 but all three together wouldn't go over ~360 (all those values are at the pool's view, cgminer showed much higher of course) trepex was kind enough to send me the uptime output of is saturn and it seems my therory is moot since the beagleboard avg load is almost the same of my jupiters
|
|
|
Can someone please explain to me why eligus disconnects the miner every time there is a short 2 to 10 minute block? twice in 2 days now. There was also a ten second round, and the miner took so long "Running Flushwork", it totally missed the block!
I thought you've been hit by knc suboptimal flushwork implementation (in cgminer driver) see: https://bitcointalk.org/index.php?topic=18313.msg3294238#msg3294238 I've almost miss a block myself due to this.
|
|
|
Anyone amongst saturns owners would mind to check beagleboard system load using uptime command from a ssh session?
I have a theory that implies that the lower perf someone get on jupiters configuration is also due to some "bugs" present in cgminer driver developed by knc that makes the system waste resources in I/O waiting.
|
|
|
One thing that I forgot to mention was that while I was trying single and paired (mercury/saturn) configurations, the board that had the bad VRM was off and this time was against the a/c unit airflow I have the miner positioned. It was off for 30 minutes while being chilled (it was usually on the far side, but I switched it by chance to the near side)
And then when I put it back on with the rest, the VRM awakens on next boot. Coincidence?? maybe, but happy either way
(why was I taking boards off my miner you ask? I was planning on cutting the miner in half for better airflow but didn't realize that the bottom is way thicker than the lid which cuts easily.. so I had to ditch those plans for now as I rethink)
DPoS sorry for spamming you but if you'll test again your "split my jup to get two saturns" would you mind to check beagleboard system load using uptime command from a ssh session? I have a theory that implies that the lower perf we get on jupiters configuration is also due to some bugs present in cgminer driver developed by knc that makes the system waste resources in I/O waiting. Edit: i would it if i had constant phisycal access to my miner
|
|
|
many thanks I'd have missed if it weren't for this thread
|
|
|
|