PDA

View Full Version : 5.2 release candidate w/ firmware v.26



seanadams
2004-06-21, 10:33
The nightly release has just been updated with new firmware (v.26).
Please snag it here:

http://www.slimdevices.com/downloads/nightly

5.2 is of course a big release for us - it's been in "feature freeze"
for a long time so we expect this to be a very stable build. It is also
the first release to include the v.2x series firmware.

Fixes in firmware v.26 are:

1) back-out a change to TCP which was reducing throughput for PCM
streaming

2) fix pausing so it doesn't lose the connection if paused for a long
time

*** Most important thing we need feedback on for this nightly: if
you've had problems with firmware updates in the past, they should be
completely fixed now - so please just confirm that it works okay
upgrading from v.25 to v.26. The process is totally solid now as far as
I know - but if you have a problem please contact me right away.


Thanks,
Sean

Dave Nanian
2004-06-21, 10:57
One teeny (and not new) glitch when updating firmware, Sean: after you
put up the "The firmware update was successful" message, it turns into
" he firmware update was successful" just before booting. Also, right
after reconnecting to the network, there's a flash of a 'firmware
update available' message just before going back to the original screen
you were on (in my case: date and time).

On Jun 21, 2004, at 1:33 PM, Sean Adams wrote:

>
> The nightly release has just been updated with new firmware (v.26).
> Please snag it here:
>
> http://www.slimdevices.com/downloads/nightly
>
> 5.2 is of course a big release for us - it's been in "feature freeze"
> for a long time so we expect this to be a very stable build. It is
> also the first release to include the v.2x series firmware.
>
> Fixes in firmware v.26 are:
>
> 1) back-out a change to TCP which was reducing throughput for PCM
> streaming
>
> 2) fix pausing so it doesn't lose the connection if paused for a long
> time
>
> *** Most important thing we need feedback on for this nightly: if
> you've had problems with firmware updates in the past, they should be
> completely fixed now - so please just confirm that it works okay
> upgrading from v.25 to v.26. The process is totally solid now as far
> as I know - but if you have a problem please contact me right away.
>
>
> Thanks,
> Sean
>
>

seanadams
2004-06-21, 11:03
Thanks Dave - I'll take a look at those. Both are definitely just
cosmetic, and not indicative of any error in installing the upgrade.



On Jun 21, 2004, at 10:57 AM, Dave Nanian wrote:

> One teeny (and not new) glitch when updating firmware, Sean: after you
> put up the "The firmware update was successful" message, it turns into
> " he firmware update was successful" just before booting. Also, right
> after reconnecting to the network, there's a flash of a 'firmware
> update available' message just before going back to the original
> screen you were on (in my case: date and time).
>
> On Jun 21, 2004, at 1:33 PM, Sean Adams wrote:
>
>>
>> The nightly release has just been updated with new firmware (v.26).
>> Please snag it here:
>>
>> http://www.slimdevices.com/downloads/nightly
>>
>> 5.2 is of course a big release for us - it's been in "feature freeze"
>> for a long time so we expect this to be a very stable build. It is
>> also the first release to include the v.2x series firmware.
>>
>> Fixes in firmware v.26 are:
>>
>> 1) back-out a change to TCP which was reducing throughput for PCM
>> streaming
>>
>> 2) fix pausing so it doesn't lose the connection if paused for a long
>> time
>>
>> *** Most important thing we need feedback on for this nightly: if
>> you've had problems with firmware updates in the past, they should be
>> completely fixed now - so please just confirm that it works okay
>> upgrading from v.25 to v.26. The process is totally solid now as far
>> as I know - but if you have a problem please contact me right away.
>>
>>
>> Thanks,
>> Sean
>>
>>

dean
2004-06-21, 11:06
The second one is a server-side glitch. Can you file both of these on
bugs.slimdevices.com?

On Jun 21, 2004, at 10:57 AM, Dave Nanian wrote:

> One teeny (and not new) glitch when updating firmware, Sean: after you
> put up the "The firmware update was successful" message, it turns into
> " he firmware update was successful" just before booting. Also, right
> after reconnecting to the network, there's a flash of a 'firmware
> update available' message just before going back to the original
> screen you were on (in my case: date and time).
>
> On Jun 21, 2004, at 1:33 PM, Sean Adams wrote:
>
>>
>> The nightly release has just been updated with new firmware (v.26).
>> Please snag it here:
>>
>> http://www.slimdevices.com/downloads/nightly
>>
>> 5.2 is of course a big release for us - it's been in "feature freeze"
>> for a long time so we expect this to be a very stable build. It is
>> also the first release to include the v.2x series firmware.
>>
>> Fixes in firmware v.26 are:
>>
>> 1) back-out a change to TCP which was reducing throughput for PCM
>> streaming
>>
>> 2) fix pausing so it doesn't lose the connection if paused for a long
>> time
>>
>> *** Most important thing we need feedback on for this nightly: if
>> you've had problems with firmware updates in the past, they should be
>> completely fixed now - so please just confirm that it works okay
>> upgrading from v.25 to v.26. The process is totally solid now as far
>> as I know - but if you have a problem please contact me right away.
>>
>>
>> Thanks,
>> Sean
>>
>>

Dave Nanian
2004-06-21, 11:24
Both quite minor, definitely -- logged in bugzilla nevertheless.

On Jun 21, 2004, at 2:03 PM, Sean Adams wrote:

>
> Thanks Dave - I'll take a look at those. Both are definitely just
> cosmetic, and not indicative of any error in installing the upgrade.
>
>
>
> On Jun 21, 2004, at 10:57 AM, Dave Nanian wrote:
>
>> One teeny (and not new) glitch when updating firmware, Sean: after
>> you put up the "The firmware update was successful" message, it turns
>> into " he firmware update was successful" just before booting. Also,
>> right after reconnecting to the network, there's a flash of a
>> 'firmware update available' message just before going back to the
>> original screen you were on (in my case: date and time).
>>
>> On Jun 21, 2004, at 1:33 PM, Sean Adams wrote:
>>
>>>
>>> The nightly release has just been updated with new firmware (v.26).
>>> Please snag it here:
>>>
>>> http://www.slimdevices.com/downloads/nightly
>>>
>>> 5.2 is of course a big release for us - it's been in "feature
>>> freeze" for a long time so we expect this to be a very stable build.
>>> It is also the first release to include the v.2x series firmware.
>>>
>>> Fixes in firmware v.26 are:
>>>
>>> 1) back-out a change to TCP which was reducing throughput for PCM
>>> streaming
>>>
>>> 2) fix pausing so it doesn't lose the connection if paused for a
>>> long time
>>>
>>> *** Most important thing we need feedback on for this nightly: if
>>> you've had problems with firmware updates in the past, they should
>>> be completely fixed now - so please just confirm that it works okay
>>> upgrading from v.25 to v.26. The process is totally solid now as far
>>> as I know - but if you have a problem please contact me right away.
>>>
>>>
>>> Thanks,
>>> Sean
>>>
>>>

Bill Fenner
2004-06-22, 07:48
On Jun 21, 2004, at 10:33 AM, Sean Adams wrote:
> 2) fix pausing so it doesn't lose the connection if paused for a long
> time

I just added another trace to bug 277; it unfortunately looks just like
the trace from firmware 24 and 23; window probes with no acks back from
the slim, and after the connection resets unpause still fails in the
same way.

Bill

Bill Fenner
2004-06-22, 08:41
On Jun 21, 2004, at 10:33 AM, Sean Adams wrote:
> 1) back-out a change to TCP which was reducing throughput for PCM
> streaming

I assume this was trying to avoid multiple acks updating the window
from tiny to small to big-enough (so that sender SWS avoidance allows
it to send). Have you considered delaying acks until the window is at
least large enough for a full-sized segment (or until 500ms has passed,
the longest suggested delayed-ack time, or until two full-sized
segments have been received)? Alternately, you could try the algorithm
in RFC 1122 section 4.2.3.3, which would (presumably) allow the window
to go to zero (keeping some of the actual window space hidden) and then
open it up again when a max-sized space is available. This would still
probably result in two ACKs per packet, where the delayed-ACK scheme
could result in only one.

For example, in the following trace, taken from firmware 26 streaming
mp3, delaying the ACK 41ms would have resulted in a single ACK with a
big-enough window:

07:56:47.965301 slimserver.9000 > squeezebox.27398: .
256107:257567(1460) ack 301 win 58400 (DF)
07:56:47.985293 squeezebox.27398 > slimserver.9000: . ack 257567 win 602
07:56:48.006475 squeezebox.27398 > slimserver.9000: . ack 257567 win
1446
07:56:48.026317 squeezebox.27398 > slimserver.9000: . ack 257567 win
1996

Bill

seanadams
2004-06-22, 10:24
Bill,

You are correct. I am going to make it work correctly but for now I'm
just putting it back the way it was.

Sean

On Jun 22, 2004, at 8:41 AM, Bill Fenner wrote:

> On Jun 21, 2004, at 10:33 AM, Sean Adams wrote:
>> 1) back-out a change to TCP which was reducing throughput for PCM
>> streaming
>
> I assume this was trying to avoid multiple acks updating the window
> from tiny to small to big-enough (so that sender SWS avoidance allows
> it to send). Have you considered delaying acks until the window is at
> least large enough for a full-sized segment (or until 500ms has
> passed, the longest suggested delayed-ack time, or until two
> full-sized segments have been received)? Alternately, you could try
> the algorithm in RFC 1122 section 4.2.3.3, which would (presumably)
> allow the window to go to zero (keeping some of the actual window
> space hidden) and then open it up again when a max-sized space is
> available. This would still probably result in two ACKs per packet,
> where the delayed-ACK scheme could result in only one.
>
> For example, in the following trace, taken from firmware 26 streaming
> mp3, delaying the ACK 41ms would have resulted in a single ACK with a
> big-enough window:
>
> 07:56:47.965301 slimserver.9000 > squeezebox.27398: .
> 256107:257567(1460) ack 301 win 58400 (DF)
> 07:56:47.985293 squeezebox.27398 > slimserver.9000: . ack 257567 win
> 602
> 07:56:48.006475 squeezebox.27398 > slimserver.9000: . ack 257567 win
> 1446
> 07:56:48.026317 squeezebox.27398 > slimserver.9000: . ack 257567 win
> 1996
>
> Bill
>
>

Adam Spiers
2004-06-27, 12:42
Bill Fenner (fenner (AT) electricrain (DOT) com) wrote:
> On Jun 21, 2004, at 10:33 AM, Sean Adams wrote:
> >1) back-out a change to TCP which was reducing throughput for PCM
> >streaming
>
> I assume this was trying to avoid multiple acks updating the window
> from tiny to small to big-enough (so that sender SWS avoidance allows
> it to send). Have you considered delaying acks until the window is at
> least large enough for a full-sized segment (or until 500ms has passed,
> the longest suggested delayed-ack time, or until two full-sized
> segments have been received)? Alternately, you could try the algorithm
> in RFC 1122 section 4.2.3.3, which would (presumably) allow the window
> to go to zero (keeping some of the actual window space hidden) and then
> open it up again when a max-sized space is available. This would still
> probably result in two ACKs per packet, where the delayed-ACK scheme
> could result in only one.
>
> For example, in the following trace, taken from firmware 26 streaming
> mp3, delaying the ACK 41ms would have resulted in a single ACK with a
> big-enough window:
>
> 07:56:47.965301 slimserver.9000 > squeezebox.27398: . 256107:257567(1460) ack 301 win 58400 (DF)
> 07:56:47.985293 squeezebox.27398 > slimserver.9000: . ack 257567 win 602
> 07:56:48.006475 squeezebox.27398 > slimserver.9000: . ack 257567 win 1446
> 07:56:48.026317 squeezebox.27398 > slimserver.9000: . ack 257567 win 1996

I still see excessive ACKs with firmware 27 (today's er, nightly).

20:26:37.355424 yoda.moosehall.9000 > squeezebox.moosehall.34101: . 29201:30661(1460) ack 0 win 6432 (DF)
20:26:37.375019 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 30661 win 424
20:26:37.395003 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 30661 win 930
20:26:37.414989 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 30661 win 1730
20:26:37.415038 yoda.moosehall.9000 > squeezebox.moosehall.34101: . 30661:32121(1460) ack 0 win 6432 (DF)
20:26:37.437177 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 32121 win 944
20:26:37.459462 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 32121 win 1302
20:26:37.476954 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 32121 win 2044
20:26:37.476999 yoda.moosehall.9000 > squeezebox.moosehall.34101: P 32121:33581(1460) ack 0 win 6432 (DF)
20:26:37.500994 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 33581 win 1104
20:26:37.523518 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 33581 win 1736
20:26:37.523564 yoda.moosehall.9000 > squeezebox.moosehall.34101: . 33581:35041(1460) ack 0 win 6432 (DF)
20:26:37.540314 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 35041 win 874
20:26:37.560010 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 35041 win 1312
20:26:37.582128 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 35041 win 2024
20:26:37.582184 yoda.moosehall.9000 > squeezebox.moosehall.34101: . 35041:36501(1460) ack 0 win 6432 (DF)
20:26:37.603382 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 36501 win 980
20:26:37.624350 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 36501 win 1424
20:26:37.644081 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 36501 win 1870

Presumably this is expected, but a fix is intended? Unfortunately I'm
no TCP expert, but I'm confused the above. I thought that dup ACKs
were only used to signal reception of out-of-order segments. Why
would they ever be used to repeatedly increase the window size? Why
can't it just get the window size right with the first ACK?

kdf
2004-06-27, 12:49
there is a firmware 28 included with the nightlies after 5.2. Unfortunately, it
didn't get in there in time to be part oftheh 5.2 build. See if that fixes your
problem.

-kdf

Quoting Adam Spiers <slim-devel (AT) adamspiers (DOT) org>:

> Bill Fenner (fenner (AT) electricrain (DOT) com) wrote:
> > On Jun 21, 2004, at 10:33 AM, Sean Adams wrote:
> > >1) back-out a change to TCP which was reducing throughput for PCM
> > >streaming
> >
> > I assume this was trying to avoid multiple acks updating the window
> > from tiny to small to big-enough (so that sender SWS avoidance allows
> > it to send). Have you considered delaying acks until the window is at
> > least large enough for a full-sized segment (or until 500ms has passed,
> > the longest suggested delayed-ack time, or until two full-sized
> > segments have been received)? Alternately, you could try the algorithm
> > in RFC 1122 section 4.2.3.3, which would (presumably) allow the window
> > to go to zero (keeping some of the actual window space hidden) and then
> > open it up again when a max-sized space is available. This would still
> > probably result in two ACKs per packet, where the delayed-ACK scheme
> > could result in only one.
> >
> > For example, in the following trace, taken from firmware 26 streaming
> > mp3, delaying the ACK 41ms would have resulted in a single ACK with a
> > big-enough window:
> >
> > 07:56:47.965301 slimserver.9000 > squeezebox.27398: . 256107:257567(1460)
> ack 301 win 58400 (DF)
> > 07:56:47.985293 squeezebox.27398 > slimserver.9000: . ack 257567 win 602
> > 07:56:48.006475 squeezebox.27398 > slimserver.9000: . ack 257567 win 1446
> > 07:56:48.026317 squeezebox.27398 > slimserver.9000: . ack 257567 win 1996
>
> I still see excessive ACKs with firmware 27 (today's er, nightly).
>
> 20:26:37.355424 yoda.moosehall.9000 > squeezebox.moosehall.34101: .
> 29201:30661(1460) ack 0 win 6432 (DF)
> 20:26:37.375019 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 30661
> win 424
> 20:26:37.395003 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 30661
> win 930
> 20:26:37.414989 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 30661
> win 1730
> 20:26:37.415038 yoda.moosehall.9000 > squeezebox.moosehall.34101: .
> 30661:32121(1460) ack 0 win 6432 (DF)
> 20:26:37.437177 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 32121
> win 944
> 20:26:37.459462 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 32121
> win 1302
> 20:26:37.476954 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 32121
> win 2044
> 20:26:37.476999 yoda.moosehall.9000 > squeezebox.moosehall.34101: P
> 32121:33581(1460) ack 0 win 6432 (DF)
> 20:26:37.500994 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 33581
> win 1104
> 20:26:37.523518 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 33581
> win 1736
> 20:26:37.523564 yoda.moosehall.9000 > squeezebox.moosehall.34101: .
> 33581:35041(1460) ack 0 win 6432 (DF)
> 20:26:37.540314 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 35041
> win 874
> 20:26:37.560010 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 35041
> win 1312
> 20:26:37.582128 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 35041
> win 2024
> 20:26:37.582184 yoda.moosehall.9000 > squeezebox.moosehall.34101: .
> 35041:36501(1460) ack 0 win 6432 (DF)
> 20:26:37.603382 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 36501
> win 980
> 20:26:37.624350 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 36501
> win 1424
> 20:26:37.644081 squeezebox.moosehall.34101 > yoda.moosehall.9000: . ack 36501
> win 1870
>
> Presumably this is expected, but a fix is intended? Unfortunately I'm
> no TCP expert, but I'm confused the above. I thought that dup ACKs
> were only used to signal reception of out-of-order segments. Why
> would they ever be used to repeatedly increase the window size? Why
> can't it just get the window size right with the first ACK?
>

dean
2004-06-27, 13:58
If you grabbed today's RPM build earlier, you got something that wasn't
the tip o the CVS tree. I'm rebuilding it now.

-dean

On Jun 27, 2004, at 12:49 PM, kdf wrote:

> there is a firmware 28 included with the nightlies after 5.2.
> Unfortunately, it
> didn't get in there in time to be part oftheh 5.2 build. See if that
> fixes your
> problem.
>
> -kdf
>
> Quoting Adam Spiers <slim-devel (AT) adamspiers (DOT) org>:
>
>> Bill Fenner (fenner (AT) electricrain (DOT) com) wrote:
>>> On Jun 21, 2004, at 10:33 AM, Sean Adams wrote:
>>>> 1) back-out a change to TCP which was reducing throughput for PCM
>>>> streaming
>>>
>>> I assume this was trying to avoid multiple acks updating the window
>>> from tiny to small to big-enough (so that sender SWS avoidance allows
>>> it to send). Have you considered delaying acks until the window is
>>> at
>>> least large enough for a full-sized segment (or until 500ms has
>>> passed,
>>> the longest suggested delayed-ack time, or until two full-sized
>>> segments have been received)? Alternately, you could try the
>>> algorithm
>>> in RFC 1122 section 4.2.3.3, which would (presumably) allow the
>>> window
>>> to go to zero (keeping some of the actual window space hidden) and
>>> then
>>> open it up again when a max-sized space is available. This would
>>> still
>>> probably result in two ACKs per packet, where the delayed-ACK scheme
>>> could result in only one.
>>>
>>> For example, in the following trace, taken from firmware 26 streaming
>>> mp3, delaying the ACK 41ms would have resulted in a single ACK with a
>>> big-enough window:
>>>
>>> 07:56:47.965301 slimserver.9000 > squeezebox.27398: .
>>> 256107:257567(1460)
>> ack 301 win 58400 (DF)
>>> 07:56:47.985293 squeezebox.27398 > slimserver.9000: . ack 257567 win
>>> 602
>>> 07:56:48.006475 squeezebox.27398 > slimserver.9000: . ack 257567 win
>>> 1446
>>> 07:56:48.026317 squeezebox.27398 > slimserver.9000: . ack 257567 win
>>> 1996
>>
>> I still see excessive ACKs with firmware 27 (today's er, nightly).
>>
>> 20:26:37.355424 yoda.moosehall.9000 > squeezebox.moosehall.34101: .
>> 29201:30661(1460) ack 0 win 6432 (DF)
>> 20:26:37.375019 squeezebox.moosehall.34101 > yoda.moosehall.9000: .
>> ack 30661
>> win 424
>> 20:26:37.395003 squeezebox.moosehall.34101 > yoda.moosehall.9000: .
>> ack 30661
>> win 930
>> 20:26:37.414989 squeezebox.moosehall.34101 > yoda.moosehall.9000: .
>> ack 30661
>> win 1730
>> 20:26:37.415038 yoda.moosehall.9000 > squeezebox.moosehall.34101: .
>> 30661:32121(1460) ack 0 win 6432 (DF)
>> 20:26:37.437177 squeezebox.moosehall.34101 > yoda.moosehall.9000: .
>> ack 32121
>> win 944
>> 20:26:37.459462 squeezebox.moosehall.34101 > yoda.moosehall.9000: .
>> ack 32121
>> win 1302
>> 20:26:37.476954 squeezebox.moosehall.34101 > yoda.moosehall.9000: .
>> ack 32121
>> win 2044
>> 20:26:37.476999 yoda.moosehall.9000 > squeezebox.moosehall.34101: P
>> 32121:33581(1460) ack 0 win 6432 (DF)
>> 20:26:37.500994 squeezebox.moosehall.34101 > yoda.moosehall.9000: .
>> ack 33581
>> win 1104
>> 20:26:37.523518 squeezebox.moosehall.34101 > yoda.moosehall.9000: .
>> ack 33581
>> win 1736
>> 20:26:37.523564 yoda.moosehall.9000 > squeezebox.moosehall.34101: .
>> 33581:35041(1460) ack 0 win 6432 (DF)
>> 20:26:37.540314 squeezebox.moosehall.34101 > yoda.moosehall.9000: .
>> ack 35041
>> win 874
>> 20:26:37.560010 squeezebox.moosehall.34101 > yoda.moosehall.9000: .
>> ack 35041
>> win 1312
>> 20:26:37.582128 squeezebox.moosehall.34101 > yoda.moosehall.9000: .
>> ack 35041
>> win 2024
>> 20:26:37.582184 yoda.moosehall.9000 > squeezebox.moosehall.34101: .
>> 35041:36501(1460) ack 0 win 6432 (DF)
>> 20:26:37.603382 squeezebox.moosehall.34101 > yoda.moosehall.9000: .
>> ack 36501
>> win 980
>> 20:26:37.624350 squeezebox.moosehall.34101 > yoda.moosehall.9000: .
>> ack 36501
>> win 1424
>> 20:26:37.644081 squeezebox.moosehall.34101 > yoda.moosehall.9000: .
>> ack 36501
>> win 1870
>>
>> Presumably this is expected, but a fix is intended? Unfortunately I'm
>> no TCP expert, but I'm confused the above. I thought that dup ACKs
>> were only used to signal reception of out-of-order segments. Why
>> would they ever be used to repeatedly increase the window size? Why
>> can't it just get the window size right with the first ACK?
>>

Adam Spiers
2004-06-27, 15:02
dean blackketter (dean (AT) slimdevices (DOT) com) wrote:
> If you grabbed today's RPM build earlier, you got something that wasn't
> the tip o the CVS tree. I'm rebuilding it now.

Thanks a lot, but even updating to that (and hence firmware 28), I'm
still seeing the dups:

22:59:00.704463 yoda.moosehall.3483 > squeezebox.moosehall.39510: P 2834:3052(218) ack 482 win 7040 (DF)
22:59:00.705211 squeezebox.moosehall.39511 > yoda.moosehall.9000: . ack 43801 win 1548
22:59:00.705260 yoda.moosehall.9000 > squeezebox.moosehall.39511: . 43801:45261(1460) ack 0 win 6432 (DF)
22:59:00.711958 squeezebox.moosehall.39510 > yoda.moosehall.3483: P 482:519(37) ack 3052 win 3000
22:59:00.712562 yoda.moosehall.3483 > squeezebox.moosehall.39510: . ack 519 win 7040 (DF)
22:59:00.735156 squeezebox.moosehall.39511 > yoda.moosehall.9000: . ack 45261 win 312
22:59:00.747502 squeezebox.moosehall.39511 > yoda.moosehall.9000: . ack 45261 win 768
22:59:00.773203 squeezebox.moosehall.39511 > yoda.moosehall.9000: . ack 45261 win 1210
22:59:00.794849 squeezebox.moosehall.39511 > yoda.moosehall.9000: . ack 45261 win 1552
22:59:00.794902 yoda.moosehall.9000 > squeezebox.moosehall.39511: P 45261:46721(1460) ack 0 win 6432 (DF)
22:59:00.815288 squeezebox.moosehall.39511 > yoda.moosehall.9000: . ack 46721 win 442
22:59:00.835937 squeezebox.moosehall.39511 > yoda.moosehall.9000: . ack 46721 win 870
22:59:00.853006 yoda.moosehall.3483 > squeezebox.moosehall.39510: P 3052:3270(218) ack 519 win 7040 (DF)
22:59:00.858472 squeezebox.moosehall.39511 > yoda.moosehall.9000: . ack 46721 win 1110

etc.

Was I right about dup ACKs only being supposed to appear due to
out-of-order segments?