Itanium OpenVMS 8.1 FTP experiences?

[Robert Young_13]

Anyone else trying the VMS 8.1 eval on Itanium? I'm wondering if others have noticed problems with FTP timing out, and system crashes when trying to mount ISO 9660 CDs?

[Kris Clippeleyr]

Hi Robert,

We're curretnly evaluating V8.1 on a dual CPU rx2600.
Haven't seen the FTP timeout yet, but crashing the system mounting CDs is no problem.
There are also other bugs still adrift.
E.g. a C program calling lib$wait must be compiled /FLOAT=G_FLOAT, otherwise you'll get an ACCVIO.
Also, since the security server can not be started, we have no means of enabling proxies. (Btw, any suggestions on this one?)
Furthermore, Motif is also somewhat buggy (haven't figured out yet what causes some callbacks to ACCVIO - they work fine on Alpha), and you cannot use the symbolic debugger yet (which is a pain).

Hope you enjoy playing with this thing, as we do.

Kris

[Ian Miller.]

for proxies you can create a proxy file on an alpha then copy to the itanium box.

[Kris Clippeleyr]

Ian,

Thanx 4 the tip on proxies. It works.

Kris

[Robert Young_13]

The biggest problem at present is that I can not get "external" files to the Itanium. The 9660 CDs cause a crash, and FTP "times out" either coming from or going to any other system. Once in a blue moon I see the expected reply from an external system on FTP, but then it freezes up and times out again. Telnet connects usually 1 out of 6 attempts when going to VMS ( and once connected stays up just fine), yet telnet to the management port is both fast, repeatable, and highly dependable (so it's not apparently a network issue with peripheral network hardware, etc ).

Does anyone know of a way to create a VMS "formatted" CD? I have seen such a system years ago (it ran on a Sun and was for mass production of CD for customer distributions), but there has to be a simpler way.

[Ian Miller.]

for creation of VMS format CD - see CDRECORD facility added to openvms alpha V7.3-1
(SYS$MANAGER:CDRECORD.COM)

have you checked for ethernet speed problems - the rx2600 is probably doing autoneg and this can lead to problems with some switches.

Have you tried ftp from the ItaniumVMS system to other vms system?

[Robert Young_13]

The latest OpenVMS on another system we have is 7.3. Don't see CDRECORD on it.

Everything on this net is normal 10 Mb ethernet. The MP ethernet port is working just fine, so it is able to determine speeds correctly. Any suggestions on how to set the autonegotiate to a set value for the other 10/100 and 10/100/1000 ports to see if that makes a difference?

Have tried ftp to/from other VMS systems (Alpha w/7.3 & Compaq TCP/IP (formerly UCX), Vax w/7.1 & Multinet) with same results.

[Ian Miller.]

CDRECORD does work on VMS 7.3. You can get it from
http://h71000.www7.hp.com/freeware/freeware60/cdrecord/

[Robert Young_13]

Tried directly connecting the Itanium to a laptop that came with a 10/100 internal network connection. A ping test from laptop to Itanium has a 75-50% loss. Can get connected using FTP with laptop as client ( at least it asks and accepts username/pwd now), but any attempt to transfer files lead to a timeout.

Thoughts??

I will look into the CDRECORD.

[Alex Daniels]

I have over the past few days FTP'ed off from the Itanium (rx2600) to an Alpha around 200GB.

Once FTP did not connect, gave some kind of error message, I don't have to hand, but I immediatly repeated the command and it connected fine.

Which ethernet port are you using?? Both the one marked 10/100 AND the one marked 1000 GB, are capable of doing 10/100. So why not try switching to the other one, reconfiguring your IP address to the other interface and see if that gives any differering results.

Alex

[Robert Young_13]

No change. I can "direct connect" between a laptop (client) and the rx2600(server) w/ nothing else on the network but them, and try telnet and ftp. Telnet usually goes through. FTP may get as far as taking a username/password (and it does authenticate because I gave it some bogus usernames), but then it simply times out.

[Alex Daniels]

What does 'mc lancp sh dev/coun' give you? Is this showing errors on the lan devices?

Can you try connecting the laptop to the Itanium via a crossover cable? It would rule out the switch then..

Alex

[Willem Grooters]

Robert,
CDRECORD requires a CD-writer on your VMS box, and AFAIK there is a limit number of drives that are supported.
I did start a tread on CD recoding on VMS: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=611786, you may find some answers there.

To Engineering: Will the LD-verb and all HELP be included in a 7.3-x patch, please.

Willem

[Robert Young_13]

Here are the results of the mcr lancp command:
Device Counters EIA0:
Value Counter
----- -------
240945 Seconds since last zeroed
5067 Bytes received
292 Bytes sent
54 Packets received
6 Packets sent
4875 Multicast bytes received
168 Multicast bytes sent
51 Multicast packets received
4 Multicast packets sent
0 Unrecognized unicast destination packets
23 Unrecognized multicast destination packets
0 Unavailable station buffers
0 Unavailable user buffers
0 Alignment errors
0 Frame check errors
0 Frame size errors
0 Frame status errors
0 Frame length errors
0 Frame too long errors
0 Data overruns
0 Send data length errors
0 Receive data length errors
0 Transmit underrun errors
0 Transmit failures
0 Carrier check failures
0 Station failures
0 Initially deferred packets sent
0 Single collision packets sent
0 Multiple collision packets sent
0 Excessive collisions
0 Late collisions
0 Collision detect check failures




Device Counters EWA0:
Value Counter
----- -------
240945 Seconds since last zeroed
3004070 Bytes received
764681 Bytes sent
39681 Packets received
7408 Packets sent
1920078 Multicast bytes received
126574 Multicast bytes sent
26552 Multicast packets received
827 Multicast packets sent
0 Unrecognized unicast destination packets
13288 Unrecognized multicast destination packets
0 Unavailable station buffers
0 Unavailable user buffers
0 Alignment errors
0 Frame check errors
0 Frame size errors
0 Frame status errors
0 Frame length errors
0 Frame too long errors
0 Data overruns
0 Send data length errors
0 Receive data length errors
0 Transmit underrun errors
0 Transmit failures
4 Carrier check failures
0 Station failures
4 Initially deferred packets sent
1 Single collision packets sent
1 Multiple collision packets sent
0 Excessive collisions
0 Late collisions
0 Collision detect check failures

I doubt that it is the switch since telnet is generally successful in getting through. If it were the switch, wouldn't all TCP/IP be equally affected? A few of these errors (like carrier check) are me plugging/unplugging cables.

If the laptop and rx2600 are directly connected, it gets "farther"...at leat I get a request for username/pwd . But the actual file transfer attempts still timeout.

[Alex Daniels]

As you said a ping test is giving you a 75% packet loss, I am guessing that telnet would be equally effected.

As in effect the problem is replicating (or at least you have problems) with both FTP and PING (ICMP) it suggests the problem is probably not due to FTP confiuration or bug.

Which is why it would be nice to rule out the switch, by using a crossover cable.

[Alex Daniels]

Also try 'mc lancp sh dev eia0/char' or obviously ewa0, if thats the one you are now using.

For the line speed is it set to 10?? And if you keep repeating the command does it flip between 10 and 100??

I have just tried a few :

LANCP> set dev eia0/speed=100
LANCP> set dev eia0/speed=10

With my port set to auto-negoitate on the switch, as expected during the change I get packet loss.

You may be experiencing the same, if your switch port isn't auto-negotiating correctly, this could explain the packet loss on ping.

Alex

[Robert Young_13]

Well I tried a cross over cable between 2 systems directly, and got the same FTP problems. Telnet works, and ping works now 100% of the time.

FTP still times out or only gets as far as username/pwd. Anything one attempts ( a dir listing, etc) after the pwd is accepted ( on those times when it gets that far) times out.

I switched it between the (2) ethernet ports on the rx2600 with the same results.

I also tried a client cpu that has a 10/100 interface. The speeds automatically switched as expected on the rx2600 between 10 and 100Mb as expected depending on the settings so auto-negotiation seems to be working.

I also tried FTP clients from Windows and a Vax running Multinet. No difference in behavior. I also tried going to the Multinet server from the rx2600, with no improvement.

Is there something to the FTP setup on VMS 8.1 that I have missed that anyone can think of that might cause this type of behavior?

[Robert Young_13]

Odd pings....

Ping shows odd behavior. Going to Itanium from Mac/X looses every other packet (based on icmp_seq). Pinging Vax ( also ran it against Alpha with same results) on same network ( same switches, etc) works fine. Thoughts?

[ROBERT-YOUNGS-C:~] robertyo% ping 208.246.88.73 {Itanium}
PING 208.246.88.73 (208.246.88.73): 56 data bytes
64 bytes from 208.246.88.73: icmp_seq=0 ttl=64 time=0.53 ms
64 bytes from 208.246.88.73: icmp_seq=2 ttl=64 time=0.469 ms
64 bytes from 208.246.88.73: icmp_seq=4 ttl=64 time=0.467 ms
64 bytes from 208.246.88.73: icmp_seq=6 ttl=64 time=0.474 ms
64 bytes from 208.246.88.73: icmp_seq=8 ttl=64 time=0.463 ms
64 bytes from 208.246.88.73: icmp_seq=10 ttl=64 time=0.479 ms
64 bytes from 208.246.88.73: icmp_seq=12 ttl=64 time=0.479 ms
64 bytes from 208.246.88.73: icmp_seq=14 ttl=64 time=0.463 ms
64 bytes from 208.246.88.73: icmp_seq=16 ttl=64 time=0.468 ms
64 bytes from 208.246.88.73: icmp_seq=18 ttl=64 time=0.485 ms
64 bytes from 208.246.88.73: icmp_seq=20 ttl=64 time=0.47 ms
64 bytes from 208.246.88.73: icmp_seq=22 ttl=64 time=0.5 ms
64 bytes from 208.246.88.73: icmp_seq=24 ttl=64 time=0.474 ms
64 bytes from 208.246.88.73: icmp_seq=26 ttl=64 time=0.487 ms
64 bytes from 208.246.88.73: icmp_seq=28 ttl=64 time=0.465 ms
^Y64 bytes from 208.246.88.73: icmp_seq=30 ttl=64 time=0.467 ms
64 bytes from 208.246.88.73: icmp_seq=32 ttl=64 time=0.474 ms
64 bytes from 208.246.88.73: icmp_seq=34 ttl=64 time=0.478 ms
^C
--- 208.246.88.73 ping statistics ---
35 packets transmitted, 18 packets received, 48% packet loss
round-trip min/avg/max = 0.463/0.477/0.53 ms

[ROBERT-YOUNGS-C:~] robertyo% ping 208.246.88.249 {Vax w/ Multinet}
PING 208.246.88.249 (208.246.88.249): 56 data bytes
64 bytes from 208.246.88.249: icmp_seq=0 ttl=255 time=0.9 ms
64 bytes from 208.246.88.249: icmp_seq=1 ttl=255 time=0.67 ms
64 bytes from 208.246.88.249: icmp_seq=2 ttl=255 time=0.64 ms
64 bytes from 208.246.88.249: icmp_seq=3 ttl=255 time=0.646 ms
64 bytes from 208.246.88.249: icmp_seq=4 ttl=255 time=0.633 ms
64 bytes from 208.246.88.249: icmp_seq=5 ttl=255 time=0.636 ms
64 bytes from 208.246.88.249: icmp_seq=6 ttl=255 time=0.649 ms
64 bytes from 208.246.88.249: icmp_seq=7 ttl=255 time=0.682 ms
64 bytes from 208.246.88.249: icmp_seq=8 ttl=255 time=0.637 ms
64 bytes from 208.246.88.249: icmp_seq=9 ttl=255 time=0.644 ms
64 bytes from 208.246.88.249: icmp_seq=10 ttl=255 time=0.643 ms
64 bytes from 208.246.88.249: icmp_seq=11 ttl=255 time=0.654 ms
64 bytes from 208.246.88.249: icmp_seq=12 ttl=255 time=0.637 ms
^C
--- 208.246.88.249 ping statistics ---
13 packets transmitted, 13 packets received, 0% packet loss
round-trip min/avg/max = 0.633/0.667/0.9 ms

[Cass Witkowski]

Please check that the duplex setting at both sides are the same. We have seen interesting behavior when one side was half and the other was full duplex. Use MC LANCP SHOW DEVICE xxxx /CHAR

[Robert Young_13]

Very odd behavior.....I plugged in BOTH the 10/100 and the 10/100/1000 RJ45 ports (giving them different IP numbers). Now I do not loose pings, and FTP appears to work!!!???

I will not look a gift horse in the mouth (it may stop working in 10 min), but does anyone have an idea as to why???

[Ian Miller.]

I hope you are talking to hp about this - you may have found a unintentional feature of VMS on itanium :-)
(iVMS as moved on a long way from V8.1 so it may be newer versions don't have this problem - I've not seen it).

[Robert Young_13]

I've been carrying on simultaneous discussions with someone at HP. They are going to pass the results along.