> >I have a Tivo running at 100 megabits (its top speed) on the same
> >network with 1 gigabit Linux hosts. TCP transfers from the Tivo are
> >very slow because of the bandwidth differential. During the TCP
> >session, the gigabit host will acknowledge the previous push packet
> >from the Tivo too quickly, and the switch drops it on the floor (as
> Buy a better switch. Anything else you do is simply a workaround. The
> switch should NOT be throwing stuff away.
Indeed, those ACKs, even at an ACK-every-other, pace should not be
getting dropped by the switch. The bandwidth of the ACK stream would
be well below 100 Mbit/s. This ass-u-me-s there is no data flowing
back in the ACK segments.
However, by any chance is the link from the TiVo to your switch
half-duplex? Are the transfers from the TiVo "bursty?" If the link
comes-up half-duplex it is possible you could be seeing capture
effect. Web search for the details, but the idea is that a sender
able to send >> 100BT speeds can end-up grabbing the link for a long
time, causing the other end of the link to have its back-off timers
grow large (this is at the ethernet level) and perhaps even end-up
dropping packets for excessive transmission retries (again this is at
the Ethernet CSMA/CD level).
If you switch has stats, check them for something like "excessive
There is also the good old fashioned issue of duplex mismatch.
How 100Base-T Autoneg is supposed to work:
When both sides of the link are set to autoneg, they will "negotiate"
the duplex setting and select full-duplex if both sides can do
If one side is hardcoded and not using autoneg, the autoneg process
will "fail" and the side trying to autoneg is required by spec to use
If one side is using half-duplex, and the other is using full-duplex,
sorrow and woe is the usual result.
So, the following table shows what will happen given various settings
on each side:
Auto Half Full
Auto Happiness Lucky Sorrow
Half Lucky Happiness Sorrow
Full Sorrow Sorrow Happiness
Happiness means that there is a good shot of everything going well.
Lucky means that things will likely go well, but not because you did
anything correctly :) Sorrow means that there _will_ be a duplex
When there is a duplex mismatch, on the side running half-duplex you
will see various errors and probably a number of _LATE_ collisions
("normal" collisions don't count here). On the side running
full-duplex you will see things like FCS errors. Note that those
errors are not necessarily conclusive, they are simply indicators.
Further, it is important to keep in mind that a "clean" ping (or the
like - eg "linkloop" or default netperf TCP_RR) test result is
inconclusive here - a duplex mismatch causes lost traffic _only_ when
both sides of the link try to speak at the same time. A typical ping
test, being synchronous, one at a time request/response, never tries
to have both sides talking at the same time.
Finally, when/if you migrate to 1000Base-T, everything has to be set
to auto-neg anyway.
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...