Note that for bfgminer you have to use the hex value for a given clock rate, whereas for cgminer you specify the clock rate in MHz.
A table of values to use in BFGminer is as follows:
Per discussion with luke-jr in the bfgminer thread, the leading 0 should be dropped from the hex values in that list in the first post. Sounds like the "leading zero" is your problem.
There was never any expectation/support for one.
How can I improve documentation to make that clear? |
|
|
|
Sounds like the "leading zero" is your problem.
There was never any expectation/support for one.
How can I improve documentation to make that clear? I used the list of hex codes for frequencies found in the Gekko compac support thread, so maybe that list needs to omit the leading 0. Your readme-asic does not include the leading 0, so I think the documentation is good. I forgot pgaset doesn't take a device specification like that. Really you need to identify them by number, so 0 and 1 instead of cbm0 and cbm1.
I tried replacing cbm0 and cbm1 with 0 and 1 and I get positive feedback when I input the commands, however the second stick still does not change frequency: edit below C:\bfgminer530>bfgminer-rpc "pgaset|1,clock,x0982"
Reply was 'STATUS=S,When=1445379015,Code=92,Msg=PGA 1 set OK,Description=bfgminer 5.3.0|'
[STATUS] =>
(
[STATUS] => S
[When] => 1445379015
[Code] => 92
[Msg] => PGA 1 set OK
[Description] => bfgminer 5.3.0
)
C:\bfgminer530>bfgminer-rpc "pgaset|0,clock,x0982"
Reply was 'STATUS=S,When=1445379022,Code=92,Msg=PGA 0 set OK,Description=bfgminer 5.3.0|'
[STATUS] =>
(
[STATUS] => S
[When] => 1445379022
[Code] => 92
[Msg] => PGA 0 set OK
[Description] => bfgminer 5.3.0
)  (new screen shot from just now, you can see stick 0 takes the new frequency, but stick 1 stays at stock)[/code][/code] *Edit, I turned up the voltage on 'stick 1' a tad to get rid of the HW errors, and using 0 and 1 in the pgaset command it now ups the voltage on each stick correctly, thanks for your help.  |
|
|
|
Here's the deal, I have 3 of these units running and they will roll to another comm port for no reason. I've tried different power supplies different quality USB cables and I've had units run for over a week without rolling to another port or going zombie, then I've had cases where the same setup goes zombie in less than 2 hours without even rolling from AU3 0 to AU3 1. The best luck I've had was running the units solo with the old version of CG Miner that Bitmain has for download on their site, but I have issues trying to get a second unit to run.
And that is U3 ownership in a nutshell. No rhyme, no reason, and lots of problems. I still have one, I run it from time to time, and then it makes me mad again and I remember why I turned it off the last time. |
|
|
|
Great work, Cryptoglance, thank you for your time! I knew this was something that someone who knew what they were doing could throw together, well done! As to the sticks/donation discussion, I have two sticks pointed to my "stick" worker and misc. usb hash to my donation address. I like the idea of keeping stick hash separate from other hash, but could also see how monster OC'd sticks would be fun to watch. There probably won't be too many people pushing sticks to the point of combustion, maybe if they want to show off a single stick they could do it as .<username>singlestick or something. Since the tracking is become more automated I would assume a few extra workers would not be a problem to keep track of. The share earnings from a .singlestick address would be lumped in with that users regular stick address and count toward the part A funds. |
|
|
|
Hmm, maybe try changing the single-quotes to double-quotes.
Thank you, that did the trick! C:\bfgminer530>bfgminer-rpc "pgaset|cbm0,clock,0x0a02"
Reply was 'STATUS=E,When=1445296756,Code=93,Msg=PGA 0 set failed: invalid clock: '0x0a02' data must be
prefixed with an x,Description=bfgminer 5.3.0|'
[STATUS] =>
(
[STATUS] => E
[When] => 1445296756
[Code] => 93
[Msg] => PGA 0 set failed: invalid clock: '0x0a02' data must be prefixed with an x
[Description] => bfgminer 5.3.0
)
It appears that the leading '0' needs to be dropped from the hex frequency value, however: C:\bfgminer530>bfgminer-rpc "pgaset|cbm0,clock,x0a02"
Reply was 'STATUS=S,When=1445296795,Code=92,Msg=PGA 0 set OK,Description=bfgminer 5.3.0|'
[STATUS] =>
(
[STATUS] => S
[When] => 1445296795
[Code] => 92
[Msg] => PGA 0 set OK
[Description] => bfgminer 5.3.0
)
I can successfully report an immediate increase in hash speed on the sticks once the command is issued. Thanks again, looking forward to 5.4.0.  I looks like you do not need the trailing quote mark for whatever reason, but it will error if you omit the leading one: C:\bfgminer530>bfgminer-rpc "pgaset|cbm0,clock,x0982
Reply was 'STATUS=S,When=1445297249,Code=92,Msg=PGA 0 set OK,Description=bfgminer 5.3.0|'
[STATUS] =>
(
[STATUS] => S
[When] => 1445297249
[Code] => 92
[Msg] => PGA 0 set OK
[Description] => bfgminer 5.3.0
)
Edit - for some reason the forum keeps inserting the extra /code breaks at the end. I didn't put them there, and when I edit to delete them they just show up again when I save...[/code][/code][/code] I have two gekko compacs running on this particular machine and the rpc command only appears to have increased the frequency on one stick. I replaced "cbm0" with "cbm1" to see if I could effect the other stick. The command was accepted successfully, however, the second stick did not increase in hash rate. Do I need to do something different to get the second stick to see the new frequency?  |
|
|
|
here is how to setup your R1 for bridged wired to wifi mode.. please excuse any typos.
Thank you! I only have rudimentary networking understanding, but if I understand bridging correctly this will allow you to use the R1 on an existing network with wifi to connect other devices that do not have wifi built in to said network, right? The user mods are what is going to make this little toy worth using, too bad they didn't put an S7 chip and little fan in it so we could all get 30GH/s out of it instead of 5... |
|
|
|
|
Well price is back up to $264, I think we're going to waffle around in the 260s for a bit before we move any higher. There's a lot of hardware out there waiting to come online and I think that is playing into it.
Diff this period is starting to rise as people plug in there S7s around the globe. Still not seeing that mega-jump we were all expecting, but I have to think it will come soon.
|
|
|
|
You are able to run twice as much hardware with 240 Volt verses 120 Volt.
The quantity of hardware you can run is based on the circuit's amperage, not voltage. Always double check that your circuit can supply enough amperage to support the attached devices, Watts = Amps x Volts. |
|
|
|
Any idea's on what the minimum hash rate might be in order to get a fair share of the pie and not end up in the dust bin?
I know that 1GH will only create dust. So I wonder about the guys running 10GH or less and if they're getting paid.
Also, is any plan in place to add up the dust until it's no longer dust and qualify for a payout, or should I go dust myself off?
Riding the coattails of giants
Right now (based on pool size) I think you need more than 10 or 11 GH/s to see a payout that is more than the dust threshold (10,000 satoshi). Yes, Kano has posted in this thread that at some point he will add code to sweep up the dust as part of the payout. You can look back a few pages and find the most recent response. |
|
|
|
any link to your nanofury failure (which IIRC is actually a fitfury chip, hence the "56bit max"), curious if the chip, PCB, or something else failed.
No, unfortunately. It happened before I found this forum and I dealt directly with crytorig via ebay. I threw the bad stick out, I should have saved it but it was before I knew better. Maybe someone will sacrifice an R1 in the name of science and see how long it will run oc'd until it burns out. Like 1 week at each incremental step up until the unit dies. |
|
|
|
|
+4.01% to +4.25% Mikestang
I expect we're going to see a lot of hash come online soon, but with diff over 60G now even a small percentage represents a fairly large bump in network power.
|
|
|
|
|
I burned out a nanofury usb stick by overclocking it from "50 bits" to "52 bits" (56 bits max), I would be wary of overclocking these little chips, especially since they do not have any active cooling. It would only be a matter of time (couple weeks in the case of my stick) before the mining chip burns itself out. And for a gain of ~2GH, is it really worth it?
|
|
|
|
Can you PM me all the workers? I'll whip up something for just this use
That is really cool of you, thanks! For anyone who doesn't use cryptoglance software, check it out. Shameless plug, but I've been using it for months. Great functionality and looks really sharp, plus the phone app to check in remotely is super handy. Install it and send them a donation to say thanks.  |
|
|
|
You'll need to run BFGMiner with --api-listen --api-allow W:127.0.0.1 and then you can use the bfgminer-rpc command from a prompt.
Thanks, I'll need a little hand holding to get through this. Here's what I am trying to do, on a Windows 7 machine, please let me know where I am going wrong. I added "--api-listen --api-allow W:127.0.0.1" to my batch file and the launched bfgminer. I opened a second command prompt and navigated to the bfgminer directory, then input the command as you had typed it (but changed the frequency hex) - is this correct? Probably not because I get the following: C:\bfgminer530>bfgminer-rpc 'pgaset|cbm0,clock,x1406'
'cbm0' is not recognized as an internal or external command,
operable program or batch file. I must be close, because if I just enter bfgminer-rpc at the second command prompt I get a nice print-out summary of what is going on: C:\bfgminer530>bfgminer-rpc
Reply was 'STATUS=S,When=1445036624,Code=11,Msg=Summary,Description=bfgminer 5.3.0|SUMMARY,Elapsed=678
,MHS av=27127.085,MHS 20s=28896.795,Found Blocks=0,Getworks=30,Accepted=1,Rejected=41,Hardware Errors=
7,Utility=0.088,Discarded=162,Stale=0,Get Failures=0,Local Work=8874,Remote Failures=0,Network Blocks=
1,Total MH=18403170.4900,Diff1 Work=4109,Work Utility=363.411,Difficulty Accepted=1041.99999975,Diffic
ulty Rejected=41,Difficulty Stale=0,Best Share=1259.64191468,Device Hardware%=0.1701,Device Rejected%=
0.9978,Pool Rejected%=3.7858,Pool Stale%=0.0000,Last getwork=1445036624|'
[STATUS] =>
(
[STATUS] => S
[When] => 1445036624
[Code] => 11
[Msg] => Summary
[Description] => bfgminer 5.3.0
)
[SUMMARY] =>
(
[0] => SUMMARY
[Elapsed] => 678
[MHS av] => 27127.085
[MHS 20s] => 28896.795
[Found Blocks] => 0
[Getworks] => 30
[Accepted] => 1
[Rejected] => 41
[Hardware Errors] => 7
[Utility] => 0.088
[Discarded] => 162
[Stale] => 0
[Get Failures] => 0
[Local Work] => 8874
[Remote Failures] => 0
[Network Blocks] => 1
[Total MH] => 18403170.4900
[Diff1 Work] => 4109
[Work Utility] => 363.411
[Difficulty Accepted] => 1041.99999975
[Difficulty Rejected] => 41
[Difficulty Stale] => 0
[Best Share] => 1259.64191468
[Device Hardware%] => 0.1701
[Device Rejected%] => 0.9978
[Pool Rejected%] => 3.7858
[Pool Stale%] => 0.0000
[Last getwork] => 1445036624
>
Thank you for the help.[/code] |
|
|
|
actually, seemed to be related to other parts of the frequency instruction.
8:125:0983 = ~4.5GH (8min sample)
6:125:0983 = ~6.4GH (30min sample)
Do these things have a small fan on the mining chip? I would be hesitant to turn up the clock at all. You example is a very small increase comparatively, however it represents and increase of over 40% in hashing speed and I have to think this little chip will be producing much more heat as a result. Kudos to diving in and figuring this stuff out, though. |
|
|
|
Hmm, I did test that it works on my Compac pre-prod sample before posting it here :/
Does it work any better if you use RPC's pgaset?
bfgminer-rpc 'pgaset|cbm0,clock,x0783'
It probably has to to with the changes made between pre- and post-production sticks. Is the command you suggested something I enter from the command line or batch file? I am not familiar with RPC. I'll see what I can find out about it in the mean time and try that way, if I can figure it out. |
|
|
|
 The image is even green for gekko science, haha.  |
|
|
|
|
The problem isn't guns, the problem is people. Joe Rogan likes to point out that the US has a mental health problem disguised as a gun problem. Most of my friend's and I are gun owners. We hunt or target shoot or, in my case, carry for protection when I'm out in the middle of the Mojave desert (never know what or who you'll run into in the wild, wild west). Normal, well balanced, educated gun owners are an asset to civilized society. Crazy people, especially crazy people with guns, is a problem.
But several of the recent shooting could have been, maybe not prevented, but the casualties greatly reduced had there been a properly trained and armed gun owner present. In one situation at a school there were several off-duty police officers who were forced to leave their guns in their vehicles because the school is a "no gun zone". Well obviously no one pointed out that sign to the crazy guy with a gun who shot a bunch of people. Had the off-duty law enforcement been properly armed they could have subdued the situation immediately.
I am often dumbstruck by the fact that the majority of people calling for "gun control" do not own and have never owned firearms themselves.
|
|
|
|
Btw can i use others campaign avatar service?
- No avatars that have anything to do with gambling.
It seems the answer is yes, as long as they are not a gambling related venture. |
|
|
|
|
Show Posts
