Are you guys both on Windows? I noticed that the Windows timeout values are defined much longer and I wonder if this is related. For Linux the timeout is 200mS but WIN32 is 999 mS. Note that I do all my testing on Linux and libusb could behave differently here.
I tested it first on Windows several days ago. KTest worked fine but CGMiner always gave timeout(-7) error so I changed the timeout to 999ms and the timeout error's gone but still had the stuck problem and low hashing rate. I moved to a real Linux box and there's no timeout error with 200ms setting but have CGMiner stuck problem until I added the "nmsleep(100);" as terrahash suggested. I tested it on both a laptop with Debian 7 and a desktop with Debian 6, all the same. |
|
|
|
Yea I was having the exactly same issue. It has disappeared magically. Maybe the logging code I added, created a little delay and thats why the lock conflicts disappeared. Try adding some delay before wr_lock around line 1500 in usbutils.c #define DEVLOCK(cgpu, _pth_state) do { \
pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &_pth_state); \
// add some delay here \
wr_lock(cgpu->usbinfo.devlock); \
} while (0)
I hardly get any good nonce if I clock it over 279. I have the exact same circuit as provided by BkkCoins. The only difference is that my capacitor is 33pF, instead of his 30pF. I just changed the 220p capacitor to 30p and the circuit is also exactly the same as BBKCoins drew. Ktest still gives "GOOD" from 128M to 300M with correct return time. However, cgminer's stuck more frequently. The WU at 128M goes down to 2.5/m, and WU at 256M goes down to 2/m. It seems that this issue has a lot to do with the clock generation circuit. May be some results cannot be captured. I will test your method. UPDATE: Your method works!!! I added nmsleep(100); \ and everything works like a charm. 128M ~ 8/m WU 256M ~ 17/m WU BBKCoins, please be noticed. This might be a common issue. |
|
|
|
Progress update. The board is currently clocked at 256 and its mining at 3.6 GH/s. See https://bitcointalk.org/index.php?topic=198489.msg2712124#msg2712124WU: ~55/m. Error rate is really low too. I still don't know what happened. I mentioned periods of total inactivity that I was noticing in the log file. I tried to debug it and realized that there was some kind of locking conflict while writing to the USB. I didn't change anything, was just trying to log additional information. Added a few lines of code to log in logging.c and miner.h. Tried to run again, and there were no conflicts anymore. Will look at everything again tomorrow and try to pin point the issue. Great to see this! I am having the same problem with CGMiner as you mentioned before. I am having 4 chips working. The same 2 NOR gates trick as BBKCoins suggested and the RC values are 100Ohm and 220pF. I have tested the board with "ww" in ktest, it always return "GOOD" from 128MHz to 300MHZ and the return time is always correct as expected. However, when I run CGMiner, it's stuck for up to 1 or 2 minutes from time to time and the hashing rate is always much lower than expected (128M WU=4/m, 300M WU=7.1/m). And the HW is very high 10-20%. I have tested it with different pools, all give the similar results. I am going to change the 220pF capacitor to 30pF and test it again. |
|
|
|
Your clock signal is great with very sharp rising/falling edge. I am wondering how you made it.
I simply added a NOR gate after the RC delay (100 ohm, 220pF) of your original circuit, but the signal is not as good as yours. The rising / falling time is much larger than yours and the pulses are broader.
It's better than the original circuit but I still get HWs.
The errors I get now are almost certainly on the input side rather than result capture, except the infrequent overrun I see get counted. I use a trailing edge delay circuit. The first NOR gate has P and N, and it's output goes to A of 2nd NOR gate, then through a 100R resistor to B of 2nd gate. B has the 30pF to GND. So the 2nd NOR is ORing the clock with a delayed clock. The UART is set for rising edge capture, and data is inverted when read out of FIFO (~RCREG). This will be updated in the schematic very soon. Great! Thanks a lot for telling the details. Very helpful. |
|
|
|
Todays snapshot: RC delay, 100 ohm, 220pF, 2 NOR gates with trailing edge circuit. Looks like a good capture and gives better results but I'm still seeing HW errors, though not so many now.  Your clock signal is great with very sharp rising/falling edge. I am wondering how you made it. I simply added a NOR gate after the RC delay (100 ohm, 220pF) of your original circuit, but the signal is not as good as yours. The rising / falling time is much larger than yours and the pulses are broader. It's better than the original circuit but I still get HWs. |
|
|
|
It's because there is no clock signal from the ASIC, but the clock is implicit in the data. So to allow a UART to capture it rather than using a CPLD or FPGA I use a single gate to extract the clock. The delay is so the PIC has enough setup time between the clock and data. Ultimately a CPLD would allow capturing at higher rates and then the PIC could clock the data in as slow as it needs. A more complicated capture could be designed in a CPLD but then we also have another device that needs programming, and you get into another programming tool and using the HDL environment etc. So I was trying to keep it simple as there's already enough to do.
I like your design. It's simple and works good. 60MHZ span is good enough for most situations where the best hashing rate is selected for long run. Geeks can change the capacitor any way. You use two NOR gates and a RC circuit to delay the clock and sharp the edge. I didn't verify it but I think you can move the RC circuit to PIN-1 of the first NOR gate (delay the signal at PIN-1) and get rid of the second NOR gate. It may work and be simpler. |
|
|
|
|
It's so exciting! Thanks a lot for your great work!
I am working on a K16 board with one ASIC at U6. I am using the latest codes on your github.
ktest shows that it works very well. Every time I send a "W", it returns a GOOD nonce.
However, cgminer(3.3.1) doesn't work very well with it. Rarely a valid nonce is returned.
At most time, I cannot see any result("=") reply. It gives "work stale due to stratum job_id mismatch" and runs very slow.
It seems that the cgminer driver doesn't capture some results message from the PIC.
I don't know why but I am thinking maybe this is because cgminer is using a different USB library than the ktest.
If this is a typical issue, I appreciate if you can help when you have time. Otherwise, just ignore it. I will work it out by myself.
|
|
|
|
Lin hi, perhaps you can post your public key on bter site and when you post here you sign hello with private key and add to the post. Then its clear its you  Or some other way to verify. Thanks for you advice. I will list our bitcointalk IDs on the home page of bter.com. |
|
|
|
Please make announcement on bter for proof.
Anyone can easily email to support@bter.com to confirm. I won't waste our spaces on these garbages showing up everyday. |
|
|
|
Please make announcement on bter for proof.
Anyone can easily email to support@bter.com to confirm |
|
|
|
300 YAC = 250 Royalcoin, pm me if interested
BE CAREFUL !!! hdclover IS LYING. He is NOT a team member of BTER.COM I am the admin of bter.com. Anyone is welcome to email to " support@bter.com" or " admin@bter.com" to confirm this. |
|
|
|
This is a thread to document and show my trades/transactions with other members on Bitcointalk.
BE CAREFUL !!! hdclover IS LYING. He is NOT a team member of BTER.COM I am the admin of bter.com. Anyone is welcome to email to " support@bter.com" or " admin@bter.com" to confirm this. |
|
|
|
THIS IS !!! NOT !!! A TEST. THIS IS A REAL EXCHANGE SYSTEM BUT NOT RELEASED TO PUBLIC ON THE WEBSITE YET SO BE CAREFUL, THE ORDERS FILLED WONT BE RESET |
|
|
|
One small thing, the last column of the My funds table on the right hand site says 总计 when it should say "Totals" in English.
Corrected. Thanks. |
|
|
|
Great exchange, BTC showed up after an hour, trade went fast... but then I couldn't withdraw my FTC. Appearantly there's a limit of 200(?!?!) for withdrawls?
withdrawal limit has been decreased to 20 FTC. I'm also gioing to assume that 出错了，无效提现数额，或提现数额小于最低限，请重新输入。means that it really is 50 too, since that's the message that shows up when I try and take out 33. It's good now. please try again. |
|
|
|
Great exchange, BTC showed up after an hour, trade went fast... but then I couldn't withdraw my FTC. Appearantly there's a limit of 200(?!?!) for withdrawls?
withdrawal limit has been decreased to 20 FTC. That's a minimum withdrawal or maximum? minimum |
|
|
|
Great exchange, BTC showed up after an hour, trade went fast... but then I couldn't withdraw my FTC. Appearantly there's a limit of 200(?!?!) for withdrawls?
withdrawal limit has been decreased to 20 FTC. |
|
|
|
The site just went offline. This is creepy.
Yes, a few minutes offline due to the data center network issue just now. Servers are at very low load. |
|
|
|
On withdrawing some FTC I was apparently charged a 0.2% fee - however I don't see any mention of this fee anywhere on bter.com
EDIT: I am however very glad to say decent quantity of FTC withdrawal was otherwise successful.
Sorry we forgot the mention the 0.2% withdraw fee on FTC withdrawal page. We have done so. You can PM me if you did the withdrawal before we mention the fee. I will refund your fee. Thanks I have sent you a PM. fee refunded. |
|
|
|
|
Show Posts
