Re: Speed Mismatch?!?

TAC

Here is how I would put the case.

Choose the simplest setup that can reproduce the issue
i.e. no stack link involved.

use 3 ports (or ideally 4)
2 x 1G
2 x 100M

Do the performance tests and
send them the results.

Send full sh run and relevant sh int to show that the
interfaces are reporting as running clean.

If you do it like this and make NO changes to anything
betwen runs then they cannot get diverted
down the blind alleys that you have already investigated
thoroughly. Can they???

Let's call the computers Gi1, Gi2 and Fa1, Fa2.

If you show Gi1 <-> Gi2 works OK AND Fa1 <-> Fa2 is OK
then ask them to fix Gi1 <-> Fa1 which is broken.

One advantage of using iperf is that they can
reproduce it for themselves.

Send
H:\>iperf -v
iperf version 1.7.0 (13 Mar 2003) win32 threads
H:\>
If that is the path you choose.

It would be interesting to know if it was indeed packets
towards the end of a burst that were disappearing.

Remember that iperf by default will only send
8k (or about 5 or 6 packtes) in one burst.
The TCP then send as it sees fit:-) which
can only reduce the burst size further.

IDEA:-
Try a test with an iperf buffer of less than 1 packet.
If that works, you MAY be able to improve the
local performance by setting the TCP Receive Window to
just over 1 packet (less than two). Or one
packet exactly? 1460 bytes usually.
Why not try it? Set the MS Windows
TCP Receive Window to 1460 and see what happens.

You will also have to set the other end to
send TCP acks for each segment.
http://support.microsoft.com/kb/328890/
tcpackfrequency.
Only available on XP and 2003 Server.
Set to ONE.


iperf -c 1.1.1.1 -l1460 :: I have had a look and it is not
:: clear that this does what I
thought.

This will though destroy WAN performance.

# # # #

If my current model is correct and the issue is indeed that
the buffers between Gi ports and Fa ports are not working
then adding a "buffering" switch to the path would help.


source--Gi-->-buffer-sw--Fa-->-Stack--Fa-->-sink

The other thing that adding switches to the path does is
that it adds latency. To a good approximation all modern
switches are store and forward. Each switch in the path
adds 1 Packets worth of Transmssion Delay. The
value is dependent on the length of each packet
and the speed of each interface.

IPERF
I have had a look and I don't think that IPERF does wait
for all of the acks after sending a block. It is not clear
to me at present.

.

Relevant Pages

  • Re: can I use keep-state for icmp rules?
    ... if you're like me and allow incoming established connections to any port, ... unless he connects withough sending a "connect" packet first - ie ... >> the impression that ipfwactually tracks the state of TCP ... > internal tcp ports that might not normally have external access available? ...
    (FreeBSD-Security)
  • Re: Why can I see other traffic at switch environment just tcpdump?
    ... > I have operated linux server at switch environment, ... > and just with tcpdump, I can see some other traffic whic is not ... to ports the destination is NOT on in a few different circumstances. ... All switches seem to leak a bit so you do see the odd packet you ...
    (Incidents)
  • Re: ADSL Hard Wired House
    ... and passes the same data out to all the other ports, so for every packet of ... A "switch" learns the IP address of each ... connection 2, and so on, it will allow traffic from 10.0.0.101 to/from ...
    (uk.telecom.broadband)
  • Re: Sky router and DMZ
    ... I thought a switch broadcast packets from the WAN side across all the ... ports downstream of it, which would give whatever was attached what it ... between ports based on mac address of destination. ... and if it finds a match it forwards the packet. ...
    (uk.telecom.broadband)
  • Re: bomb the network
    ... the packet to the switch, fill the whole bandwidth, so other 23 ... Can i bomb the UDP packet? ... If you use TCP, ...
    (comp.os.linux.networking)