Hi,
Our lab recently installed an Alteon Gigabit switch and I'm interested in getting the
maximum speed out of the link. We tried netperf and tsock for measuring the maximum
link speed, but it just comes out to be around 450 Mbps. When the buffer sizes are
small i.e. around 1024 bytes or multiples of those, the cpu gets maxed out with
thruput at about 350Mbps, but by enabling jumbo frames in the NIC and fixing buffer
sizes to around 4K, 8K etc. the cpu is only utilized to @ 70% but still the max. speed
is only 450Mbps.
Any idea how we can measure the maximum speed of the link. What other performance
benchmarks should be used.
Thanks
Aamir
---
On Tue, 08 Feb 2000 08:45:51 Rick Blake wrote:
>A fascinating discussion. Can any machine flood a Gigabit Ethernet segment?
>
>My NetWare server at home has gotten a Gigabit segment up to about 40%
>utilization in a test. It's just a PII-450, and nothing else is special in
>the least. I haven't tried optimizing it to get more utilization,
>primarily 'cause I'd have to borrow the hardware again, and that was a very
>special favor. More to the point, I'd be looking for throughput. 1000MB/s
>= what for bytes, maybe 120MBytes/s? Do I have a disk drive channel
>capable of delivering data that fast?
>
>The concept of jumbo frames is also interesting. The network I oversee is
>Token-Ring and Ethernet. The overwhelming majority (70%+) of packets are
><128bytes. Most 64-128 bytes. What earthly good does an 8K frame do me?
>The Token segment rarely sees a 4k frame, and then *ONLY* when a NetWare
>user gets a LIP or burst going. All other services, especially SMB, never
>get over 1500 bytes. Of course, the Ethernet segment doesn't know a packet
>larget than 1536. And the routed packets over our WAN often are chopped
>into 576 bytes, for no good reason. Jumbo frames must appeal to those who
>send massive data streams. for the real world, this does not seem attractive.
>
>All of the above is IMHO, of course. Along with the notion that real-world
>performance has as much to do with other factors, such as switch
>performance, OS, and application. My favorite whine here is an app that
>users complain takes to long to load, normally about 10-14 seconds. It
>takes the first 7 seconds to display the logo screen. That's all it does.
>*Then* it goes about loading code. Can I tell my users to whine to the
>vendor, and get rid of the splash?
>
>Rick
>
>ps- great list. great contributors.
>
>At 01:14 PM 2/8/00 +0100, you wrote:
>>>>>>> "Ingo" == Ingo Molnar <[EMAIL PROTECTED]> writes:
>>
>>Ingo> On Tue, 8 Feb 2000, Anton Ivanov wrote:
>>
>>>> Wrong. All GigE cards I have checked so far have interrupt
>>>> mitigation. At init you program them to delay IRQ until that many
>>>> packets are in the queue or a timer expires and the timer
>>>> value. The only problem is that these are usually not passed as
>>>> module params. So you have to recompile if you find your current
>>>> mitigation params bad.
>>
>>Ingo> yep, also with jumbo frames (mtu 9000) there is no problem at
>>Ingo> all. Eg. the SysKonnect cards i use do just over 20k IRQs/sec
>>Ingo> when i'm saturating 107MB/sec TCP bandwith - this IRQ load is
>>Ingo> simply not a problem at all for an APIC controller. I've seen
>>Ingo> IRQ rates of 80k/sec as well.
>>
>>Sorry but thats *BAD* performance by the SK card. I do around 2.5K
>>ints/sec with the Alteon when doing 65MB/sec traffic in one direction
>>with regular sized frames. The load is maybe not a problem for the
>>APIC, but 80k/sec truly sucks for the CPUs considering the number of
>>context saves/restores they have to do.
>>
>>>> See above. If you program a sane GigE NIC correctly you actually
>>>> transfer more than 8K at a time. Donald Becker's hamachi driver is
>>>> a good example.
>>
>>Ingo> also other cards are using jumbo frames as well (and it actually
>>Ingo> makes sense to increase packet size).
>>
>>It's the switch vendors who are causing the problems.
>>
>>Jes
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-net" in
>>the body of a message to [EMAIL PROTECTED]
>>
>>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-net" in
>the body of a message to [EMAIL PROTECTED]
>
MailCity. Secure Email Anywhere, Anytime!
http://www.mailcity.com
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
