SGI Performance Comparisons

Copying a Large File Straight to Disk

Last Change: 08/May/2008

In this test, I timed how long the various systems took to copy the main 179685K (175.5MB) Quake2 pak0.pak data file from the Quake2 CDROM straight to disk. The file was always copied to /var/tmp, and all tests were performed using IRIX 6.5. Data rates are in KBytes/sec. The command sequence used to run the test, which was entered into a raw xterm where the current working directory was /CDROM/install/data/baseq2, was:

   timex cp pak0.pak /var/tmp


Results for Origin200 R10000SC 180MHz (1MB L2):

CDROM     Time     Data
Speed    (m:ss)    Rate

  2X      
 32X      1:15     2396

        Table 40


Results for O2 R5000SC 200MHz (the 12X is the O2's internal CDROM):

CDROM     Time     Data
Speed    (m:ss)    Rate

  2X      5:01      597 
 12X      3:22      890
 32X      2:30     1198

        Table 16


Results for Indigo2 250MHz R4400SC:

CDROM     Time     Data
Speed    (m:ss)    Rate

  2X      4:59      601
 32X      1:34     1912

        Table 17


Results for Indy 200MHz R4400SC:

CDROM     Time     Data
Speed    (m:ss)    Rate

  2X      5:59      501
 32X      2:30     1198

        Table 18


Results for Indy 133MHz R4600PC:

CDROM     Time     Data
Speed    (m:ss)    Rate

  2X      6:47      442
 32X      4:35      653

        Table 19


Results for Indy 100MHz R4600PC:

CDROM     Time     Data
Speed    (m:ss)    Rate

  2X      6:58      430
 32X      4:27      673

        Table 20


As shown in CDROM TEST 1, Tables 19 and 20 prove that a faster CDROM for a system with a slow CPU is barely worth the expense. But far more interesting are the following two observations:

These results are totally different to the figures given in Table 14, which shows significant differences between the CPUs for the various stages of processing, and shows Indigo2 R4400SC/250 to actually be little better or slower than O2 R5000SC/200. So what's going on?

My theory is this: copying a file from a CDROM merely involves getting the data as fast as possible through the main CPU, ie. into the registers, out to the disk (loads and stores). These operations usually only take a single clock cycle. Thus, the design of the CPU won't affect how quickly the data is copied, ie. it's the raw clock speed that matters, assuming the CPU is of the type which does the generic 1 int operation per clock tick. This is why the Indy R4400SC/200 copied the file in exactly the same amount of time as the O2 R5000SC/200 (for the 32X CDROM) - the two CPUs run at the same clock speed. On the other hand, tasks like installing software require the CPU to process the incoming data in some way. How well the CPUs do this depends on their design, so the R5000 performs better. Well, that's my theory anyway.

Tables 21 and 22 show the data from tables 16 to 20 reorganised to show the performance for each CDROM type separately (the 12X results for O2 have been excluded).

                         Time     Data
                        (m:ss)    Rate

Indigo2 250MHz R4400SC:  4:59      601
O2 R5000SC 200MHz 1MB:   5:01      597
Indy 200MHz R4400SC:     5:59      501
Indy 133MHz R4600PC:     6:47      442
Indy 100MHz R4600PC:     6:58      430

   Table 21: 2X CDROM Performance
   Copying a large file to disk.



                         Time     Data
                        (m:ss)    Rate

Indigo2 250MHz R4400SC:  1:34     1912
O2 R5000SC 200MHz 1MB:   2:30     1198
Indy 200MHz R4400SC:     2:30     1198
Indy 133MHz R4600PC:     4:35      653
Indy 100MHz R4600PC:     4:27      673

   Table 22: 32X CDROM Performance
   Copying a large file to disk.