|
Note: The Relay Network is no longer being actively maintained. If you wish to take over its operation and keep it running, please contact me.
|
|
|
|
Hi, i am using the windows exe version. Is it normal for it to be using 40+ % CPU usage on an i5 3570K at 4Ghz? Just wanted to check to see if it was perhaps something wrong.
That is definitely wrong. It shouldn't average more than 1-5%, maybe with spikes up higher, but 40% is crazy unless you built it in test mode. |
|
|
|
The relay client will gladly work on a separate machine (most larger users do this, I believe), but is really only designed to run on the same LAN/on a network with incredibly low latency and great bandwidth between your relay client and your bitcoind. As for running it on Windows, it should work, in theory, but recent comments by other windows users indicate that it may not work at all (see https://github.com/TheBlueMatt/RelayNode/issues/16). Since I dont have anything running Windows I cant test it outside of Wine. |
|
|
|
|
Is anyone still accessing the Relay Network via the P2P protocol (ie via -addnode)? I would very much like to turn that off in the coming days....speak now or forever get your connections -j REJECT'ed.
|
|
|
|
Had 2 relay issues in the last few hours.
One where it went down for a short while.
Another, at the moment, where I'm only seeing blocks coming from the relay (for the last 3 blocks), no txns coming or going - so the blocks are about the same size 'on the wire'
It's also slower than one of my non-relay bitcoinds so I'm guessing there's a problem?
(code is of course current as at ea55c37)
Edit: restart (temporarily) fixed it, but it only lasted 327 txns until it stopped again.
(and a second restart lasted 326)
There were some server issues this evening (PST). I'm monitoring closely but expect some hiccups in the next day or two. Client restarts should (hopefully) not be required as they will reset when your connection to the server is reset, but do notify me if a client restart fixes things. |
|
|
|
|
Network performance for the past week or so has been rather dismal. 5 seconds seems pretty excessive, but either way I just pushed a rather large update to github and on the servers. It should improve compression a ton (and also drops connections for those using many-months-old clients).
|
|
|
|
If you're not, update coming soon that you should really upgrade to as well  . |
|
|
|
|
If you're one of the many users still (somehow) using version "toucan twink" you need to upgrade NOW. At some point in the next day or two the servers will start simply dropping your connections.
|
|
|
|
Is the network down?  No known issues atm. |
|
|
|
|
Oops, I didnt bother to update this thread when I switched servers around. Here are the latest updates from bitcoinrelaynetwork.org, copied:
September 16th: New topology is now active, but having some issues with GFW. New HK node is thus not yet available to connect to as it might have to move again. Got a new IP for the HK server, which seems to have fixed the GFW issues, so it has been enabled and the stats have been reset and reenabled.
September 15th: DigitalOcean Singapore's generally shitty service finally pissed me off enough and I destroyed that server when it went down yet again. Waiting on a new Hong Kong server to be provisioned from a new provider and switched to a different host in Singapore which has much better routing and will be used as a hop-only node (ie be used for transit and will not be connectable by clients). Stats are broken but the rest of the network should generally not have any problems.
|
|
|
|
Matt, I just wanted to thank you for your great work on this and other projects. FWIW, my RelayNode has not had any problems during the last 24+ hours of increased transaction activity (and for a pretty long time before). Yea, I didnt bother turning off compression, but set the mempool query code to only select a smaller set. This has resulted in a huge drop in compression effeciency (see graphs linked above), but it does till work... |
|
|
|
If people could update to at least include https://github.com/TheBlueMatt/RelayNode/commit/6c479374f1f7f9a9338b656f8d5baa45d91e7d2c in their build, it would help a lot...when people start spamming the network the b/w usage on the relay servers spikes to much higher than reasonable, which may cause most servers to use more b/w than their monthly allotment. It has no effect on the effectiveness of the relay network, and is almost entirely redundant. |
|
|
|
When I execute it with parameters it prints some garbage.
And few seconds later windows halts the program.
(Sorry, the Windows displays dialog box in Russian)
Strange that it prints garbage to start, but that does actually look like its working. Wait 30 seconds and see if it prints a bunch of messages about transactions received/sent? |
|
|
|
Now it does not start at all  Windows 7x64 What stable build can be used? Well, I told you I fixed your original bug :p. Sadly, I dont have any Windows boxes anywhere to test with, and it works in wine now....So you get not prints when you try to run it, and it also doesnt run when you specify your local bitcoind (ie "relaynetworkclient.exe my-bitcoind-address 8333")? |
|
|
|
WTF with latest executable?
Should be fixed now. |
|
|
|
In other news, things seem to be working pretty well now but I probably wont be able to devote a ton of time writing new features in the near future, and since I spent a ton of time recently refactoring the whole codebase, contributing should now be reasonably possible. I'm sure we could drop global relay times another 10-20% pretty easily, and put up some issues at https://github.com/TheBlueMatt/RelayNode/issues that should be reasonably doable for people without stepping on code everywhere else (well, except maybe the rething-low-level-transport-protocol one). |
|
|
|
Question:
So if I see 'S' 66% sends and 'R' 34% receives in the data in my log, that would represent that I'm supplying ~50% of the transactions to the server I connect to?
... since each receive is followed by a send, 'S' 66% would be 100% of the transactions and 'R' 34% would be the amount of those transaction that were sent to me?
i.e. 100 - (R / S) would be my % ?
Ignore out-of-band transactions (it should be pretty much 1:1, then, which means you are, as expected, pretty much just echoing all the transactions the server sends you...see https://github.com/TheBlueMatt/RelayNode/issues/11). Out-of-band transactions are just you sending transactions that the relay network may or may not have already seen that probably arent going to be used to compress things (see https://github.com/TheBlueMatt/RelayNode/issues/13). |
|
|
|
Added a node in Siberia which improves Japan/Beijing<->EU times, though its not publicly available to connect to (if anyone is mining in Russia and wants to connect to it, please ping me). Check out the nice little map of where the nodes are now at the bottom of the stats page ( http://bitcoinrelaynetwork.org/stats.html#hotspot_map) |
|
|
|
Sent transaction of size 427 to relay server
Received transaction of size 427 from relay server
Sent transaction of size 427 to relay server
public.eu.relay.mattcorallo.com Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
public.eu.relay.mattcorallo.com Disconnect: failed to read message header (Connection reset by peer)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
public.eu.relay.mattcorallo.com Disconnect: failed to read message header (Connection reset by peer)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
Connected to relay node with protocol version sponsor printer
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
The amount of Tx sizes of 226/7 & 427/8 flying by at light speed is mind blowing - never seen so many of the same size. However, what ever changes you're making seem to be an improvement, so we appear to be on the right road  Edit2: I think I've nailed the disconnect problem. I just noticed that the default number of threads to service RPC calls is set at 4 on bitcoind, which, seeing as I'm merge mining 10 other coins plus the relaynetworkclient on my p2pool node - doesn't seem enough. So I increased this value to 10 in the .conf file using: ...and restarted bitcoind. Since doing this I've not observed a single disconnect - only the constant stream of 226/7 & 427/8 Tx fees flying by at warp speed I'll keep an eye on it, but hopefully this info will prove useful to other merge miners. LOL, I'm blind! That is disconnecting from 127.0.0.1, so, yea, its not able to hold a connection to your bitcoind (because your bitcoind is overloaded). It has little to nothing to do with the relay network. |
|
|
|
|
Show Posts
