larryd@bmerh140.bnr.ca (Larry Dunkelman) (11/01/90)
After reading a number of postings concerning the performance of the 5810/20 I realized I wasn't alone in wondering why these machines seem to run slower than the supposedly slower 3100. I ran a benchmark to compare the performance of 5810 with a 3100. The 5810 was configured with 256 MB of memory and 6 RA90 drives connected via an HSC. The 3100 had 8 MB of memory and 2 SCSI disks. I tested the "raw" CPU power, (no disk I/O and limited memory access) and found that the 5810 was about 30% faster than the 3100 (as expected since the 5810 uses the faster R3000 processor). I then ran a memory test which involved an enormous amount of memory access (the program built a linked list by scanning the list until the end was reached and then adding the list element - 5000 times!). The results of this last test were very suprising. The 3100 ran the benchmark in 29 seconds. The 5810 took 67 seconds. These times were CPU usage (real time was the same as there was no other system activity). DEC acknowledged the problem with the memory on the 5800 series but said they were not planning on doing anything about it. I gave DEC my program about 4 months ago -- no word since then. I'll save the rest of my experiences with the 5800s (yes, I have two of them -- and have plans to buy two more) and ULTRIX 4.0 for later. Larry.
grr@cbmvax.commodore.com (George Robbins) (11/02/90)
In article <1990Nov1.050433.5615@bmers145.bnr.ca> larryd@bmerh140.bnr.ca (Larry Dunkelman) writes: > After reading a number of postings concerning the performance of the > 5810/20 I realized I wasn't alone in wondering why these machines seem > to run slower than the supposedly slower 3100. ... > I then ran a memory test which involved an enormous amount of memory > access (the program built a linked list by scanning the list until the > end was reached and then adding the list element - 5000 times!). > > The results of this last test were very suprising. The 3100 ran the > benchmark in 29 seconds. The 5810 took 67 seconds. These times were > CPU usage (real time was the same as there was no other system activity). > > DEC acknowledged the problem with the memory on the 5800 series but said > they were not planning on doing anything about it. I gave DEC my program > about 4 months ago -- no word since then. This isn't too surprising, the basic concept seems to be that the CPU board to XMI memory interface is a major bottleneck in the 5810. As long as the cache can effectively handle the system working set, you get the theoretical 1.X times the DS3000. However, once a large percentage of accesses require XMI access, performance decreases drastically. The DS3100 and DS5000 don't really have a "system level Memory Bus" in the sense of the XMI or BI bus, thus the cache<->memory interface can more closely match the needs of the CPU. The DS5400 probably lies somewhere in between. It is interesting to note that the new 128MB memory boards announced for the VAX6500 series introduce a new cache support strategy. It's possible this could convey some benefit to the DS5800 CPU boards, or more likely a second generation "5900" CPU board. DEC could also improve the situation by releasing a new CPU board with both faster MIPS chips, a larger cache and possibly some kind of local memory attachment sub-bus, but it's hard to judge their level of commitment to the DS5800 as a server level product. Releasing a DS5500 product that has a higher performance level than the DS5800 (and is much cheaper) strikes me as an admission that either they are in desperate trouble with DS5800 follow up projects, or have abandoned the platform in favor of something with lower "overhead" that makes it possible to be price competitive with Sun, without blowing the captive VAX/VMS price margins on XMI memory and XMI/BI peripherals... > I'll save the rest of my experiences with the 5800s (yes, I have two of > them -- and have plans to buy two more) and ULTRIX 4.0 for later. Sure, let us know -- I think I've given up on Ultrix 4.0, at least for the 5800 and will wait for the 4.1 tapes to show up and age a bit. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
rosenblg@cmcl2.NYU.EDU (Gary J. Rosenblum) (11/02/90)
I spoke with a few DECies at the Unix Expo in NYC today, and basically the consensus was 'We screwed up'. In fact one highly placed engineer said it in stronger language. I asked him what he would suggest, and he said it might very well be to buy a 5500! Of course, this wasn't the 5800 product manager or anyone on the team, so this ain't the gospel. But it is widely known that (as George said) the CPU-XMI interface is a major bottleneck. Not to mention the SMP scheduler code leaves lots to be desired. They did say that 4.1 will be shipping ASAP, and that might alleviate the performance problem a little. I couldn't get it out of them what the future of the 5800 series would be. That is for marketing, unfortunately. Now, if we can get them to tell the customers that there IS a problem with the 5800s, instead of having to beat them up until they admit it.... gary Gary J. Rosenblum UNIX Systems Manager rosenblg@nyu.edu New York University gary@nyu.edu