network throughput

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <dc998cfd.0410040624.2fc730e7@posting.google.com>,
wld <aaabbb16@hotmail.com> wrote:
:a switch has 48 ports and 1Gb for each port. it also support
:full deplux mode. so max. throughput is 96Gb.
:if use min. packet 64 bytes then theoretical throughput
ps(packets-per-seconds)=142,857,142
:above info. is from a article.
:my question is why use 64 bytes

64 bytes is the minimum packet size, and so takes the least amount of
time to transmit, and so allows the greatest number of packets to
be transmitted in a given time interval. As well, because the 64 packets
are the shortest valid packets, a continuous stream of 64 byte packets
puts the greatest stress on a switch or router, in the sense that
the switch or router has the least amount of time to process the packet
and get ready for the next one.

:and where is 142,857,142 come from?

Calculate the maximum packets per second on one link by taking the number
of bit-times in one second, and dividing by the number of bits required
for one packet. One packet on ethernet starts with a preamble and other
overhead of a fixed length before the packet itself, and then there is
the packet, and then there is a mandatory "intra-frame gap" of 96 bit times.
When you have found the number of packets per second for one link,
multiply by the number of simultaneous links (96 in your case) to
get the theoretical maximum packets per second handled by the router or
switch.

I haven't done the calculation for the scenario you present, but the
number stated looks about right.
--
Positrons can be described as electrons traveling backwards in time.
Certainly many Usenet arguments about the past become clearer when they
are re-interpreted as uncertainty about the future.
-- Walter Roberson

Archived from groups: comp.dcom.lans.ethernet (More info?)

Thanks!!


64 =46+12+2+4
46 byes-->min. packet (payload)
12 bytes-->mac address of source and des.
2 bytes --> type /length
4 bytes -->CRC

add 20 more byes (8 byes preamble and 12 byes IFG)
64+20=84bytes
96,000,000,000/(84*8)=142,857,142pps (should be FPS)

Thanks again!!

LL






Rich Seifert <usenet@richseifert.com.invalid> wrote in message news:<usenet-DB53B0.08385104102004@news.isp.giganews.com>...
> In article <dc998cfd.0410040624.2fc730e7@posting.google.com>,
> aaabbb16@hotmail.com (wld) wrote:
>
> > Hi,
> > a switch has 48 ports and 1Gb for each port. it also support
> > full deplux mode. so max. throughput is 96Gb.
>
> You must work in Marketing. ;^)
>
> Even assuming that the traffic distribution is perfectly uniform (e.g.,
> each port is receiving frames at the rate of 1 Gb/s and is forwarding
> them to a single, unique output port), there is still only 48 Gb/s of
> data being moved. With the exception of those few management-related
> frames actually being sent to the switch as an end-station, *every
> frame* that arrives at the switch is tranferred out of the switch on
> another port; i.e., each frame uses link capacity *twice*, once on
> input, and then again on output. Thus, the "data throughput" is 48 Gb/s,
> not 96; 48 Gb/s is being "put through" the switch.
>
> Many companies try to inflate their performance data by counting each
> frame twice.
>
> > if use min. packet 64 bytes then theoretical throughput
> > pps(packets-per-seconds)=142,857,142
> > above info. is from a article.
> > my question is why use 64 bytes and where is 142,857,142 come from?
> >
>
> There is no reason to use 64 byte frames; this is simply a worst-case
> scenario considered from a "frames-per-second" basis. That is, the
> switch will see the most frames-per-second (as opposed to *bits* per
> second) when using minimum length (64 byte) frames.
>
> Using 64 byte frames, and allowing for preamble and interframe gap, a
> GbE link can carry 1,488,095.23 frames-per-second. Multiply this by the
> 48 ports of the switch, and the resulting throughput is 71,428,571
> frames-per-second. That is, the switch must examine, parse, and make a
> forwarding decision on ~71 million frames per second, in the worst-case.
>
> As in the throughput example earlier, you can make yourself look better
> by doubling that number (i.e., counting the frames both as they enter
> and leave the switch) to 142,857,142 (the number you quoted), but the
> fact is that the real performance demands on the switch are related to
> frame parsing on input, not frame forwarding on output, so doubling the
> number is inappropriate as a reflection of switch performance.