Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards

[kakobrekla]

Probably a good idea, as long as ignore is added until reasonable sample is gathered (~10min after reset?).

Actually, I'd leave it up to the user.  Frankly, I need both.  A time to first check samples, and the the frequency of checking rates thereafter.

Lets see what ET will say about it.

[1714190222]

1714190222

[1714190222]

1714190222

[1714190222]

1714190222

[kano]

...
 1. If the work is more than a few minutes old, the pool reports "unknown-work" or similar.  Most pools only retain the outstanding jobs in RAM, and since this is limited they forget jobs after 90 seconds or so.  If you try to submit a nonce from a job older than this the pool will reject it even if it's valid (and even if it would have resulted in finding a block!).
...

Of course, since the work IS invalid.

The problem is your software not adhering to the rules given it by the pool - don't try and shift the blame elsewhere.
The pool states the time that work is valid - and your software should adhere to that.
Yes it is a bug in your miner, as you have implied, but that is all it is - the '90 seconds or so' is not some uncertain number as you are implying, it is specified to you by the pool.

There is also a very important reason why that work SHOULD be invalid - it directly represents increasing BTC transaction confirm times.
If you work on a piece of work for half an hour (on a long block) there will be half an hour of BTC transactions that you have ignored if you find a block.

[eldentyrell]

I'd like to make a suggestion: please add something to the effect of minimum_accept_timeframe, so that we can change the frequency that the accept rate is checked.

Hey sure, that's easy.  I have added it to 1.60 (see below).

[eldentyrell]

The pool states the time that work is valid - and your software should adhere to that.

Satoshi's original GetWork API does not provide this information.

Is there some extension that does?  If so, I will support it.

[eldentyrell]

TML 1.60 is posted.


15.Dec.2012  Version 1.60
             Add -Daccept_rate_check_ms=X option to control accept-rate check frequency
             Give RingWrapper.currentJob its own separate lock
             Clean up ping threads from dropped signcryption connections
             Call Thread.setName() more often to help with debugging
             Stop trying to read the output pointer after 10 failures

[kano]

The pool states the time that work is valid - and your software should adhere to that.

Satoshi's original GetWork API does not provide this information.

Is there some extension that does?  If so, I will support it.

Hmm - I'm wrong - it's only with roll-n-time that you get any expiry information from the pool.
cgminer sets it directly.
Oh well - it's an option in cgminer that defaults to 120s (that you can reduce if your pool has it shorter and thus rejects work too often)
Thus since the default in cgminer is 120s I'd guess that means most pools allow 120s also

[BR0KK]

Can someone help a windows noob to get tml running:

Ztex with -m c option working:


Ztex with new tml:


What am i looking at here? There's an error but that thing seems to run somehow?

Now somehow tml recognized the board:



But still not working. There's a lib USB error ?


Dumb question: Does this software run with p2Pool or do i need to switch to a prorietary pool like EMC?

[-ck]

Hmm - I'm wrong

See? Respect the man who admits when he's wrong. Might have to save this link for future use...

[eldentyrell]

Oh well - it's an option in cgminer that defaults to 120s (that you can reduce if your pool has it shorter and thus rejects work too often)

Same with TML, although the default is 90 seconds:


$ java -jar tml.jar
_________________________________________________________________________
Tricone Mining Logic, host software v1.60

usage: java [<properties>] -jar tml.jar <devs> <urls>
...
     max_job_age               maximum age of a job (1m30s)

[eldentyrell]

Please post your logs as text files, not images.  Also, please don't host your stuff on sites that pop up obnoxious sports ads in my face when I try to view the log files.  Thanks.

But still not working. There's a lib USB error ?

Unfortunately the code that supports the ztex device's proprietary USB interface relies on ztex's USB code, which is full of bugs that have driven me to the brink of insanity.  Kakobrekla might be able to help you get it working, but you're really better off using JTAG instead of that board's proprietary USB connection.

Dumb question: Does this software run with p2Pool or do i need to switch to a prorietary pool like EMC?

You can use any pool you like.  You can even solo mine with the TML.

[eldentyrell]

I'd like to make a suggestion: please add something to the effect of minimum_accept_timeframe, so that we can change the frequency that the accept rate is checked.

Hey sure, that's easy.  I have added it to 1.60 (see below).

Grr, I left out the commit that enables this feature.  I've re-uploaded 1.60 fixing that (and not changing anything else); if you downloaded it 1.60 already and want this feature, please re-download.  The shasum of the updated jar is 689d00e5ac86cabfde749ac11a912ec35a27bf54

[kakobrekla]

But still not working. There's a lib USB error ?

Sorry for the late reply, not that is of much use. Unfortunately in all my efforts I didn't manage to get past invalid interface -1 on any of my windows setups. Virtual machine will fix this for you.

Seems like a part of ztex's lib acts differently under Windows.

[kano]

But still not working. There's a lib USB error ?

Unfortunately for ztex board the TML relies on ztex's USB code, which is full of bugs that have driven me to the brink of insanity.  Kakobrekla might be able to help you get it working, but you're really better off using JTAG.
...

Having battled with USB in windows a few weeks back I can suggest some hints that *might* be relevant:

Firstly, ensure it is indeed libusb and not libusbx being used.

Secondly, I had to make sure the driver was WinUSB (+libusb) and that solved the cgminer windows USB issues
(Zadig - http://sourceforge.net/projects/libwdi/files/zadig/)
the code worked fine with linux from the outset but I then spent small parts of a couple of weeks until I found all the extra code I added wasn't actually mandatory ... though certainly useful

Though of course with java YMMV (i.e. it may not be relevant)

[eldentyrell]

Hmm - I'm wrong

See? Respect the man who admits when he's wrong. Might have to save this link for future use...

Indeed, that is unusual for kano -- he still hasn't admitted he was wrong about his absurd claim that the TML was derived from cgminer.

[lukasbradley]

Looking good so far on 1.60 on MMQs.  It's been running stably for 3 hours now on 2 miners.

I'm going to guess this was the change that did it:

Code:

Give RingWrapper.currentJob its own separate lock

I'll let everyone know more tomorrow morning if it stays up all night.

[kano]

Hmm - I'm wrong

See? Respect the man who admits when he's wrong. Might have to save this link for future use...

Indeed, that is unusual for kano -- he still hasn't admitted he was wrong about his absurd claim that the TML was derived from cgminer.

LOL - that comment was exactly as it says - sarcasm stating if you're charging for your service, since you made the claim that you spent so many hours doing it (way many less hours than have been spent on cgminer by the likes of jgarzik, ckolivas, myself and others) then make sure you provide your own miner rather than expecting someone with a free miner to do that work for you.
Which you did.
No idea why your confusion level is so high understanding that simple post.

[lukasbradley]

Looking good so far on 1.60 on MMQs.  It's been running stably for 3 hours now on 2 miners.

I'm going to guess this was the change that did it:

Code:

Give RingWrapper.currentJob its own separate lock

I'll let everyone know more tomorrow morning if it stays up all night.

I spoke too soon... it died.  Ugh... what a bad night.

Will rewrite the shell script tonight to try to use the new command line args.

[kakobrekla]

Looking good so far on 1.60 on MMQs.  It's been running stably for 3 hours now on 2 miners.

I'm going to guess this was the change that did it:

Code:

Give RingWrapper.currentJob its own separate lock

I'll let everyone know more tomorrow morning if it stays up all night.

I spoke too soon... it died.  Ugh... what a bad night.

Will rewrite the shell script tonight to try to use the new command line args.

Can you send a log to email?

kakobrekla

[lukasbradley]

Looking good so far on 1.60 on MMQs.  It's been running stably for 3 hours now on 2 miners.

I'm going to guess this was the change that did it:

Code:

Give RingWrapper.currentJob its own separate lock

I'll let everyone know more tomorrow morning if it stays up all night.

I spoke too soon... it died.  Ugh... what a bad night.

Will rewrite the shell script tonight to try to use the new command line args.

Can you send a log to email?

kakobrekla

I will, but it's the same issue as before.  The process continues to report on the miner, but the miner apparently stops.  Hashing drops to zero over 3 or so minutes.

[kakobrekla]

Looking good so far on 1.60 on MMQs.  It's been running stably for 3 hours now on 2 miners.

I'm going to guess this was the change that did it:

Code:

Give RingWrapper.currentJob its own separate lock

I'll let everyone know more tomorrow morning if it stays up all night.

I spoke too soon... it died.  Ugh... what a bad night.

Will rewrite the shell script tonight to try to use the new command line args.

Can you send a log to email?

kakobrekla

I will, but it's the same issue as before.  The process continues to report on the miner, but the miner apparently stops.  Hashing drops to zero over 3 or so minutes.

Ok, just to make sure this is the second 1.60 with shasum of 689d00e5ac86cabfde749ac11a912ec35a27bf54? If it is, lets wait for ET to go through the log.