Operating System - Tru64 Unix
1832535 Members
7803 Online
110043 Solutions
New Discussion

Re: Tru64 5.1b PK2 fragments dropped (duplicate or out of space)

 
SOLVED
Go to solution
eric verdin_1
Occasional Contributor

Tru64 5.1b PK2 fragments dropped (duplicate or out of space)

netstat -p ip:
347697271 total packets received
7062185 fragments dropped (duplicate or out of space)
2790532 fragments dropped after timeout

We have 1GB network cards (servers and clients: two @ 100MB), in a cluster (MC interconnect), running NFS, with 18 clients all Tru64 5.1A PK4 (server is 5.1B PK2) going through a CISCO 6509 router. The NFS read/write size are at the default of 49k. Changed the protocol to six of the clients to TCP and has seen a reduction in 'fragments dropped' but we are looking for a soultion for UDP, any tuning prams would be great. We have seen no retransmissions on the clients everything has been 'timeouts', from nfsstat -rc (or badcalls).
5 REPLIES 5
Mark Poeschl_2
Honored Contributor

Re: Tru64 5.1b PK2 fragments dropped (duplicate or out of space)

It's not entirely clear from your post what speed/duplex you're actually running at. This sounds like it might be an autonegotiation issue. Some GB NICs support disabling autonegotiation as do some types of 6509 blades. If it's possible in your case I would hard-code the desired speed and duplex settings in both the NIC (using lan_config) and the switch and disable autonegotiation.
eric verdin_1
Occasional Contributor

Re: Tru64 5.1b PK2 fragments dropped (duplicate or out of space)

Okay Thanks going to try this but I thought that in Tru64 you could not set the speed to non-autonegotiation for fibre NICâ s and have the NIC work correctly.
BTW: Servers are ES45
NICâ s are DEGXA-SA
Al Licause
Trusted Contributor

Re: Tru64 5.1b PK2 fragments dropped (duplicate or out of space)

In your initial posting, you mentioned 1GB cards and two at 100Mbps but didn't say whether the 100Mbps were on server or client. You also didn't metion the type of Gigabit card as you did in your response.

However, the DEGXA-SA is a Broadcom device (bcm) which does not respond to attempts to disable autonegotiation for either utp or fiber drivers.

However the issue of flow control is valid and a frequent cause of timeouts and lost packets between nfs server/client pairs. Make sure this is enabled on all GigE switch ports.

RE: V5.1a pk4....that's pretty old. You might want to consider upgrading to v5.1b pk4 or pk5 as there have been many fixes for nfs since v5.1a pk4. Unless you have no support contract, or no prior version support contract, that version would not be supported.

eric verdin_1
Occasional Contributor

Re: Tru64 5.1b PK2 fragments dropped (duplicate or out of space)

Two of the 18 Tru64 (5.1A PK4) clients have the two 100Mbs, the other (16 Tru64 clients) NICâ s are DEGPAâ s. The two servers NICs are the only DEGXA-SA we have.

Question: Should the DEGPA be hard coded to 1000Mbs? Or should we leave these to auto negotiation?

Also our CISCO router is set to â Flow Control Desirableâ only on the server ports, the rest of the ports are turned off (Flow Control Disabled).
Al Licause
Trusted Contributor
Solution

Re: Tru64 5.1b PK2 fragments dropped (duplicate or out of space)

Engineering recommends that any network device running at 1G speeds be set using autonegotiation. So do not set this manually.

As to flow control, if it is available, I'm not sure why you don't use it on any 1G port.