Processor contention(?) and network bandwidth on AMD
Many of your questions may have already been answered in earlier discussions or in the FAQ. The search results page will indicate current discussions as well as past list serves, articles, and papers.
Joshua Baker-LePain jlb17 at duke.eduMon Apr 29 12:49:32 PDT 2002
- Previous message: Processor contention(?) and network bandwidth on AMD
- Next message: Processor contention(?) and network bandwidth on AMD
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, 29 Apr 2002 at 3:40pm, Mark Hahn wrote > well, there are several contributing factors, which are probably > mitigated by running a decently modern (ie 2.4.18) kernel. > > for instance, at gigabit speeds, you're almost certainly generating > nontrivial MM load. there's been a huge amount of improvement in 2.4's > in how they handle ram. These tests (obviously) were only at FE speed, though. The receiving end was gigabit, but the sending end (the dual AMD nodes) was FE. > > unloaded: 11486.6 KB/real sec > > 2 matlab simulations: 10637.8 KB/real sec > > 2 matlab simulations and 2 SETI at homes (nice -19): 6645.4 KB/real sec > > SETI at home is obviously in the "so don't do that" category. I expect your > matlab was decelerated by a similar amount. Sure, but it was just an example of a niced background load, which "shouldn't" interfere with anything. It certainly shouldn't crash bandwidth like that. > > tested (dual PIII 933 on an i860) showed very little bandwidth drop with > > i860 is a P4 chipset afaik... Oops -- not enough coffee. I meant i840. Dual PIII with RDRAM. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
- Previous message: Processor contention(?) and network bandwidth on AMD
- Next message: Processor contention(?) and network bandwidth on AMD
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Beowulf mailing list
