Swedish ASIC miner company kncminer.com

[btc_uzr]

WOW, this shit is fo reeel!!
http://www.unic.ac.cy/about-us/university-of-nicosia-digital-currency-initiative/bitcoin-payments

You would need to have a screw loose to pay in BTC.  looks like we are in a reverse head and shoulders trading pattern, the only thing stopping it is the previous all time high. once we break $901 there is no looking back until $1300 - $1400 imho


why do you think o many people are paying stupid money for asics?  are they all confused about the diff factor and ROI?  nope.. there a lot of traders out there that know a $12000 KNC at 550GHS will get ROI.

Look at it this way, you are in a country where it is difficulty to get money out as private person. Now you can buy bitcoins in your currency and wait a week, then spend most of them for your study fees you had to pay anyways, but instead of using banks and stuff you did it through bitcoin und saved a nice amount.

[1540099380]

1540099380

[1540099380]

1540099380

[1540099380]

1540099380

[1540099380]

1540099380

[soy]

Calm down folks. I just posted it to let people know it happens even to developers, and have read what people suggested, but none of those fixed my particular issue. Every time I try one of those fixes things seem to just get a little worse so I'm afraid to touch it now...

Conman - did you try the hard reset - 5 times + 5secs + 5 times?

Yep, didn't make a difference.

thx & sorry it didnt help.

you made it quite clear nothing advised had helped but some people need it literally spelled out to get a clue.

what GH/s rate are you getting now?

mine has s.l.o.w.l.y crawled up to 530.1Gh/s over the past few days. could be and has been a lot worse.

It eventually speeds up to almost normal hashrate, but is laggy as in connecting and never quite averages as much as it used to because of that, making rejects worse too. Maybe it's just coincidence and the problem is elsewhere in my network but the timing with happening from the moment I upgraded to 0.99 is hard to ignore when I haven't changed anything else. Downgrading didn't fix it either.

I know its' saturday but just try to join kncminer channel @ freenode, hno's usuallly to be there most of the time.

I had seen an effect and it may be unique to my machine but you could look.  Case off, I diverted air from the two front fans down onto the BBB.  Hashrate rose (in cgminer).  Took the cardboard away and the hashrate plummeted.  I keep the airflow on the BBB now.  As I say it could be unique to my miner.

Also, somebody's earlier post described moving a Jupiter closer to the floor and the hashrate dropping.  If in moving it closer to the floor he put it too close to a wall so there was some obstruction to the airflow out the back, it would reduce the airflow over the BBB at the front causing a drop in hashrate if his machine reacts to a BBB cooling change with a hashrate change as mine does.

[btc_uzr]

Capitalising on the fact that I saw that dud cores are better disabled, here's an experimental binary that tunes things fairly aggressively:

http://ck.kolivas.org/apps/cgminer/kncminer/cgminer

First it enables all cores on startup (so it can take a while before it starts mining!)
Then it will disable cores after only 3 hw errors in a row, but staggers disabling of cores 5 seconds apart.
Then it tries re-enabling cores after only another minute, but staggers re-enabling them.
If the cores fail 3 times in a row, they're decommissioned at that point.

Nice!!

As soon as the first report good numbers I'll go for it.
Currently running stable on 3.8.2 with my 5/192 bad cores board, so I don't want to mess with it now.

[edgar]

Now I'm a retard, and a jackass according to edgar & xtr8guy...  quite the accomplishment.
To me, chastising someone for trying to help is retarded.
If you don't like my comments, PLEASE, feel free to put me on ignore.
This is totally unproductive, and I'd rather not waste time on such.

Appreciate the lessened uptime, but dont play the victim again - bragging and repeating irrelevant non help isnt trying to help, its called blowing your own trumpet and its annoying. Just like being called on it is annoying.

Its not the first time its been mentioned, and not by just 1 person who finds it distasteful.

I dont wish to ignore you, you have made some very decent posts but you do go on & on...

i also disagree its unproductive to get closer to each other and let others know when they cross boundaries - we can all learn from each other.



As for my earlier post, im not 100% sure what it means, presumably a number of things.

It was indeed stated that the Nov rigs are to be expected to hash at 650Gh/s or more, but 1200w...

the 'recommended''inclined to go for' silent pro gold 1200w only has 2 PCI-e ports while the not powerful enough v1000 has 4 ports...

https://bitcointalk.org/index.php?topic=170332.msg3613013#msg3613013

the hosted novembers will be powered by 2 v850s so presumably they have PCI-e cables coming out of their ears in stockholm...



but my emphasis was regarding the lack of direct feedback concerning using only 3 cables on the october rigs and 0die dc/dc low current concerns which for most seem to have been rectified, thankfully by repeated reboots & fw upgrades & downgrades.

but NOT Mine!

does anyone with the right knowledge know if using only 3 cables is even possible to effect or be caused by the vrm/0die dc/dc low current problems??

[sickpig]

Capitalising on the fact that I saw that dud cores are better disabled, here's an experimental binary that tunes things fairly aggressively:

http://ck.kolivas.org/apps/cgminer/kncminer/cgminer

First it enables all cores on startup (so it can take a while before it starts mining!)
Then it will disable cores after only 3 hw errors in a row, but staggers disabling of cores 5 seconds apart.
Then it tries re-enabling cores after only another minute, but staggers re-enabling them.
If the cores fail 3 times in a row, they're decommissioned at that point.

many thanks.

anyway looking at /etc/init.d/cgminer.sh it seems to me that all the cores are are enabled at start time by the script itself, no?

 

[fubly]

Capitalising on the fact that I saw that dud cores are better disabled, here's an experimental binary that tunes things fairly aggressively:

http://ck.kolivas.org/apps/cgminer/kncminer/cgminer

First it enables all cores on startup (so it can take a while before it starts mining!)
Then it will disable cores after only 3 hw errors in a row, but staggers disabling of cores 5 seconds apart.
Then it tries re-enabling cores after only another minute, but staggers re-enabling them.
If the cores fail 3 times in a row, they're decommissioned at that point.

Can you include an option like:

-dcrsp "a72, b191, c18, e88"

(dcrsp = disable cores permanent)
a = Asic-Board 1
b = 2
..
f  = 6

because some cores are really death, and enabeling them will be an problem for current work on shares!

You can put this array to the cgminer code where also the enablecores is pointed.

What do ypu think about this?


What I not understand is why inside the monitor script is also included the enabeld cores.
One time yes, but not so often.

Like Orama said: "Running through the floor and opening and closing the doors" I think it´s too much opening and closing the dors.

[Bogart]

To maximise the performance of your November shipment orders, we recommend the following:
- for November Jupiter’s a 1200 Watt PSU with a minimum of four separate PCI-E adaptors (6 pins or 6+2 pin).
- for November Saturn’s an 850 Watt PSU with a minimum of two separate PCI-E adaptors (6 pins or 6+2 pin).

I might have missed it due to the noise level here but does this mean that the November Jupiter's are less efficient than their October counterparts?  I thought they were around 1W/GH

if memory serves 'orama said 650+GH/s and that the max consumption measured at the wall during test was 1050W.

so yes the worst case scenario is 1.6W/GHs.

Thanks guys.  That is a little disheartening.  Efficiency is really going to be key going forward.  Midsize miners will need lots of hashrate with minimal electric use to stay competitive.

I think it's just that the November batch is capable of being pushed harder (higher clockspeed, higher voltage, lower efficiency) using the forthcoming tuning suite.  If you wanted you could tune it back down to have performance and efficiency similar to what the October batch is running now..

I imagine most miners will run theirs as hard as they can in the near term.

[Cablez]

I agree with you but overclocking should probably not be the focus of future hardware revisions versus raw efficiency gains.  High overall hashrate for a single unit is just a good excuse to charge higher prices at the expense of not being able to use the device as long as you can. Not everyone has sub 10c electric.

[sudya_dred]

Hard day. KNCminer Water cooling upgrade.

Just photo. More stat later.

http://i.imgur.com/WSQO2pV.jpg

http://i.imgur.com/1cFtkXx.jpg

http://i.imgur.com/FAlPMkD.jpg

May the Force be with you

[sickpig]

Hard day. KNCminer Water cooling upgrade.

Just photo.





May the Force be with you

wow

porno for miners!

did you chose to put heatsinks on top of the VMRs because they were running too hot in this configuration ?

[edgar]

Very Well Done.

details

performance...

[soy]

There are 8 main islands here in Hawaii,  But  technically 137 total islands in the Hawaiian chain.

Just saying.

Oh well, I guess I'll pry myself away from the computers
and do some actual labor around the farm today.....
Things are beginning to look like I abandoned
the place.... lol  


BTW:
Cointerra is saying mid February for Batch 1 Tear-the-money-from-your-wallet-Miner...!
Hashfast is sayin' Mid December for Batch 1 Baby Jetgusher...!
I don't feel any others are even worth mentioning....lol
Looks as if both CT & HF are taking March orders now....
and HF is asking the same price for a March unit,as they charged for a December unit....  OMG
Those Guys in So-Cal are smoking some good stuff...  lol
GO KNC!

Farm huh?  Maui Waui?  

And who's in SoCal?  Cointerra is in Austin and HashFast is in Silicon Valley.

okay, silicon valley...
...and no, I'm on the actual Island of Hawaii, not Maui...
although the State is also called Hawaii....  we have 7 islands

BTW... what is this?...poke Ewok hour?  

Anyone else notice NMC went to $2.50... !

Staying on the present topic, I'd love to live in Hawaii.  My father was a Seabee stationed there in WWII.  End of the war there were huge stores of partly assembled motorcycles, jeeps, cranes, trucks, all in cosmolene, that to prevent an adverse impact on post-war industry on the mainland, were laid to rest in large excavations and covered over.  They should be perfectly preserved in the cosmolene.

GET RICH QUICK SCHEME: 1) find the valley in which the machines were buried, 2) buy the valley with bitcoins you mined with your Jupiters, 3) request the EPA declare the valley toxic due to the cosmolene, 4) dig up the machines financed with some envirnmental disaster fund.

[soapmodem]

Capitalising on the fact that I saw that dud cores are better disabled, here's an experimental binary that tunes things fairly aggressively:

http://ck.kolivas.org/apps/cgminer/kncminer/cgminer

First it enables all cores on startup (so it can take a while before it starts mining!)
Then it will disable cores after only 3 hw errors in a row, but staggers disabling of cores 5 seconds apart.
Then it tries re-enabling cores after only another minute, but staggers re-enabling them.
If the cores fail 3 times in a row, they're decommissioned at that point.

Awesome. Thanks, ckolivas.

I'll fire it up now and report back my results after it has a chance to stabilize.

[Bogart]

@bogart - do you have any close ups of the areas you advised checking for 'opens' around the VRMs??

That must have been another user...

https://bitcointalk.org/index.php?topic=170332.msg3576554#msg3576554

Bogart
Hero Member
*****
Re: Swedish ASIC miner company kncminer.com
14 November 2013, 10:51:13
   
Reply with quote  #21655
                    Quote from: soy on 14 November 2013, 09:46:43
                     maybe it got so hot as to melt solder and create an open.

That's would be what I would look for.

Use a flashlight and a magnifier and check the big power-carrying solder joints for hairline "cracks".  You can try push/pulling on the VRM too and looking for movement of the pin in the solder pool.

I used to see this all the time in old TVs and monitors and such.

Oh...yeah I guess I hadn't really looked at it when I said that.  I was picturing through-hole components, which these are not.

I guess you can't really see the solder joints on these so that wouldn't work.  Sorry.

[RenHoek]

just to inform u that there is something going on with Nov. batch...  



my Status (ordernumber 85xx) has changed from 'payed' to 'in progress'!



 

[jonoiv]

just to inform u that there is something going on with Nov. batch...  

my Status (ordernumber 85xx) has changed from 'payed' to 'in progress'.

Thats the best news all week

My order still just shows "paid" order 93xx

[Phoenix1969]

To maximise the performance of your November shipment orders, we recommend the following:
- for November Jupiter’s a 1200 Watt PSU with a minimum of four separate PCI-E adaptors (6 pins or 6+2 pin).
- for November Saturn’s an 850 Watt PSU with a minimum of two separate PCI-E adaptors (6 pins or 6+2 pin).

I might have missed it due to the noise level here but does this mean that the November Jupiter's are less efficient than their October counterparts?  I thought they were around 1W/GH

if memory serves 'orama said 650+GH/s and that the max consumption measured at the wall during test was 1050W.

so yes the worst case scenario is 1.6W/GHs.

Thanks guys.  That is a little disheartening.  Efficiency is really going to be key going forward.  Midsize miners will need lots of hashrate with minimal electric use to stay competitive.

I think it's just that the November batch is capable of being pushed harder (higher clockspeed, higher voltage, lower efficiency) using the forthcoming tuning suite.  If you wanted you could tune it back down to have performance and efficiency similar to what the October batch is running now..

I imagine most miners will run theirs as hard as they can in the near term.

KNC also did mention the November units would fit the "Underpromise, Overdeliver" scenario they like to employ... So given that they said 650 GH/s, and want you to get a 1200watt supply....  It could very well be that they normally push a bit more than 650, and that the Tuning Suite could even push them farther...    just sayin'...

[jxz]

As for my earlier post, im not 100% sure what it means, presumably a number of things.

It was indeed stated that the Nov rigs are to be expected to hash at 650Gh/s or more, but 1200w...

the 'recommended''inclined to go for' silent pro gold 1200w only has 2 PCI-e ports while the not powerful enough v1000 has 4 ports...

https://bitcointalk.org/index.php?topic=170332.msg3613013#msg3613013

The silent pro gold 1200w has 4 separate PCI-e connectors.

[kslavik]

Capitalising on the fact that I saw that dud cores are better disabled, here's an experimental binary that tunes things fairly aggressively:

http://ck.kolivas.org/apps/cgminer/kncminer/cgminer

First it enables all cores on startup (so it can take a while before it starts mining!)
Then it will disable cores after only 3 hw errors in a row, but staggers disabling of cores 5 seconds apart.
Then it tries re-enabling cores after only another minute, but staggers re-enabling them.
If the cores fail 3 times in a row, they're decommissioned at that point.

Seems like API is disabled in this version with the following message:
Invalid command
cgminer 3.8.2

Was it done on purpose? Can we get it back, please?

[Phoenix1969]

Capitalising on the fact that I saw that dud cores are better disabled, here's an experimental binary that tunes things fairly aggressively:

http://ck.kolivas.org/apps/cgminer/kncminer/cgminer

First it enables all cores on startup (so it can take a while before it starts mining!)
Then it will disable cores after only 3 hw errors in a row, but staggers disabling of cores 5 seconds apart.
Then it tries re-enabling cores after only another minute, but staggers re-enabling them.
If the cores fail 3 times in a row, they're decommissioned at that point.

Seems like API is disabled in this version with the following message:
Invalid command
cgminer 3.8.2

Was it done on purpose? Can we get it back, please?

That's probably a temporary thing 'till the memory leak is isolated Ckilovas is working on.  It most likely stops the leak.  But I could be wrong.....