The CGI process did not produce any response
+1 cold reboot your controller, i did the same As I said before, the problem is that lightningasic.com is currently down. The firmware checks with http://www.lightningasic.com/firmware/md5/md5.txt and tries to match the md5 of the uploaded file. If it can't connect then there is nothing to match and it times out. I've notified Jack. |
|
|
|
this version gives me around 10% lesser hashrate then the orginal cgminer .... I did a test with 20 miners .... I asked for it ... with PM no answer ... so far ... Interesting. I started using the girnyau version recently but have not noticed this. Will take a closer look. The two versions are not much different from comparing the source code. The dtbartle version went away from setting static freq's and now support increments of 25. The version you referenced is an earlier build of dtbartle that had static freq. I have considered forking the current dtbartle version with the per miner freq part of girnyau but am still undecided on doing static freq's or increments of 25. If I could figure out how to code increments of 5 that would be great. If static then there is not much benefit over just using girnyau's fork. My miners are all over the map supporting freq's of 850 - 900+. Most of them do 863. Are you basing your results on the pool reported hashrates? Contrary to what that one poster spams all over various threads the hashrate reported by pools are inaccurate and should not be used as a basis of your miners performance. Edit: I'm not using a Pi. I found it too unreliable and like you mentioned about 10% lower hashrate. IMO 25 MHz increments work the best, one of my miners runs stable at 925 MHz, but throws HW errors at 856 MHz. The 25 MHz increments have the lowest PLL frequency and other PLL dividers set at 0. I have also found that the cgminer forks does not take in account the hashing time lost when finding an invalid nonce (HW error). Interesting. Thanks...hadn't actually looked at the methods they are using to increment. When you say "cgminer doesn't take in account the hashing time lost when finding an invalid nonce (HW error)" are you referring to it's display of hashrate? Are you using dtbartle or girnyau? Here's a 48 hour run on girnyau. Notice that some of the individual chips are not as good as others. I think someone mentioned perhaps coding freq per chip in the future (might have been bfgminer). I'm going to scale down to increments of 25 on girnyau to see what that does. Also some of these HW errors may be due to the internet connection as I only have 1-2 bars on the mobile hotspot it's hooked up to...not the best setup for testing  Yes the hashrate displayed is basically (time elapsed x some constant x frequency x 5). So in that sense, hardware errors don't affect hashrate, at all. The way I do it, increment a hashes variable and time_spent_hashing variable, when a HW error occurs the hashes isn't incremented, but the time_spent_hashing is, and thus hashrate drops. That is the way it should be IMO, to get an accurate estimation of how HW errors affect the hashrate. Not using any of those, but Lighningasic firmware (which uses cpuminer) has per chip auto overclocking ATM. |
|
|
|
Argh, lightningasic.com is down again, which is why upgrading isn't working currently. Upgraded my V3c to V3d, seems to be mining good. Very stable hashrates at the pool. Would love to have the current clock speed display on a separate column on the miner page (1st page) just as a quick indication of what they are clocked at currently. If there is enough space to add it... auto overclocking tunes each chip seperately, so a miner may be running at different frequencies. |
|
|
|
Prolly being biased, but you guys should switch to Lightningasic firmware, we now have an auto-overclocking feature that will overclock each individual chip (5 chips per Gridseed miner). Also the reject rate is close to 0, I've been getting 99.91% accepted running over 24 hours at Ghash.io.
Do you have an image for Raspberry Pi yet? I've seriously considered it, but I have no intentions of buying a TP controller. No intentions of porting to Rpi. |
|
|
|
New updated firmware available (v3d).
If you are already running v3, can you upgrade to v3d directly? Or should you first use v2 firmware? I flashed to v3d but can't tell if it worked or not. Any way to check this? You can upgrade directly from v3, if you see the new option "Auto Overclocking" means that it succeeded. |
|
|
|
but its only for the controller not cgiminer or bfgminer  . SO is the firmware new firmware for the gridseeds or new firmware for the contoller? and i have a TP link 703n, just not modded it yet or flashed it, where can i get an image for flashing it for controllering the grids??? It will work with Tp-link 703N, just follow the guide on how to flash it. There is cpuminer included, its faster and more efficient at Gridseed mining than cgminer or bfgminer. nice but the price of an Tp link + wiibox is to expensive to ROI just for that few hasing rate if you do not have an massive amount of gridseeds at home. If you have just a few, IMHO it's better to buy 1 extra gridseed cheap. Who said you need to buy a Wiibox? Tp-link 703N can be easily had for $20 shipped. |
|
|
|
but its only for the controller not cgiminer or bfgminer . SO is the firmware new firmware for the gridseeds or new firmware for the contoller? and i have a TP link 703n, just not modded it yet or flashed it, where can i get an image for flashing it for controllering the grids??? It will work with Tp-link 703N, just follow the guide on how to flash it. There is cpuminer included, its faster and more efficient at Gridseed mining than cgminer or bfgminer. |
|
|
|
|
Prolly being biased, but you guys should throw away the Rpi and switch to Lightningasic firmware, we now have an auto-overclocking feature that will overclock each individual chip (5 chips per Gridseed miner). Also the reject rate is close to 0, I've been getting 99.91% accepted running over 24 hours at Ghash.io.
BTW, Jack is making a test rig with 100 miners connected on a single controller, I will have a pic up to prove it.
|
|
|
|
I get the same "failed to unpack" problem with RC10d as I did with RC10c.
There has to be a sollution for this, other than mailing it to either of you guys and loosing out on days or weeks of mining.
Those of us experiencing this problem, were we supplied flawed controllers from AsiaBTC?
What exactly is it you guys fix if we were to send the controller to you? Can it really not be fixed in any other way?
This is starting to become a big problem with new versions looking better. This needs to be adressed.
If you are good at soldering, you can attempt it yourself: http://forums.openpilot.org/blog/52/entry-92-unbrick-wr703n-wifi-router/Reflash your controller through the serial console to the v1 bin image, then using the web interface upload the rc10 bin image. I'm offering to repair free of charge, all you need to do is send them to me and pay the shipping. Where are you located? Any chance of a swap system? You send a fixed controller first, I hook that one up, and send the broken one to you? I am located in W-Europe (PM me to arrange shipping), I don't have a spare controller on me ATM. |
|
|
|
|
Prolly being biased, but you guys should throw away the Rpi and switch to Lightningasic firmware, we now have an auto-overclocking feature that will overclock each individual chip (5 chips per Gridseed miner). Also the reject rate is close to 0, I've been getting 99.91% accepted running over 24 hours at Ghash.io.
|
|
|
|
|
Prolly being biased, but you guys should switch to Lightningasic firmware, we now have an auto-overclocking feature that will overclock each individual chip (5 chips per Gridseed miner). Also the reject rate is close to 0, I've been getting 99.91% accepted running over 24 hours at Ghash.io.
|
|
|
|
|
To elaborate a bit on how the auto overclocking works, if the chip has hashed for over 600s it will attempt to change the frequency. If there is more than 1 HW error or if the current hashrate is less than the previous hashrate (after that 600s period), it will decrease the frequency, otherwise increase it. It will stop adjusting if the frequency has been decreased atleast once, so make sure to pick a low enough frequency to start with. The frequency adjusts in steps of 25MHz, I have found this to give the most stable results while overclocking, and it also makes sense if you look at how the frequency is calculated from the PLL variables.
|
|
|
|
I get the same "failed to unpack" problem with RC10d as I did with RC10c.
There has to be a sollution for this, other than mailing it to either of you guys and loosing out on days or weeks of mining.
Those of us experiencing this problem, were we supplied flawed controllers from AsiaBTC?
What exactly is it you guys fix if we were to send the controller to you? Can it really not be fixed in any other way?
This is starting to become a big problem with new versions looking better. This needs to be adressed.
If you are good at soldering, you can attempt it yourself: http://forums.openpilot.org/blog/52/entry-92-unbrick-wr703n-wifi-router/Reflash your controller through the serial console to the v1 bin image, then using the web interface upload the rc10 bin image. I'm offering to repair free of charge, all you need to do is send them to me and pay the shipping. |
|
|
|
New updated firmware available (v3 d). With this update, it is possible to run some of your miners at 925MHz without hardware errors. https://www.dropbox.com/sh/6c5xbwiud9fbrz7/iWVpZNkIMm/LAG3355_12-RC10d.binChanges: - Added Auto Overclocking: automatically finds the best frequency for each individual chip, and adjust it accordingly. The number after the '@' sign indicates the chip_id
- Fixed a bug with delayed work dispatching, this should further decrease reject rate
- Disabled FIFO
As always, a cold reboot might be necessary after updating.  |
|
|
|
New updated firmware available (v3 d). With this update, it is possible to run some of your miners at 925MHz without hardware errors. https://www.dropbox.com/sh/6c5xbwiud9fbrz7/iWVpZNkIMm/LAG3355_12-RC10d.binChanges: - Added Auto Overclocking: automatically finds the best frequency for each individual chip, and adjust it accordingly. The number after the '@' sign indicates the chip_id
- Fixed a bug with delayed work dispatching, this should further decrease reject rate
- Disabled FIFO
As always, a cold reboot might be necessary after updating. |
|
|
|
good works.
hope LIGHTNINGASIC can help to improve mining investment ROI.
Jack, Is there a way to get replacement controllers? I updated to the first version of the V3 firmware and after that, it won't allow me to update the firmware again. I get "failed to unpack firmware" errors on both of my controllers. I don't want to miss out on the improvements in later versions. send back to me by post. let me upgrade it for u. Or you could mail them to me, you pay for shipping and I will repair them for free. |
|
|
|
I still don't get why you guys are running your miners on Rpi's, that shit is so unstable, mine would crash with just 10 miners connected.
For $20 shipped you could buy yourself a Tp-link 703N and install Lightningasic firmware, and run 50+ miners on it (or 100+ if you have modded the RAM to 64MB).
Where do you get lightning asic firmware? |
|
|
|
|
I still don't get why you guys are running your miners on Rpi's, that shit is so unstable, mine would crash with just 10 miners connected.
For $20 shipped you could buy yourself a Tp-link 703N and install Lightningasic firmware, and run 50+ miners on it (or 100+ if you have modded the RAM to 64MB).
|
|
|
|
|
Show Posts
