TML 1.71 is posted with a minor bugfix relative to 1.70.
Topic: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards - page 3. (Read 119444 times)
February 26, 2013, 01:47:12 AM
February 25, 2013, 10:28:13 PM
ET hasn't been too willing to work on his bitstream to support cm1.
No, the carinsmore people just haven't provided software to talk to their proprietary USB interface.
https://bitcointalk.org/index.php?topic=49971.msg1282883;topicseen#msg1282883
ChrisP sent me some code, but it doesn't seem to work (see link above). If I can't talk to the board there's not much more I can do.
Maybe you can email ET and ask him kindly to implement a DCM watchdog on his next bitstream
It already has one.
Ah ok, I don't believe their usb interface is proprietary though. The bitstream for the controller is open source. We just need to get someone who develops for the cm1 like makomk or glasswalker to try and debug it with the TML bitstream then.
February 25, 2013, 10:06:26 PM
TML 1.70 has been released.
This release contains a lot of fixes to reduce stales. This is mostly due to one major fix (forgetting to register work in the "get me all the work with this prevblock" table) and a lot of smaller fixes. I strongly urge everybody to upgrade. New software only, no new bitstream(s).
This release also adds the option prevblock_blacklist_ms, default=4000. After the TML sees work with a prevblock it's never seen before, it immediately marks all work as invalid -- this is the "new prevblock detection". It turns out that, for reasons which elude me, many pools will actually switch from one prevblock to another and then back. This was causing major problems with the new prevblock detection code a few releases back, so I disabled most of it. Now that I know what was causing the craziness, I can go back to blacklisting old prevblocks once a new one shows up, but the blacklisting is only for a short period of time -- in case the pool decides to go back to the old prevblock (again, I have no idea why it would do this…)
25.Feb.2013 Version 1.70
Add -Dprevblock_blacklist_ms
major overhaul of how work revocation is handled
QueueingWorkSource: print just the exn, not the stack trace
HttpWorkSource: catch exceptions thrown in timer thread
HttpWorkSource: do the new-prevblk check proactively in the long poll
WorkRevocationFilter: maintain static work-to-filter mapping
deal with an unlikely sitaution in SCClient by simply erroring out the job
telnet monitor updates
This release contains a lot of fixes to reduce stales. This is mostly due to one major fix (forgetting to register work in the "get me all the work with this prevblock" table) and a lot of smaller fixes. I strongly urge everybody to upgrade. New software only, no new bitstream(s).
This release also adds the option prevblock_blacklist_ms, default=4000. After the TML sees work with a prevblock it's never seen before, it immediately marks all work as invalid -- this is the "new prevblock detection". It turns out that, for reasons which elude me, many pools will actually switch from one prevblock to another and then back. This was causing major problems with the new prevblock detection code a few releases back, so I disabled most of it. Now that I know what was causing the craziness, I can go back to blacklisting old prevblocks once a new one shows up, but the blacklisting is only for a short period of time -- in case the pool decides to go back to the old prevblock (again, I have no idea why it would do this…)
25.Feb.2013 Version 1.70
Add -Dprevblock_blacklist_ms
major overhaul of how work revocation is handled
QueueingWorkSource: print just the exn, not the stack trace
HttpWorkSource: catch exceptions thrown in timer thread
HttpWorkSource: do the new-prevblk check proactively in the long poll
WorkRevocationFilter: maintain static work-to-filter mapping
deal with an unlikely sitaution in SCClient by simply erroring out the job
telnet monitor updates
February 25, 2013, 09:57:17 PM
ET hasn't been too willing to work on his bitstream to support cm1.
No, the carinsmore people just haven't provided software to talk to their proprietary USB interface.
https://bitcointalk.org/index.php?topic=49971.msg1282883;topicseen#msg1282883
ChrisP sent me some code, but it doesn't seem to work (see link above). If I can't talk to the board there's not much more I can do.
Maybe you can email ET and ask him kindly to implement a DCM watchdog on his next bitstream
It already has one.
February 25, 2013, 01:06:57 AM
How would i let it run in a cairnsmore Board? Flash it and use it icarus style, or only via jtag or another special dip switch mode. chrisp never answered here openly and i do not seem to find anything else.
ET hasn't been too willing to work on his bitstream to support cm1. The DCM on the cm1 boards are unstable and another clock source has to be used or at least a watch dog. Maybe you can email ET and ask him kindly to implement a DCM watchdog on his next bitstream release and then we can use chrisp's work to debug further.
February 25, 2013, 12:28:26 AM
February 25, 2013, 12:25:31 AM
How would i let it run in a cairnsmore Board? Flash it and use it icarus style, or only via jtag or another special dip switch mode. chrisp never answered here openly and i do not seem to find anything else.
January 14, 2013, 12:20:58 AM
If there is more then one running they seem to disconnect randomly.
We really can't do anything at to help you unless you post a log file.
The log file is that stuff that prints on the console when you run the TML. If you're using unix, just type
$ tml args-go-here | tee log-file.txt
And post log-file.txt here (or link to it on pastebin) after the problem occurs.
January 10, 2013, 11:40:33 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.
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.
Same issue with modminers on tml. If there is more then one running they seem to disconnect randomly. Using the most current version and using
sudo java -Dclock_pin=fgg484.K20 -Davoid_reprogramming=true -Dclock_pin_freq=100 -Dstatus_port=5555 -jar tml-1.60a.jar modminer:/dev/ttyACM0 modminer:/dev/ttyACM1 at the command line.
I'll check with ET whats the status with this, can you try to produce a the log as described on the tml page?
January 10, 2013, 11:35:25 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.
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.
Same issue with modminers on tml. If there is more then one running they seem to disconnect randomly. Using the most current version and using
sudo java -Dclock_pin=fgg484.K20 -Davoid_reprogramming=true -Dclock_pin_freq=100 -Dstatus_port=5555 -jar tml-1.60a.jar modminer:/dev/ttyACM0 modminer:/dev/ttyACM1 at the command line.
January 07, 2013, 03:41:45 PM
Yes.
Not working. Getting this error now.
H:0 X:0 E:0 T:4m15s | H:0 E:0 A:0 R:0 T:4m15s java.io.IOException: TML acknowledgement of read operation failed; expected=0x1 got=0x0 chip=x6500:AH01A6QI:0
at com.triconemining.board.MiningChip.read(MiningChip.java:68)
at com.triconemining.miner.ChipWrapper.checkMagicNumber(ChipWrapper.java:307)
at com.triconemining.miner.ChipWrapper.
at com.triconemining.miner.BoardWrapper.getChip(BoardWrapper.java:53)
at com.triconemining.miner.BoardWrapper.run_(BoardWrapper.java:108)
at com.triconemining.miner.BoardWrapper.run(BoardWrapper.java:72)
This has nothing to do with the error above. Please pastebin a debug log of the latest version ran with the correct switches. http://www.tricone-mining.com/troubleshooting.html
Thanks.
How do I do a debug log. The command line is the same as I have always been using. Not sure why there is an error now.
The instructions are on the link above. You can see all the available switches/options here http://www.tricone-mining.com/tml.html
Ill just switch back to one of the other miners as this is out of my realm of understanding on how to do it.
You did reset the boards before re-runing it, right?
Thanks. That looks like it solved the problem.
January 07, 2013, 03:02:02 PM
Yes.
Not working. Getting this error now.
H:0 X:0 E:0 T:4m15s | H:0 E:0 A:0 R:0 T:4m15s java.io.IOException: TML acknowledgement of read operation failed; expected=0x1 got=0x0 chip=x6500:AH01A6QI:0
at com.triconemining.board.MiningChip.read(MiningChip.java:68)
at com.triconemining.miner.ChipWrapper.checkMagicNumber(ChipWrapper.java:307)
at com.triconemining.miner.ChipWrapper.
at com.triconemining.miner.BoardWrapper.getChip(BoardWrapper.java:53)
at com.triconemining.miner.BoardWrapper.run_(BoardWrapper.java:108)
at com.triconemining.miner.BoardWrapper.run(BoardWrapper.java:72)
This has nothing to do with the error above. Please pastebin a debug log of the latest version ran with the correct switches. http://www.tricone-mining.com/troubleshooting.html
Thanks.
How do I do a debug log. The command line is the same as I have always been using. Not sure why there is an error now.
The instructions are on the link above. You can see all the available switches/options here http://www.tricone-mining.com/tml.html
Ill just switch back to one of the other miners as this is out of my realm of understanding on how to do it.
You did reset the boards before re-runing it, right?
January 07, 2013, 02:57:12 PM
Yes.
Not working. Getting this error now.
H:0 X:0 E:0 T:4m15s | H:0 E:0 A:0 R:0 T:4m15s java.io.IOException: TML acknowledgement of read operation failed; expected=0x1 got=0x0 chip=x6500:AH01A6QI:0
at com.triconemining.board.MiningChip.read(MiningChip.java:68)
at com.triconemining.miner.ChipWrapper.checkMagicNumber(ChipWrapper.java:307)
at com.triconemining.miner.ChipWrapper.
at com.triconemining.miner.BoardWrapper.getChip(BoardWrapper.java:53)
at com.triconemining.miner.BoardWrapper.run_(BoardWrapper.java:108)
at com.triconemining.miner.BoardWrapper.run(BoardWrapper.java:72)
This has nothing to do with the error above. Please pastebin a debug log of the latest version ran with the correct switches. http://www.tricone-mining.com/troubleshooting.html
Thanks.
How do I do a debug log. The command line is the same as I have always been using. Not sure why there is an error now.
The instructions are on the link above. You can see all the available switches/options here http://www.tricone-mining.com/tml.html
Ill just switch back to one of the other miners as this is out of my realm of understanding on how to do it.
January 07, 2013, 02:55:10 PM
Yes.
Not working. Getting this error now.
H:0 X:0 E:0 T:4m15s | H:0 E:0 A:0 R:0 T:4m15s java.io.IOException: TML acknowledgement of read operation failed; expected=0x1 got=0x0 chip=x6500:AH01A6QI:0
at com.triconemining.board.MiningChip.read(MiningChip.java:68)
at com.triconemining.miner.ChipWrapper.checkMagicNumber(ChipWrapper.java:307)
at com.triconemining.miner.ChipWrapper.
at com.triconemining.miner.BoardWrapper.getChip(BoardWrapper.java:53)
at com.triconemining.miner.BoardWrapper.run_(BoardWrapper.java:108)
at com.triconemining.miner.BoardWrapper.run(BoardWrapper.java:72)
This has nothing to do with the error above. Please pastebin a debug log of the latest version ran with the correct switches. http://www.tricone-mining.com/troubleshooting.html
Thanks.
How do I do a debug log. The command line is the same as I have always been using. Not sure why there is an error now.
The instructions are on the link above. You can see all the available switches/options here http://www.tricone-mining.com/tml.html
January 07, 2013, 02:53:22 PM
Yes.
Not working. Getting this error now.
H:0 X:0 E:0 T:4m15s | H:0 E:0 A:0 R:0 T:4m15s java.io.IOException: TML acknowledgement of read operation failed; expected=0x1 got=0x0 chip=x6500:AH01A6QI:0
at com.triconemining.board.MiningChip.read(MiningChip.java:68)
at com.triconemining.miner.ChipWrapper.checkMagicNumber(ChipWrapper.java:307)
at com.triconemining.miner.ChipWrapper.
at com.triconemining.miner.BoardWrapper.getChip(BoardWrapper.java:53)
at com.triconemining.miner.BoardWrapper.run_(BoardWrapper.java:108)
at com.triconemining.miner.BoardWrapper.run(BoardWrapper.java:72)
This has nothing to do with the error above. Please pastebin a debug log of the latest version ran with the correct switches. http://www.tricone-mining.com/troubleshooting.html
Thanks.
How do I do a debug log. The command line is the same as I have always been using. Not sure why there is an error now.
January 07, 2013, 02:25:30 PM
Yes.
Not working. Getting this error now.
H:0 X:0 E:0 T:4m15s | H:0 E:0 A:0 R:0 T:4m15s java.io.IOException: TML acknowledgement of read operation failed; expected=0x1 got=0x0 chip=x6500:AH01A6QI:0
at com.triconemining.board.MiningChip.read(MiningChip.java:68)
at com.triconemining.miner.ChipWrapper.checkMagicNumber(ChipWrapper.java:307)
at com.triconemining.miner.ChipWrapper.
at com.triconemining.miner.BoardWrapper.getChip(BoardWrapper.java:53)
at com.triconemining.miner.BoardWrapper.run_(BoardWrapper.java:108)
at com.triconemining.miner.BoardWrapper.run(BoardWrapper.java:72)
This has nothing to do with the error above. Please pastebin a debug log of the latest version ran with the correct switches. http://www.tricone-mining.com/troubleshooting.html
Thanks.
January 07, 2013, 02:21:51 PM
Yes.
Not working. Getting this error now.
H:0 X:0 E:0 T:4m15s | H:0 E:0 A:0 R:0 T:4m15s java.io.IOException: TML acknowledgement of read operation failed; expected=0x1 got=0x0 chip=x6500:AH01A6QI:0
at com.triconemining.board.MiningChip.read(MiningChip.java:68)
at com.triconemining.miner.ChipWrapper.checkMagicNumber(ChipWrapper.java:307)
at com.triconemining.miner.ChipWrapper.
at com.triconemining.miner.BoardWrapper.getChip(BoardWrapper.java:53)
at com.triconemining.miner.BoardWrapper.run_(BoardWrapper.java:108)
at com.triconemining.miner.BoardWrapper.run(BoardWrapper.java:72)
January 07, 2013, 01:30:52 PM
Yes.
January 07, 2013, 01:22:21 PM
The signcryption network was effectively not working for a few hours today. I apologize. I am really really sick right now, and the failure occurred right after I'd gone to bed and taken a lot of cold medicine. Kako paged me but I slept through the page and didn't respond to it until after I woke up.
Long story short, all bitstream versions prior to maclane were trial versions valid only for 60 days after their creation date. When checking "is this bitstream version a trial or not" in order to produce (what I thought would be) helpful error messages I used a "<=" instead of a "<" sign. The issue has been fixed.
PS, somebody please tell bitvps to fix their SSL certificate, I can't pay my bill with them until they do this. If they don't get their act together right-quick I'm dropping them from the signcryption network. I've been pestering them about this for two weeks now and am pretty unimpressed with the lack of any sort of response.
Long story short, all bitstream versions prior to maclane were trial versions valid only for 60 days after their creation date. When checking "is this bitstream version a trial or not" in order to produce (what I thought would be) helpful error messages I used a "<=" instead of a "<" sign. The issue has been fixed.
PS, somebody please tell bitvps to fix their SSL certificate, I can't pay my bill with them until they do this. If they don't get their act together right-quick I'm dropping them from the signcryption network. I've been pestering them about this for two weeks now and am pretty unimpressed with the lack of any sort of response.
Has this been fixed yet.
January 06, 2013, 06:47:38 PM
The signcryption network was effectively not working for a few hours today. I apologize. I am really really sick right now, and the failure occurred right after I'd gone to bed and taken a lot of cold medicine. Kako paged me but I slept through the page and didn't respond to it until after I woke up.
Long story short, all bitstream versions prior to maclane were trial versions valid only for 60 days after their creation date. When checking "is this bitstream version a trial or not" in order to produce (what I thought would be) helpful error messages I used a "<=" instead of a "<" sign. The issue has been fixed.
PS, somebody please tell bitvps to fix their SSL certificate, I can't pay my bill with them until they do this. If they don't get their act together right-quick I'm dropping them from the signcryption network. I've been pestering them about this for two weeks now and am pretty unimpressed with the lack of any sort of response.
Long story short, all bitstream versions prior to maclane were trial versions valid only for 60 days after their creation date. When checking "is this bitstream version a trial or not" in order to produce (what I thought would be) helpful error messages I used a "<=" instead of a "<" sign. The issue has been fixed.
PS, somebody please tell bitvps to fix their SSL certificate, I can't pay my bill with them until they do this. If they don't get their act together right-quick I'm dropping them from the signcryption network. I've been pestering them about this for two weeks now and am pretty unimpressed with the lack of any sort of response.
Jump to: