mankin@gateway.mitre.ORG (12/03/87)
Hi, folks, I am working on IP-level performance in 4.3 BSD on a MicrovaxII. The CPU is a 630-Q-A, since we bought the system over 2 years ago. The operating system is pure Berkeley 4.3. My question is about the real-time clock resolution. The hardware manual does not cover the 630, but analogy to the 750 (and a good letter to this list by Chris Torek back in August) got me hoping it would be possible to read times at a resolution of microseconds from the 630's Interval Count Register. I didn't see anything to contradict this in the 4.3 source code. Alas, experiment and our DEC representative have at last revealed that I will never read times of less than 10 milliseconds from this ICR. Now, in the latest Proceedings of the ACM Symposium on Operating Systems Principles (SOSP-11), there are at least two articles where a MicrovaxII was used to do performance timings. Jeff Mogul et al includes figures like 1.77 milliseconds for the kernel to process a received IP packet. Liskov et al give times such as that required for a minimal system call (200 microseconds). (By the way, their articles are very juicy and interesting). Do you get such timings only by doing thousands of identical operations and measuring the aggregate time? I've found out from DEC about a programmable real-time clock for the MicrovaxII, the KWV-11-C. Its cost is quite low, but they do not have a driver for it outside an expensive package called LabStar. Could anyone point me to a UNIX driver, or to the good techniques other than aggregate measurements for using the MicrovaxII for kernel timings? AM <mankin@gateway.mitre.org>
ji@garfield.columbia.edu.UUCP (12/04/87)
Last year I had to do system call timing on a Multibus Sun-2. I got fairly repeatable results using a logic analyzer and a kernel hack. I suppose there should be something similar that you can do for the Microvax. The idea was to use a variant of syscall 0 (the indirect system call) to put something recognizable on the bus, trigger a logic analyzer with it, execute the system call, then put something else on the bus to signal the end and use the l.a. to measure the elapsed time. After some hunting in the kernel sources I found how to turn on and off the eight LEDs on the edge of the Multibus Sun-2 CPU. The LEDs were being driven by a 74LS373 octal latch; I used a 20-pin clip on probe to get the signals to my logic analyzer. I added a system call to the kernel that turned all the LEDs on and off before and after executing the specified system call, set my logic analyzer to trigger on 0xFF and the rest is history. (If anyone is interested, I can post the kernel mods). There are some more horror stories associated with the incident, like rearranging the NMI routine by breaking to the PROM monitor, changing the memory and continuing, but that's another story. The results I got this way, though, were pretty similar with the ones I got with just calling the system calls 1000 times and dividing by 1000, or something to that effect. Good luck with the Microvax, /ji #include <appropriate_disclaimers> VOICE: +1 212 280 5510 INET: ji@garfield.columbia.EDU USnail: John Ioannidis 450 Computer Science USENET: columbia!ji Columbia University, New York, NY 10027 ... It's all Greek to me!
whm@arizona.edu (Bill Mitchell) (12/11/87)
In article <10646@brl-adm.ARPA>, mankin@gateway.mitre.ORG (Allison J. Mankin) writes: > > Hi, folks, > > I am working on IP-level performance in 4.3 BSD on a > MicrovaxII. The CPU is a 630-Q-A, since we bought the system > over 2 years ago. The operating system is pure Berkeley 4.3. > > My question is about the real-time clock resolution. The > hardware manual does not cover the 630, but analogy to the 750 > (and a good letter to this list by Chris Torek back in August) > got me hoping it would be possible to read times at a resolution > of microseconds from the 630's Interval Count Register. > I didn't see anything to contradict this in the 4.3 source code. > Alas, experiment and our DEC representative have at last revealed > that I will never read times of less than 10 milliseconds from this ICR. The VAX Architecture Reference Manual, a hardbound book published by DEC, talks about this. The MicroVAX II is a subset VAX implementation and for a subset VAX implementation, the NICR and ICR may be omitted and the ICCS needs only a working IE bit. When IE is set, an interrupt at IPL 22 is generated every 10ms. It goes on to say that the ICR and NICR on the MVII read as zero and ignore writes (do you get non-zero values from your MVII ICR?). > Now, in the latest Proceedings of the ACM Symposium on Operating > Systems Principles (SOSP-11), there are at least two articles where > a MicrovaxII was used to do performance timings. Jeff Mogul et al > includes figures like 1.77 milliseconds for the kernel to process a > received IP packet. Liskov et al give times such as that required for > a minimal system call (200 microseconds). (By the way, their articles > are very juicy and interesting). Do you get such timings only by doing > thousands of identical operations and measuring the aggregate time? I'd definitely be interested in hearing about how they got the accurate timings on a MVII. It might be the KWV11-C that you mention, but I wonder if there might be something even simpler available somewhere. All that you really need is a board that has a high-resolution real-time clock that can be read in response to a system call -- there must be some 3rd party boards around that can do that. I tried to get some KWV11-C documentation out of DEC, but they say that all that is available is a schematic (for $95). If there's a driver, I'd like to know about it. All the VAX-11 models supposedly have a full-precision (1usec resolution) clock so if you're desperate, maybe you could pick up a 725, 730, or 750 at a bargain price. Bill Mitchell whm@arizona.edu {allegra,cmcl2,ihnp4,noao}!arizona!whm