Would anyone be terribly upset if I did not build a stickminer around this chip? Interfacing to the ASIC directly kinda sucks, and the minimum buck voltage is at the top end of what's likely the practical range for the chip.
It'd be better to use a proper interface chip, but that's kinda wasteful without multiple ASICs. Of course, multiple ASICs also adds to the cost. Doesn't double the cost of course. I don't know how much it'd add.
So, what's a general consensus - a two- or three-chip stickminer (for, say, nominally $35 or $40 versus the original Compac's $25) or no stickminer at all?
sounds like a great idea. I'm definitely interested. the compac I have is still hashing away mining dust, but contributing none the less. - zed |
|
|
|
But if you sell the hub and PSU, what are you gonna do when a newer better stick comes out?
You have another miner project going? Inquiring miners want to know.  I'll probably add an eighth port that's power only, for charging or fans or whatever. Looking at the same 7-port controller used in the 49-port Eyeboot hub (and a couple others I have) since I know it's decent.
I like the idea of the wide input voltage range. I'll have both a barrel jack and 6-pin for input, and the barrel jack means you could use something like a 20V laptop brick if you wanted. Course if you wanted to pull 3A per port and used a 12V brick you'd end up melting the jack like an idiot, so that's one point of concern. But idiots are gonna find a way to mess things up anyway.
I'd definitely be interested in an 8-port hub. If there is a new GekkoScience Compac USB miner with a newer hashing chip in the works, I'd be interested in that, too. My current Compac is pretty near bulletproof hashing away at 325 MHz as a lottery miner. Cheers, - zed |
|
|
|
I have a sidehack modded S7-LN (2TH @ ~450 watts) that is powered off and gathering dust now. I was never able to get it to reliably connect to any pool, and I couldn't figure out why it was so. I upgraded my network connection to a higher speed and still no joy. If you are at all interested in the details you can read about it here: https://bitcointalk.org/index.php?topic=1562227.0Cheers, - zed I have a 2Mbs connection (256KB/s) , so pretty slow. I've ran up to: - 1 S7 - 4 S5 - 4 S3+ - 6 compac - 6 U3 Without any issue. And that's on top of 13 computers and 2 cellphone on wifi. So my guess is that it is not a speed issue, but a firewall/proxy filtering your bitcoin packets.... I was thinking the same thing, but it seems that the only packets/messages getting filtered are the ones where the miner is sending a result to the pool. And as soon as the miner sends a TCP RST to the pool, everything works again, until the result is sent. Occasionally the miner is able to submit shares, but then fails over to a backup pool...  I've given up on the S7-LN and I'm only running the single Compac and my ethereum GPU rig, which is rock solid, if not a hashing monster. I'll probably try to sell the S7-LN before too long, and use the money to add a GPU to the ethereum rig. Cheers, - zed |
|
|
|
Alright, thank you Kano, then I'll wait If you are connected properly -- you should start finding shares within seconds. Don't wait. Check your settings. Not necessarily. I have pointed my GekkoScience Compac stick miner at a number of different pools, kano.is included, and it can take variable amounts of time, from 10 minutes to multiple hours, before it starts having shares accepted. Once shares are being accepted it seems to stay that way until something causes the miner code (cgminer 4.9.2 w/ GekkoScience Compac support) to be redirected. The GekkoScience Compac stick is lottery mining on solo.ckpook.org now. I have a sidehack modded S7-LN (2TH @ ~450 watts) that is powered off and gathering dust now. I was never able to get it to reliably connect to any pool, and I couldn't figure out why it was so. I upgraded my network connection to a higher speed and still no joy. If you are at all interested in the details you can read about it here: https://bitcointalk.org/index.php?topic=1562227.0Cheers, - zed |
|
|
|
To start, I've seen the older post that lists all possible hubs but most of those are either no longer sold or insanely hard to come by and overpriced.
I'm running 4 GekkoScience compacs and a fan on a Rosewill RHB-500 controlled by a RPI-3 - no issues there, problem starts when I try adding the rest of my sticks that are not in use (I have 3 more) the hub just loses power and resets...
I tried running one extra stick from the RPI itself, but it either caused the miner to crash or say my other 4 sticks are dead.
Before jumping 3 steps ahead and buying something like the AsicMiner 49 Port BlockErupter board is there any cheaper solution?
try this one https://www.amazon.com/Superbpag-Portable-Charger-Transfer-Samsung/dp/B013OK10YM/ref=sr_1_1?ie=UTF8&qid=1470365385&sr=8-1&keywords=superbpag+usb+hubthere has been some positive feedback in the gekkoscience thread, just make sure that you plug the hub into a USB2.0 port. Cheers, - zed |
|
|
|
In your command line or batch file that you use to launch cgminer you need to put your own btc address (or user name) in for the user, and your password if the pool requires one. If you post up your batch file we can show you exactly what needs to change.
Thank u Mr.Mikestang and this is my run file cgminer_run in notepad that write.. cgminer.exe -o stratum+tcp://stratum.mining.eligius.st:3334 -u 1BURGERAXHH6Yi6LRybRJK7ybEm5m5HwTr --compac-freq 150 ===== sorry i new and i read #1 post but i dont understand Change what is in bold to your bitcoin address or username depending on what the pool you are using requires. Cheers, - zed |
|
|
|
Helo Everyone , I am new Can I ask something , i have GekkoScience Compac BM1384 and How i use this with Window 7 64 Bit and How can i run it ? Thank u   1. Read the first post of this thread. 2. keep reading following posts that answer questions 3. try what is suggested 4. If that still hasn't worked, keep reading more of the thread posts 5. After reading first few pages of posts in this thread Go back to #1 Pretty much everything you need to know is covered in the first few pages of this thread. Cheers, - zed |
|
|
|
|
Mr. Phil,
ZedZedNova = -9.9
Thank you sir.
Cheers,
- zed
|
|
|
|
The Compac stick communicates fine. I point my Compac at solo.ckpool.org (actually stratum.ckpool.org which is where it eventually winds up if I start at solo.ckpool.org) and specify --suggest-diff 17, which is where it is now after bouncing back and forth between 1000 and 17, and it still takes a seemingly random amount time before the pool begins accepting shares. ./cgminer -o stratum+tcp://stratum.ckpool.org:3333 -u <my btc address>.Compac1 -p x --compac-freq 325 --suggest-diff 17
Well that didn't work... I let the Compac run while I got some sleep, and 10 hours after starting the miner, still no joy using the above command.  I restarted the Compac a few minutes ago using this command: ./cgminer -o stratum+tcp://stratum.ckpool.org:3333 -u <my btc address>.Compac1 -p x --compac-freq 325
To see how long it runs before the submitted shares are accepted. Edit: Below this is new (~11.5 hours after original post)Gave up waiting after 90 minutes and switched over to this command: ./cgminer -o stratum+tcp://solo.ckpool.org:3333 -u <my btc address>.Compac1 -p x --compac-freq 325
That command took over two hours before a share was submitted that didn't have any retransmits. The response that came back was a reconnect: {"id":null,"method":"client.reconnect","params":["stratum.ckpool.org","443",0]}That resulted in another 40 or so minutes of attempting to submit shares before one was accepted with a 1000 Diff. Five minutes later another submitted share: {"params": ["<my btc address>.Compac1", "5786cf6b000071a3", "9625000000000000", "5793d7c4", "5c73552b"], "id": 128, "method": "mining.submit"}
and the pool responds with: {"params":[24],"id":null,"method":"mining.set_difficulty"}immediately followed by: {"error":null,"result":true,"id":128}Hooray! Another accepted share. From that point on the Compac has been doing fine.  Cheers, - zed |
|
|
|
I glossed over your complete data set, but you're probably communicating fine, it's just that finding 1k diff shares is a rare event on a compaq stick which is why you see the S7 communicating fine which makes 1k shares far more frequently. There's nothing to fix there, unless you want the feedback faster, in which case mine on a pool that supports the stratum specification command --suggest-diff (like kano.is or solo.ckpool.org) and use cgminer which supports the command and choose your starting diff.
@-ck, Thanks. Those are actually the two pools I used. In fact the images are from when I had the S7-LN pointed at solo.ckpool.org, but the results on kano.is are essentially the same and is where I have the S7-LN pointed now. The Compac stick communicates fine. I point my Compac at solo.ckpool.org (actually stratum.ckpool.org which is where it eventually winds up if I start at solo.ckpool.org) and specify --suggest-diff 17, which is where it is now after bouncing back and forth between 1000 and 17, and it still takes a seemingly random amount time before the pool begins accepting shares. ./cgminer -o stratum+tcp://stratum.ckpool.org:3333 -u <my btc address>.Compac1 -p x --compac-freq 325 --suggest-diff 17
I restarted the Compac over an hour ago with the above command and it has yet to receive an "Accepted" share message. I've got wireshark running capturing the packets. I'll edit this message later today (eastern US timezone) with the time it took to get the first accepted share. Meanwhile, here is what I see a lot of in the terminal window: [2016-07-23 02:48:15.875] Stratum connection to pool 0 interrupted
[2016-07-23 02:48:16.518] Pool 0 difficulty changed to 1000
[2016-07-23 02:48:16.579] Pool 0 message: Authorised, welcome to solo.ckpool.org <my btc address>!
[2016-07-23 02:48:16.895] Pool 0 difficulty changed to 17
[2016-07-23 02:48:16.895] Stratum from pool 0 requested work restart
[2016-07-23 02:48:35.015] Lost 7 shares due to no stratum share response from pool 0
On the S7-LN I have not been able to figure out how to specify --suggest-diff. Bitmain doesn't make it easy to adjust their miners, especially across a reboot/power cycle. On kano.is I use the worker management page to specify a diff of 1072 which is what the pool commands when the miner is finally able to get a few accepted shares. However, even doing that it doesn't seem to make a difference. I guess the thing that I find most odd is that the pool servers always seem to go "deaf" when the miner sends the packet that contains the mining.submit: {"params": ["<my btc address>.Compac1", "5786cf6b00006ab9", "0e01000000000000", "57930c36", "69c70e16"], "id": 336, "method": "mining.submit"}
By deaf I mean that there is no TCP message coming back from the pool at all. The non-response triggers a bunch of retransmits from the miner, and when those fail, the connection times out and the miner sends a TCP RST, which "wakes up" the pool and the cycle starts all over again. If the pool doesn't like the submitted share, for any reason, I would expect the pool to send stratum message indicating the share was rejected with a "result": false and optionally some error code. Eventually the pool accepts the submitted share and responds appropriately. On the Compac that means it happily mines away until cgminer is stopped for one reason or another. On the S7-LN it's as if only the secondary pool gets accepted shares, and it only lasts for a little while (couple of minutes or so). Inevitably the miner fails back to the primary pool address and goes back to the "deafness" issue. Cheers, - zed |
|
|
|
Hello pool software/stratum protocol/miner software experts, I've got several miners that seem to take random amounts of time to establish communications to a pool such that shares are accepted. My GekkoScience Compac miner can take anywhere from just a few minutes to multiple hours before I start seeing messages like: [2016-07-22 19:36:16.626] Accepted 2bbe2621 Diff 1.5K/17 COMPAC In the case of some pools it seems that the Compaq never does establish communications with the pool such that shares are accepted. Clearly you want to point to a pool that is relatively close by so that there isn't a lot of lag in communications. By close by I mean round trip ping times are low and do not fluctuate too much. In addition to the Compac I have an Antminer S7-LN that I can not get to mine successfully on any pool I have pointed it at. What I see on the Miner Stats page looks like this:  As you can see, this miner has been working for over an hour, but has not had the DiffA# or DiffR# shares counters pegged. That means the pool is not happy with what it is receiving, or more specifically should be receiving, but probably is not. When miner and pool are communicating well (my Compac with cgminer running on my Mac Mini), it looks like this: Mac-mini:~ boris$ netstat -alnt | awk 'NR == 2 || /a.b.c.d/'
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 192.168.1.101.51812 a.b.c.d.3333 ESTABLISHED
Mac-mini:~ boris$ netstat -alnt | awk 'NR == 2 || /a.b.c.d/'
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 192.168.1.101.51812 a.b.c.d.3333 ESTABLISHED
Mac-mini:~ boris$
And when the miner and pool are not communicating well (my S7-LN) it looks like this: root@antMiner:~# netstat -alnt | awk 'NR == 2 || /a.b.c.d/'
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 5217 192.168.1.196:53729 a.b.c.d:3333 FIN_WAIT1
tcp 0 815 192.168.1.196:53730 a.b.c.d:3333 ESTABLISHED
netstat: /proc/net/tcp6: No such file or directory
root@antMiner:~# netstat -alnt | awk 'NR == 2 || /a.b.c.d/'
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 5217 192.168.1.196:53729 a.b.c.d:3333 FIN_WAIT1
tcp 0 2934 192.168.1.196:53730 a.b.c.d:3333 ESTABLISHED
netstat: /proc/net/tcp6: No such file or directory
root@antMiner:~# netstat -alnt | awk 'NR == 2 || /a.b.c.d/'
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 5217 192.168.1.196:53729 a.b.c.d:3333 FIN_WAIT1
tcp 0 3097 192.168.1.196:53730 a.b.c.d:3333 ESTABLISHED
netstat: /proc/net/tcp6: No such file or directory
root@antMiner:~# netstat -alnt | awk 'NR == 2 || /a.b.c.d/'
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 3097 192.168.1.196:53730 a.b.c.d:3333 ESTABLISHED
netstat: /proc/net/tcp6: No such file or directory
root@antMiner:~#
For those reading this thread who are unfamiliar with TCP/IP communications, the state FIN_WAIT1 means that the local side (miner in this case) has told the remote side to close the connection. In this case the reason the miner is in the FIN_WAIT1 state on this particular connection is because it has exhausted all of the TCP retransmissions for the most recent message, and the connection has timed out. If you look at the output from netstat there is a column called Send-Q. When things are working normally (see the netstat output from my Mac Mini) the value in that column is zero. That means that there is no data in the output queue waiting to be sent to the remote side of the connection. When things are not working normally (see the netstat output from the Antminer) there is a number greater than zero in that column. I put a wireshark packet sniffer onto the network and I can "see" that the miner is communicating with the pool and the "conversation" seems to be going OK right up until the miner sends a stratum mining.submit message. The mining.submit message is never ACKnowledged by the pool. Eventually that causes the miner to retransmit the message. The miner will continue to retransmit (waiting an exponentially longer time before sending the message again) until it has reached the TCP/IP time-out limit which is 30 seconds. Can any of the pool software/stratum protocol/miner software experts help me figure out what is happening here Initially I thought it was network bandwidth issues, but I have increased my bandwidth and I'm still seeing the same behavior. I know that the Compac miner eventually "sync's" with the mining pool, and the S7-LN has occasional "moments" when it is submitting DiffA# or DiffR# accepted shares, but seemingly only when I have a second pool destination URL specified, and only intermittently. Edit: Added the below info... Here is the image of the miner configured with two pool addresses. The addresses are the same, with the miner somehow successful in submitting shares to the "backup" pool, but not to the "primary" address.  The netstat from the miner looks like: root@antMiner:~# netstat -alnt | awk 'NR == 2 || /a.b.c.d/'
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 7173 192.168.1.196:58286 a.b.c.d:3333 FIN_WAIT1
tcp 0 3423 192.168.1.196:58295 a.b.c.d:3333 ESTABLISHED
tcp 0 0 192.168.1.196:58247 a.b.c.d:3333 ESTABLISHED
netstat: /proc/net/tcp6: No such file or directory
root@antMiner:~# netstat -alnt | awk 'NR == 2 || /a.b.c.d/'
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 3586 192.168.1.196:58295 a.b.c.d:3333 ESTABLISHED
tcp 0 0 192.168.1.196:58247 a.b.c.d:3333 ESTABLISHED
netstat: /proc/net/tcp6: No such file or directory
root@antMiner:~# netstat -alnt | awk 'NR == 2 || /a.b.c.d/'
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 1630 192.168.1.196:58298 a.b.c.d:3333 ESTABLISHED
tcp 0 7336 192.168.1.196:58296 a.b.c.d:3333 FIN_WAIT1
tcp 0 0 192.168.1.196:58247 a.b.c.d:3333 ESTABLISHED
netstat: /proc/net/tcp6: No such file or directory
root@antMiner:~#
And of course when the miner "fails" back to the primary it isn't able to submit shares. Thanks, - zed |
|
|
|
I just lol'ed when looking at bitmain website, no S9 listing at all, they're trying to create a scarcity when there's none exists, they have thousands of S9's loaded up and ready to ship. Let's see if they actually RAISE the price for the next batch. They're so sketchy, it's not even funny. You know they don't have to play this stupid game, trying to fool people into thinking their S9 miners are so scarce. Epic failure on bitmain. They're turning into a scammy company. Shame on bitcointalkers for enabling them.
Huh? How is it an epic failure on their part? They have a product for which there is a clear demand. They are charging what they want and people are still buying them. Clearly there are people willing to pay the asking prices, as evidenced by the info that @philipma1957 has posted regarding the BTC addresses used for payment. Just because you and a number of other people think the S9s should be cheaper doesn't make it so. If you are not happy with the prices, just hodl your coins and wait. Until there are new miners available from other companies that rival the S9, or the demand for the S9 dries up, Bitmain will continue with prices at the current level. Cheers, - zed |
|
|
|
Now after HALVNIG my main question is:
WHICH IS THE ULTIMATE MINING HARDWARE
after that block reward droped on 12,5BTC im searching most profitable miner that exist
Im not experienced miner but also not a newbie,also checked few mining hardware products
ANTMINER S9 =new miner with nice ammount of TH/s
SMART Miner 3.0 Ultimate Rack Mount 50TH/s = found that on wallminer.com,but is this reliable peace?
and other miner producers
LightMiner
YesMiner
Rock Miner
BIT MAIN Make the Antminers (S7, S7LN, and S9)
MINERSLAB
BH Miner
DRAGON MINER
Gridseed Out of business, I believe
AVALON Make the A6, but nothing recently except rumors
BIT FURY Missing in action unless you have Panamax sized boats of money, maybe
Butterfly Labs Out of business, I believe
BLACK ARROW Out of business, I believe
SPONDOOLIES Out of business, I believe
ZEUS MINER
big bunch of companys but which is the right!?
I updated what I know. - zed |
|
|
|
Now for the expanding world of kano.is nodes ...
I've added another new node nl.kano.is in amsterdam, that anyone can mine to
This is somewhat of an attempt at a replacement for the DK node, but both will run in parallel for a short while.
If I do (probably) end up shutting down the DK node, I'll simply point DK to NL
DK has been a little unreliable, and one of the initial things that the provider said about upgrading their out of date KVM software, they still haven't done, so the NL node is a better performer than the DK node.
If anyone tries it out and compares the DK and NL nodes from wherever they, let me know how it fares for you.
So while I was trying to get my S7-LN working on *any* node I tried stratum.kano.is, de.kano.is, and dk.kano.is. As it turns out I am likely hitting upstream bandwidth limits (crappy @$$ DSL where I live, and no other reasonable options). That said for me to get to stratum.kano.is is ~84ms and to get to nl.kano.is is ~98.5ms. The odd thing is that the trip from my Mac to stratum.kano.is 17 hops with seven cross US trips, while the trip to nl.kano.is is 13. Mac-mini:~ boris$ traceroute -In stratum.kano.is
traceroute to stratum.kano.is (104.194.28.194), 64 hops max, 72 byte packets
1 192.168.1.1 My wired/wireless router
2 10.0.0.1 my DSL router
3 71.54.128.1 Ridgeland, South Carolina (Embarq Corp.)
4 71.32.28.81 Fargo, Noth Dakota (Qwest Communications)
5 67.14.28.246 Washington, DC (Qwest Communications)
6 63.235.40.174 Los Angeles, California (Qwest Communications)
7 64.125.20.121 Arlington, VA (Abovenet Communications)
8 64.125.30.248 Los Angeles, California (Abovenet Communications)
9 64.125.29.45 Los Angeles, California (Abovenet Communications)
10 64.125.28.103 Los Angeles, California (Abovenet Communications)
11 64.125.29.21 Los Angeles, California (Abovenet Communications)
12 64.125.30.187 Los Angeles, California (Abovenet Communications)
13 64.125.24.138 Los Angeles, California (Abovenet Communications)
14 64.125.24.142 Los Angeles, California (Abovenet Communications)
15 64.124.179.234 White Plains, New York (Abovenet Communications)
16 192.228.109.50 Las Vegas, Nevada (VegasNAP, LLC)
17 104.194.28.194 Las Vegas, Nevada (Versaweb, LLC)
Mac-mini:~ boris$
Mac-mini:~ boris$ ping -c 5 stratum.kano.is
PING stratum.kano.is (104.194.28.194): 56 data bytes
64 bytes from 104.194.28.194: icmp_seq=0 ttl=54 time=83.802 ms
64 bytes from 104.194.28.194: icmp_seq=1 ttl=54 time=83.279 ms
64 bytes from 104.194.28.194: icmp_seq=2 ttl=54 time=83.751 ms
64 bytes from 104.194.28.194: icmp_seq=3 ttl=54 time=84.106 ms
64 bytes from 104.194.28.194: icmp_seq=4 ttl=54 time=83.585 ms
--- stratum.kano.is ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 83.279/83.705/84.106/0.271 ms
Mac-mini:~ boris$
Mac-mini:~ boris$ traceroute -In nl.kano.is
traceroute to nl.kano.is (45.32.185.251), 64 hops max, 72 byte packets
1 192.168.1.1 My wired/wireless router
2 10.0.0.1 my DSL router
3 71.54.128.1 Ridgeland, South Carolina (Embarq Corp.)
4 71.32.28.81 Fargo, Noth Dakota (Qwest Communications)
5 67.14.28.18 Washington, D.C. (Qwest Communications)
6 213.248.96.93 Ashburn, Virginia (TeliaSonera International Carrier)
7 62.115.113.212 Ashburn, Virginia (TeliaSonera AB)
8 80.91.251.208 London, England (Telia International Carrier)
9 62.115.142.225 Amsterdam, Noord-Holland (TeliaSonera AB)
213.155.136.87 Amsterdam, Noord-Holland (TeliaSonera International Carrier)
213.155.130.26 Amsterdam, Noord-Holland (TeliaSonera International Carrier)
10 62.115.137.149 Amsterdam, Noord-Holland (TeliaSonera AB)
62.115.136.101 Amsterdam, Noord-Holland (TeliaSonera AB)
62.115.137.147 Amsterdam, Noord-Holland (TeliaSonera AB)
11 62.115.58.194 Amsterdam, Noord-Holland (TeliaSonera AB)
12 * * *
13 45.32.185.251 Matawan, New Jersey (Vultr Holdings LLC)
Amsterdam, North Holland (Vultr Holdings LLC)
Amsterdam, Noord-Holland (Choopa, LLC)
Mac-mini:~ boris$ ping -c 5 nl.kano.is
PING nl.kano.is (45.32.185.251): 56 data bytes
64 bytes from 45.32.185.251: icmp_seq=0 ttl=52 time=99.468 ms
64 bytes from 45.32.185.251: icmp_seq=1 ttl=52 time=98.950 ms
64 bytes from 45.32.185.251: icmp_seq=2 ttl=52 time=97.697 ms
64 bytes from 45.32.185.251: icmp_seq=3 ttl=52 time=97.433 ms
64 bytes from 45.32.185.251: icmp_seq=4 ttl=52 time=98.441 ms
--- nl.kano.is ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 97.433/98.398/99.468/0.758 ms
Mac-mini:~ boris$
|
|
|
|
above 150 instable
above 160 170 don't start work
To be honest, this sounds like a problem with the USB hub you have the Compac plugged into. The Compac I have is plugged into a powered USB 2.0 hub (it's the only device on the hub), the core voltage is ~0.800mV, and I am able to run the Compac at 325MHz. It's drawing more than the USB spec'd current on the port, but the hub seems to be OK. There have been some good recommendations for powering your Compac in the last few pages, and if you read through the first few pages of posts in this thread you will find a bunch of recommendations for powered USB hubs that work really well with the Compac miner. For what it's worth, my Compac is stable, and has been for months. I'm "lottery" mining and participating in the gekkorun.de "race." solo.ckpool.org stats: http://solo.ckpool.org/workers/1KZKt84mNoo3WFyiapRi5NAoi9V5DMi8nr.Compac1gekkorun.de: http://www.gekkorun.deCheers, - zed |
|
|
|
|
wow, look away for a day for two, and much to my surprise, the miner got a big share to chew on.
Still searching for the elusive 213G share...
Cheers,
- zed
|
|
|
|
|
-1.7 = ZedZedNova, please.
- zed
|
|
|
|
Well, for anyone curious, it appears it was an arp table in some main router/switch/whatever at the data centre that was fuxored. I have a number of VPS in the same place as the main bare metal hardware that is the main server in Vegas, and they were all ok during all this. Though, that's my interpretation of the 'incomplete' reply about what was going on. But, yeah arp tables are something that most people don't even know what they are, let alone work out that there's a problem with them  That's interesting that the VPS were not affected, but the bare metal server was. Sounds almost like it could have been a TOR switch/fex where your bare metal server is, and the error was propagated to their core. Whee, lots of fun. I gave up troubleshooting that stuff about a year ago. This last year with out a portfolio of hardware to manage (a couple of small datacenters for my team) has been interesting. First time in over 20 years without some kind of hardware/lab to manage as part of my job. - zed |
|
|
|
Have no idea why the thing with my browser, either...ain't gonna burn daylight trying to figure it out. Quite likely a DNS issue, but not with @kano's servers. All that has to happen for you to get hosed up like that is that the DNS server you use get's a bad (possibly intentionally malicious) update and the addresses it provides are bogus. Cheers, - zed |
|
|
|
I currently make 25 Cents per month at the current exchange rate and on one stick.
Well, if that is the case, multiply $0.25 by the number of sticks to figure out your monthly income at this point in time. Be prepared for that income to never fully materialize, and in fact be a lot less than you think or expect. There are a lot of variables that are beyond your control and that affect your income from any miner. Look at cost/GH and I think you'll quickly conclude that the stick miners are not particularly cost effective for earning lots of cash. They are great as a learning tool that might earn you a few cents if you mine long enough. If you are serious about earning money with a miner you probably need to be looking at something like A Bitmain S7, S7-LN, or S9, or an Avalon A6, or an equivalent. Essentially current generation and last generation miners. I think that any miner made prior to that technology would need free electricity to have a chance at earning you money. Cheers, - zed |
|
|
|
|
Show Posts
