SCA REPORT very slow on Itanium

[Ian Miller.]

Brian - ensure the cost of this issue (and others) is visible as a cost of not having a HP support contract.

You can report issues informally to HP via email. I have posted a note with a reference to this itrc thread.

[P Muralidhar Kini]

>> Brian - ensure the cost of this issue (and others) is visible as a cost of not
>> having a HP support contract.
Thats a very good point by Ian. The management should know the impact of
various problems faced. Who knows couple more problems like this and they
might change their decision!

Any query that you on OpenVMS, you send mail qeury to OpenVMS.Programs@hp.com.
This way the mail query would get routed to the appropriate VMS Engineering team.

>> You can report issues informally to HP via email.
>> I have posted a note with a reference to this itrc thread.
Looks like Ian has already done that on your behalf.

Regards,
Murali

[Volker Halle]

Brian,


However it made little difference, the SCA$SHARE execption PC is still the most common. For a 5 second trace it accounted for 141432 faults. LIB$GET_VMS was next with a rate of 5366


This exactly demonstrates the problem: the addresses were being symbolized as SDA$SHARE, because they were P0 space addresses and your process context was your SDA process. Once you've set process context to the process running SCA$MAIN, the PC values reported by the FLT trace were correctly being symbolized to be happening in SCA$SHARE !

This is a massive problem in SCA, generating that many alignment faults.

Volker.

[Hoff]

>Thats a very good point by Ian. The management should know the impact of various problems faced.
>Who knows couple more problems like this and they
might change their decision!

Yeah. They might.

What tends to occur when these issues and these technical problems are brought to visibility among customer or ISV management and opened up for more general consideration and discussion usually involves a cost comparison of support with the other available options and other vendors.

One of those other options is a port off of VMS.

I've seen and worked these ports. Sometimes to Windows. Sometimes to Unix or Linux. These customers and these vendors? They're often gone from VMS.

HP certainly has to balance its investments and revenues here. Support has costs. Accepting (and resolving) bug reports can be expensive. Conversely, porting means that the customer is (barring cases where HP-UX is the porting target) gone, and that's expensive both for the customer and for the vendor.

And interestingly, the reverse can also be true. Not accepting bug reports - requiring paid support - has its costs. To the vendor.

A vendor can get blind-sided if unaware of the frequency of a problem, and when the customers don't know about ECOs or don't apply the ECOs. The vendor can be leaving useful information unconsidered, and that's a bad move in any game. The perception that an operating system is unstable or that ECO kits are buggy is difficult to overcome, and rush-fixes for paying (support) customers can be technically challenging and politically expensive. Knowing that SCA is hammering out massive quantities of alignment faults is useful information for a vendor, regardless of its source.

This situation is not fun. But then customer and ISV and vendor management are respectively paid The Big Bucks to make these trade-offs; to schedule and to trade-off and to fund the various and usually-conflicting business requirements; including vendor software support contracts.

[Brian Reiter]

Many thanks for all the replies. To give some hint as to the problem, I repeated the build, once without the SCA reporting and again with.

The build without the SCA reporting completed in 6 minutes 41 seconds (both debug and release builds), the build with SCA reporting completed in 1 hour, 16 minutes and 6 seconds. The build was performed on a RX2660 with 2 CPUS and 4 Gbyte of memory.

Its a large difference which is tricky to
explain away. Thankfully it is only a problem with the builds, the rest of the applications appear not too cause too many alignment faults. In the short to medium term builds will be performed without SCA reporting during the day, if SCA reports are required then the build will be performed overnight.

At least I now have a good trace from ANALYSE/SYS which I will email to HP via the mechanism Murali suggested.

As for the support contract, the management view is that given that the issues tend not to occurr too often and can normally be worked around, hence the contract is not essential. Any savings can then be passed to the customer.

Fortunately we're unlikely to port off of VMS, there are too many years of investment in the systems (millions of pounds and many many years over 2 decades) for our customer to suggest we move off.

Anyway, thanks for all your help


Regards


Brian

[Brian Reiter]

For what its worth, the equivalent non SCA build on the Alpha took 8 minutes to complete, the build with full SCA reports took 30 minutes.

[P Muralidhar Kini]

Hi Brian,

>> The build without the SCA reporting completed in 6 minutes 41 seconds
>> (both debug and release builds), the build with SCA reporting completed
>> in 1 hour, 16 minutes and 6 seconds. The build was performed on a
>> RX2660 with 2 CPUS and 4 Gbyte of memory.
The problem has been narrowed down to the SCA reporting.
In any case the margin is huge.

>> if SCA reports are required then the build will be performed overnight.
right. until the problem is fixed, this would be the workaround that needs to be in place.

>> At least I now have a good trace from ANALYSE/SYS which I will email to HP
>> via the mechanism Murali suggested.
Yes, thats the way forward. Hope the problem gets resolved.

Regards,
Murali