| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2423.1 | Firefox to be retired... according to "Sale Update" | FUEL::graham | if ya want home cookin, stay home | Fri Mar 09 1990 17:26 | 10 |
|
>The customer has an application which is used to benchmark various
>workstations against a Firefox: whoever meets the VS3520 performance may
>bid for a large workstation project. The problem we have is that the Firefox
>is quite expensive when compared with some of the competition's stations.
Please get somebody to give your customer a PID on our soon-be-announced
2D/3D RISC workstations. The performance and prices are very competitive.
Kris..
|
| 2423.2 | | STAR::MCLEMAN | Jeff McLeman, VMS Development | Sun Mar 11 1990 19:14 | 4 |
| re: -1
But they don't run VMS, do they.
|
| 2423.3 | VMS is a non-issue here... | SICVAX::GRAHAM | if ya want home cookin, stay home | Sun Mar 11 1990 22:54 | 7 |
|
>But they don't run VMS, do they.
The competition's workstations don't run VMS either ;-)
Do they?
Kris....
|
| 2423.4 | | STAR::MCLEMAN | Jeff McLeman, VMS Development | Mon Mar 12 1990 06:52 | 5 |
| Not to get into a religion war, but, if the customer requires
VMS, it would be a bad situation if you try to shove a
RISC/UNIX platform down his/her throat. But then again, maybe one
would, just for a sale.
|
| 2423.5 | | FLUME::dike | | Mon Mar 12 1990 07:35 | 2 |
| How can they be requiring VMS if companies other than DEC are bidding for it?
Jeff
|
| 2423.6 | Try the 5.4 field test kit | STAR::BMATTHEWS | | Mon Mar 12 1990 08:29 | 7 |
| If there application currently runs on VMS then bidding a VMS system that
meets their performance goals should be a strong bid. I would suggest that
you try the VMS 5.4 field test software. Is the customer using width-0 dashed
lines in the benchmark? VMS 5.3-1 went out using the machine independent code
for thin dashed lines and that code doesn't perform well and uses lots of
virtual memory.
Bill
|
| 2423.7 | | STAR::MCLEMAN | Jeff McLeman, VMS Development | Mon Mar 12 1990 08:35 | 11 |
| re; -2
Jeff,
From what i read of the base note, this person was currently running a
VMS application on the 3520. He then tried the VS3100/SPX to see
what the performance difference was. The note didn't say he was trying
to bid against the competition. He was trying to find a less
expensive VMS solution.
Jeff
|
| 2423.8 | | FLUME::dike | | Mon Mar 12 1990 12:51 | 4 |
| True, but the reason they are concerned about the performance of a VMS
application is because competitors workstations outperform it, which implies
that the customer is not wedded to VMS.
Jeff
|
| 2423.9 | Are we reading the same note? | FUEL::graham | The harder they come.. | Mon Mar 12 1990 13:24 | 17 |
| RE: .7
>..The note didn't say he was trying to *bid* against the competition .
The following is what the base noter said.
> The customer has an application which is used to benchmark *various
> workstations* against a Firefox: *whoever* meets the VS3520 performance
> may *bid* for a large workstation project.
> The *problem* we have is that the Firefox is quite *expensive* when compared
> with some of the *competition's stations*.
NB: The asterisks are my own additions to highlight the key words in the
the base note. It is interesting to see the word *bid* in notes .0
and .7.
Kris..
|
| 2423.10 | | STAR::MCLEMAN | Jeff McLeman, VMS Development | Mon Mar 12 1990 13:33 | 2 |
| If you also note, the call he uses to keep track of the timer
is LIB$TIMER, which is a VMS call.
|
| 2423.11 | Maybe it is the SPX that is the bottleneck in this case | DECWIN::FISHER | Prune Juice: A Warrior's Drink! | Mon Mar 12 1990 17:34 | 13 |
| Let's quite OS-bashing and try to help the guy, if possible.
For example, might it be the case that the program is highly graphics
intensive? If so, it could be the SPX that is the bottleneck. If the hardware
and the software do some work in parallel (as they should with any pipelining)
then increasing the cpu speed will only increase the amount of time that the
SPX is busy and the CPU is not.
Does this make sense? In that case you want to try to switch graphics operations
to those which the SPX can do best. Someone else will have to help you with
that, although Bill Matthews had some ideas earlier.
Burns
|
| 2423.12 | No religion here... | FUEL::graham | The harder they come.. | Mon Mar 12 1990 19:34 | 12 |
|
>Let's quite OS-bashing and try to help the guy, if possible.
Agreed....so let's have an OPEN mind. Let him try the most
effective Digital solution. Meaning, he should weigh the choice
of a VS3100 and the next Digital 2D/3D RISC machine. Provide
the best solution to ward off the competition. Seed units of our
R3000-based workstations can be odered now. I suggest signing up
your customer. I have seen the performance of these babies - They
are very serious price/performance graphics contenders.
Kris..
|
| 2423.13 | Some background... | TAV02::CORFAS | Israel-never a dull moment | Tue Mar 13 1990 03:00 | 53 |
|
Well,
I'm really moved by the amount of replies this note has
generated; I realize that in addition to my current (and poignant) problem,
many issues of more general nature (VMS vs. UNIX, etc.) have been raised,
perhaps due to an inadequate wording of my base note. I'll try to enter
into more detail, in order to clarify some points and avoid having you
people guess what I really *meant* to say:
The customer developed the application on a VS3520 with VMS. They
used VAX ADA and X calls (not even the DECWindows Toolkit, which at the
time they started had not been adopted by OSF), in order to stay portable.
When the time came to ask for proposals, several companies (HP,SG)
brought their workstations, and measured their performance with tools
"similar" to VMS's LIB$SHOW_TIMER. None of them could perform as well as
the Firefox, so they were eliminated. We then came and offered the VS3520,
but it had two major shortcomings: price, and the fact that is going to be
soon retired. In addition, the customer discovered what seems to be a bug
in the Firefox implementation of the DECWindows server (dashed lines do not
appear, see note #2422). The VS3100/SPX model 38 that we offered does not
comply, as explained in the base note, with the performance requirements.
The Firefox does not perform some of the required functions (namely, dashed
lines), in addition to its other mentioned problems. So now the customer says:
"You've won the bid, and you have nothing to offer which will meet the
requirements."
There are three ways we can go from here (in descending order of preference):
1. Find the reason for the performance glitch in the VS3100, supply
the first 15 (out of a couple of hundreds) of stations, and be
happy for (ever?) after...
2. Solve the dashed-lines problem in the Firefox, and supply 11 ($)
stations, straining a bit our credibility and prestige with the
customer when they discover they've bought a soon-to-be-retired
station.
3. Port to a DECStation, and start a new round of testing (now against
new players such as IBM's RS6000, HP's new stations, etc.) Note:
don't be misled by availabality dates regarding IBM's new H/W; this
customer has already gear that IBM plans to announce in 10 months
time, and their premises are full of seed units of our equipment too.
Thanks again for all the feedback, and I still hope that someone
may come up with some insight on the performance problem (namely, what can be
done to improve the server's performance).
Avi
|
| 2423.14 | need more info | TOOLEY::B_WACKER | | Tue Mar 13 1990 10:14 | 12 |
| You might start by characterizing the application. How much graphics,
how many planes used? How are pixmaps used and what are their sizes?
Is there a lot of get/put image calls?
Lib$init_timer is only going to give you the client side and 1 second
is too little to draw any conclusions from. Are you sure image
activation and initial paging has been eliminated?
For some sanity check background is the firefox hardware inherently
faster than GPX/dragon, how about SPX? Given ages, I'd guess that SPX
should be faster than firefox, but someone with hardware knowledge
needs to give us some help to bound our guessing in reality.
|