Hi all,
Some words about our experiences.
Especially the microcomputers tend to send packets in clusters, that is:
100 Mbps of traffic over 1 Gbps link may have 10% of the time running at
line speed, other times line is idle. Can happen in iBobs too if they
decide to send at the same time.
We found this out when trying to push 896 Mbps from two computers over a 1
Gbps link. Solved this by setting one of the computers to act as a nat
server for the other, after that zero errors.
TCP is not a solution either for long fat pipes, takes about half an hour
for it to run to full 1 Gbps speed. If one packet is lost, speed drops to
half and there is another half an hour wait.
Kind of amazing that the memory in routers is quite expensive when normal
microcomputer dram is fast enough...
Cheers,
Jouko
--
"Life is pretty simple: You do some stuff. Most fails. Some works. You do
more of what works. If it works big, others quickly copy it. Then you do
something else. The trick is to do something else."
On Tue, 21 Jun 2011, Jean Borsenberger wrote:
On Mon, 2011-06-20 at 12:54 -0700, [email protected]
wrote:
Hello,
0.5 mbyte buffer per port
I read in the spec: Buffer memory: 512 KB embedded memory per unit
seems global for a switch.
That resemble to what I am used to. Usually on chip port buffers are
at most 17KB.
These devices are tuned for a traffic which is mainly TCP, and UDP with
data integrity control delegated to clients.
Basically they drop a lot of packets, which is of little importance in
usual
use, as those packets are requested by the listener and re-emitted.
Of course in contention situations this behaviour may impact badly
things
like voice transportation.
In your design, many lines converge to one. Hope the time statistic is
fair. The time to be considered to examine this is:
buffer_size/effecive_line_speed
Be carefull that not all of the buffer memory may be available for one
port, depending on the policy adopted in the switching strategy.
Jean
