MSCP controllers

fre 2007-10-05 klockan 12:00 -0500 skrev "Jerome H. Fine" <jhfinedp3k at compsys.to>: Thank you. And yes, there might be a big difference between systems like RT-11, and larger ones. I don't know enough of the innards of RT-11 device drivers to tell how it is doing, nor how programs might utlize the driver. There is a big problem with using E11 here, since it queues and optimizes disk I/O as well, and so does the underlying OS also in the end. So it is tricky to do much evaluation of the controllers as such. You basically see what is best under E11. Analysis is always a good thing. And yes, the implementation of the respective emulation in E11 plays a big part. An interrupt handler that took anywhere near a fraction of 1/60 of a second is so broken it should be shot. Basically, you cannot measure anything with a clock of that low precision. Also, you need to check for I/O completion before doing the next operation. If you skip that, you will loose. So the question then is: is it acceptable to be in a tight loop waiting for I/O to complete, or do you want the machine to be able to do something else meanwhile? Let us instead look at this from a theoretical point of view. With the HD: driver, you need to somehow make sure that the previous operation have completed before you start the next one. This must all be done in PDP-11 code. You have the choice of either doing it polled, using a tight loop, or having an interrupt when the device is ready. Now, having a tight loop will most likely be better, but then your machine will do nothing else while it is waiting for the previous operation to complete. So most likely you will want to use interrupts. But no matter, we're talking about executing PDP-11 instructions the whole time here. Either to polled loop, followed by setting up the registers for the next I/O request, or having an interrupt handler entry doing the same setup after some sagister saving and so on. As such, they take a damn much longer than doing native instructions on the host CPU. This is important. The host CPU in the HD: case is the machine running the E11 emulator, while for the MSCP case is either the machine running E11, or the local CPU on the controller card. My point here then is: once the previous operation have completed, the HD: controller must run through some PDP-11 code before the next I/O operation can start. With MSCP, the host CPU needs to run though some code before the next I/O operation can start, while the PDP-11 isn't burdened at all in this phase. Obviously, the MSCP case is better. But this is only true, if you queue more than one I/O reuqest to the MSCP controller. If you don't take advantage of this feature in MSCP, then your MSCP controller will be the same as the HD: controller, but with more overhead, since there is more bits to fiddle on the PDP-11 before a new I/O request can start using MSCP. Basically stop and go. Not efficient at all. So it's a question of if the device driver takes advantage of this or not. And this might be something that RT-11 don't do. Oh, and no, disk operations under E11 aren't so fast that no instructions will be executed before the operation completes. However, with disk caching and tricks inside E11, a few operations might appear to go that fast, before reality catches up with you. Disk I/O still takes on the order of milliseconds to complete. Guess how long one PDP-11 instruction in E11 takes? If anything, computer speed have advanced much more that disk speeds, so that even with emulated computers, we now manage to do a *lot* while waiting for disks. And already with the trusty old real hardware, we sat around waiting for disks long times... There are obviously several reasons why this needs to be in the controller. If we go back to the first point I discussed above, about MSCP being more efficient if we queue several operations at once, without having to wait for each operation to complete before queueing the next one, then you must also do queue optimization inside the controller, since obviously you cannot easily synconize and reorder operations inside the device driver once you have queued them to the controller. That would require you to withdraw that I/O request, so that you can insert another and then reinsert the revoked one again for you to get the correct ordering. Now, if you don't want the efficiency of being able to queue new operations immediately, but instead only issue them once the previous one is finished, then you can easily also do queue optimizations in the device driver. However, this all also is related to another aspect of MSCP that I mentioned: bad block replacement. Since the controller does this without the involvement of the driver, you cannot from the software really say which ordering of the I/O requests that are optimal. Bad block replacements mean that block that you might think are adjacent might physically be very far apart on the disk. In short, the software haven't a clue to how the physical layout of the disk looks like, and therefore the software can't really do correct I/O queue optimizations. Another aspect is once again efficiency. By letting the controller do the queue optimizations, you unburden the normal CPU from this task, which otherwise takes quite a few CPU cycles to do. The controller can play with this while it's doing a transfer and is just idling anyway, so even if it is a slower CPU, this will end up being faster. So from several points of view, this is both more efficient, and leads to smaller and nimbler device driver, by not having to implement some issues for efficiency because that is moved to the controller instead. Well, as to your thoughts above, I think I've covered that now. As for explanations why you're observing faster operations with the HD: driver in RT-11, my first suspicion would be that the program don't issue multiple reads/writes to the controller, but instead issues one and waits for it to complete before doing the next one. If the program indees tries to be optimal, then my next guess would be the device driver not issuing several operations to the same controller, leading to the same behaviour. While I admittedly don't know enough about RT-11 to say, and obviously don't know how your program does it, I know that in RSX, the device driver do issue the request immediately if possible, and as such you can have several operations outstanding in parallell. If I were to write a na?ve copy program, I might not care enough to try to get the disks working at full speed, which would lead to the same problem you're observing. However, I know how to write such a program in RSX so that I really would keep the controller busy at all times. But that would involve using asynchronous I/O. Another thing: The MSCP driver in RSX is maybe the most complex driver there is (in competition with the TT: driver). There is a reason for this. MSCP is a complex controller. One interesting thing to note is that RSX device drivers can use I/O queue optimization. There is support in the kernel for drivers to do this. And the MSCP driver do have the code for this, but is turned off by default, since it's mostly useless, for the reasons above. Only if very many packets are queued will the driver I/O queue optimization even begin to be used, and then over just the trailing I/O requests that the controller don't have room for. Johnny