ARSC T3D Users' Newsletter 11, November 7, 1994

List of Differences Between T3D and Y-MP

The current list of differences between the T3D and the Y-MP is:

  1. Data type sizes are not the same (Newsletter #5)
  2. Uninitialized variables are different (Newsletter #6)
  3. The effect of the -a static compiler switch (Newsletter #7)
  4. There is no GETENV on the T3D (Newsletter #8)
  5. Missing routine SMACH on T3D (Newsletter #9)
  6. Different Arithmetics (Newsletter #9)
  7. Different clock granularities for gettimeofday (Newsletter #11)
I encourage users to e-mail in differences that they have found, so we all can benefit from each other's experience.

Upcoming upgrade on ARSC T3D software

ARSC will be upgrading the T3D software to CrayLib_M 1.1.1.2, MAX 1.1.0.4 and SCC_M 4.0.2.20 on December 4th.

We are asking users to submit their codes to be part of our regression test suite. We are looking for relatively small, short running, self contained programs in source form. The advantage of submitting your code is that it will be one of the first programs run on a new T3D release and so if it doesn't work we wouldn't install the new T3D software. Otherwise your program may fail after the new T3D software has become the default.

What Exact Versions Are We Running Now? ...

Users may use the "what" command to find out exactly what exact version is in /mpp/lib. For example here is the output from: what /mpp/lib/libsma.a

  /mpp/lib/libsma.a:
  libsma_version          1.1.0.0 06/08/94 09:39:24
  libsma/and_int.c        11.2    04/20/94 13:13:50
  libsma/barrier.c        11.1    02/17/94 09:37:18
  libsma/cache_mgmt.s     11.1    02/22/94 10:08:05
  libsma/clear_event.c    11.0    02/11/94 14:18:02
  libsma/clear_lock.c     11.0    02/11/94 14:18:02
  libsma/critical.c       11.0    02/11/94 14:18:02
  libsma/end_critical.c   11.0    02/11/94 14:18:02
  libsma/max_dbl.c        11.2    04/20/94 13:13:50
  libsma/max_int.c        11.2    04/20/94 13:13:50
  libsma/min_dbl.c        11.2    04/20/94 13:13:50
  libsma/min_int.c        11.2    04/20/94 13:13:50
  libsma/or_int.c         11.2    04/20/94 13:13:50
  libsma/prod_dbl.c       11.2    04/20/94 13:13:50
  libsma/prod_int.c       11.2    04/20/94 13:13:50
  libsma/set_barrier.c    11.1    02/17/94 09:37:18
  libsma/set_event.c      11.1    02/24/94 09:21:47
  libsma/set_lock.c       11.1    02/22/94 10:08:05
  libsma/SHMEM_BAR.c      11.1    02/22/94 10:08:05
  libsma/shmem_bar.s      11.3    04/05/94 09:21:26
  libsma/shmem_col.c      11.1    04/05/94 09:21:26
  libsma/shmem_fcol.c     11.1    04/05/94 09:21:26
  libsma/shmem_iget.s     11.3    04/26/94 16:35:21
  libsma/shmem_iput.s     11.1    03/28/94 16:34:40
  libsma/shmem_ixget.s    11.1    04/05/94 09:21:26
  libsma/shmem_ixput.s    11.1    04/05/94 09:21:26
  libsma/shmem_lbcast.c   11.7    06/06/94 10:37:35
  libsma/shmem_sbcast.s   11.2    04/05/94 09:21:26
  libsma/shmem_wait.s     11.1    02/22/94 10:08:05
  libsma/shmemcpy.s       11.1    03/01/94 15:32:19
  libsma/shmemget.s       11.1    03/22/94 10:43:49
  libsma/shmemput.s       11.1    03/22/94 10:43:49
  libsma/sum_dbl.c        11.2    04/20/94 13:13:50
  libsma/sum_int.c        11.2    04/20/94 13:13:50
  libsma/sync_utils.c     11.0    02/11/94 14:18:02
  libsma/syncinit.c       11.3    05/12/94 13:51:02
  libsma/test_barrier.c   11.1    02/17/94 09:37:18
  libsma/test_event.c     11.0    02/11/94 14:18:02
  libsma/test_lock.c      11.1    02/17/94 09:41:06
  libsma/wait_barrier.c   11.1    02/17/94 09:37:18
  libsma/wait_event.c     11.1    02/22/94 10:08:05

PE Limits

At ARSC, most production runs can be handled by the 32 PE NQS queue. The use of large partitions of 64 or 128 PEs seems restricted to research problems of the "what if..." type. Basically, development is done on smaller partitions and then to complete a table of performance or problem sizes the larger partitions are used.

We have been accommodating this situation by individually changing a user's interactive permissions with the understanding that users would share their results with us. We are in the process of notifying users of a change in this policy. In the future we will reset everyone back to the default settings and then make it easy for users to request changes that will be in affect for a fixed length of time (perhaps a week per request).

Each user can display their own current T3D limits using the udbsee command:


  udbsee 
 egrep -e"jmpp
jpe"
  jpelimit[b]     :32:
  jmpptime[b]     :86400:
  jpelimit[i]     :8:
  jmpptime[i]     :3600:
the time limits are given in seconds.

The Clock Granularity of gettimeofday

In the T3D class given at UAF this past week, many interesting coding examples were brought up by the exercises. In one exercise, we measured the speed of PVM messages on the T3D. As a prelude to doing the timings, we measured the granularity of the function common to most UNIX systems, gettimeofday. For any timing instrument, its granularity is the time between changes in its display. The program we used was posted on the net a couple of years ago:

  /* clockgran.c
  *
  *  Demonstrate the granularity of the clock by sampling it
  *  as fast as we can and saving the deltas.
  *
  *  10 Dec 1991  Manchek
  */
  
  #include <stdio.h>
  #include <time.h>
  #include <sys/time.h>
  
  main()
  {
    struct timeval t1, t2;
    int del[200];
    int i;

    gettimeofday(&t1, (struct timezone*)0);
    for (i = 0; i < 200; i++)
    {
      do gettimeofday(&t2, (struct timezone*)0);
      while (t2.tv_sec == t1.tv_sec && t2.tv_usec == t1.tv_usec);
      del[i] = (t2.tv_sec - t1.tv_sec)*1000000 + t2.tv_usec - t1.tv_usec;
      t1 = t2;
    }
    for (i = 0; i < 200; i++) printf("%8d", del[i]);
    puts("");
    exit(0);
  }
The program repeatedly calls the function until it receives a change from the previous call. Then the difference of the two calls is saved for output after recording 200 such ticks of the clock.

On denali, the granularity from this program is consistently 31 or 32 microseconds. On the T3D, the granularity is about 2500 microseconds with a good deal of variability. It makes a tremendous difference in the measured speeds of PVM messages on the T3D. When measuring quick events on the T3D the poor granularity of of the timer can make the machine look slower than it actually is.

Next week I'll describe a replacement for gettimeofday on the T3D and describe some of the PVM timings.


Current Editors:
Ed Kornkven ARSC HPC Specialist ph: 907-450-8669
Kate Hedstrom ARSC Oceanographic Specialist ph: 907-450-8678
Arctic Region Supercomputing Center
University of Alaska Fairbanks
PO Box 756020
Fairbanks AK 99775-6020
E-mail Subscriptions: Archives:
    Back issues of the ASCII e-mail edition of the ARSC T3D/T3E/HPC Users' Newsletter are available by request. Please contact the editors.
Back to Top