KVC@engvax.UUCP (09/05/85)
Here's a riddle that perhaps someone could shed some light on... I have a couple'a 785's that used to be 780's. Shortly after the upgrade, one of our NASty-TRAN users complained that our system did not seem any faster than when it was a 780 (or compared to other 780's in the company). Being a busy system manager, the first time he mentioned it, I sort of ignored him. Well, when he came back I made up a simple little benchmark to compare systems and sure enough, our 785 was about 40%-50% faster than the 780. He went away grumbling... Well, just the other day I picked a simple little WHETSTONE benchmark up off the net and gave it a run on our 785 and 780. What'dya know! The damn 785 really ISN'T any faster than our 780. In fact, it seems to be just a tad slower on the average. The first thing I checked was my previous benchmarks. They still run just as fast as before, but turned out to be integer only (of course -- system programmers have no need for real numbers, billing, or databases....). So, it appears that my 785 processes integers about 50% faster than a 780, but real numbers are the same or slower than a 780. The next thing I did was try my benchmarks on every system I could get ahold of. Our other 785, running UNIX, seems to have exactly the same problem as my 785. Every other 785 I tried (about 4 of them) run integers the same as mine, but floating point about 35% faster. Before anyone claims I don't have a floating point accelerator, let me assure you that I do. I can see it, it's right there in the cabinet! In fact, I even found (believe it or not) a 785 without an FPA and it runs floating point REAL slow, about 1/2 the speed of my (slow) 785 or a (normal) 780. The only thing I can think of is that I have the brains of a 785, but the FPA of a 780 in my machine. DEC assures me this is impossible and I would tend to agree with them... Someone from DEC back East is supposed to be calling on Friday... We'll see what he has to say. So far, they keep telling my that my configuration must be the cause, but I KNOW that is a load of bull. I have run my benchmarks on a lot of 780's and 785's with widely varying configurations and work loads, and I ALWAYS get within a few hundredths of a second of the CPU times I expect. In fact, one of my test systems got really wierd results once. The system response time was great, but the benchmarks were SSLLOOWW!! Turned out someone had taken the system disk for one system (a 780) and booted a 750 with it while doing disk r&r's. The system came up on the ethernet as 4CCVAX, with no indication that it was a completely different CPU! I finally decided (based on my benchmark times) that someone had cleverly disguised a 750 as a 780. Sure enough, that was the case... By the way, all the systems I tested were running VMS 4.0 or 4.1 and I used the same .EXE file on them all to avoid possible compiler differences. Also the problem is the same under UNIX. Our 785 UNIX seems to be the same speed at floating point as a 780 UNIX. Anyway, enough of this. Anyone have any clever answers to my riddle? I welcome any and all wild theories. /Kevin Carosso engvax!kvc @ CIT-VAX.ARPA Hughes Aircraft Co.
JARRELLRA%VPIVAX5.BITNET@WISCVM.ARPA ("Ronald A. Jarrell") (09/08/85)
Have you had your 785 fpa checked? The fpa's that went out *don't work*. A number of things aren't fixed yet, and are bascially commented out. I think there are several different fpa's out in the field. We wemt through 4, 2 because they were actually bad, and the other because a newer version was out and we needed it desperatly (the vax was bought only to be a number cruncher...) As a side point, check the microcode file on your boot floppy. If it's a B, contact Field Service and get C. (that will be slow, my FE has been trying to get it for 2 months) B has a bug that causes a VMS system to crash with an insufficient pagedyn message if the right combination of instructions is used. C fixes it. -Ron Jarrell Va Tech JARRELLR%VPIVAX3.BITNET@WISCVM.ARPA