PlanetCrypto
|
|
August 16, 2014, 03:23:39 AM |
|
The point is, the "pool" is paying out more than it can ever take in on a PPS model so somethings up somewhere.
Trying to build a bitcoin affiliate network is what they are saying, also they claim the payout of bonus may last up until 5TH. This suggests they could end it sooner if they reach the goals for the pool. If something is to good to be true it usually is. But on the other hand, if I had the resources, and could afford it, I would do the exact same thing to promote my own business, though perhaps not as aggresive as 12.5% *Edit I am on the NY server, I only had a few minor disconnects, which may have to do with the fact the pool / company is in process of being built.stratum+tcp://east2.bitcoindigger.com:3333 STILL dead ! I'll let test miner run for 10 minutes to see if it corrects but I doubt it. Edit: Seems it was a worker issues _ instead of . I am running 1 s-3 on it seems okay. I did the VA server as I may be closer to it then the NY one. I am in the Midwest and run all 12 miners (9-S1's and 3-S3's) on the VA server. My 2 S1's are on the VA server. Did a ping to all of them and east1 (VA) had the lowest times (~80ms). I'm in Minnesota. Didn't read the previous post about not posting about pools in this thread. Won't happen again. Sorry.
|
|
|
|
|
|
|
"This isn't the kind of software where we can leave so many unresolved bugs that we need a tracker for them." -- Satoshi
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
Askit2
|
|
August 16, 2014, 03:37:28 AM |
|
I believe the setting is quite pool specific. I used to use --queue 1 but found I got a lower DOA rate & slightly better performance using --queue 0 with the cpu at ~80% - but I'm pointing mine at p2pool so maybe that's why? Load is currently: 1.58 1.62 1.40 @ 237.5
Thanks for the feedback. I'm pointing them at Slush, with Bitminter as a backup (failover). Don't see how the CPU% is dependent on the OC, but I ran tests on 3 different clocks, with 3 different queue settings. The load was pretty high on all of them. Everytime there is a new block the cpu has to make 4097, 129, 3, 2, or 1 work unit to send out immediately. There is always 1 with a queue of 0 you have 1 work unit prepped to send to the next chip needing work. with 4096 you have 4097 work units ready to go out. At the end of a block you still have 1 to 4097 work units ready to go. The cpu will have far less load spikes on a lower number. I started with 2 (three prepped in total) but noticed 1 (2 ready at all times) used a bit less cpu. I then moved to 1 and got just under 2 UNLESS I go to the Realtime Graphs tab. The big advantage to something slightly above 0 but less then maybe 16 is that if most of your hashing chips suddenly ran out of work there is enough work for half of them queued up. At least for one work unit each. I really did prefer 2 ish but 0 seems to be less loaded and pool results aren't significantly different for me.
|
|
|
|
visdude
Legendary
Offline
Activity: 1081
Merit: 1001
|
|
August 16, 2014, 03:50:16 AM Last edit: August 21, 2014, 03:04:53 AM by visdude |
|
Update....the latest firmware is a disaster on my miners...I don't like how the asic frequencies are only read from the rom (read only) for starters...the clock selections defaulting to 237.5 was the first sign, along with the other details I mentioned in the first post I made regarding this new firmware..back to 0721 for me and I don't get x's on stock like I do with the new firmware...all in all I think its a piece of junk and should be pulled from bitmain site...and what is the deal with the july 28 firmware...I had it on a few of my ants and now its gone due to the flash "upgrade" downgrade...I cant honestly see any benefit from having the latest August firmware...and for those who will say it helps with overclocking...if that is the help you need to overclock, please quit while you are ahead interesting observations and thanks for sharing. I just saw the firmware update on the site and downloaded but now hesitant to update. Anyone out there that updated and had no issues? As the saying goes, "don't fix it if it ain't broke".
|
|
|
|
crazyates
Legendary
Offline
Activity: 952
Merit: 1000
|
|
August 16, 2014, 03:53:52 AM |
|
I believe the setting is quite pool specific. I used to use --queue 1 but found I got a lower DOA rate & slightly better performance using --queue 0 with the cpu at ~80% - but I'm pointing mine at p2pool so maybe that's why? Load is currently: 1.58 1.62 1.40 @ 237.5
Thanks for the feedback. I'm pointing them at Slush, with Bitminter as a backup (failover). Don't see how the CPU% is dependent on the OC, but I ran tests on 3 different clocks, with 3 different queue settings. The load was pretty high on all of them. Everytime there is a new block the cpu has to make 4097, 129, 3, 2, or 1 work unit to send out immediately. There is always 1 with a queue of 0 you have 1 work unit prepped to send to the next chip needing work. with 4096 you have 4097 work units ready to go out. At the end of a block you still have 1 to 4097 work units ready to go. The cpu will have far less load spikes on a lower number. I started with 2 (three prepped in total) but noticed 1 (2 ready at all times) used a bit less cpu. I then moved to 1 and got just under 2 UNLESS I go to the Realtime Graphs tab. The big advantage to something slightly above 0 but less then maybe 16 is that if most of your hashing chips suddenly ran out of work there is enough work for half of them queued up. At least for one work unit each. I really did prefer 2 ish but 0 seems to be less loaded and pool results aren't significantly different for me. I understand how the queue works; I've been using cgminer since v 1.4 or something silly like that. When I dropped down to queue=1, my hashrate dropped from ~480 to ~460. I'm running it with a queue of 16 for now, but my load is still 2+. But to answer my original question: this sounds like something that other people are living with, and is normal?
|
|
|
|
visdude
Legendary
Offline
Activity: 1081
Merit: 1001
|
|
August 16, 2014, 03:56:08 AM |
|
Please keep your "pool" spam off the Bitmain thread - I & others don't want to scroll past quote upon quote about how good/shit it is while trying to find info about Bitmain products.
Thanks.
No, thank you! You beat me to it.
|
|
|
|
contactlight
|
|
August 16, 2014, 03:57:25 AM |
|
I just applied the firmware update on one of my miners and after the reboot something was wrong. It wouldn't start mining and the CPU load would be very high. I went ahead to reset the settings and rebooted. Now I can't access the device at all.
How is the physical hard reset done again?
|
|
|
|
yslyung
Legendary
Offline
Activity: 1500
Merit: 1002
Mine Mine Mine
|
|
August 16, 2014, 03:59:06 AM |
|
I just applied the firmware update on one of my miners and after the reboot something was wrong. It wouldn't start mining and the CPU load would be very high. I went ahead to reset the settings and rebooted. Now I can't access the device at all.
How is the physical hard reset done again?
pin hole next to lan port /led
|
|
|
|
jimmyoh
Newbie
Offline
Activity: 49
Merit: 0
|
|
August 16, 2014, 04:17:21 AM |
|
I just applied the firmware update on one of my miners and after the reboot something was wrong. It wouldn't start mining and the CPU load would be very high. I went ahead to reset the settings and rebooted. Now I can't access the device at all.
How is the physical hard reset done again?
pin hole next to lan port /led Also, if you haven't done so already, make sure to uncheck the "save settings" on the firmware update page. If don't your Miner Status page while remain blank. That last FW update caused more problems than it fixed so went back to the older one.
|
|
|
|
visdude
Legendary
Offline
Activity: 1081
Merit: 1001
|
|
August 16, 2014, 04:29:30 AM Last edit: August 16, 2014, 04:46:18 AM by visdude |
|
Wow! It's even hotter today for my S3s than yesterday. Ambient room temperature peaked at 37.3C (99.2F). They have been clocked higher at 237.5M this time around and drawing 408W at the wall but didn't seem to skip a beat at all. These were the stats during that particular period:
|
|
|
|
dankefoss
Newbie
Offline
Activity: 22
Merit: 0
|
|
August 16, 2014, 04:35:43 AM |
|
Why does 250M make my miner go slower with an x in the asic status...
Same with me. I had the most stable of miners and now with the update from yesterday, I am losing a chip (x). Same frequency, nothing else changed. My other miner seems to be performing the same or a little better.
|
|
|
|
crazyates
Legendary
Offline
Activity: 952
Merit: 1000
|
|
August 16, 2014, 05:09:00 AM |
|
Wow! It's even hotter today for my S3s than yesterday. Ambient room temperature peaked at 37.3C (99.2F). They have been clocked higher at 237.5M this time around and drawing 408W at the wall but didn't seem to skip a beat at all. These were the stats during that particular period: Your fans aren't really running at 15k RPM, are they?
|
|
|
|
visdude
Legendary
Offline
Activity: 1081
Merit: 1001
|
|
August 16, 2014, 05:21:38 AM |
|
Wow! It's even hotter today for my S3s than yesterday. Ambient room temperature peaked at 37.3C (99.2F). They have been clocked higher at 237.5M this time around and drawing 408W at the wall but didn't seem to skip a beat at all. These were the stats during that particular period: Your fans aren't really running at 15k RPM, are they? I don't think so. I'm sure I'd notice if it's spinning at 15K. It's been like that since day 1, hot or cold . If Bitmain doesn't care about fixing it, then I don't care as long as I know they are spinning and pushing/pulling air.
|
|
|
|
Atomar
|
|
August 16, 2014, 05:23:37 AM |
|
Wow! It's even hotter today for my S3s than yesterday. Ambient room temperature peaked at 37.3C (99.2F). They have been clocked higher at 237.5M this time around and drawing 408W at the wall but didn't seem to skip a beat at all. These were the stats during that particular period: Your fans aren't really running at 15k RPM, are they? My fans showing both 15300! Allways. And they run for sure NOZ that fast. Wired Thing. Even with the new firmware. Does anybudy know how to fix that ?
|
|
|
|
Fahlcor
|
|
August 16, 2014, 05:58:05 AM |
|
Not an endorsement at all but the S3 Ants work perfect on Nicehash. Best return I have got from any pool and beating Coinwarz calc/thash.
Thanks for making nice product Bitmain. My miners are running stock B5 firmware and all 12 are running like champs. Not touching any new firmware with a 10 foot pole.
And the ants obviously like 40 C as the fans seem to spin down to keep them there.
S1:210 0d 9h 15m 2s 449.24 453.37 0 0.0021% 402,628 2,048 UUU 0.2073 0 2520 2520 1440 40 39 40 S1:211 0d 8h 26m 58s 463.29 475.92 0 0.0138% 3,152,112 2,048 UUU 0.13 0 4020 4020 1680 40 40 40 S1:212 0d 9h 11m 24s 462.17 451.12 0 0.0128% 453,492 2,048 UUU 0.3807 0 3420 3240 3420 39 39 39 S1:213 0d 9h 10m 42s 478.88 453.08 0 0.0174% 13,183,229 1,000 UUU 0.2416 0 1620 1620 1560 40 38 40 S1:214 0d 9h 10m 31s 482.52 479.14 0 0.0012% 7,223,355 2,048 UUU 0.0827 0 1920 1920 1560 40 40 38 S1:215 0d 9h 10m 3s 467.46 441.25 0 0.0054% 6,928 2,048 UUU 0.2207 0 3600 3600 1620 41 39 41 S1:216 0d 9h 0m 48s 458.94 476.88 0 0.0018% 3,790,128 2,048 UUU 0.2666 0 1860 1860 1620 40 40 40 S1:217 0d 9h 4m 23s 438.85 445.99 0 0.008% 166,728 1,000 UUU 0.3658 0 2520 2520 1680 39 39 38 S1:218 0d 9h 3m 41s 470.49 463.01 0 0.0053% 7,342 2,048 UUU 0.1764 0 2940 2940 2040 40 37 40 S1:219 0d 9h 2m 53s 469.22 453.46 0 0.0048% 4,203,450 2,048 UUU 0.4787 0 1860 1860 1620 39 38 39 S1:220 0d 9h 1m 26s 469.62 475.45 0 0.0116% 765,930 2,048 UUU 0.3104 0 3840 3840 1380 40 40 40 S1:221 0d 9h 1m 23s 441.22 440.07 0 0.0023% 248,037 2,048 UUU 0.3358 0 3180 3180 1560 39 39 39
oh and Ant monitor rocks for easy watching them all. Bitmain should buy and include this software.
Fahlcor
|
|
|
|
visdude
Legendary
Offline
Activity: 1081
Merit: 1001
|
|
August 16, 2014, 06:10:44 AM |
|
Wow! It's even hotter today for my S3s than yesterday. Ambient room temperature peaked at 37.3C (99.2F). They have been clocked higher at 237.5M this time around and drawing 408W at the wall but didn't seem to skip a beat at all. These were the stats during that particular period: Your fans aren't really running at 15k RPM, are they? My fans showing both 15300! Allways. And they run for sure NOZ that fast. Wired Thing. Even with the new firmware. Does anybudy know how to fix that ? Well, if it's not a firmware issue, then perhaps it's hardware-related. I don't know the quality of sensors Bitmain has been using in their devices but I kinda lost faith in them. It's already obvious that these fan speeds are not realistic. Like I said, as long as the fans themselves are spinning (and seem to audibly change RPM every now and then), I don't care about the reported numbers anymore. But that's just me. One of my S1s used to turn all "x" on me yet hash rates on both sides were never actually affected. I just hope that the temperature sensors in these units are up to par because they are more crucial than anything else but considering the significant differences/variations in S3 temperature readings posted by members in here, I doubt it. So, in a way, we're flying blind here. We're really not sure what we're getting. I think physically monitoring our units is the best way to stay on top of it since we cannot really rely on these numbers. A little food for thought: How did we manage to successfully run mining farms using USB miners that were not equipped with temperature sensors?
|
|
|
|
visdude
Legendary
Offline
Activity: 1081
Merit: 1001
|
|
August 16, 2014, 06:15:22 AM |
|
Not an endorsement at all but the S3 Ants work perfect on Nicehash. Best return I have got from any pool and beating Coinwarz calc/thash.
Thanks for making nice product Bitmain. My miners are running stock B5 firmware and all 12 are running like champs. Not touching any new firmware with a 10 foot pole.
And the ants obviously like 40 C as the fans seem to spin down to keep them there.
S1:210 0d 9h 15m 2s 449.24 453.37 0 0.0021% 402,628 2,048 UUU 0.2073 0 2520 2520 1440 40 39 40 S1:211 0d 8h 26m 58s 463.29 475.92 0 0.0138% 3,152,112 2,048 UUU 0.13 0 4020 4020 1680 40 40 40 S1:212 0d 9h 11m 24s 462.17 451.12 0 0.0128% 453,492 2,048 UUU 0.3807 0 3420 3240 3420 39 39 39 S1:213 0d 9h 10m 42s 478.88 453.08 0 0.0174% 13,183,229 1,000 UUU 0.2416 0 1620 1620 1560 40 38 40 S1:214 0d 9h 10m 31s 482.52 479.14 0 0.0012% 7,223,355 2,048 UUU 0.0827 0 1920 1920 1560 40 40 38 S1:215 0d 9h 10m 3s 467.46 441.25 0 0.0054% 6,928 2,048 UUU 0.2207 0 3600 3600 1620 41 39 41 S1:216 0d 9h 0m 48s 458.94 476.88 0 0.0018% 3,790,128 2,048 UUU 0.2666 0 1860 1860 1620 40 40 40 S1:217 0d 9h 4m 23s 438.85 445.99 0 0.008% 166,728 1,000 UUU 0.3658 0 2520 2520 1680 39 39 38 S1:218 0d 9h 3m 41s 470.49 463.01 0 0.0053% 7,342 2,048 UUU 0.1764 0 2940 2940 2040 40 37 40 S1:219 0d 9h 2m 53s 469.22 453.46 0 0.0048% 4,203,450 2,048 UUU 0.4787 0 1860 1860 1620 39 38 39 S1:220 0d 9h 1m 26s 469.62 475.45 0 0.0116% 765,930 2,048 UUU 0.3104 0 3840 3840 1380 40 40 40 S1:221 0d 9h 1m 23s 441.22 440.07 0 0.0023% 248,037 2,048 UUU 0.3358 0 3180 3180 1560 39 39 39
oh and Ant monitor rocks for easy watching them all. Bitmain should buy and include this software.
Fahlcor
I take it that you didn't read the last couple of pages that contain references on "pool" spamming.
|
|
|
|
Askit2
|
|
August 16, 2014, 08:12:33 AM |
|
I believe the setting is quite pool specific. I used to use --queue 1 but found I got a lower DOA rate & slightly better performance using --queue 0 with the cpu at ~80% - but I'm pointing mine at p2pool so maybe that's why? Load is currently: 1.58 1.62 1.40 @ 237.5
Thanks for the feedback. I'm pointing them at Slush, with Bitminter as a backup (failover). Don't see how the CPU% is dependent on the OC, but I ran tests on 3 different clocks, with 3 different queue settings. The load was pretty high on all of them. Everytime there is a new block the cpu has to make 4097, 129, 3, 2, or 1 work unit to send out immediately. There is always 1 with a queue of 0 you have 1 work unit prepped to send to the next chip needing work. with 4096 you have 4097 work units ready to go out. At the end of a block you still have 1 to 4097 work units ready to go. The cpu will have far less load spikes on a lower number. I started with 2 (three prepped in total) but noticed 1 (2 ready at all times) used a bit less cpu. I then moved to 1 and got just under 2 UNLESS I go to the Realtime Graphs tab. The big advantage to something slightly above 0 but less then maybe 16 is that if most of your hashing chips suddenly ran out of work there is enough work for half of them queued up. At least for one work unit each. I really did prefer 2 ish but 0 seems to be less loaded and pool results aren't significantly different for me. I understand how the queue works; I've been using cgminer since v 1.4 or something silly like that. When I dropped down to queue=1, my hashrate dropped from ~480 to ~460. I'm running it with a queue of 16 for now, but my load is still 2+. But to answer my original question: this sounds like something that other people are living with, and is normal? I didn't intend to imply you hadn't been using cgminer or that you didn't know how the queue worked. I only wanted to point out that I find it less likely that running even more processor cycles initially to get to a certain level of queued work would be somewhat less likely to help improve speed. I do see how an increase from 440 to 480 would represent a 8.333333% increase in speed. Likely the processor requirements to keep up with said improvement in hashing speed are fairly linear. If you are running 90% at 440 I would expect nearly 99% at 480. That having been said I also would wonder how bogging the cpu down for longer initially and maintaining a higher average load would improve hashing speed. I suppose since the new work can be queued up farther down the line and cgminer wouldn't run out of work maybe it makes sense. I do see that you tested it and I don't want to infer you have made a mistake. I don't think you have. I just find it very curious. I do wish the BITMAIN would publish the device driver details so that a current version of cgminer could be attained. I know at least 2 releases in 4 had notes about queue improvements and one at least specifically stated it generated work much faster. Also one of the last 3's had an improvement about how work was loaded into devices. I know for sure 3.12 is very old and I am positive that many work generation improvements have been added since then. This analysis also ignores the serial load as that is separate unless BITMAIN actually has them running direct USB. Meaning the load will be actually higher for cgminer then it appears on top or the process tree.
|
|
|
|
bluecityste
Newbie
Offline
Activity: 47
Merit: 0
|
|
August 16, 2014, 08:37:33 AM |
|
Hi, just set up my new s3 this morning.
It's working at bitminter (verified hashing on there pool) but it won't let me get passed the login page on the miner user interface, I.e. I get to log on, enter root root as per normal and then the following appears:
/usr/lib/lua/luci/dispatcher.lua:448: Failed to execute function dispatcher target for entry '/'. The called action terminated with an exception: /usr/lib/lua/luci/sauth.lua:87: Session data invalid! stack traceback: [C]: in function 'assert' /usr/lib/lua/luci/dispatcher.lua:448: in function 'dispatch' /usr/lib/lua/luci/dispatcher.lua:195: in function </usr/lib/lua/luci/dispatcher.lua:194>
Anyone have any ideas? Do I need to reset and start again? Thanks
|
|
|
|
bluecityste
Newbie
Offline
Activity: 47
Merit: 0
|
|
August 16, 2014, 09:20:55 AM |
|
Powered off 5 times, then on the 6th it let me back in....panic over
|
|
|
|
Ilan1
|
|
August 16, 2014, 10:16:48 AM |
|
I read somewhere that the new firmware update shows a new Freq tab or something, I have just uploaded it but don't see any changes?
|
|
|
|
|