Post
Topic
Board Pools
Re: [450 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff
by
stewdk
on 11/01/2014, 18:42:20 UTC
ICMP is not guaranteed way to test connection over internet - many routers have ICMP limit, which causes the packet to be dropped
Check with mtr and there will be no losses on the last hop

Good point. Sorry about making an unfair assumption.  Regardless, I'd still like to check the reliability of my connection to stratum.mining.cz.  I tried running mtr stratum.bitcoin.cz a couple of times, and it seems to resolve to different addresses each time.  Looks to me like some load balancing of some sort is going on, but it seems odd to me that it wouldn't just resolve to the closest geographical server to me every time.  Sometimes it's smeu01.bitcoin.cz, sometimes it's 192.198.107.178, and sometimes it's 54.225.68.97 (ec2-54-225-68-97.compute-1.amazonaws.com).

Do you think manually specifying 54.225.68.97:3333 in my miner would be a good idea?  54.225.68.97 seems to have the lowest latency for me.

If it works yes,

but keep in mind tomorrow something else may be better.

No connection is perfect.

Yep, it works. I can successfully submit shares using all three of those addresses.

It's not a good idea to use a static IP on my opinion.

The main reason to use load balancing is to distribute the load and failover to the remaining live servers in case of problems, which you will loose in this case.
Lowest latency does not mean 'best' ... what if the server is close but overloaded?

If you insist on fixed IP - it's recommended to at least add the hostname for failover

Of course I'll still have stratum.bitcoin.cz as a failover pool specified in the miner since that's the supported address.  I'm just trying to outsmart the load-balancer to get the best connection.

However, if I'm reading the output from mtr right, there is actually some loss at the last hop.  More so for 54.225.68.97 than the other two.  Maybe smeu01.bitcoin.cz is actually the best address for me even if it has the highest latency?

EDIT: Yeah, I realize this isn't a solution if the server is overloaded... But you said there shouldn't be any loss at the last hop?

EDIT2: In case the bitcointalk image proxy doesn't work:
http://i.imgur.com/RjbI23B.png
http://i.imgur.com/BsR2ZBi.png
http://i.imgur.com/aR7eFpU.png
Try not to quote the images.

http://i.imgur.com/RjbI23B.png

http://i.imgur.com/BsR2ZBi.png

http://i.imgur.com/aR7eFpU.png