> The Apple machine may be rate limiting their transmissions.
> The Apple is sending only 2 packets per round trip time.
I think (acknowledgment number + advertized window) of ACKs sent by
the FreeBSD machine limits how much data the Mac can inject into the
network.
Regards,
Noritoshi Demizu
on Fri, 11 Mar 2005 20:20:02 +0900 (JST), Noritoshi Demizu said:
>ack 4195629532 win 5792 (-)<- Original ACK
>ack 4195629532 win 6576 (+784) <- dup ACK (with window update)
>ack 4195629532 win 6576 (0)<- dup ACK
>ack 4195629532 win 7240 (+664)
> The server is not telling the client that a packet has been lost.
> The first two ACKs are correct duplicate ACKs, but the remaining
> ACKs coming from he server have window adjustments, so the
> client does not treat them as duplicate ACKs coming from a packet
> loss.
I made a list of ACKs with
On Wed, 9 Mar 2005, Mark Tinguely wrote:
For related curiousities, would you tell me if the FreeBSD a Uniprocessor
or multiprocessor?
Let me give you some details:
FreeBSD 4.10 p5, single Cyrix 250MHz cpu, and the nic is a Netgear
identified as so:
sis0: port 0xee00-0xeeff mem
0xfebff000-0xfebf
While normally not able to pour water out of a boot with
instructions on the heel, on Wed, Mar 09, 2005 at 07:51
our dear friend Mark Tinguely uttered this load of codswallop:
> Thinking about the trace a little more, the Apple send buffer
> must be set much lower (about 18-19KB ballpark) than
Thinking about the trace a little more, the Apple send buffer must be set
much lower (about 18-19KB ballpark) than the FreeBSD recieve buffer (56 KB).
If these settings were simular, the Apple machine should be providing
more data as the FreeBSD gives the window updates - this would give
the FreeB
Sent: Tuesday, March 08, 2005 3:47 PM
To: Charles Sprickman
Cc: freebsd-net@freebsd.org
Subject: Re: FreeBSD 4.x and OS-X tcp performance
According to RFC 793 (the original TCP specification), the client may
(even should) wait at least one second before retransmitting any
segment.
Ho
> In this particular case, the server is increasing the window size with
> subsequent ACKs. What does this mean? The receive buffer became less
> full so quickly? The receive buffer was enlarged?
The last ACKs that you mention are window update notifications that the client
application removed
On Tue, Mar 08, 2005 at 08:11:00AM -0600, Mark Tinguely wrote:
> The server is not telling the client that a packet has been lost.
> The first two ACKs are correct duplicate ACKs, but the remaining
> ACKs coming from he server have window adjustments, so the
> client does not treat them as duplica
Basing from what I see in Daniel Hartmeier analysis of tcpdump
(I honestly did not look at the original, when is has been summerized
so conveniently):
The server is not telling the client that a packet has been lost.
The first two ACKs are correct duplicate ACKs, but the remaining
ACKs coming fro
According to RFC 793 (the original TCP specification), the client may
(even should) wait at least one second before retransmitting any
segment.
However, RFC 2001 describes Fast Retransmission, where the third
acknowledgment for the same segment should be interpreted as an
indication of packet loss
On Tue, Mar 08, 2005 at 02:04:20AM -0500, Charles Sprickman wrote:
> http://home.manymonkeys.com/tcpdump/
> Observing this showed that the os-x to fbsd transfer went at about 200KB/s
> and the os-x to obsd transfer went at about 2.6MB/s.
In the osx-fbsd case we see the same problem again. This
Hello all,
As promised, I have 4 tcpdump traces (saved with the "-w" option
per request of another poster). Since these are a little too big to be
broadcast to everyone on the list, I'm posting them here:
http://home.manymonkeys.com/tcpdump/
For all tests I used os-x's command line ftp program
On Mon, Mar 07, 2005 at 02:04:01PM -0500, Charles Sprickman wrote:
> Very interesting, thank you for that read of the tcpdump output. If you
> have the time, could you post back a few lines of the tcpdump with
> comments so that I might learn a little about what's going on? I don't
> have the
On Mon, 7 Mar 2005, Daniel Hartmeier wrote:
On Sun, Mar 06, 2005 at 04:45:30PM -0500, Charles Sprickman wrote:
For fun I'm going to post a full tcpdump of an ftp session from one box to
the other, maybe someone can spot something there? It's attached and
bzip'd. It's a tcpdump of both hosts trans
On Sun, Mar 06, 2005 at 04:45:30PM -0500, Charles Sprickman wrote:
> For fun I'm going to post a full tcpdump of an ftp session from one box to
> the other, maybe someone can spot something there? It's attached and
> bzip'd. It's a tcpdump of both hosts transferring a 1MB tarfile.
I can only
Charles Sprickman wrote:
I'd really like to move past the duplex issues. I'm very very
familiar with that and already chased my tail on that one here and in
my many years of working at an ISP. I did a back-to-back test with
speed/duplex locked and I get the same result. All the switch ports
On Fri, 4 Mar 2005, Bill Vermillion wrote:
"Ang utong ko ay sasabog sa sarap!" exclaimed Charles Sprickman
while reading this message on Fri, Mar 04, 2005 at 18:43
and then responded with:
On Fri, 4 Mar 2005, Darcy Buskermolen wrote:
On Friday 04 March 2005 14:34, Charles Sprickman wrote:
Howdy,
"Ang utong ko ay sasabog sa sarap!" exclaimed Charles Sprickman
while reading this message on Fri, Mar 04, 2005 at 18:43
and then responded with:
> On Fri, 4 Mar 2005, Darcy Buskermolen wrote:
> >On Friday 04 March 2005 14:34, Charles Sprickman wrote:
> >>Howdy,
> >>Sorry to bring what seems l
On Mar 4, 2005, at 5:43 PM, Charles Sprickman wrote:
Yep, I wouldn't have come here without checking all the basics. I
should also add that given three machines in my standard config I get
the following results which will also help rule out
cabling/speed/duplex issues:
os-x <-> obsd - good
os-x
On Fri, 4 Mar 2005, Darcy Buskermolen wrote:
On Friday 04 March 2005 14:34, Charles Sprickman wrote:
Howdy,
Sorry to bring what seems like a simple issue up here. I had been blaming
slow afp filesharing between my OS-X (10.3.8 and previous) and FreeBSD 4.x
boxes on netatalk's afp implementation fo
On Friday 04 March 2005 14:34, Charles Sprickman wrote:
> Howdy,
>
> Sorry to bring what seems like a simple issue up here. I had been blaming
> slow afp filesharing between my OS-X (10.3.8 and previous) and FreeBSD 4.x
> boxes on netatalk's afp implementation for some time. Not too long ago I
>
22 matches
Mail list logo
