[HECnet] MONITOR DISK - Meaning of values

[Johnny Billquist]

On 2015-09-16 13:53, Sampsa Laine wrote:
> You're probably under a Chinese/Russian robot attack, trying to brute-force their way in.

Quite possibly. Some day I should summarize and post logs of attempts at 
Madame.Update.UU.SE (RSX). It's quite funny. Fortunately, my RSX 
implementation is rather robust.

> 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?

I know how iptables and similar tools work. That is no help here.
This is a *VAX* running VMS. Not some simh instance...

	Johnny

>
> 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:
>>>
>>>> On 16 Sep 2015, at 11:46, Brian Schenkenberger, VAXman- =
>>>> <system at TMESIS.COM> wrote:
>>>>
>>>>> 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?
>>>
>>> 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$
>>
>> 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
>>
>