hall@ziggy.EDU (Lawrence O. Hall) (12/30/89)
We have a couple of questions about Mach, which are probably very basic, but here goes... 1) While using C is there another timer available under Mach which provides microsecond or millisecond accuracy on the Encore Multimax, besides "gettimeofday"? 2) In our use of gettimeofday it seems that calls to it get put into a priority queue of some type and are not necessarily processed in the order made. We see threads which do the same exact thing take radically different run time intervals under gettimeofday. Is it possible the calls are queued in some fashion? 3) Again trying to obtain the time interval of each thread and a parent processor doing the same task, we find that the parent appears to be interrupted (or something) and it takes longer to accomplish the task than do its children. Is this possible? Should the parent not do concurrent work? We would very much appreciate answers or pointers to the answers of these questions. Thank you in advance for any help. --Larry Hall hall@sol.usf.edu Dept. of Computer Science and Engineering University of South Florida Tampa, Fl. 33620
boykin@encore.com (Joseph Boykin) (01/03/90)
In article <1303@ziggy.EDU>, hall@ziggy.EDU (Lawrence O. Hall) writes: > We have a couple of questions about Mach, which are probably very > basic, but here goes... The answers here will depend on which version of Mach you are running. Encore has made three "major" releases: 0.2, 0.4 and 0.5. There have been a few "minor" releases as well (e.g. we're currently shipping 0.5.3). 0.2 is essentially a straight port of Mach from CMU. The BSD portions of the kernel run master/slave so performance is pretty bad. 0.4 and 0.5 both have the filesystem, tty and network subsystems parallelized. Performance for these versions is pretty much comparable to our highly-parallelized commercial Umax operating system. In general, you can give our customer service number a call for questions such as this. Mach is not a fully supported product (although we are looking at how to do that) but it is supported. > 1) While using C is there another timer available under Mach which > provides microsecond or millisecond accuracy on the Encore Multimax, > besides "gettimeofday"? The Multimax has a 32-bit free running counter with micro-second resolution. I forget which release of 0.5 it went into, but since April or so we've added the system call "mapfrcounter()" to gain access to this counter. Syntax is: mapfrcounter(addr, anywhere) vm_offset_t *addr; int anywhere; Typical use is: vm_offset_t *ptr; unsigned long old, new; if(mapfrcounter(&ptr, 1) < 0) { perror("mapfrcounter"); exit(1); } *old = *ptr; /* * Do some work */ *new = *ptr; > 2) In our use of gettimeofday it seems that calls to it get > put into a priority queue of some type and are not necessarily processed > in the order made. We see threads which do the same exact thing take > radically different run time intervals under gettimeofday. > Is it possible the calls are queued in some fashion? To keep things short, scheduling is accomplished by having each processor examine a global run queue of runnable threads. This queue is priority ordered. In the parallelized kernels (0.4 or 0.5) system calls occur in parallel until a lock is taken to protect a shared data structure. There is no ordering implied when the lock is released. In the serial kernel (0.2) system calls were queued on the "master" processor for execution. With an eleveted system load, I could certainly believe that threads may be blocked for a while. > 3) Again trying to obtain the time interval of each thread and a parent > processor doing the same task, we find that the parent appears to be ^^^^^^^^^ process? > interrupted (or something) and it takes longer to accomplish the task than > do its children. Is this possible? Should the parent not do concurrent > work? Again, in the parallel kernel "all threads are created equal". There is no implicit or explicit difference between the parent and child. ---- Joe Boykin Manager, Mach OS Development Encore Computer Corp Treasurer, IEEE Computer Society Internet: boykin@encore.com UUCP: encore!boykin