🚀 go-pugleaf

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