@Clueless Arktika 1.4.0 said INFO: Error talking to mining pool: io.grpc.StatusRuntimeException: UNAVAILABLE: Channel shutdownNow invoked, but 1.2.0 is okay to mining
1.4.0 arktika works fine for me
So I dont know why it is happened. I must use 1.2.0 again.
Sure nothing else is different?
None of that network code has changed
nothing different, same configure files? is configure files different between 1.20 and 1.4.0?
Same config file?
find error.
I need update my Pool application.lol
@alistar what pool are you connected to?
my own pool
well, glad it is nothing I need to fix. :wink:
@Joko I still like you but was just cleaning up perms
Haha I like you too mate :smile:
yeah, you had github commit access
Damn, I should have abused my powers when I had my chance!
So, nicely, you can use `cpulimit` to throttle your miner if you want, or perhaps an iolimit
@Rotonen I'm able to get 750+K mining in a VM, really not bad.
using `cpulimit` to throttle to `15%` for testnet nets me `Oct 23 10:06:30 vmsnow1 cpulimit[27821]: INFO: Mining rate: 19456.636/sec - at this rate 0.487 hours per block`
Anyone want to make a testnet faucet so I don't have to?
My plan is to encourage people to use testnet to play with things (like the upcoming Android client)
@Fireduck I´ll take the job
@mjay awesome
First step: Testnet explorer online. http://testnet.snowblossom-explorer.org/
awesome. Let me know when you want some testnet coin
You can send me some: snowtest:varv2n46rmmf79n5etad2lw8flx758axx0gd4pum
done
thank you
@Clueless rather use chrt if you want it to stay out of the way
Is there a minimal length for snow addresses?
not really
if they end up with a bunch of zeros on the front the base32 form will be smaller
What language are you working with? We can probably come up with a validator.
I´ll just do some basic validation, should be fine
cool
the send will reject it if it is nonsense
so whatever
contains only base32, is 40 chars or shorter, it should be fine
snowtest: removed before test
the address can be valid with snowtest: on the front or not
when presenting anything to a user, you should always have snowtest: on
for clarity
I remove it before the check if its present, and always send it without to the node
cool. I'm just saying you can send to the node either way.
5 testsnow each time
1) awesome
2) I've filled it up more
thanks
once it drops below 1k snow a miner will start
that is fancy
cronjobs are
hey, that is like an if statement and something to not spawn a new one each time the job runs (presumably)
and maybe even some mechanism to turn it off when not needed
so fancy
its a simple cronjob. Every 15 minutes: kill the miner (nothing happens if none is running), and start a new one if balance < 1000
still untested, so I expect it to be broken
not even doing a sigterm timeout dance?
I like it, it has a certain brutal efficency
walk into room. Shoot one foot above guard desk. If a guard is required, call temp agency for a new one.
efficient shooting using SIGTERM
SIGKILL sounded a little harsh
@mjay no i mean handling the fact signal sending is blocking
you mean, waiting until the process stops?
in general handling an indefinite stall upon SIGTERM
I just added another SIGKILL 5 seconds after the SIGTERM
how does the script get there if the kill is blocking
It never happened to me that a kill blocks
seems you mostly deal with well behaving well written software
how can you get it to block?
I had processes that catch sigterm and ignore it, zombies, cuda-processes with gpu crashed (ignoring even sigkill)
but kill never blocked (so far)
i'm sorta paranoid on that sorta unixy stuff, so i use fancy bells and whistles the kernel gives me to decide my course of action, like https://lwn.net/Articles/288056/ Like most versions of Unix, Linux has two fundamental ways in which a process can be put to sleep. A process which is placed in the TASK_INTERRUPTIBLE state will sleep until either (1) something explicitly wakes it up, or (2) a non-masked signal is received. The TASK_UNINTERRUPTIBLE state, instead, ignores signals; processes in that state will require an explicit wakeup before they can run again.
i think you can also get a file descriptor on the signal you've sent these days, but that's too new for me
@mjay if you want to implement a test program for yourself, see this https://cr.yp.to/docs/selfpipe.html seek out the classic book, and misimplement the example
From Mr. Bernstein, nice
Those old unix books are fun to read and experiment with
yeah, funny how that parallels with dusty magic tomes for wizardry
I like that djb posts on the post quantum mailing list I'm on
I just watch, no real clue what those guys are on about
what mailing list is this?
Yep
Watching with an eye towards adding winners to snowblossom
Nice, joined
but yeah, people with a lifetime of experience in this stuff debating how to deal with unknown unknowns is probably... dense
hehe
it is
There was some brilliant shade last week
Someone announced an attack on one of the candidates
DJB came back a few days later saying the attack had no merit.
:fire:
Its really impressive to read through these papers, barely understanding it, and to know someone came up with this stuff
Specialization is great
Those folks are specialist in that area
I specialize in doing dumb things with hashed tries