Cluster XL - Old or too-new arriving updates

[kraemer]

Hi CP-Gurus!
I have some questions to the output of cphaprob syncstat command
on an SPLAT R60 HFA3 Cluster XL:

The output on my platform looks like this:

cphaprob syncstat

Sync Statistics (IDs of F&A Peers - 1 ):

Other Member Updates:
Sent retransmission requests................... 256
Avg missing updates per request................ 1
Old or too-new arriving updates................ 78804199
Unsynced missing updates....................... 0
Lost sync connection (num of events)........... 29
Timed out sync connection ..................... 0

Local Updates:
Total generated updates ....................... 7832822
Recv Retransmission requests................... 124
Recv Duplicate Retrans request................. 138

Blocking Events................................ 0
Blocked packets................................ 0
Max length of sending queue.................... 0
Avg length of sending queue.................... 0
Hold Pkts events............................... 10703181
Unhold Pkt events.............................. 10703181
Not held due to no members..................... 13
Max held duration (sync ticks)................. 1
Avg held duration (sync ticks)................. 0

Timers:
Sync tick (ms)................................. 100
CPHA tick (ms)................................. 100

Queues:
Sending queue size............................. 512
Receiving queue size........................... 256

My general question is aboute the value of:
Old or too-new arriving updates................

In the Cluster XL guide is an hint about the value, that says:
"a large value implys connectivity problems"
But I can't find anything until now in our network.

The next tips are: enlarge the reciving queue or contact the Technical Support ...

Are there any experiences on your side with this problems. Can anyone give some reference values for the reciving queue, perhaps in dependency of the traffic going through an Cluster.
(Our cluster is running in pivot mode)

I am thankful for any suggestions or tips..

Regards
Karsten

[seanmac1904]

(obvious one)

have you checked the date/time on both of the cluster members ?
ntp running ?

cheers

Sean

[kraemer]

Hi seanmac1904,
thanks for your tip. But both cluster members have the identical date and time. Additionaly they are adjusted by NTP.

Regards,
Karsten

[mmoret]

Are the two systems physically seperated?
I had to adjust the Timers by 10 (we run a ClusterXL cluster across a WAN)

regards
Martijn

lawrencium(root)# cphaprob syncstat

Sync Statistics (IDs of F&A Peers - 1 ):

Other Member Updates:
Sent retransmission requests................... 0
Avg missing updates per request................ 0
Old or too-new arriving updates................ 0
Unsynced missing updates....................... 0
Lost sync connection (num of events)........... 1
Timed out sync connection ..................... 2

Local Updates:
Total generated updates ....................... 2161345
Recv Retransmission requests................... 92
Recv Duplicate Retrans request................. 1

Blocking Events................................ 0
Blocked packets................................ 0
Max length of sending queue.................... 0
Avg length of sending queue.................... 0
Hold Pkts events............................... 1584
Unhold Pkt events.............................. 1584
Not held due to no members..................... 66
Max held duration (sync ticks)................. 11
Avg held duration (sync ticks)................. 0

Timers:
Sync tick (ms)................................. 100
CPHA tick (ms)................................. 1000

Queues:
Sending queue size............................. 512
Receiving queue size........................... 256

[kraemer]

Hi Martijn,
if the meaning of "physically seperated" is, that the sync is seperated from the rest of the network, the the answer ist yes. We are using two sync-interfaces with crossover cables between the 2 machines.

Can you give me some more background information to your decision to increase the CPHA tick value?

Perhaps I can get some hints in cover of our network environment.

Thank you very much!

Karsten

[perw07]

There is now a description of when this is a non-problem. If you have more than one sync interface, every hit in

Total generated updates

on one system will generate a hit in

Old or too-new arriving updates

on the other system. As long as they "balance", there is no problem.

See also sk34118 with the title Running the cphaprob syncstat command on a cluster member generates unfamiliar output.

/Per Westerlund