Meanwhile, in the land of mining nodes ...
I'm gonna get rid of the DK node in about 10-12 hours.
No one has to do anything to their miners, since, I'll firstly, simply point DK at NL, then about 1/2 an hour or so later send anyone mining on DK a redirect to NL.
Finally, when I stop the pool node itself, anyone still left will reconnect to NL, since DK will be pointing to NL by then.
If you rent and mine to DK, then the rental may give up, since certain rental place's poxy software may not handle a redirect.
Makes you wonder what you are paying that exorbitant fee to them for ... if they cant add that original stratum command.
Right now, NL is ~580THs and DK is only 80THs, so not many people left on the DK node - about 6.
The NL node is faster and better than the DK node, and also gets work from the main Vegas node faster than the DK node, so as I actually mentioned I'd do when I setup the NL node, it's now time to get rid DK.
I'll post again when I'm doing it, but for the ~6 people mining on the DK node, it should just be a reconnect in cgminer.
OK, doing the DK DNS switch now, this has no effect on anyone at all, but just means that if you are one of the few people pointing to DK, if you reconnect 10 minute or more from now, you'll end up on NL.
In about half an hour I'll send the reconnect, to redirect everyone on DK to NL, and then stop the pool node shortly after that, which will force a reconnect for anyone left: i.e. not cgminer or a proxy that ignores reconnects
DK is currently 70THs (NL is 650THs)
Also, anyone wondering about the list of nodes, the thread subject contains the list, but of course there is no us.kano.is
FWIW...sorta kinda what I figgered...the primary (kano.is) is my best bet here, at around 75ms. SG runs over 200ms, JP didn't connect (I think Kano dumped that one, but my memory ain't that super anymore)
...
JP works fine
But it usually only has a very small hash rate, but that's OK also since all nodes work on distributing our blocks faster also, and it's well placed for that.
