Disk IO retry - OpenVMS 7.3-2

[Wim Van den Wyngaert]

Not on topic but ...

Today a disk was replaced in a raid set on the GS160/HSG80 (same config as above).

During this operation I monitored the drive and IO was stalled 3 times for 0.1 sec, then 0.4 sec and finaly for 1.6 sec.

Fwiw

Wim

[Wim Van den Wyngaert]

I started a backup from a large file from a disk (HSG80) to the same disk and looked how another process was delayed doing writes to the same disk.

1 out of 5 writes were delayed with by average 0.6 sec !!!

During a backup of the file to another disk 1 out of 2 writes to the FROM disk were delayed with by average 0.3 sec.

During a backup of a file from another disk to the disk the writes were not delayed at all.

During normal operation of the disk (or even a copy of a large file) I saw only delays of a few 1/100 sec.

Fwiw

Wim

[Jur van der Burg]

If you run backup it can throw a number of i/o's at the disk, and seeing a delay of 0.6 seconds is not unusual at all. So it depends on the quota's that you gave the backup process. I've seen people giving it a diolm of 4096, guess what happens with the response time of one i/o if you queue that many i/o's to the disk.

Jur.

[Wim Van den Wyngaert]

Jur,

I know. Just had no idea of the size of the delay.

Just saw during normal Sybase operations a delay of 0.8 seconds ! 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.

Wim

[Wim Van den Wyngaert]

Zero for me. Bug in script.

It's not 1 out of 5 IO's that's delayed but 10 IO's per minuut when doing CONTINOUS IO.

Idem for 1 out of 2 : it's 30 per minute.

Sorry

Wim

[Jan van den Ende]

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

[Wim Van den Wyngaert]

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

[Jan van den Ende]

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

[Wim Van den Wyngaert]

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

[Ian Miller.]

Don't confuse IPL with scheduling priority.
They are different things.