If you configured you IPv6 addresses by hand then your deployment wasn't canonical. The normal, expected way of deploying IPv4 is DHCP; the normal, expected way of deploying IPv6 is DHCP6 or SLAAC. I am not sure which parts from my information made you came to this wrong conclusion. As I clearly wrote that this is a VPS or a server, I don't need DHCP6 to configure IPv6. As I also wrote above, I got /64 subnet of IPv6 addresses from my VPS providers. So I can use any of 18,446,744,073,709,551,616 IPv6 addresses that my VPS providers gave me. And this is the normal way of configuring IPv6 on servers. The temporary and permanent IPv6 addresses are described in RFC 4941 http://tools.ietf.org/html/rfc4941 "Privacy Extensions for Stateless Address Autoconfiguration in IPv6". There's plenty of tutorials available if you find reading RFCs too difficult. If you had been given a subnet of IPv6 address, the permanent or temporary addresses (in your term) are not really relevant any more. I think you misunderstood the information that you mentioned. My guess is that your nodes are operating properly, although maybe non-optimal. You probably simply don't understand some wrinkle in the expected network deployment procedures. The IPv6 represents return to the normalcy, auto-configuration is default, like it was in nearly every network protocol stack like DECNET, Novell, AppleTalk, etc. IPv4 was the odd one requiring so much manual settings.
I have been using and working on IPv6 at work in the last 5 years. And 3 years ago, my ISP provider deployed IPv6. So I am quite familiar with it and I understood enough about the settings related to that. What I would actually recommend is that you rent a Windows VPS for a short term evaluation, just to understand how it should be done. It somewhat pains me to be recommending Windows, but that is the reality: Microsoft did it right while most of Linux distributions screwed up.
This is really interesting comments  There are 5 PCs in my home and none of them is using Window$ OS. I use Window$ PC at work as I have to. There are countless problems on Window$ in regards to IPv6 setup on servers and workstations in my office, which Microsoft certified engineers cannot even fix properly. There is no IPv6 related issues on Linux PCs that I cannot fix myself. I guess this discussion goes out of topic too far. |
|
|
|
If you have single IPv6 address per interface then your IPv6 deployment is somewhat nonstandard. The canonical way of deploying IPv6 is with at least two IPv6 aliases per interface: one "permanent" and at least one "temporary" that is changed on a regular schedule. The "permanent" is mostly for incoming connections, the "temporary" is mostly for outgoing connections. If you have man long-lasting outgoing connections (like e.g. Bitcoin, unlike e.g. HTTP) you should have multiple simultaneous "temporary" IPv6 addresses active on the interface.
On both my VPS' of Bitcoin nodes, I have a single eth0 interface with 1 IPv4 and 4 IPv6 addresses. And my setup on IPv6 was initially "standard". But I thought that causes the problem on IPv6 Bitcoin node connections as the the outgoing packets use different IPv6 address than the IPv6 address used by the incoming packets which Bitcoin node listens to. That is why I made sure that Bitcoin only uses a single IPv6 address for both incoming and outgoing packets. But this turned out to be in fact an issue according to you. I am not sure what you meant by "permanent" and "temporary" addresses. All IPv4 and IPv6 addresses on my eth0 are all permanent addresses. Perhaps the "temporary" address that you meant is the "link-local addresses". This becomes more confusing than I expected. Unfortunately, there is no documentation related to this that I can find. |
|
|
|
The general idea was that Bitcoin client is supposed to randomize its outgoing IP address usage to avoid constantly connecting to the same subnets. The code is a little weird, it avoids connecting to the same /16 subnet over IPv4, what it effectively does with IPv6 I did not analyze. But even with regularly changing IPv4 addresses (like vast majority of xDSL deployments, every 24 hours) it doesn't operate well, certainly is much worse than Bittorrent at locating and connecting to peers.
I set 4 IPv6 addresses on the /64 subnet that I got from my providers. But I use only 1 IPv6 address for the node and I made sure that both incoming and outgoing Bitcoin packets use that particular IPv6 address via ip route and iptables settings. According to what you mentioned, does this mean we should not set 2 different IP addresses on a single Bitcoin node even they are on different network, i.e. IPv4 and IPv6? |
|
|
|
Out of those few nodes, how many are still up or at those addresses? You are checking the debug.log, which only tells you nodes you have connected to in the past, that doesn't mean that all of those nodes are still online. Out of those 34 nodes, it is possible that many of them have gone offline, or that some are the same node just with a different ip address. Of course, your nodes wouldn't know that so they are counted separately.
Basically, the probability of getting ipv6 nodes is low compared to ipv4 nodes since there are significantly less of them that exist. According to bitnodes, out of 5703 nodes, only 826 are ipv6 nodes. That isn't a lot compared to the ipv4 nodes.
I pinged all of those 11 and 23 IPv6 nodes and all of them are replying. CorrectionThe word "replying" on my comment above is wrong. I just assumed that all the nodes were replying as those nodes are up according to nmap. But in fact not all of them opened port 8333. So some of them in fact shows for instance the following: Starting Nmap 6.47 ( http://nmap.org ) at 2016-01-31 19:04 CET
Nmap scan report for XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX
Host is up.
PORT STATE SERVICE
8333/tcp filtered unknown
or Starting Nmap 6.47 ( http://nmap.org ) at 2016-01-31 19:05 CET
Nmap scan report for XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX
Host is up.
PORT STATE SERVICE
8333/tcp closed unknown
At the time I checked them, only 6 of the IPv6 peers on my debug.log have port 8333 opened. |
|
|
|
I don't see any proof that your client is somehow not accepting IPv6 connections/preferring IPv4 connections or malfunctioning in any way. There aren't that many users with IPv6 on their connections (and I've definitely never had a node connected via IPv6, either on the different VPS services I used or in my home connection). The probability of having IPv4 nodes connected is pretty higher. Here are Google's IPv6 statistics. They're worth what they're worth... but it's a starting point to measure adoption. Yes. There is nothing preventing my nodes to connect to any available IPv6 peers as I can manually initiate the connection to those peers. And there is nothing preventing any IPv6 peers from connecting to my nodes. However, I have an impression that something in Bitcoin node prefers IPv4 peers than IPv6 peers, hence my questions about this. I think Google is not a good reference in term of IPv6 usage on Bitcoin node. According to https://bitnodes.21.co/nodes/, there are 5705 nodes at the time I am writing this. And out that there are 4875 IPv4 nodes and 830 IPv6 nodes. So I was wondering that only maximum 3 of those 830 nodes, connect to each of my 2 nodes. I guess I just have to force my nodes to connect to those IPv6 nodes as many as possible. |
|
|
|
There aren't many nodes or people that are using IPv6. It is likely that there are simply not enough IPv6 nodes that can connect to you.
I am not sure if that is the main reason. Because when I did a quick check with "cat debug.log | grep 'peeraddr=\[' | wc -l" just now, I got 2256 list of peers with IPv6. There are of course duplication of IPv6 addresses. But I expect that my nodes should be able to connect to more than one IPv6 and there should be more IPv6 peers that can connect to my nodes instead of only maximum 3 of them. Just for completeness, with the following command: cat debug.log | grep -oP '(?<=peeraddr=\[).+(\])' | wc -l
I got 2268 IPv6 peers. Out out that, there are actually only 11 unique IPv6 peers which I obtained using the following command: cat debug.log | grep -oP '(?<=peeraddr=\[).*(?=\])' | sort | uniq | wc -l
On the other node, I got 23 unique IPv6 addresses. As I mentioned above, I think my nodes should be able to get more IPv6 peers connected to them than only 3 peers, and they should be able to connect to more than one IPv6 peers. |
|
|
|
|
I have been running 2 Bitcoin full nodes for a few weeks using 0.11.2 version on Linux. On each node, I set to accept connections on both IPv4 and IPv6.
On the incoming connection, the number of peers connected to my nodes are mostly on IPv4, in the order above 80 peers while only about 3 peers connected on IPv6.
On the outgoing connection, my nodes always connect by itself to 7 different peers on IPv4 but only 1 peer on IPv6. I am using the default maxconnections, which I believe it is 125 connections for both outgoing and incoming connections.
I can force my nodes to connect to IPv6 peers using addnode command, but I am wondering why my nodes does not want to connect to more IPv6 peers by itself and why only a few IPv6 peers connected to them. Do you guys have any idea why this is happening?
|
|
|
|
Just add printtoconsole=1 to bitcoin.conf and enjoy no new data added to debug.log file, there is nothing realy interesting to see there anyway.
Thanks. But I still need to have the debug.log for figuring out the reasons of any issues on my full nodes, e.g. bitcoind crashes, database corruptions, naughty peers, etc. |
|
|
|
Anyone have any use for a U3 that no longer hashes? Fan spins, usb led comes on, but it won't hash. If you pay shipping I'll send it to you.
I definitely need that, Mike!  But I am not sure if it would be worth it to pay the shipping cost. How much do you think the cost to send it to Austria? |
|
|
|
Actually it is not part of mempool. In fact it has no category, it is just Error. I don't think there are docs on this, I had to dig through the source code. And if you could somehow suppress the Error type, then you would be suppressing all of them, including ones that would matter.
Thanks for your help. I have also just been digging up the source (with my limited C programming knowledge), with the hope that I could just remark the commands related to those messages and re-compile bitcoind. But it seems to be more complicated than just remarking them. I guess I have to live with this for a while. It is just an annoying issue anyway. |
|
|
|
The category for that message would be mempool. If you don't want it, then I think you will need to specify everything except mempool.
Thanks a lot for responding my questions. How about my second question? If would set the debug not to record any messages of mempool category, does that mean I will not get any other important messages? And what are the type of messages of mempool category? Is there any documentation about this? Or do we have to dig up the source on https://github.com/bitcoin/bitcoin? |
|
|
|
I have been running full nodes for quite sometime now. I have added another full node in the last few weeks and I have upgraded the bitcoind to version 0.11.2. Everything is running fine except that I cannot figure out how to suppress the useless messages like below from being inserted into the debug.log file. .
2016-01-05 22:51:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2016-01-05 22:51:24 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2016-01-05 22:51:24 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2016-01-05 22:51:31 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2016-01-05 22:51:31 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2016-01-05 22:51:33 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2016-01-05 22:51:43 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2016-01-05 22:51:48 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
.
The bitcoin documentation mention the following options, but I cannot find any more detail information about what each category does and how to set them. -debug=<category> Output debugging information (default: 0, supplying <category> is optional)
If <category> is not supplied, output all debugging information.
<category> can be: addrman, alert, bench, coindb, db, lock, rand, rpc, selectcoins, mempool, net.
Which category is related the above messages? And could I actually use multiple categories, e.g. debug=addrman,bench,coindb, except the category of the above messages? As the type of the above messages is ERROR message and if I would suppress such messages, would that mean I will not see other ERROR messages that are important? Thanks in advance for your help. |
|
|
|
I bought 2 Antminer U3s in August this year. Today 1 ASIC chip on each of them stop hashing, the 3rd chip on the first one and the 1st chip on the second one. I have tried resetting them so many times but they keep refusing to do the hashing. So the chips just seem to work for only 4 months.  I want to try to desolder the good chip from one miner to replace the bad one on the other miner. Does anybody know how to identify the exact location of the bad chips? On the PCB, the BM1382 ASIC chips are identified as U8, U9, U10 and U11. Could anybody confirm please that on my AMU0 the bad chip is U10 and on my AMU1 the bad chip is U8? Thanks in advance for your help. Just a quick update. I was still not sure if one chip on each of my 2 Antminer U3 are really broken. So I played around with the settings a bit more last night. Both chips that look to be broken are hashing again when I set the voltage to 0.8 V and the frequency to 100 MHz. However, they are only hashing at around 1.5 Gh/s. With the voltage below 0.8 V, HW errors were shown on the chips including the good ones after just a few seconds of hashing.  It looks like the problems are somewhere else. I have checked each components on the PCB for loose solder due to drawing high current, but they seem to be all right. I think I will try to change the electrolytic capacitors, possibly with higher capacitance. Does anybody have any other suggestions? |
|
|
|
I bought 2 Antminer U3s in August this year. Today 1 ASIC chip on each of them stop hashing, the 3rd chip on the first one and the 1st chip on the second one. I have tried resetting them so many times but they keep refusing to do the hashing. So the chips just seem to work for only 4 months. I want to try to desolder the good chip from one miner to replace the bad one on the other miner. Does anybody know how to identify the exact location of the bad chips? On the PCB, the BM1382 ASIC chips are identified as U8, U9, U10 and U11. Could anybody confirm please that on my AMU0 the bad chip is U10 and on my AMU1 the bad chip is U8? Thanks in advance for your help. |
|
|
|
Did anyone get a reset script to work?
Tried
echo "0" > "/sys/bus/usb/devices/usb1/power/autosuspend"
echo "auto" > "/sys/bus/usb/devices/usb1/power/level"
echo "0" > "/sys/bus/usb/devices/usb2/power/autosuspend"
echo "auto" > "/sys/bus/usb/devices/usb2/power/level"
echo "0" > "/sys/bus/usb/devices/usb3/power/autosuspend"
echo "auto" > "/sys/bus/usb/devices/usb3/power/level"
echo "0" > "/sys/bus/usb/devices/usb4/power/autosuspend"
echo "auto" > "/sys/bus/usb/devices/usb4/power/level"
But seems it not working i still have to power on /off the u3s
I am using BFGMiner on my TL-WDR3600 WiFi router. I only connected 2 of my Antminer U3 to it on /dev/ttyUSB0 and /dev/ttyUSB1. I use the following script to toggle both ttyUSBs when one and/or both miners are dead. #!/bin/sh
# Switch OFF ttyUSB0
echo "0" > /sys/devices/virtual/gpio/gpio22/value
# Switch OFF ttyUSB1
echo "0" > /sys/devices/virtual/gpio/gpio21/value
sleep 10
# Switch ON ttyUSB0
echo "1" > /sys/devices/virtual/gpio/gpio22/value
# Switch ON ttyUSB1
echo "1" > /sys/devices/virtual/gpio/gpio21/value
exit 0
That script does not help all the time. I sometime still need to physically unplug and re-plug the USB cables. And if that still does not bring the miners up and running in stable condition, i.e. one of the chips shows to have 0.0 Gh/s effective hash rate, I have to also physically unplug and re-plug the power cables. |
|
|
|
|
Hi Luke,
When my Antminer U3s stop hashing, I usually start with unplug and re-plug the USB cable to bring them up again while BFGMiner is still running. But sometime I have to unplug and re-plug the power as well while BFGMiner is running. And when the last action does not bring the miners into stable state, I have to stop BFGMiner, unplug USB cable first, unplug the power, plug the power, plug the USB cable and start BFGMiner again.
There seems to be different behaviours on the above 3 series of actions. While BFGMiner is running, after I unplug and re-plug the USB cable, does BFGMiner set the chip type, clock, voltage and timing when it realises that the miner is connecting again? How about if I also unplug and re-plug the power while BFGMiner is running? Does it behave the same like when I unplug and re-plug only the USB cable?
Cheers,
Anto
|
|
|
|
|
Thanks a lot icezer0z and sixxkilur for your suggestions.
|
|
|
|
I changed my mind. I think it is better to keep the "address" setting as fall back in case there would be something wrong with the list of addresses for the "rewardRecipients", e.g. the list is corrupted causing an empty list. So that manual distribution of the reward from the "address" can still be done as a fall back. |
|
|
|
According to UNOMP sample config on github, we can distribute the reward by setting it on the pool config like below "address": "mi4iBXbBsydtcc5yFmsff2zCFVX4XG7qJc", //Address to where block rewards are given
/* Block rewards go to the configured pool wallet address to later be paid out to miners,
except for a percentage that can go to, for examples, pool operator(s) as pool fees or
or to donations address. Addresses or hashed public keys can be used. Here is an example
of rewards going to the main pool op and a pool co-owner. Can also be set for mandatory
donation coins like GRE and DMD. */
"rewardRecipients": {
"n37vuNFkXfk15uFnGoVyHZ6PYQxppD3QqK": 1.5, //1.5% goes to pool op
"mirj3LtZxbSTharhtXvotqtJXUY7ki5qfx": 0.5 //0.5% goes to a pool co-owner
},
I believe this setting is only being loaded once at the time we start the pool. I would like to use only the "rewardRecipients", so no "address" setting. And I would like to maintain the list of addresses for the "rewardRecipients" outside UNOMP and I would like UNOMP to regularly load that list. Does anybody have suggestion on how to achieve that? Thanks in advance for your help. |
|
|
|
|
Show Posts
