First of all: THANK YOU ALL for your replies! Now I have many
starting points for research and testing - hopefully I will find a
solution.
Paolo,
I've recently faced a similar :-( problem with two Linux box.
Problem arise with network stack, TCP Selective Acknowledgement
Options SACK. High bandwidth links and large packets can emphasize
bad behavior, and completely bocks specific protocols (for me was
SMTP).
Try to turn off it on Solaris side, it's on by default.
Thanks for the hint, I will try and report!
Peter,
> One obvious suggestion would be to turn off delayed ACK on the Mac
OS X box.
>
> sudo sysctl -w net.inet.tcp.delayed_ack=0
> You can do this using UNIX sysctl or my own IPNetTunerX
> (www.sustworks.com) which will give you better visibility into the
> parameters available and the effect of tuning.
>
> I noticed just now on 10.4.8 that the value for delayed Ack is "3"
which
> surprises me. Previously I only noticed it could be "on" (1) or
> "off" (0). This may have some bearing on why Mac OS X is ACKing
so lazily.
I think I tried that, but I'll doublecheck. (Yes, on Panther it's "1"
- I never noticed that!)
> This certainly looks like a delayed_ack issue. I've just never
seen the
> delay become quite so large. Are your two machines directly
attached to
> the same LAN, or is there a router between them? I ask because TCPs
> slow start behavior is different for a host on a non-local network.
They are attached to different subnets, and as you suspect, the
problem only occurs if they are. If I attach the Mac to the same
subnet as the Sun, it just works.
> Notice you can also adjust the maximum ACK delay time
(net.inet.tcp.delacktime). The default is 50ms.
I will tinker with this setting. Question: For which case is this
delay used? I mean, the delay seems to change as needed...so shouln't
there be a range defined, or settings for each "state" of connection?
Justin,
> This is the comment from tcp_input.c (ppc darwin 8.0.7 source),
where DELAY_ACK is defined:
>
> * Indicate whether this ack should be delayed.
> * We can delay the ack if:
> * - delayed acks are enabled (set to 1) and
> * - our last ack wasn't a 0-sized window. We never want to
delay
> * the ack that opens up a 0-sized window.
> * - delayed acks are enabled (set to 2, "more compatible") and
> * - our last ack wasn't a 0-sized window.
> * - if the peer hasn't sent us a TH_PUSH data packet (this
> * solves 3649245)
> * - the peer hasn't sent us a TH_PUSH data packet, if he did,
> * take this as a clue that we
> * need to ACK with no delay. This helps higher level protocols
> * who won't send
> * us more data even if the window is open because their last
> * "segment" hasn't been ACKed
> * - delayed acks are enabled (set to 3, "streaming detection") and
> * - if we receive more than 4 full packets per second on this
> * socket, we're streaming acts as "1".
> * - if we don't meet that criteria, acts like "2". Allowing
faster
> * acking while browsing for example.
I'll tinker with this. I wonder if behaviour will change.
Josh,
> Actually, with 10.4.8, SACK is there and enabled by default.
>
> sysctl net.inet.tcp
>
> You should see:
>
> net.inet.tcp.sack: 1
> net.inet.tcp.sack_maxholes: 128
> net.inet.tcp.sack_globalmaxholes: 65536
> net.inet.tcp.sack_globalholes: 0
Uh. I will try disabling SACK.
-
Heiko
PS: I will try those options in our lab next tuesday (can't do it
earlier) and report.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/email@hidden
