• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Reducing the Minimum Packet Retransmit Delay on MacOS X
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reducing the Minimum Packet Retransmit Delay on MacOS X


  • Subject: Re: Reducing the Minimum Packet Retransmit Delay on MacOS X
  • From: "Peter Sichel" <email@hidden>
  • Date: Thu, 16 Aug 2007 15:57:05 -0400

On 8/16/07, David Garcea wrote:

>Is the minimum packet retransmit delay on Mac OS X really a second? Is there
>any way to lower that?
>
>We have developed an application for MacOS X which sends large amounts of
>data to a custom hardware device over the network. During testing with a
>direct Ethernet connection, we are seeing the Mac drop packets, and it takes
>1.0-1.3 seconds to retransmit.
>
>The documentation, and the Darwin tcp source, suggest that the rexmit
>timeout is calculated as RTT + 4*RTTVAR.  Our RTT is typically
>sub-millisecond, so this would be fine, if the minimum retransmit delay
>wasn't so long.

I'm not familiar with a minimum RTO (RTO = srtt + 4*rttvar), so
perhaps the problem is the rttvar (smoothed mean deviation estimator).
Since you indicate packets are being dropped, this suggests you are
overflowing some input queue which may result in a large value for rttvar.

From your description, it is unclear where packets are being dropped.
Is the Mac dropping send packets, which it then needs to retransmit?
Or is the remote device failing to acknowledge some packets which
the Mac is slow to retransmit?

TCP/IP implements two flow control mechanisms:
(1) The "receive window size" which allows the receiver to limit how
    much data can be in flight.
(2) "Slow start" which prevents a sender from sending a burst of many
    more packets than the number of Acks it has received.

Other features include "Duplicate ack fast retransmit"
that allows a receiver to request a quick retransmission,
and Selective Ack that allows the receiver to indicate the
specific segments it needs retransmitted.

The TCP Info tool in my own IPNetMonitorX might give you a bit
more information as it plots duplicate and retransmit data in
real time (free for 21 days).  A direct Ethernet connection
should rarely if ever drop packets, so it sounds like you may
need some rate limiting or tuning based on other system limits.


- Peter Sichel
  Sustainable Softworks
  www.sustworks.com



 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Reducing the Minimum Packet Retransmit Delay on MacOS X
      • From: David Garcea <email@hidden>
References: 
 >Reducing the Minimum Packet Retransmit Delay on MacOS X (From: David Garcea <email@hidden>)

  • Prev by Date: Reducing the Minimum Packet Retransmit Delay on MacOS X
  • Next by Date: Re: Developing drivers for a USB-based network device. . .?
  • Previous by thread: Reducing the Minimum Packet Retransmit Delay on MacOS X
  • Next by thread: Re: Reducing the Minimum Packet Retransmit Delay on MacOS X
  • Index(es):
    • Date
    • Thread