16 Sep
2015
16 Sep
'15
1:53 p.m.
You're probably under a Chinese/Russian robot attack, trying to brute-force their way
in.
I've had this on occasion and am tempted to just drop all packets originating from
China..
Not sure what the best way to do this is, I have a pretty simple consumer level router
(Draytek) so I guess I could use iptables or something on Linux - however I'm not if
that'll just affect the host I run the iptables command on or the whole interface.
Basically, I have one physical interface for 8 virtual machines and a bunch of SIMH
instances etc. If I could drop the packets at the interface of the host machine it'd
be ideal.
Any iptables experts out there?
sampsa
On 16 Sep 2015, at 12:46, Johnny Billquist <bqt at softjar.se> wrote:
On 2015-09-16 13:34, Brian Schenkenberger, VAXman-
wrote:
Sampsa Laine <sampsa at mac.com> writes:
Wouldn't that just show a delta of how many blocks have been allocated? That do not
really correspond to I/O throughput.
That said, what does the monitor operation_rate tell? Is it QIOs, disk blocks, disk
requests, or something else?
If it would actually be disk blocks, then Sampsa can indeed deduce I/O rates from it,
since we know the size of a disk block.
However, QIOs can cover many disk blocks, and so can I/O requests.
While I'm at it - a slightly different question. On a VMS system (VMS 7.3 on a VAX),
I now have like hundreds of telnet connections that are in a SUSP state. This have gone so
far that I cannot establish any more connections to the system. I have no idea what
people/probes/robots have been doing, but it seems TCP/IP or telnet daemon in VMS 7.3 have
some issues.
But my first question is, how do I get rid of all these processes? Do I have to kill each
one, giving the PID, or is there some better way of getting this unstuck?
Johnny
On 16 Sep 2015, at 11:46, Brian Schenkenberger,
VAXman- =
<system at TMESIS.COM> wrote:
It's a performance metric that is maintained in/by VMS about the number of I/O
operations to the disks. Maintaining block counts would be more/only meaning-
ful on a per-disk basis. That's generally not something that's a performance
metric.
This is a very simple procedure to get you a block/second count. Put this in
a file (BLOCKS_PER_SECOND.COM, for example) and execute it with the disk name
in question. (ie. $ @BLOCKS_PER_SECOND DKA100)
$ 100$: BLOCKS_THEN = F$getdvi(P1,"FREEBLOCKS")
$ WAIT ::01
$ WRITE SYS$OUTPUT BLOCKS_THEN-F$getdvi(P1,"FREEBLOCKS") ! THEN - NOW
$ GOTO 100$ Sampsa Laine <sampsa at mac.com> writes:
=20
> I'm running a batch job that is creating a large (82 GB) file and =3D
> monitoring the system with MONITOR DISK.
> =20
> The value I'm getting is 39 - what does this actually mean, what is =
the
=3D
> unit that is being monitored?
=20
=20
I'm assuming you did not specify /ITEM. =46rom the MONITOR HELP:
=20
When the /ITEM qualifier is omitted, the default is =
/ITEM=3DOPERATION_RATE.
:
:
OPERATION_ Specifies that I/O operation rate statistics are
RATE displayed for each disk.
=20
What's you concern, if any?
Yes, I did this but the operation rate does not give me an indication of =
how many block/second are beyond read/written, or does it?