Re: Speed Mismatch?!?

TAC has been "...[looking] at the captures..." for the last day+.

No word yet.

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

This _is_ a clue. It's buried above, but the reason it took me a year
and a half to realise that somthing was horribly wrong, not just slow
servers etc - was because I have an extra switch in my path compared to
the rest of the users. I can get 30mbit/sec to Gi. Still crapy and
asym....80 going to Gi, 30 coming from.

I have not tried exactly what you have above, I did this:

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

IOW, I did not try buffering w/ a switch that had an Fa link to the
stack...I stayed on Gi.

I also took this a little further and setup an 4x etherchannel, still
all gi...I _WAS_ trying to buffer somthing somwhere, not really knowing
how but wondering if packet A overran packet B to the point that the
stack could not see the etherframe signature of A anymore...reports no
drop becuase it saw no packet in the first place. I know there is a
drop somwhere, where is this drop occuring? Packet drop counters
increment if and only if IOS is aware that a drop has occured...I doubt
interface counters care what goes on between the guts that contect
other interfaces. Stack ring counters? Still don't know how to get
any.

Anyway, I have time right now to try what you suggest.

< time passes >

It works at 65 mbit/sec.

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

iperf...

Recall that I'm unable to conect from fa-client to gi-server to run the
test. I get "connection failed" If I fail to lanuch "ipsef -s" on Gi,
I get "Connection refused" I have the same problem with pcattcp.
Thing is client-fa-->server-Gi is not the slow path. It's slower that
it should be using robocoy.

Gi-server-->stack-->Gi-sink

....kicks so much ass. Very fast.

I got no clue about the inerds of a 3750...is there supposed to be a
buffer/queue dedicated for moving data between fa and gi?!?!?!?

I'm been thinkg about the odds of a gi-host overruning an fa-host. I
don't see it. TCP does send some segments out...but do not most TCP
stacks "wait" at some point for some ACKs beofre sending more data? In
UDP, I could see Gi sending so much that packets just drop in the
switch once egrees queues filled up. Or does it not work that way?
I'm just making assumption based on prior data; not knowing how much
value said prior data/experiance has in this case. </end bable>

.

Relevant Pages

  • Re: Data Compression Before or After Encryption ?
    ... And bacause of that we say, use CTR. ... Let's suppose the key stays the same and ECB mode is used... ... > You have no clue about security and we have no clue about your app. ... > of each packet can start as soon as the IV is received (probably with the ...
    (sci.crypt)
  • Re: Data Compression Before or After Encryption ?
    ... I don't understand the encryption algorithms and never ... And bacause of that we say, use CTR. ... You have no clue about security and we have no clue about your app. ... of each packet can start as soon as the IV is received. ...
    (sci.crypt)
  • Re: 64 bit packet counters
    ... > AH>use of 64 bit packet counters and the differentiation between ... > You may lookup the discussions in the mailing lists. ... > that I plan to implement in my snmp daemon) is to periodically monitor ... incremented per packet, and have a background task/thread to update the ...
    (freebsd-net)
  • Re: Strange issue with NDISPROT xmit and the network performance counter
    ... It seems that the packet counters in the NIC are different from the counters ... from the Task Manager counts only IP packets and completely ignores my ... custom Ethernet frames. ...
    (microsoft.public.development.device.drivers)
  • Re: Embassy No 1
    ... >>Can anyone with a clue tell me why Embassy No 1's now have a "Jim'll ... >>Fix It" question on the side of the packet? ...
    (uk.rec.motorcycles)