Operating System - OpenVMS
1828214 Members
2471 Online
109975 Solutions
New Discussion

Re: Disk IO retry - OpenVMS 7.3-2

 
SOLVED
Go to solution
Jan van den Ende
Honored Contributor

Re: Disk IO retry - OpenVMS 7.3-2

Wim,

>>>
So, now I do the test with an increased priority to be sure I'm first in getting the cpu. But with the same results.
<<<

That does not surprise me at all. The lower prio (relative to the process with prio raised) only means that the IO -issueing- perhaps gets done later, but, -when- it is done, the handling of it proceeds at interrupt priority, which is way above scheduling priority. And process priorities are only relative WITHIN the scheduler...


hth

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Wim Van den Wyngaert
Honored Contributor

Re: Disk IO retry - OpenVMS 7.3-2

Jan,

Agree but we have processes at prio 10 (but light cpu usage) which is above the interrupt priority.

In any case, real time applications should be handled with extreme care. Kevin has a difficult job to do.

Wim
Wim
Jan van den Ende
Honored Contributor

Re: Disk IO retry - OpenVMS 7.3-2

Wim,

sorry, incorrect!

ANY scheduling is done at IPL 2 (InterruptPriorityLevel). IOs are WAY above that! (IPL 20-24)

And prio 10 is not THAT high! Real time prios start at 16; but even there, interrupts HAVE to be handled first!

fwiw

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Wim Van den Wyngaert
Honored Contributor

Re: Disk IO retry - OpenVMS 7.3-2

interrupts yes, but after the IO completion the process gets a boost of 2 (so gets to prio 6). 10 is not real time but still higher than 6. So, the dcl code that calculates the time difference may get delayed.

Wim

Wim
Ian Miller.
Honored Contributor

Re: Disk IO retry - OpenVMS 7.3-2

Don't confuse IPL with scheduling priority.
They are different things.
____________________
Purely Personal Opinion
Kevin Raven (UK)
Frequent Advisor

Re: Disk IO retry - OpenVMS 7.3-2

Our application response gets measured in 20 Millisecond responses times. Our end users test this. Make sure they are getting a good response when they want to deal. If the EMC support chaps make a configuration change that stalls IO and application for 1.8 to 4.9 seconds ..then this is seen as an outage.
The outcome so far, is no config changes during production time. Until now they could get away with it. Other users of the storage (EMC) did not notice the stall. Now we have joined the shared EMC storage club , we have a different level of SLA.
In the past we had local storage to the cluster ...via HSJ70's (prior to me joining the company).
I'm told that they used to get a 5 second outage on these also. This was when a battery check was peformed. This was scheduled for outside the production window ?
Never heard of this battery test prior.
However it has been years since I have touched HSJ70's.

Kevin