Have the issues with the modminers been addressed yet.
Do you still have issues with the latest version with all the correct switches?
Topic: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards - page 4. (Read 119421 times)
December 30, 2012, 09:39:41 PM
Do you still have issues with the latest version with all the correct switches?
December 30, 2012, 09:33:30 PM
Have the issues with the modminers been addressed yet.
December 17, 2012, 03:27:16 PM
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:
I'll let everyone know more tomorrow morning if it stays up all night.
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.
December 17, 2012, 03:19:23 PM
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:
I'll let everyone know more tomorrow morning if it stays up all night.
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.
December 17, 2012, 02:29:58 PM
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:
I'll let everyone know more tomorrow morning if it stays up all night.
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
December 17, 2012, 01:07:51 PM
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:
I'll let everyone know more tomorrow morning if it stays up all night.
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.
December 17, 2012, 02:56:50 AM
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.
Which you did.
No idea why your confusion level is so high understanding that simple post.
December 17, 2012, 01:29:17 AM
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:
I'll let everyone know more tomorrow morning if it stays up all night.
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.
December 16, 2012, 10:11:20 PM
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.
December 16, 2012, 09:45:49 PM
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.
...
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)
December 16, 2012, 09:39:40 PM
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.
December 16, 2012, 09:34:52 PM
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
December 16, 2012, 09:33:09 PM
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.
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.
You can use any pool you like. You can even solo mine with the TML.
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.
December 16, 2012, 09:31:18 PM
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 [
...
max_job_age maximum age of a job (1m30s)
December 16, 2012, 08:32:19 AM
Hmm - I'm wrong
See? Respect the man who admits when he's wrong. Might have to save this link for future use... 
December 16, 2012, 08:04:45 AM
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?
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?
December 16, 2012, 02:49:55 AM
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.
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
December 15, 2012, 10:10:23 PM
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
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
December 15, 2012, 10:09:54 PM
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.
December 15, 2012, 10:06:26 PM
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).
Jump to: