How can this link still be your customer support section?
I'm fed up guys... Fix your transaction fee.
This is the last time you'll bugger a transaction for me. I'm not recommending your service again until you get it fixed. Sending without a transaction fee when the wallet profile is set to normal is not ok. You're the best option for new users on iPhones, so this needs to be a priority.
Peg the default transaction fee to $0.01 and everyone will be much happier. At the very least add an option to send the equivalent of $0.01 for every transaction.
I haven't read this thread, so I don't know how much of a steady whine this is...
Get it fixed before black friday and I'll donate 0.1 btc to the charity of your choice.
And then your next complaint will be "why is my transaction not getting confirmed"...  |
|
|
|
What exactly is being promoted here? Is there a product available? Maybe less time making videos and more time making products would be a good idea...at least for your customers. |
|
|
|
|
Payent received. Tracking sent.
|
|
|
|
0.12 shipping to uk
actually from the forum tim the last 2 bids might be invalid. i believe you missed out by 12 seconds I think you can change the forum display time. In real world time, 8 more hours. |
|
|
|
0.05  Is that a bid? cuz I'll take it... well it sure aint a shopping list XD anymore details on why they just HW error? lol...yeah I would put working ASIC's on my shopping list. Not sure why they error, they show hashing in cgminer but it all goes to HW error so no accepted shares. The projectklondike webpage has some good troubleshooting guides but I don't have the time for it. |
|
|
|
0.05 Is that a bid? cuz I'll take it... |
|
|
|
Auctioning 2 Klondike's from steamboat group buy (16 avalon chips each). These give 100% hardware errors. Buyer pays shipping from Tampa FL 33618. They will fit in a medium flat rate box. Auction ends 5pm Pacific Mon Nov 25. Payment by 8pm Mon Nov 25 for shipping Tues morning. - Bid is for both, NOT selling single units - Minimum bid .05 BTC- Increment .01 BTC  |
|
|
|
@zvs: When I'm mining on your node, and it goes down, my cgminer client totally locks up and stops working. Other nodes, however, don't have that problem and cgminer properly switches to failover nodes. Has anyone else seen this on your node? I don't remember the error it gave; I stopped mining on it after it happened a few times (3 times last week).
This keeps happening to us on OGnasty's node and we've had to take 1.1TH off P2Pool because of this plus we'll have 650GH/s Jupiter soon to hash on as well. So that's 1.75TH/s for P2Pool if anyone can help us. Does anyone have a list of the nodes you mention that enable a fallover? Edit: Although my friend hosting the miners says it's cgminer actually crashing and is a cgminer problem. it is a cgminer problem, I think I found some info here: https://bitcointalk.org/index.php?topic=188533.0funny thing is that OgNasty's node failsover fine for me! I have much smaller hashrate, maybe that has something to do with it too. KNC have released a new firmware update today. If anyone finds out this stops the cgminer P2Pool for KNC Jupiters bug let me know and the pool will gain 1.75TH. What flags are you using for cgminer? I have had a dozen types of miners including a Jupiter on my node and they always fail over fine to my backup pool when I take the node down for maintenance. failover-only is the only thing I add to my conf for ASICs. |
|
|
|
it a fool idea
when i set btcaddress+256 i got a 99% reject!!!!!!!!!!!!!!!!!!11
256 is too high for 82GH/s. I don't know where the double your hash rate idea came from. Read here: https://bitcointalk.org/index.php?topic=274023.0Or just let p2pool do it for you  |
|
|
|
Anyone know why KLN devices would show up but mine at 0 on latest Ubuntu? Sometimes they work, but mostly not. I'll have a few up then restart cgminer or the computer and then different ones will be at 0. Annoying.
Power? Yeah that would make sense, so I've tried with different hubs and power setups and get the same results. So, since they are in Florida, and there is always plenty of lightning, I'm going to try that as a power source next. At least that will be entertaining https://bitcointalk.org/index.php?topic=326985.0 |
|
|
|
|
Anyone know why KLN devices would show up but mine at 0 on latest Ubuntu? Sometimes they work, but mostly not. I'll have a few up then restart cgminer or the computer and then different ones will be at 0. Annoying.
|
|
|
|
One of our Jupiters is hashing well currently on P2Pool using the latest firmware. We're going to leave it on there for twenty-four hours and if all is well put both on there. Which should add ~1.1TH/s to the pool.
Can you share your node address so we can see stats, and paste cgminer output from Jupiter? I am curious how you can say "it's hashing well" when AFAIK KNC firmware is still doing full stop for 2-3sec everytime when LP/work restart arrives, lol. The .98 firmware and cgminer 3.6.6 solved the horrible work restarts. KNC's do work well on p2pool now. I restarted recently, but here is about a 12 hr run. The cgminer hashrate displays lower than the pool average reports - so don't take that as the true rate. I average around 520GH/s on my node stats page, that's what I'm paid on right? 2013-11-05 10:27:48.573721 Pool: 38534GH/s Stale rate: 19.5% Expected time to block: 12.1 hours
2013-11-05 10:27:51.588785 P2Pool: 17319 shares in chain (17323 verified/17323 total) Peers: 23 (17 incoming)
2013-11-05 10:27:51.589007 Local: 494GH/s in last 10.0 minutes Local dead on arrival: ~4.6% (3-7%) Expected time to share: 24.1 minutes
2013-11-05 10:27:51.589132 Shares: 36 (3 orphan, 0 dead) Stale rate: ~8.3% (2-22%) Efficiency: ~113.8% (97-121%) Current payout: 0.3551 BTC
cgminer version 3.6.6 - Started: [2013-11-05 03:25:31]
--------------------------------------------------------------------------------
(5s):560.6G (avg):472.1Gh/s | A:5110528 R:117504 HW:297721 WU:7295.2/m
ST: 1 SS: 3 NB: 89 LW: 7667747 GF: 1 RF: 0
Connected to 24.173.129.247 diff 128 with stratum as user Jupiter+128
Block: 0000856c4a884be0... Diff:391M Started: [15:20:37] Best share: 1.51M
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
KnC 0: | 601.4G/472.1Gh/s | A:5110528 R:117504 HW:297721 WU: 7295.2/m
--------------------------------------------------------------------------------
[2013-11-05 15:28:58] Accepted 00f0fbf9 Diff 271/128 KnC 0 pool 0
[2013-11-05 15:28:58] Accepted 01ad75f9 Diff 152/128 KnC 0 pool 0
[2013-11-05 15:29:00] Accepted 00c26124 Diff 337/128 KnC 0 pool 0
[2013-11-05 15:29:01] Accepted 01b8facc Diff 148/128 KnC 0 pool 0
[2013-11-05 15:29:02] Accepted 00da070a Diff 300/128 KnC 0 pool 0
[2013-11-05 15:29:02] Accepted 0082729e Diff 502/128 KnC 0 pool 0
[2013-11-05 15:29:03] Accepted 00bc1667 Diff 348/128 KnC 0 pool 0
[2013-11-05 15:29:05] Accepted 0162889c Diff 184/128 KnC 0 pool 0
[2013-11-05 15:29:06] KnC: core 2-64 was enabled back from disabled state
[2013-11-05 15:29:06] Accepted 00136d41 Diff 3.37K/128 KnC 0 pool 0
[2013-11-05 15:29:06] Accepted 004a7296 Diff 880/128 KnC 0 pool 0
[2013-11-05 15:29:07] KnC: core 2-82 was enabled back from disabled state
[2013-11-05 15:29:08] Stratum from pool 0 requested work restart
[2013-11-05 15:29:08] KnC running flushwork
[2013-11-05 15:29:09] Accepted 018eec8a Diff 164/128 KnC 0 pool 0
[2013-11-05 15:29:09] Accepted 01d02268 Diff 141/128 KnC 0 pool 0
[2013-11-05 15:29:10] Accepted 0188e0ca Diff 166/128 KnC 0 pool 0
[2013-11-05 15:29:10] Accepted 016bb15a Diff 180/128 KnC 0 pool 0
|
|
|
|
|
I think it's 3.7.0, 3.6.6 works fine for me.
|
|
|
|
Er...  [2013-11-04 20:52:19] Started cgminer 3.7.0
[2013-11-04 20:52:21] Klondike (2:5) detect read failed (0:-7)
[2013-11-04 20:52:22] Klondike (2:5) detect read failed (0:-7)
[2013-11-04 20:52:24] Klondike (2:4) detect read failed (0:-7)
[2013-11-04 20:52:25] Klondike (2:4) detect read failed (0:-7)
[2013-11-04 20:52:28] Klondike (2:3) detect read failed (0:-7)
[2013-11-04 20:52:29] Klondike (2:3) detect read failed (0:-7)
[2013-11-04 20:52:31] Klondike (2:2) detect read failed (0:-7)
[2013-11-04 20:52:32] Klondike (2:2) detect read failed (0:-7)Segmentation fault (core dumped) |
|
|
|
Just a heads up that from the 40 nodes I can see right now; 24.161.35.225, 184.56.251.69, 183.136.216.39, 24.10.44.25, 183.136.216.39, 95.128.48.209, 193.190.255.150, 38.109.218.101, 198.91.172.112, 209.195.4.74, 186.220.27.239 all have over 1MB of transactions stored (while most everyone else in this lot has 45kb). That's why your bitcoind latency is so high. Some of these nodes are essentially dead, but others aren't...
Upgrade your bitcoind version, you're probably picking up the horse staple battery transactions... or lower maxblocksize to something like 250000...
oh, btw, 24.161.35.225... very impressive system there, the other five I looked at had latencies from 2s to 6s, yours is hanging out around 0.9s...
Where do you find all this information? |
|
|
|
Over the next few hours I'm pointing a Jupiter, Saturn and a Mercury all at p2pool for testing on FW 0.98.
Jupiter already seems to be happier than it was last time, Saturn will move over soon.
Yes .98 is much better. I'm up from 440GH/s to 530GH/s on my Jupiter. |
|
|
|
Rev 2 chips are being auctioned. I suspect SB might have been waiting for these announcements before offering refund options on assembly. We might hear something now that the options are clearer.
I like where this could end up. I'd pay for new chips. Waited this long, what's another forever? |
|
|
|
Node collection: This can be done and bigger miners are encouraged to do this to help out the smaller ones. You can do this by using the username "username/{difficulty}". So if I want to return one HUGE share that is worth 10x a small share, I log in with "-u username/1400000" I find a share 10x less frequently, but when I do it pays out a lot. people who find 50+ shares a day can do this and see a negligible change in variance and payout while encouraging smaller miners to keep mining by reducing small miner variance.
Maybe this should be set automatically by p2pool like the difficulty to keep the share difficulty lower and keep smaller miners on the pool? Yes, I really think this should be implemented. P2pool share should not be found by a miner more frequent than every 30 minutes. If it happens, p2pool node should automatically adjust real share difficulty to higher number, so share time is still estimated to be 30 minutes. Right now having about 400 GH/s will give you p2pool share every 30 minutes. But we have miners here with 1000GH/s and more, they are finding share in less than 10 minutes. If they could increse their share time, small miners will have chance again to mine with p2pool. p2pool does this by default, it readjusts share difficulty for miners to make sure no miner has > 5% of the shares in a given window: https://github.com/forrestv/p2pool/blob/0460c6cf03b8da4a5accb5ac26606e596a5571ff/p2pool/work.py#L251desired_share_target = min(desired_share_target, bitcoin_data.average_attempts_to_target(local_hash_rate * self.node.net.SHARE_PERIOD / 0.05)) # limit to 5% of pool shares by modulating share difficulty That will only limit >1.5TH/s miners at current pool rate? That's a bit high to be much help for smaller miners. |
|
|
|
I'm debating on moving ahead and just asking him to ship my miners, if they are fully functional with low hardware errors, I don't see a reason to have to reprogram the firmware.
Should there be any reason to wait?
It looks like the only thing missing now is the i2c functionality to allow you to chain the miners together and only use 1 usb cable. If you don't mind connecting each miner to its own usb port I don't know what else you'd be missing. Is that really it? They are already mining over 6GH/s, I doubt new firmware will make them fast enough to compensate for the lost time waiting. Am I missing something? |
|
|
|
|
Show Posts
