I have 2 systems in a remote location, 1 an alpha 1000a with VMS 7.1
and a DE500 nic card.  The 2nd system is an rx3600 with an i8254x
running VMS 8.3

I can set host between them using either TCP or CTERM or LAT and it
works OK  but..... when I try to copy files from the alpha to the
RX3600  they take a very long time no matter what way I try, FTP or
DECNET (IV)

what if anything can I tweak on VMS to make this work faster?

Hank wrote:
> I have 2 systems in a remote location, 1 an alpha 1000a with VMS 7.1
> and a DE500 nic card.  The 2nd system is an rx3600 with an i8254x
> running VMS 8.3

   And how slow is the network connection between them?

> I can set host between them using either TCP or CTERM or LAT and it
> works OK  but..... when I try to copy files from the alpha to the
> RX3600  they take a very long time no matter what way I try, FTP or
> DECNET (IV)

   Define "very long time", and/or reveal the size of the
"files" you're trying to copy.

> what if anything can I tweak on VMS to make this work faster?

   If the network is slower than the CPUs, then data
compression could help.

      http://www.info-zip.org/

On Apr 22, 7:53=A0am, Hank <hvand...@comcast.net> wrote:
> I have 2 systems in a remote location, 1 an alpha 1000a with VMS 7.1
> and a DE500 nic card. =A0The 2nd system is an rx3600 with an i8254x
> running VMS 8.3
>
> I can set host between them using either TCP or CTERM or LAT and it
> works OK =A0but..... when I try to copy files from the alpha to the
> RX3600 =A0they take a very long time no matter what way I try, FTP or
> DECNET (IV)
>
> what if anything can I tweak on VMS to make this work faster?

Hank,

I would recommend checking the network error counts on both nodes.

There are a variety of network related-problems that can cause
problems of this description. One of the most common is a duplex
mismatch (full/half) between the switches and the systems. The problem
shows up as collisions and timeouts.

Along the same lines, check the duplex settings on both systems and
the switch ports that they are connected to.

It is common for terminal traffic to not cause these problems, since
it is relatively low usage.

- Bob Gezelter, http://www.rlgsc.com

On Apr 22, 9:36=A0am, Bob Gezelter <gezel...@rlgsc.com> wrote:
> On Apr 22, 7:53=A0am, Hank <hvand...@comcast.net> wrote:
>
> > I have 2 systems in a remote location, 1 an alpha 1000a with VMS 7.1
> > and a DE500 nic card. =A0The 2nd system is an rx3600 with an i8254x
> > running VMS 8.3
>
> > I can set host between them using either TCP or CTERM or LAT and it
> > works OK =A0but..... when I try to copy files from the alpha to the
> > RX3600 =A0they take a very long time no matter what way I try, FTP or
> > DECNET (IV)
>
> > what if anything can I tweak on VMS to make this work faster?
>
> Hank,
>
> I would recommend checking the network error counts on both nodes.
>
> There are a variety of network related-problems that can cause
> problems of this description. One of the most common is a duplex
> mismatch (full/half) between the switches and the systems. The problem
> shows up as collisions and timeouts.
>
> Along the same lines, check the duplex settings on both systems and
> the switch ports that they are connected to.
>
> It is common for terminal traffic to not cause these problems, since
> it is relatively low usage.
>
> - Bob Gezelter,http://www.rlgsc.com

Bob,
I did  show error on both system and neither one shows any errors
I don't know of anyway to check the duplex settings on the card via
VMS so I will have to get there and check them out
I will have to check the switches and see what the ports are set to
but I think they are the "non-settable" ones

thanks for the ideas

Hank

On Apr 22, 9:34=A0am, Steven Schweda <sms.antin...@gmail.com> wrote:
> Hank wrote:
> > I have 2 systems in a remote location, 1 an alpha 1000a with VMS 7.1
> > and a DE500 nic card. =A0The 2nd system is an rx3600 with an i8254x
> > running VMS 8.3
>
> =A0 =A0And how slow is the network connection between them?
>
> > I can set host between them using either TCP or CTERM or LAT and it
> > works OK =A0but..... when I try to copy files from the alpha to the
> > RX3600 =A0they take a very long time no matter what way I try, FTP or
> > DECNET (IV)
>
> =A0 =A0Define "very long time", and/or reveal the size of the
> "files" you're trying to copy.
>
> > what if anything can I tweak on VMS to make this work faster?
>
> =A0 =A0If the network is slower than the CPUs, then data
> compression could help.
>
> =A0 =A0 =A0http://www.info-zip.org/

I am trying to copy over RMS ISAM files some about 3000 blocks and it
can take 4-5 min. to get them copied
some are bigger ..... 500,000 blocks

Hank

On Apr 22, 11:04=A0am, Hank <hvand...@comcast.net> wrote:
> On Apr 22, 9:36=A0am, Bob Gezelter <gezel...@rlgsc.com> wrote:
>
>
>
> > On Apr 22, 7:53=A0am, Hank <hvand...@comcast.net> wrote:
>
> > > I have 2 systems in a remote location, 1 an alpha 1000a with VMS 7.1
> > > and a DE500 nic card. =A0The 2nd system is an rx3600 with an i8254x
> > > running VMS 8.3
>
> > > I can set host between them using either TCP or CTERM or LAT and it
> > > works OK =A0but..... when I try to copy files from the alpha to the
> > > RX3600 =A0they take a very long time no matter what way I try, FTP or
> > > DECNET (IV)
>
> > > what if anything can I tweak on VMS to make this work faster?
>
> > Hank,
>
> > I would recommend checking the network error counts on both nodes.
>
> > There are a variety of network related-problems that can cause
> > problems of this description. One of the most common is a duplex
> > mismatch (full/half) between the switches and the systems. The problem
> > shows up as collisions and timeouts.
>
> > Along the same lines, check the duplex settings on both systems and
> > the switch ports that they are connected to.
>
> > It is common for terminal traffic to not cause these problems, since
> > it is relatively low usage.
>
> > - Bob Gezelter,http://www.rlgsc.com
>
> Bob,
> I did =A0show error on both system and neither one shows any errors
> I don't know of anyway to check the duplex settings on the card via
> VMS so I will have to get there and check them out
> I will have to check the switches and see what the ports are set to
> but I think they are the "non-settable" ones
>
> thanks for the ideas
>
> Hank

Hank,

LANCP will allow you to see the duplex settings, at least on the 8.3
node.

On the 7.1 system, at the very least, NCP has SHOW CIRCUIT COUNT
commands.

- Bob Gezelter, http://www.rlgsc.com

"Hank" <hvanderw@comcast.net> wrote in message 
news:38d87320-ac10-4314-96f1-0b33fc18b52c@i40g2000yqd.googlegroups.com...

> I did  show error on both system and neither one shows any errors

SHOW ERROR doesn't show network error counters.

MC LANCP SHOW DEV/ {COUNT, PAR, INT} are useful.

MC NCP SHOW KNOWN {CIRC, LINES} on the older system,
if itdoesn't have LANCP.

I would also try a PING test, with a decent size packet size,
say 1000 bytes x 100 packets, see if you have packet loss.
You might have congestion/loss further up the network.

If the network is healthy you can tune the performance a bit.
Worth starting from the ground up though. 

On Apr 22, 11:10=A0am, Bob Gezelter <gezel...@rlgsc.com> wrote:
> On Apr 22, 11:04=A0am, Hank <hvand...@comcast.net> wrote:
>
>
>
> > On Apr 22, 9:36=A0am, Bob Gezelter <gezel...@rlgsc.com> wrote:
>
> > > On Apr 22, 7:53=A0am, Hank <hvand...@comcast.net> wrote:
>
> > > > I have 2 systems in a remote location, 1 an alpha 1000a with VMS 7.=
1
> > > > and a DE500 nic card. =A0The 2nd system is an rx3600 with an i8254x
> > > > running VMS 8.3
>
> > > > I can set host between them using either TCP or CTERM or LAT and it
> > > > works OK =A0but..... when I try to copy files from the alpha to the
> > > > RX3600 =A0they take a very long time no matter what way I try, FTP =
or
> > > > DECNET (IV)
>
> > > > what if anything can I tweak on VMS to make this work faster?
>
> > > Hank,
>
> > > I would recommend checking the network error counts on both nodes.
>
> > > There are a variety of network related-problems that can cause
> > > problems of this description. One of the most common is a duplex
> > > mismatch (full/half) between the switches and the systems. The proble=
m
> > > shows up as collisions and timeouts.
>
> > > Along the same lines, check the duplex settings on both systems and
> > > the switch ports that they are connected to.
>
> > > It is common for terminal traffic to not cause these problems, since
> > > it is relatively low usage.
>
> > > - Bob Gezelter,http://www.rlgsc.com
>
> > Bob,
> > I did =A0show error on both system and neither one shows any errors
> > I don't know of anyway to check the duplex settings on the card via
> > VMS so I will have to get there and check them out
> > I will have to check the switches and see what the ports are set to
> > but I think they are the "non-settable" ones
>
> > thanks for the ideas
>
> > Hank
>
> Hank,
>
> LANCP will allow you to see the duplex settings, at least on the 8.3
> node.
>
> On the 7.1 system, at the very least, NCP has SHOW CIRCUIT COUNT
> commands.
>
> - Bob Gezelter,http://www.rlgsc.com

well I think I found my bottle neck.   The alpha box NIC is running at
10MB
it is a DE500 so it shoudl be able to be set to 100 right?

On 2010-04-22 17:47, Hank wrote:
> On Apr 22, 11:10 am, Bob Gezelter<gezel...@rlgsc.com>  wrote:
>> On Apr 22, 11:04 am, Hank<hvand...@comcast.net>  wrote:
>>
>>
>>
>>> On Apr 22, 9:36 am, Bob Gezelter<gezel...@rlgsc.com>  wrote:
>>
>>>> On Apr 22, 7:53 am, Hank<hvand...@comcast.net>  wrote:
>>
>>>>> I have 2 systems in a remote location, 1 an alpha 1000a with VMS 7.1
>>>>> and a DE500 nic card.  The 2nd system is an rx3600 with an i8254x
>>>>> running VMS 8.3
>>
>>>>> I can set host between them using either TCP or CTERM or LAT and it
>>>>> works OK  but..... when I try to copy files from the alpha to the
>>>>> RX3600  they take a very long time no matter what way I try, FTP or
>>>>> DECNET (IV)
>>
>>>>> what if anything can I tweak on VMS to make this work faster?
>>
>>>> Hank,
>>
>>>> I would recommend checking the network error counts on both nodes.
>>
>>>> There are a variety of network related-problems that can cause
>>>> problems of this description. One of the most common is a duplex
>>>> mismatch (full/half) between the switches and the systems. The problem
>>>> shows up as collisions and timeouts.
>>
>>>> Along the same lines, check the duplex settings on both systems and
>>>> the switch ports that they are connected to.
>>
>>>> It is common for terminal traffic to not cause these problems, since
>>>> it is relatively low usage.
>>
>>>> - Bob Gezelter,http://www.rlgsc.com
>>
>>> Bob,
>>> I did  show error on both system and neither one shows any errors
>>> I don't know of anyway to check the duplex settings on the card via
>>> VMS so I will have to get there and check them out
>>> I will have to check the switches and see what the ports are set to
>>> but I think they are the "non-settable" ones
>>
>>> thanks for the ideas
>>
>>> Hank
>>
>> Hank,
>>
>> LANCP will allow you to see the duplex settings, at least on the 8.3
>> node.
>>
>> On the 7.1 system, at the very least, NCP has SHOW CIRCUIT COUNT
>> commands.
>>
>> - Bob Gezelter,http://www.rlgsc.com
>
> well I think I found my bottle neck.   The alpha box NIC is running at
> 10MB
> it is a DE500 so it shoudl be able to be set to 100 right?

That in itself would not normaly make a copy take "a very long time"
as you said. But if you also have mixed "half duplex" with
"full duplex" (usualy between one of the boxes and the switch
it's connected to) you might see very slow transfers. In particular
FTP will slow down to a crawl if this is miss-configured.

On Apr 22, 12:01=A0pm, Jan-Erik Soderholm <jan-erik.soderh...@telia.com>
wrote:
> On 2010-04-22 17:47, Hank wrote:
>
>
>
> > On Apr 22, 11:10 am, Bob Gezelter<gezel...@rlgsc.com> =A0wrote:
> >> On Apr 22, 11:04 am, Hank<hvand...@comcast.net> =A0wrote:
>
> >>> On Apr 22, 9:36 am, Bob Gezelter<gezel...@rlgsc.com> =A0wrote:
>
> >>>> On Apr 22, 7:53 am, Hank<hvand...@comcast.net> =A0wrote:
>
> >>>>> I have 2 systems in a remote location, 1 an alpha 1000a with VMS 7.=
1
> >>>>> and a DE500 nic card. =A0The 2nd system is an rx3600 with an i8254x
> >>>>> running VMS 8.3
>
> >>>>> I can set host between them using either TCP or CTERM or LAT and it
> >>>>> works OK =A0but..... when I try to copy files from the alpha to the
> >>>>> RX3600 =A0they take a very long time no matter what way I try, FTP =
or
> >>>>> DECNET (IV)
>
> >>>>> what if anything can I tweak on VMS to make this work faster?
>
> >>>> Hank,
>
> >>>> I would recommend checking the network error counts on both nodes.
>
> >>>> There are a variety of network related-problems that can cause
> >>>> problems of this description. One of the most common is a duplex
> >>>> mismatch (full/half) between the switches and the systems. The probl=
em
> >>>> shows up as collisions and timeouts.
>
> >>>> Along the same lines, check the duplex settings on both systems and
> >>>> the switch ports that they are connected to.
>
> >>>> It is common for terminal traffic to not cause these problems, since
> >>>> it is relatively low usage.
>
> >>>> - Bob Gezelter,http://www.rlgsc.com
>
> >>> Bob,
> >>> I did =A0show error on both system and neither one shows any errors
> >>> I don't know of anyway to check the duplex settings on the card via
> >>> VMS so I will have to get there and check them out
> >>> I will have to check the switches and see what the ports are set to
> >>> but I think they are the "non-settable" ones
>
> >>> thanks for the ideas
>
> >>> Hank
>
> >> Hank,
>
> >> LANCP will allow you to see the duplex settings, at least on the 8.3
> >> node.
>
> >> On the 7.1 system, at the very least, NCP has SHOW CIRCUIT COUNT
> >> commands.
>
> >> - Bob Gezelter,http://www.rlgsc.com
>
> > well I think I found my bottle neck. =A0 The alpha box NIC is running a=
t
> > 10MB
> > it is a DE500 so it shoudl be able to be set to 100 right?
>
> That in itself would not normaly make a copy take "a very long time"
> as you said. But if you also have mixed "half duplex" with
> "full duplex" (usualy between one of the boxes and the switch
> it's connected to) you might see very slow transfers. In particular
> FTP will slow down to a crawl if this is miss-configured.

I have someone checking the switches but both boxes at set to full
duplex and neither one is showing errors

On Apr 22, 5:11=A0pm, Hank <hvand...@comcast.net> wrote:
> On Apr 22, 12:01=A0pm, Jan-Erik Soderholm <jan-erik.soderh...@telia.com>
> wrote:
>
>
>
> > On 2010-04-22 17:47, Hank wrote:
>
> > > On Apr 22, 11:10 am, Bob Gezelter<gezel...@rlgsc.com> =A0wrote:
> > >> On Apr 22, 11:04 am, Hank<hvand...@comcast.net> =A0wrote:
>
> > >>> On Apr 22, 9:36 am, Bob Gezelter<gezel...@rlgsc.com> =A0wrote:
>
> > >>>> On Apr 22, 7:53 am, Hank<hvand...@comcast.net> =A0wrote:
>
> > >>>>> I have 2 systems in a remote location, 1 an alpha 1000a with VMS =
7.1
> > >>>>> and a DE500 nic card. =A0The 2nd system is an rx3600 with an i825=
4x
> > >>>>> running VMS 8.3
>
> > >>>>> I can set host between them using either TCP or CTERM or LAT and =
it
> > >>>>> works OK =A0but..... when I try to copy files from the alpha to t=
he
> > >>>>> RX3600 =A0they take a very long time no matter what way I try, FT=
P or
> > >>>>> DECNET (IV)
>
> > >>>>> what if anything can I tweak on VMS to make this work faster?
>
> > >>>> Hank,
>
> > >>>> I would recommend checking the network error counts on both nodes.
>
> > >>>> There are a variety of network related-problems that can cause
> > >>>> problems of this description. One of the most common is a duplex
> > >>>> mismatch (full/half) between the switches and the systems. The pro=
blem
> > >>>> shows up as collisions and timeouts.
>
> > >>>> Along the same lines, check the duplex settings on both systems an=
d
> > >>>> the switch ports that they are connected to.
>
> > >>>> It is common for terminal traffic to not cause these problems, sin=
ce
> > >>>> it is relatively low usage.
>
> > >>>> - Bob Gezelter,http://www.rlgsc.com
>
> > >>> Bob,
> > >>> I did =A0show error on both system and neither one shows any errors
> > >>> I don't know of anyway to check the duplex settings on the card via
> > >>> VMS so I will have to get there and check them out
> > >>> I will have to check the switches and see what the ports are set to
> > >>> but I think they are the "non-settable" ones
>
> > >>> thanks for the ideas
>
> > >>> Hank
>
> > >> Hank,
>
> > >> LANCP will allow you to see the duplex settings, at least on the 8.3
> > >> node.
>
> > >> On the 7.1 system, at the very least, NCP has SHOW CIRCUIT COUNT
> > >> commands.
>
> > >> - Bob Gezelter,http://www.rlgsc.com
>
> > > well I think I found my bottle neck. =A0 The alpha box NIC is running=
 at
> > > 10MB
> > > it is a DE500 so it shoudl be able to be set to 100 right?
>
> > That in itself would not normaly make a copy take "a very long time"
> > as you said. But if you also have mixed "half duplex" with
> > "full duplex" (usualy between one of the boxes and the switch
> > it's connected to) you might see very slow transfers. In particular
> > FTP will slow down to a crawl if this is miss-configured.
>
> I have someone checking the switches but both boxes at set to full
> duplex and neither one is showing errors

Do you know whether it's a DE500-AA or a DE500-AB? I have a vague
recollection of a hiccup with early DE500s (which this might be if
it's in an AlphaServer 1000???) where the speed/duplex detection/
negotiation didn't always work as expected with third party kit, which
led to extremely low throughput because it was spending much of its
time doing negotiation rather than sending/receiving.

Anyone else remember this, and if you do, what the fix might be? Or am
I misremembering?

The DE500 info in the VMS FAQ at http://h71000.www7.hp.com/faq/vmsfaq_024.h=
tml
gives the setup instructions but no mention of any interoperability
issues,

On Apr 22, 8:47=A0am, Hank <hvand...@comcast.net> wrote:
[...]
> well I think I found my bottle neck. =A0 The alpha box NIC is running at
> 10MB
> it is a DE500 so it shoudl be able to be set to 100 right?- Hide quoted t=
ext -

I think most Alphas of that generation had console variables
that set the NIC speed & duplex settings since auto-negotiate
was problematic.

Look for a variable like ewa0_mode and set it to Fast_FD
to get 100-Full.

   -Ken

On 2010-04-22 18:11, Hank wrote:
 >
 > I have someone checking the switches but both boxes at set to full
 > duplex...

*If* (any of) the switches are set to half-duplex, you have a problem.

 > and neither one is showing errors

*What* errors are they not showing ?

Hank wrote:
> On Apr 22, 9:36 am, Bob Gezelter <gezel...@rlgsc.com> wrote:
>> On Apr 22, 7:53 am, Hank <hvand...@comcast.net> wrote:
>>
>>> I have 2 systems in a remote location, 1 an alpha 1000a with VMS 7.1
>>> and a DE500 nic card.  The 2nd system is an rx3600 with an i8254x
>>> running VMS 8.3
>>> I can set host between them using either TCP or CTERM or LAT and it
>>> works OK  but..... when I try to copy files from the alpha to the
>>> RX3600  they take a very long time no matter what way I try, FTP or
>>> DECNET (IV)
>>> what if anything can I tweak on VMS to make this work faster?
>> Hank,
>>
>> I would recommend checking the network error counts on both nodes.
>>
>> There are a variety of network related-problems that can cause
>> problems of this description. One of the most common is a duplex
>> mismatch (full/half) between the switches and the systems. The problem
>> shows up as collisions and timeouts.
>>
>> Along the same lines, check the duplex settings on both systems and
>> the switch ports that they are connected to.
>>
>> It is common for terminal traffic to not cause these problems, since
>> it is relatively low usage.
>>
>> - Bob Gezelter,http://www.rlgsc.com
> 
> Bob,
> I did  show error on both system and neither one shows any errors
> I don't know of anyway to check the duplex settings on the card via
> VMS so I will have to get there and check them out
> I will have to check the switches and see what the ports are set to
> but I think they are the "non-settable" ones
> 
> thanks for the ideas
> 

Be aware that some older hardware (ca. 1998) does not autonegotiate 
properly!  There was an ambiguity in the standard and different vendors 
interpreted it differently.  I think the ambiguity was resolved long ago 
but the old hardware, if not fixed or replaced, can still cause problems.

The crude, but workable, fix is to force 100 Full Duplex on both ends of 
the link.  Just brutalize it.

Hank wrote:
> On Apr 22, 11:10 am, Bob Gezelter <gezel...@rlgsc.com> wrote:
>> On Apr 22, 11:04 am, Hank <hvand...@comcast.net> wrote:
>>
>>
>>
>>> On Apr 22, 9:36 am, Bob Gezelter <gezel...@rlgsc.com> wrote:
>>>> On Apr 22, 7:53 am, Hank <hvand...@comcast.net> wrote:
>>>>> I have 2 systems in a remote location, 1 an alpha 1000a with VMS 7.1
>>>>> and a DE500 nic card.  The 2nd system is an rx3600 with an i8254x
>>>>> running VMS 8.3
>>>>> I can set host between them using either TCP or CTERM or LAT and it
>>>>> works OK  but..... when I try to copy files from the alpha to the
>>>>> RX3600  they take a very long time no matter what way I try, FTP or
>>>>> DECNET (IV)
>>>>> what if anything can I tweak on VMS to make this work faster?
>>>> Hank,
>>>> I would recommend checking the network error counts on both nodes.
>>>> There are a variety of network related-problems that can cause
>>>> problems of this description. One of the most common is a duplex
>>>> mismatch (full/half) between the switches and the systems. The problem
>>>> shows up as collisions and timeouts.
>>>> Along the same lines, check the duplex settings on both systems and
>>>> the switch ports that they are connected to.
>>>> It is common for terminal traffic to not cause these problems, since
>>>> it is relatively low usage.
>>>> - Bob Gezelter,http://www.rlgsc.com
>>> Bob,
>>> I did  show error on both system and neither one shows any errors
>>> I don't know of anyway to check the duplex settings on the card via
>>> VMS so I will have to get there and check them out
>>> I will have to check the switches and see what the ports are set to
>>> but I think they are the "non-settable" ones
>>> thanks for the ideas
>>> Hank
>> Hank,
>>
>> LANCP will allow you to see the duplex settings, at least on the 8.3
>> node.
>>
>> On the 7.1 system, at the very least, NCP has SHOW CIRCUIT COUNT
>> commands.
>>
>> - Bob Gezelter,http://www.rlgsc.com
> 
> well I think I found my bottle neck.   The alpha box NIC is running at
> 10MB
> it is a DE500 so it shoudl be able to be set to 100 right?

Right!  ISTR that some versions of the DE500 had a problem with 
autonegotiation.  Forcing 100/Full Duplex on both ends of the link 
should straighten things out!

On 2010-04-22 22:47, Richard B. Gilbert wrote:
> Hank wrote:
>> On Apr 22, 11:10 am, Bob Gezelter <gezel...@rlgsc.com> wrote:
>>> On Apr 22, 11:04 am, Hank <hvand...@comcast.net> wrote:
>>>
>>>
>>>
>>>> On Apr 22, 9:36 am, Bob Gezelter <gezel...@rlgsc.com> wrote:
>>>>> On Apr 22, 7:53 am, Hank <hvand...@comcast.net> wrote:
>>>>>> I have 2 systems in a remote location, 1 an alpha 1000a with VMS 7.1
>>>>>> and a DE500 nic card. The 2nd system is an rx3600 with an i8254x
>>>>>> running VMS 8.3
>>>>>> I can set host between them using either TCP or CTERM or LAT and it
>>>>>> works OK but..... when I try to copy files from the alpha to the
>>>>>> RX3600 they take a very long time no matter what way I try, FTP or
>>>>>> DECNET (IV)
>>>>>> what if anything can I tweak on VMS to make this work faster?
>>>>> Hank,
>>>>> I would recommend checking the network error counts on both nodes.
>>>>> There are a variety of network related-problems that can cause
>>>>> problems of this description. One of the most common is a duplex
>>>>> mismatch (full/half) between the switches and the systems. The problem
>>>>> shows up as collisions and timeouts.
>>>>> Along the same lines, check the duplex settings on both systems and
>>>>> the switch ports that they are connected to.
>>>>> It is common for terminal traffic to not cause these problems, since
>>>>> it is relatively low usage.
>>>>> - Bob Gezelter,http://www.rlgsc.com
>>>> Bob,
>>>> I did show error on both system and neither one shows any errors
>>>> I don't know of anyway to check the duplex settings on the card via
>>>> VMS so I will have to get there and check them out
>>>> I will have to check the switches and see what the ports are set to
>>>> but I think they are the "non-settable" ones
>>>> thanks for the ideas
>>>> Hank
>>> Hank,
>>>
>>> LANCP will allow you to see the duplex settings, at least on the 8.3
>>> node.
>>>
>>> On the 7.1 system, at the very least, NCP has SHOW CIRCUIT COUNT
>>> commands.
>>>
>>> - Bob Gezelter,http://www.rlgsc.com
>>
>> well I think I found my bottle neck. The alpha box NIC is running at
>> 10MB
>> it is a DE500 so it shoudl be able to be set to 100 right?
>
> Right! ISTR that some versions of the DE500 had a problem with
> autonegotiation. Forcing 100/Full Duplex on both ends of the link should
> straighten things out!

And note that "the link" is *not* the link between the two VMS
systems. There are *two* links, one from each VMS system to their
nearest network switch. The fact that the two VMS systems are
running at different speeds should *not* be the problem here.
There is no such requirement at all.

*Only* setting the DS500 to 100 Mhz will probably just make things
worse (no matter full/half duplex). If one of the boxes is running
10 MHz *now* I'd bet that the switch port it's connected to is also
running 10 MHz, if not, things would had ben much worse right now.

Jan-Erik.

On Apr 22, 2:36=A0pm, Bob Gezelter <gezel...@rlgsc.com> wrote:
> On Apr 22, 7:53=A0am, Hank <hvand...@comcast.net> wrote:
>
> > I have 2 systems in a remote location, 1 an alpha 1000a with VMS 7.1
> > and a DE500 nic card. =A0The 2nd system is an rx3600 with an i8254x
> > running VMS 8.3
>
> > I can set host between them using either TCP or CTERM or LAT and it
> > works OK =A0but..... when I try to copy files from the alpha to the
> > RX3600 =A0they take a very long time no matter what way I try, FTP or
> > DECNET (IV)
>
> > what if anything can I tweak on VMS to make this work faster?
>
> Hank,
>
> I would recommend checking the network error counts on both nodes.
>
> There are a variety of network related-problems that can cause
> problems of this description. One of the most common is a duplex
> mismatch (full/half) between the switches and the systems. The problem
> shows up as collisions and timeouts.
>
> Along the same lines, check the duplex settings on both systems and
> the switch ports that they are connected to.
>
> It is common for terminal traffic to not cause these problems, since
> it is relatively low usage.
>
> - Bob Gezelter,http://www.rlgsc.com

It may be common for much terminal traffic to not show symptoms in a
misconfigured network if using TCP or DECnet, but LAT used to be quite
good at exposing some kinds of flaw (e.g. slow transfers, packet
loss), because of its shorter timeouts and fewer/no retries.

On Apr 22, 2:53=A0pm, Hank <hvand...@comcast.net> wrote:
> I have 2 systems in a remote location, 1 an alpha 1000a with VMS 7.1
> and a DE500 nic card. =A0The 2nd system is an rx3600 with an i8254x
> running VMS 8.3
>
> I can set host between them using either TCP or CTERM or LAT and it
> works OK =A0but..... when I try to copy files from the alpha to the
> RX3600 =A0they take a very long time no matter what way I try, FTP or
> DECNET (IV)
>
> what if anything can I tweak on VMS to make this work faster?

On the Alpha, set the console (srm) parameter ewa0_mode to auto-
negotiate (not auto-sensing!).
No idea whether the IA64 has a similar facility. Check with LANCP what
the NIC thinks it's doing.
Most likely there's a duplex mismatch between switch and NIC.

"H Vlems" <hvlems@freenet.de> wrote in message 
news:31740f5b-2954-46d6-8a1b-a7118fa58e10@12g2000yqi.googlegroups.com...

No idea whether the IA64 has a similar facility. Check with LANCP what
the NIC thinks it's doing.


You only get auto-negotiate on Itanium boxes.

John 

"Richard B. Gilbert" <rgilbert88@comcast.net> wrote in message 
news:kJ-dnfZchMeVKU3WnZ2dnUVZ_tydnZ2d@giganews.com...

> Be aware that some older hardware (ca. 1998) does not autonegotiate properly!  There was 
> an ambiguity in the standard and different vendors interpreted it differently.  I think 
> the ambiguity was resolved long ago

Yes, it was resolved in 802.3-1998

> The crude, but workable, fix is to force 100 Full Duplex on both ends of the link.  Just 
> brutalize it.

What you say is true but my inclination would not be to advise people to
force full duplex, because 90% of the time it's following that advice
incorrectly that has caused the problem. I would rather put the Alpha to
100HD, and not worry about whether the switch is managed or not, and who
the network admin is, where the switch configuration is documented.

This is an old argument though, but the pre-standard hardware just won't die. 

Richard Brodie wrote:
> "Richard B. Gilbert" <rgilbert88@comcast.net> wrote in message 
> news:kJ-dnfZchMeVKU3WnZ2dnUVZ_tydnZ2d@giganews.com...
> 
>> Be aware that some older hardware (ca. 1998) does not autonegotiate properly!  There was 
>> an ambiguity in the standard and different vendors interpreted it differently.  I think 
>> the ambiguity was resolved long ago
> 
> Yes, it was resolved in 802.3-1998
> 
>> The crude, but workable, fix is to force 100 Full Duplex on both ends of the link.  Just 
>> brutalize it.
> 
> What you say is true but my inclination would not be to advise people to
> force full duplex, because 90% of the time it's following that advice
> incorrectly that has caused the problem. I would rather put the Alpha to
> 100HD, and not worry about whether the switch is managed or not, and who
> the network admin is, where the switch configuration is documented.
> 
> This is an old argument though, but the pre-standard hardware just won't die. 
> 
> 

IFF autonegotiation works, it's clearly the way to go.  Sometimes you 
get antique hardware that can't/won't autonegotiate; then  you have to 
brutalize it!

In article <74e9ae2d-ae63-4b1c-9915-5ee8e99d0a87@r27g2000yqn.googlegroups.com>, Hank <hvanderw@comcast.net> writes:

> I am trying to copy over RMS ISAM files some about 3000 blocks and it
> can take 4-5 min. to get them copied
> some are bigger ..... 500,000 blocks

   Have you tried convert/reclaim et. al. to make sure the file isn't
   full of holes?

On Apr 23, 1:14=A0am, "John Reagan" <johnrrea...@earthlink.net> wrote:
> "H Vlems" <hvl...@freenet.de> wrote in message
>
> news:31740f5b-2954-46d6-8a1b-a7118fa58e10@12g2000yqi.googlegroups.com...
>
> No idea whether the IA64 has a similar facility. Check with LANCP what
> the NIC thinks it's doing.
>
> You only get auto-negotiate on Itanium boxes.
>
> John

I haven't seen, let alone used an IA64. Does it have a console
environment similar to srm?
If so can you only set ewa0_mode to auto-negotiate or is fastFD a
possible option too?

On Apr 24, 3:04=A0pm, H Vlems <hvl...@freenet.de> wrote:
> On Apr 23, 1:14=A0am, "John Reagan" <johnrrea...@earthlink.net> wrote:
>
> > "H Vlems" <hvl...@freenet.de> wrote in message
>
> >news:31740f5b-2954-46d6-8a1b-a7118fa58e10@12g2000yqi.googlegroups.com...
>
> > No idea whether the IA64 has a similar facility. Check with LANCP what
> > the NIC thinks it's doing.
>
> > You only get auto-negotiate on Itanium boxes.
>
> > John
>
> I haven't seen, let alone used an IA64. Does it have a console
> environment similar to srm?
> If so can you only set ewa0_mode to auto-negotiate or is fastFD a
> possible option too?

I hope to be on site this weekend  I will post what I have found then
Thanks to all for your suggestions.