Topic: Swedish ASIC miner company kncminer.com - page 225. (Read 3049515 times)

I meant people that have received hardware, ie status changed to shipped. Can't find a tracking number anywhere.

Nope. #201xx, paid March 21

imho if it is really really unfixable at the KNC end they will simply get a patch out that works at 100mh and say they are square with what we ordered it at....wtf they don't plan on selling any equipment to us ever again anyway...

IF they say the Titan is badly designed fire hazard not up to snuff..then by admitting that imho ..they would have to refund or compensate Neptune folks

no way they will ever do that ..they will use whatever wiggle room that they can to stomp out any Titan refunds or compensation.....as it would reflect on the Neptune folks

getting refunds too..and there are  a lot more of them...

from my point of view it is the "BFL like 'deafening silence' " that is familiar......no refunds.....for us Titan folks and 3rd batch Neptunes I think .....so if it gets to that point they
will let the lawyers work it out and stall it out for 2 to 3 years...by the by I notice that people in the EU said they HAVE gotten refunds...no one I know of has outside of the EU
that I know of...(well one guy with a KNC advocacy group when KNC missed a reply) but other then him...nothing comes to mind

we be screwed in the short term and all this mining tied up $$$ in bitcoin is always in the short term...they will drag it out till the whole problem is moot refund $$$ wise imho

still can't believe how they went from nun  (last year) to porn star (this year) ...that is quite the hoop to jump thru ethics wise....then of course I heard brock pierce has his
fingers in KNC from last jan 2013..that could explain most of this

all rumor..like BFL we will find out the real deal a year or so from now when probably authorities will act...too late.but still

It might be an interesting experiment to create multiple workers on a Titan using the load balancing feature.

For example, create 5 separate workers to b) the same pool and b) different pools, each with a 20% quota and report the results.
This should result in 5 workers each with ~ 60 Mh/s, which is well within the experiences people already have with some Zeus or Innosilicon miners.

Would you like to conjecture why this might be true and provide an example of the type of back-end (pool) tuning required to fix it ?

Perhaps, for example, you'd explain to us how back-end (pool) tuning would solve the problem Lucazane recently described in this recent post https://bitcointalksearch.org/topic/m.9007810

Looks like my scrap metal has shipped. Did you guys receive tracking numbers for your KNC hardware?

It does 'see' it as work the same way for the most part, but the backend if not properly tuned for fast hashing asics, can cause low hashrates/high errors, and cause them to cap out or poop. I've seen it firsthand. I definitely wouldn't trust a multipool if I had a Titan and was focused on ROI. I've seen SHA256 coins do the same thing, especially on pools where the operator didn't really know much about tuning the backend, causing 100-200gh miners to be running around 50-75, because the pool couldn't use the work being generated.

I've seen large GPU farms do just fine on a pool, and when gridseeds of same hashrate hit the same pool, they tank. They required custom settings on the backend. I would bet that for some--not all--the same thing is occuring fo KNC's gear.

Certainly doesn't apply to the Smolder feature which some have been shipped with.

For fixed difficulty pools, a miner needs to set an appropriate difficulty for its worker(s). For pools which implement vardiff, it is up to the pool to set an appropriate difficulty for each worker based on miner work submission rates.

There should be nothing special about using a Titan on either type of pool provided difficulty is set appropriately. From a stratum protocol point of view, one miner looks just like the next.

Recent customer reports indicate that the Titan is slow to flush old work and accept new, at times taking up to 7 seconds.

Which scrypt miners, and more importantly multi coin pools, have been found to be stable on multipool/merge mining at 300 Mh/s+?

There has been reports on other threads about problems with fast miners on merge/multipools pools.   It appears some multi coin pools were originally set up assuming miners hash rates of a few Mh/s and have trouble with faster miners.  

When I have a look into the code base I cannot find any changes that could have an impact on bad dies or anything related to hashing.
There's only shutting down DCs on system reboot/shutdown and minor improvements for the web-interface (uses a cache now).

I have expected more when reading their engineers work day & night to improve the firmware even further.

Thanks for the update bitdigger2013

The Titan should be able to mine any scrypt coin at the advertised hash rate (300 Mh/s+) on any pool that appears stable to other types of scrypt miners.

If it doesn't, it is broken.

It is obvious to me from comments here and on the KNC forum that KNC have failed to deliver a fully functional Titan miner in Q2/Q3. Blaming pools is disingenuous. It is also obvious to me, based on reports of the 1.03 firmware release, that they don't know how to fix the problems.

It has taken their team of embedded systems engineers almost a week to publish a firmware release that by all accounts is worse than the last one.

 

It seems to me there are several different issues and not sure if they are all related or not.

1. People report reboots of bfgminer every 3 min or so. Worst problem since you can't mine very well like that

2. Hashing speed of Titan not stable BUT DOES NOT involve a restart of BFGminer.

Luckily, I think, I don't have 1. problem. BFGminer does not restart for me and keeps mining.

My issue is #2

When mining on liteguardian.com which is a litecoin only pool that has an asic specific port with 1500 worker difficulty I get the best hash rate of 300MHS. I do get nonce errors and flushing work errors but hash seems to be fairly stable.

Mining on litecoinpool.org where you can set your own worker difficulty, which I played around with from 1024 to 16384 gets lower hash rate. Averaging between 225 and 260mhs. This pool has DOGE merge mining.

Trying multipool (clevermining, wafflepool) setting my own difficulty and again same ranges available. I get way more rejects 10%+ way more nonce errors and flushing work. Hash rate varies from 100-270 mhs

Trying my own NOMP pool with litecoin I get similar results as liteguardian...however I have not found a block yet

Again on my own NOMP trying different alt scrypt coins like VIA, QTL etc. There I really see what is happening.

VIA has block times of 24 secs with fast coin diff readjustments. This is where I see 90% of the errors occurring. The changes in diff and the fact that blocks are being found very fast, TITAN is not able to keep up with it and is constantly getting none errors, flushing work and tons and tons of rejects. I have tried anything form worker diff of 256 to 32768. In fact the higher the diff I set the worse the results because I am losing more work everytime there is a change.

I don't understand what causes this to happen as I am not well versed in hardware or software but it sure seems from what I am observing in my tests is that the miner is STABLE when mining a coin that does not merge mine and has a stable difficulty and block time is longer. Less errors and better observed hash speed.

On the other hand coins with fast block times and fast diff readjustments cause the titan to be UNSTABLE and have poor performance.

What I don't know is if this is caused by poor pool settings or if it is the hardware/firmware of Titan.

Hahah these is joke

Where are the bonus Neptics ??

No still paid mine

Any Titan order status changes today ?

Order #, Paid date ?

It would have probably been helpful for the titan batch 1 customers, but the bend-over already happened and now its too late. Maybe soothing ointment can help now.

Yes but a20 or a10 not pi

You could solder the cables to the board and still have the same/similar issues if there's too much draw.

While it's a pisspoor setup from an OEM, I would just bite the bullet and solder some 12-16 gauge wires from the 12v rail inside the PSU, to the PCB and be done with it.