<<  >> (p.218)
    Author Topic: [ mining os ] nvoc  (Read 418569 times)
    kk003
    Member
    **
    Offline Offline

    Activity: 117
    Merit: 10


    View Profile
    November 16, 2017, 12:56:11 PM
     #4341


    Mmmm, I see, thx for testing the code. I only use claymore and ewbf, never found so many open connection from the miner.
    I think @Papampi's idea and yours are both great.

    About my code and your output I've notice that only 2 ips (guess must be pool's ips) are public and all others are private.
    In case of need should be easy to find the local network range and remove ip+port for those ones and keep only the public ips+ports.
    That way it does not matter how many ips has the pool, it would be possible to ping all of them.
    Anyway, just thinking aloud. All approaches look good to me, 

    Yes. I did that intentionally to prove the point that once you open the can of worms that is testing for pool connectivity, a lot of scenarios come up that makes the problem a lot more difficult than one would think at first. In that example, as I say, I am using not only the ZM miner to mine for ZEC but also cpuminer to mine for XMR. Most people don't realize that DSTM's ZM miner uses 2 connections: 1) for his connection to the pool he uses to mine for his dev share 2) the connection to whatever pool you are mining.  (Side Note: As of the 0.5.4* version, BOTH connections had to work or the miner would not mine. Those that use that miner are all too familiar with that because the pool he uses (flypool in EU) was down for a few hours last week and his miner stopped working. Needless to say, this caused quite an uproar with his users (see https://bt.irlbtc.com/view/2021765.1060) and he took a savage beating.)

    *Fortunately, DSTM has just released version 0.5.5 that supposedly will not block if his dev pool connection is unavailable.

    Thx for sharing :-).
    Talking about "can of worms", that's why we test code  Grin
Page 217
Viewing Page: 218