The system setup is shown below. The HP/UX system is a C200, running Objectivity v5.0. The data disk is a narrow SCSI device, rated at ~8 MBytes/sec. The ATM is on dedicated fibre (no other users), running at 155 Mbits/sec.
Note that the initial rate obtained of ~12 MBytes/sec on both the ATM and the disk was confirmed by the ftp utility, which reported 11.5 MBytes/sec for the second file transferred.
Why this exceeds the nominal maximum rate for the SCSI disk is not understood.
The oscillation in rates at the start of the transfers is not understood.
Comment by Hugh Matlock: "It seems to me that the anomaly could be explained if the measurement system was not reporting results quickly enough. The disk IO and ATM counts could be accurate (as verified with FTP) but not available immediately to the "du -ks" or "atmmgr" utilities. Imagine, for example, that a low priority O.S. software process was used to copy and empty interrupt-level event counters. If this process was scheduled on a 1 or 2 second interval, then the counts available to the utilites would show pronounced spikes. Hope this helps..... "
The value of 47 for the cell size is confirmed for this payload by measuring the cell count for the ftp of a file of known size in bytes.
This is not understood
It is not understood what the excess traffic consists of.
The cause of this is not understood. Perhaps either the AMS or LockServer ... requires further tests.
Other graphs are available for 2 clients, 4 clients, 8 clients.
If you have comments on, or insights into, the above, please send me email.