Swedish ASIC miner company kncminer.com

[adrd]

What if 469GH/s is with 1% of chip working? Are we getting 46,9TH/s devices?!

[1714033212]

1714033212

[1714033212]

1714033212

[bobsag3]

I've said this phrase too often, but "Excuse my ignorance", shouldn't CGMiner display the actual mining rate without having to do calculations?
When I look at my erupters mining, it is displaying 333MHash/s each, plain as day. Why not here?

That's because the implementation of the hashrate meter is driver dependent, and in this case, we didn't write the driver. When we do write the driver, the hashrate displayed is the effective valid hashrate only (i.e. not hardware errors).

ahh, and you are planning to do it? will you receive some KNC miner for testing and driver development?

Earlier on knc said they'd engage us early on in the development process... but then didn't, and wrote their own driver for cgminer. I can't predict what they'll do now and how that will impact on whether code will be merged or maintained in cgminer, but I will be asking for them to provide their driver code publicly.

Sigh.
It really wouldn't be that hard for them y'know...

What if 469GH/s is with 1% of chip working? Are we getting 46,9TH/s devices?!

You would probably need a building to power that. or 2

[ASIC-K]

What if 469GH/s is with 1% of chip working? Are we getting 46,9TH/s devices?!

hahahah good one!

[ASIC-K]

I've said this phrase too often, but "Excuse my ignorance", shouldn't CGMiner display the actual mining rate without having to do calculations?
When I look at my erupters mining, it is displaying 333MHash/s each, plain as day. Why not here?

That's because the implementation of the hashrate meter is driver dependent, and in this case, we didn't write the driver. When we do write the driver, the hashrate displayed is the effective valid hashrate only (i.e. not hardware errors).

ahh, and you are planning to do it? will you receive some KNC miner for testing and driver development?

Earlier on knc said they'd engage us early on in the development process... but then didn't, and wrote their own driver for cgminer. I can't predict what they'll do now and how that will impact on whether code will be merged or maintained in cgminer, but I will be asking for them to provide their driver code publicly.

doesnt really matter though right? once you get your hands on one, you can make your own awesome driver anyway....

[The Avenger]

Unofficially, i'm currently assembling your kit, so cheers whoever gave them the Ikea chair assembly image.

You're welcome  

I've been asked if I'm free this weekend, but Mon is the 30th.

Time for your job interview. Bring a soldering iron, might be like this  

Haha, yeah that was it. They found it very funny. Thanks for that, appreciated!

No problem.

Let them know I called dibs on the first 1BTC they mined on the 1st jupiter. https://bitcointalk.org/index.php?topic=170332.msg3276905#msg3276905

I'm going to frame it and pin it to my wall (metaphorically speaking   ).

[canth]

Has anyone seen the latest statistics from the Jupiter they have mining? It was fluctuating up to 800Ghz AND IS STABLE AT 650!

http://eligius.st/~wizkid057/newstats/userstats.php/17Czc8RVL3FU5T2MLx2zLbRnpfBNgH9vFo

That could be more than one machine...maybe Jupiter + Mercury? I wouldn't give too much weight to those numbers unless we know that they're only running 1 Jupiter on those workers.

[-ck]

I've said this phrase too often, but "Excuse my ignorance", shouldn't CGMiner display the actual mining rate without having to do calculations?
When I look at my erupters mining, it is displaying 333MHash/s each, plain as day. Why not here?

That's because the implementation of the hashrate meter is driver dependent, and in this case, we didn't write the driver. When we do write the driver, the hashrate displayed is the effective valid hashrate only (i.e. not hardware errors).

ahh, and you are planning to do it? will you receive some KNC miner for testing and driver development?

Earlier on knc said they'd engage us early on in the development process... but then didn't, and wrote their own driver for cgminer. I can't predict what they'll do now and how that will impact on whether code will be merged or maintained in cgminer, but I will be asking for them to provide their driver code publicly.

doesnt really matter though right? once you get your hands on one, you can make your own awesome driver anyway....

Yes I'll support any device I have myself.

But I don't see confirmation that we'll be given hardware, and I'm not buying one.

[ASIC-K]

I've said this phrase too often, but "Excuse my ignorance", shouldn't CGMiner display the actual mining rate without having to do calculations?
When I look at my erupters mining, it is displaying 333MHash/s each, plain as day. Why not here?

That's because the implementation of the hashrate meter is driver dependent, and in this case, we didn't write the driver. When we do write the driver, the hashrate displayed is the effective valid hashrate only (i.e. not hardware errors).

ahh, and you are planning to do it? will you receive some KNC miner for testing and driver development?

Earlier on knc said they'd engage us early on in the development process... but then didn't, and wrote their own driver for cgminer. I can't predict what they'll do now and how that will impact on whether code will be merged or maintained in cgminer, but I will be asking for them to provide their driver code publicly.

doesnt really matter though right? once you get your hands on one, you can make your own awesome driver anyway....

Yes I'll support any device I have myself.

But I don't see confirmation that we'll be given hardware, and I'm not buying one.

what if i loan you my mercury?

[vesperwillow]

I've said this phrase too often, but "Excuse my ignorance", shouldn't CGMiner display the actual mining rate without having to do calculations?
When I look at my erupters mining, it is displaying 333MHash/s each, plain as day. Why not here?

That's because the implementation of the hashrate meter is driver dependent, and in this case, we didn't write the driver. When we do write the driver, the hashrate displayed is the effective valid hashrate only (i.e. not hardware errors).

ahh, and you are planning to do it? will you receive some KNC miner for testing and driver development?

Earlier on knc said they'd engage us early on in the development process... but then didn't, and wrote their own driver for cgminer. I can't predict what they'll do now and how that will impact on whether code will be merged or maintained in cgminer, but I will be asking for them to provide their driver code publicly.

Sigh.
It really wouldn't be that hard for them y'know...

What if 469GH/s is with 1% of chip working? Are we getting 46,9TH/s devices?!

You would probably need a building to power that. or 2

It was likely to fast-track the development/delivery. They were on a razor-thin line to make deadlines and literally cut it by seconds. Delays, even on the software side, would've thrown everything awry. I doubt they didn't want to work with the cgminer team at all, merely they sidestepped the plan at the time. Considering the team will get equipment at some point somehow, it wasn't likely to try and avoid them. Merely, deadlines mattered more.

In some work I've done in the past when it came to deadlines, it was simply easier for me to take something into my own hands and make sure it was checked-off, rather than hand it off to the person it was designated to in the first place. Revisit it in the future, without a doubt.

Has anyone seen the latest statistics from the Jupiter they have mining? It was fluctuating up to 800Ghz AND IS STABLE AT 650!

http://eligius.st/~wizkid057/newstats/userstats.php/17Czc8RVL3FU5T2MLx2zLbRnpfBNgH9vFo

That could be more than one machine...maybe Jupiter + Mercury? I wouldn't give too much weight to those numbers unless we know that they're only running 1 Jupiter on those workers.

One clue we were given is they were making, on average, 1.4W/gh. It doesn't mean they were limited solely to 500gh or 600gh either. I'd imagine, especially since the chips have built-in failover, you could get much more provided you worked around providing it more power. The machines are using 860w PSU's. Just like with a AM Blade, more power, up the clock = more cycling.

[RoadStress]

Can anyone estimate how many chips per wafer can KnC make?

[flowdab]

I've said this phrase too often, but "Excuse my ignorance", shouldn't CGMiner display the actual mining rate without having to do calculations?
When I look at my erupters mining, it is displaying 333MHash/s each, plain as day. Why not here?

That's because the implementation of the hashrate meter is driver dependent, and in this case, we didn't write the driver. When we do write the driver, the hashrate displayed is the effective valid hashrate only (i.e. not hardware errors).

ahh, and you are planning to do it? will you receive some KNC miner for testing and driver development?

Earlier on knc said they'd engage us early on in the development process... but then didn't, and wrote their own driver for cgminer. I can't predict what they'll do now and how that will impact on whether code will be merged or maintained in cgminer, but I will be asking for them to provide their driver code publicly.

Sigh.
It really wouldn't be that hard for them y'know...

What if 469GH/s is with 1% of chip working? Are we getting 46,9TH/s devices?!

You would probably need a building to power that. or 2

It was likely to fast-track the development/delivery. They were on a razor-thin line to make deadlines and literally cut it by seconds. Delays, even on the software side, would've thrown everything awry. I doubt they didn't want to work with the cgminer team at all, merely they sidestepped the plan at the time. Considering the team will get equipment at some point somehow, it wasn't likely to try and avoid them. Merely, deadlines mattered more.

In some work I've done in the past when it came to deadlines, it was simply easier for me to take something into my own hands and make sure it was checked-off, rather than hand it off to the person it was designated to in the first place. Revisit it in the future, without a doubt.

Has anyone seen the latest statistics from the Jupiter they have mining? It was fluctuating up to 800Ghz AND IS STABLE AT 650!

http://eligius.st/~wizkid057/newstats/userstats.php/17Czc8RVL3FU5T2MLx2zLbRnpfBNgH9vFo

That could be more than one machine...maybe Jupiter + Mercury? I wouldn't give too much weight to those numbers unless we know that they're only running 1 Jupiter on those workers.

One clue we were given is they were making, on average, 1.4W/gh. It doesn't mean they were limited solely to 500gh or 600gh either. I'd imagine, especially since the chips have built-in failover, you could get much more provided you worked around providing it more power. The machines are using 860w PSU's. Just like with a AM Blade, more power, up the clock = more cycling.

So you're saying I should have ordered a 1200W power supply instead of the 850 I'm having delivered tomorrow?

[kano]

...
Earlier on knc said they'd engage us early on in the development process... but then didn't, and wrote their own driver for cgminer. I can't predict what they'll do now and how that will impact on whether code will be merged or maintained in cgminer, but I will be asking for them to provide their driver code publicly.

doesnt really matter though right? once you get your hands on one, you can make your own awesome driver anyway....

There'd be no point buying one now - it won't get back it's BTC cost - since difficulty will sky rocket in the next month or so - and they don't want us involved so I can't see one appearing on the doorstep.

(a 200% jump would mean that after that 200% jump, 469GH/s would make 22BTC in 100 days if after that jump it rose 30% each 11 days ... then subtract 850W for 100 days ...)

So ... yeah, except that they are required to provide the source code to anyone with one, that asks for the code, I can't see much else happening.

As a developer I certainly have no interest in giving someone $1000's of dollars to update their driver ... and never get that $1000's back.
That's paying someone when you do work for them - yeah not gonna happen.
I prefer to simply not lose the BTC.

[DeathAndTaxes]

Can anyone estimate how many chips per wafer can KnC make?

KNC has never reported the die size.  If someone wants to destroy their new miner and break open the package we could find out real quick.

[ASIC-K]

...
Earlier on knc said they'd engage us early on in the development process... but then didn't, and wrote their own driver for cgminer. I can't predict what they'll do now and how that will impact on whether code will be merged or maintained in cgminer, but I will be asking for them to provide their driver code publicly.

doesnt really matter though right? once you get your hands on one, you can make your own awesome driver anyway....

There'd be no point buying one now - it won't get back it's BTC cost - since difficulty will sky rocket in the next month or so - and they don't want us involved so I can't see one appearing on the doorstep.

(a 200% jump would mean that after that 200% jump, 469GH/s would make 22BTC in 100 days if after that jump it rose 30% each 11 days ... then subtract 850W for 100 days ...)

So ... yeah, except that they are required to provide the source code to anyone with one, that asks for the code, I can't see much else happening.

As a developer I certainly have no interest in giving someone $1000's of dollars to update their driver ... and never get that $1000's back.
That's paying someone when you do work for them - yeah not gonna happen.
I prefer to simply not lose the BTC.

I offered ckolivas my mercury for a couple days to make a better driver if it would help the community.

[600watt]

when knc is over with this hash attack the business model of maybe more than one competitor is history. hashfast, cointerra and all the others, that have no product to ship currently ----  you are screwed, aren´t you ?  

[optimator]

Earlier on knc said they'd engage us early on in the development process... but then didn't, and wrote their own driver for cgminer. I can't predict what they'll do now and how that will impact on whether code will be merged or maintained in cgminer, but I will be asking for them to provide their driver code publicly.

I hope the API on the KNC machines is the same as on cgminer. 

[Puppet]

when knc is over with this hash attack the business model of maybe more than one competitor is history. hashfast, cointerra and all the others, that have no product to ship currently ----  you are screwed, aren´t you ?  

Not at all. First of all those companies all sold enough preorders that they have nothing to worry about no matter what happens.

Secondly, as difficulty shoots up, power consumption will become key again. Not exactly KnC's strong suit. If anything, a few months from here its KnC that will have put themselves out of business while the others, assuming they can deliver on their performance/w promises, will still have products that can be sold, even though obviously the margins wont be anywhere near where they are today.

[ImI]

Does anybody know what size and weight the shipment of one Jupiter is???

[mruiter]

Anybody received a UPS tracking number yet ?

[DeathAndTaxes]

when knc is over with this hash attack the business model of maybe more than one competitor is history. hashfast, cointerra and all the others, that have no product to ship currently ----  you are screwed, aren´t you ? 

It likely will dry up future sales until they start shipping but both of the companies you listed have enough funds (preorders) to make it to delivery.  However if anyone pulls a BFL and falls on their face there is no ability to bring in more funding by extended preorders and upgrades.  My guess is both HF and Cointerra deliver.   I don't think every ASIC company today will still be here in 2015.   It is relatively easy to make a fortune when difficulty is low, demand is high and margins are 99.9% or higher.  As the difficulty skyrockets, demand falls and margins collapse not every company will make it.