Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

the distro kunundrum...



Well, here's what I did.

I have a program called tcpBlaster which I use to test network speeds. 
it basically opens up a socket connection and dumps bits over it as fast 
it can go. There is no disk io involved.

The rates that I'm getting are 7MBytes/sec into the system, 15MBytes/sec 
out of the system when running RHEL 5.4.

The Dell came with broadcom netxtreme cards. The first thing I did was 
pull over the latest driver from broadcom. Same transfer rates. I then 
plugged in an intel nic ard which uses the e1000 driver. Same result. I 
then booted from the fedora 11 live CD, and the data rates sprang to 
94MBytes/sec which is what I would expect for gigabit ethernet.

I also used ethtool to look at the various options paying careful 
attention to the offload parameters. Turning them on and off didn't 
change the data rate problem. The other odd bit, is that an excessive 
amount of CPU is being used, makes me think that it's not servicing 
interrupts properly or something like that. Since I didn't change the 
cables or switches when I got the data rates to go from 7/15 to 95 
MBytes/sec, I'm ruling out broken cables/switches.... although 
autoconfiging could still be a problem.

Thanks for the replies.

Cheers. Steve.

Brendan wrote:
> On Monday 16 November 2009, Jarod Wilson wrote:
>   
>> On Nov 16, 2009, at 12:29 PM, Dan Ritter wrote:
>>     
>>> On Mon, Nov 16, 2009 at 12:22:55PM -0500, Stephen Adler wrote:
>>>       
>>>> Well... so I've boxed myself in... At work I ordered a Dell (I had no
>>>> choice really, the IT guys only buy Dells) to run RHEL for a backup
>>>> system I'm putting together. After way to much time fussing around, I
>>>> finally got the damn thing up and running. I then go to test the network
>>>> and the network performance is very bad. So I mess around, putting in
>>>> different nic cards brands only to find that the problem doesn't go way.
>>>> Next I burn a fedora 11 live CD, fire it up and lo and behold, I get
>>>> close to 100Mbytes/sec data rate over the nic, as what I would expect.
>>>>
>>>> So now I have a choice of wiping off RHEL and putting on fedora or
>>>> somehow getting a newer kernel installed... which in the end breaks the
>>>> model of getting enterprise software for an enterprise application....
>>>> Putting a home grown not RHEL supported kernel on RHEL basically voids
>>>> the warenty sort to speak....
>>>>
>>>>
>>>> any words of advice? I'm kind of blowing off steam right now...
>>>>         
>>> Perhaps something besides "the whole kernel" is causing the
>>> issue? I would check the driver versions for the NIC you are
>>> using (RHEL vs Fedora) and see if RHEL is doing something odd
>>> with sysctl parameters or a firewall.
>>>       
>> Never hurts to give a quick spin through bugzilla.redhat.com as well, see
>>  if maybe there's a bugzilla opened with a patch queued up. You didn't
>>  mention the NIC model and/or driver. Mention it, and maybe someone could
>>  take a peek and see what's in the queue in the way of network driver
>>  patches that could be relevant...
>>
>>     
>
> What tools were used to test? What kind of tests were run?
> Were the cables tested, what about debug output? Perhaps one kernel has a few 
> options on that the other doesn't...What about a vanilla kernel, etc.?
> The OP leaves a lot to be desired in this QA...
> _______________________________________________
> Discuss mailing list
> Discuss-mNDKBlG2WHs at public.gmane.org
> http://lists.blu.org/mailman/listinfo/discuss
>
>   







BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org