🚀 go-pugleaf

Greetings to all of you,

In article <9010091422.AA23544@theory.TN.CORNELL.EDU>, BOHN@VKPMZB.Physik.Uni-Mainz.DE writes:
> 
>         1. Is there an C004-Linkswitch on your Transputerboard ?
>                 If so, the flood-fill-configurer will not work !
>                 He tries to boot a worker-task into the C004 and destroys
>                 the link-connection-programming. In this case, you have to
>                 use the static configurer instead. (If you have more
>                 questions about how to use the static configurer with
>                 master, worker and the frouter, please ask again!)

We are using a QUINTEK Fast4 Transputer board which does not have a link
switch. (If a link switch were to be used, then it should be pre-programmed,
and connection to the config link of the C004 should  be removed
before loading the network). The organisation of the 4 Transputers
is as follows:


	PC <---------> T0 <-----------> T1
                        | \           /  |
                        |   \       /    |
                        |     \   /      |
                        |       X        |     Tx = T800 (20Mhz)
                        |     /   \      |
                        |   /       \    |
                        | /           \  |
	               T3 <-----------> T2

> 
>         2. The other possibility is, that your master-task has to do a
>                 lot of work in comparison with the 4 worker-tasks. That
>                 means, that 2 worker-tasks have done their work faster than
>                 the master for every packet. In this case you cannot reach
>                 a Speed-Up better than approx. 2. You have to check your
>                 application, to displace the main portion of work
>                 to the worker-task (Thats the reason why they have their
>                 name !!!). Have you tried out the 'mandelbrot'-example,
>                 delivered with the 3L-compiler ??? In this example, you
>                 should reach a Speed-Up of approx. 4, if point 1. is not
>                 the problem.
> 

I have made measurements in our application and found that the
problem is CPU bound i.e. more time is spent in the computation
(performed by the slaves) than in communication. Hence I don't
think the farmer process is the bottleneck (unless the processes
are scheduled in some funny way that it does become a bottleneck).
Here are some figures supporting this:

	The following measurements are taken with only one
	Transputer executing out the farmer process:

	Total time to process 200 work packets : 27.0 secs.
	Total time the farmer actually performs useful work : 26.5 secs.

Therefor communication/farmer overheads are relatively low.
This makes sense because the master does nothing but sending work packets
and receiving the results (all I/O to the PC shut off).

Others so far have mentioned some problems with the configurer i.e.
the tasks are not allocated optimally with respect to the network.
I look foreward to any further contribution.

Thanks again.

-dzahar-