Re: Request for HUP-ing Unix clients

Eating Before Swimming (mathboy@sizone.org)
Tue, 27 May 1997 12:13:52 -0400 (EDT)


then Garance A Drosehn's all..
>
> The deschall project is an interesting example of a distributed
> application, and I'm toying with the idea of running it on more of
> our Unix machines whenever a machine has no real user logged onto
> it. I pretty much have to blow the process away as soon as someone
> does log in, simply because these machines were bought for the
> people who are logging in, and were not bought to run deschall
> clients. So, when someone logs in I send a HUP signal to the
> deschall client, and it politely goes away.

No no no, just kill -STOP it.

It uses up a whole 200K or so, which isnt alot. Or if that memory is
needed it will get swapped out to use up 200K of swap space.

When the user logs out, kill -CONT it.

If there are enuf users logging in and out, it will never get to complete
a key range check if it never gets to run for 5000 odd seconds without
a user logging in, if you are -HUPping it.

I spose thats better than nothing, having it run perhaps at night for
8 hours. Killing -CONT will only stop it for the time the user is logged in.

STop completely. So he gets 100% of the processor, including idle time.

Well thats not true now is it! init, update, gettys and all the
rest, inetd, etc are all eating CPU.

Nice -19 deschall-client will effect the same thing.[*]

(unless you are running Irix, apparently).

I sometimes run a program that requires EXTREMELY frequent and timely
access to the CPU or I will notice. That's quake for linux. At -19,
I DO NOT notice deschall running. And for good reason, it falls to less
than 10% of its key cracking rate, even tho Quake does have some idle
times in it when it needs less cpu (staring at a wall or into the
dark, for eg).

The only thing I've found that does suffer from DESCHALL even at -19
is my quake server on an incredibly expensive but very slow Sparc 5 Netra.
If I -STOP it it shaves 3-5 milliseconds off the users pings times when
I have 3 full 16 player servers going on it. ;)

At -19 it will use negligible CPU. Will not bother the user. If the name
of the process bothers the user, get creative. ;)

> On some of the SGI's I tested this on, the client picks up 2^29

Ack! You might not be able to nice -19 and have expected things happen.
There are better ways to control process CPU on Irix.

> Initially I was going to suggest that the unix client support an
> option to set the maximum time-period. The workstations here at

This has been done. I imagine the development team for DESCHALL got
this request about 15 seconds after the first client was released. ;)
They'd have it out if it was ready, and til then, I spose it will
be ready when its ready... :)

> If the client receives a HUP signal, then stop all calculations of
> new keys, but report back to the server with the progress made on
> the current block. Maybe just report the progress to the nearest
> complete block of 2^22 or 2^24 keys, so you don't end up with

I think its done in 2^20 blocks.

> absurdly small lots of numbers. At the very least, report back to
> the server that this client is shutting down immediately, so the
> server can assume this client will never return a reply for the
> current block of keys.

Whats the difference between this and kill -STOPping it? The process
stays in the proc table swapped out? Is that bad?

Are you subject to the stupidity that I have been as far as 'resource
hogging' and the like? :) "This process was started on May 1st, its
HOGGING TOO MANY RESOURCES!!" "But its only using IDLE CPU!"

To get past this we should ask Rocke to get a client out that forks
itself off a couple times (except for Win95 or NT :p ) every time it
completes a keyrange and kill the parents, look, whole new process
with 0 cumulative CPU time! :)

/kc

-- 
Ken Chase mathboy@sizone.org Sonic Interzone $free$ email/news Toronto Canada
------------------------------------------------------------------------------
Join the DES Challenge! Wake up the US Govt!   www.frii.com/~rcv/deschall.htm

NB:Only 16000 P200-months CPU req'd to recover 56-bit IBM alliance keys! ** U.S. EXPORT LAWS MAY NOT APPLY TO YOUR COUNTRY: DEVELOP YOUR NATIONS' OWN CRYPTO-EXPORT INDUSTRY! USE 2048bit KEYS FREELY! FLAUNT YOUR SOVEREIGNTY! **