[Spread-users] Tuning Windows XP for Spread

[John Lane Schultz]

Doug Palmer wrote:
> On Wed, 2007-07-11 at 11:01 +1000, Doug Palmer wrote:
> 
>> We've been running 4-5 spread daemons at High priority. However, we keep
>> on seeing the tok_hurry count go up and cases where one spread daemon
>> (apparently because it's the segment leader) suddenly develop a huge
>> number of s_retrans counts, which just keeps on going up. At the same
>> time, the spread deamons start growing in memory size and eventually
>> lock up.
> 
> Further investigation reveals that the run-away s_retrans occurs when I
> send a message of size 1266 bytes. All other messages are <1k. So I
> suspect that something is going wrong in the message fragmentation. 
> 
> By switching around entries in spread.conf I can get the segment leader
> to shift. However, the run-away s_retrans occurs on the system that sent
> the message. So the segment leader idea is wrong.
> 
> When should tok_hurry be sent and by what? At the moment, the count goes
> up on all daemons (from sptmonitor) every 2 seconds (well, 5 every 10
> seconds). I get the impression that this shouldn't be happening.
> 
> What does s_ (or u_) retrans mean? This doesn't seem to be documented
> anywhere.
> 

s_retrans stands for segment retransmission.  This occurs when multiple daemons 
within the same segment are missing the same packet.

u_retrans stands for unicast retranmission.  This occurs when a single daemon is 
missing a packet.

tok_hurry is when a daemon requests the token because it thinks it is lost.

If you are consistently getting tok_hurry's, which do occur by default every two 
seconds, lots of s_retrans and u_retrans then you probably have faulty network 
hardware somewhere in your setup and packets are getting dropped by the network.

I'm not sure if/how this relates to the runaway problem you've noticed with 
pakcets bigger than 1K.

Cheers!

-- 
John Schultz
Spread Concepts LLC
Phn: 443 838 2200
Fax: 301 560 8875