[Info-vax] Accuweather new contract

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> johnson.eric at gmail.com
> Sent: 29-Mar-15 4:49 PM
> To: info-vax at info-vax.com
> Subject: Re: [New Info-vax] Accuweather new contract
> 
> On Sunday, March 29, 2015 at 11:10:05 AM UTC-4, Kerry Main wrote:
> 
> > Wrt to Multinet, I am wondering if your testing was before the most
> > recent version V5.4 and if it included things like fastpath in the testing:
> 
> This would have been 2010 so probably not. I can't remember if fastpath
> was an option that was available or tested.
> 
> The comparison strategy is actually very simple. Instead of focusing on
> TCP
> and all of its well intended options, I focused on UDP since that enabled a
> simpler baseline.
> 
> My basic mode of comparison was... how long does it take to send a
> single
> 80 byte UDP packet. I measured that by doing that in a tight loop. It was
> pretty
> easy to write a portable version that ran on both Linux and VMS. For
> grins
> I also write a version that used the QIO$ interface. That improved things
> a little
> bit, but Linux still won by a wide margin.
> 
> EJ

Not saying that Linux might be marginally faster, but usually when there Is 
a "wide margin", there is usually something else under pinning the results.

When network results like this are seen, I usually think of the mis-matched
full duplex auto-config issue with older network gear, NIC's and drivers. This 
was quite common a few years back. A number of driver changes were made 
to try and minimize these challenges, but the end result was a half-duplex 
config that saw OpenVMS network performance literally cut in half.

The easy fix was to hard code the speeds via OS SW or the console to match 
the network gear.

I still hear of these issues happening at some sites today e.g. "why does my
OpenVMS FTP xfer take so much longer than may XYZ platform?" This is not
the only possible reason, but is usually one of the first things I ask the local 
resource to check.

Regards,

Kerry Main
Back to the Future IT Inc.
 .. Learning from the past to plan the future

Kerry dot main at backtothefutureit dot com