Re: Geschwindigkeit gigabit Ethernet
Am Montag, 14. März 2005 02:31 schrieb Bernd Schubert:
> > Der Server ist ein Athlon XP2400+ mit 512 DDR RAM 3 Plattten die über
> > PATA 100 angschlossen sind;
>
> Sind die Platten zum Raid zusammengeschaltet? Dann z.B. jede Platte 30MB/s
> -> schon 90MB/s dafür weg.
>
nein, die hängen einzeln, jede für sich an einem IDE Kanal.
> >> Ein normaler 32bit/33MHz PCI Bus schafft nunmal schon rechnerisch nur
> >> 126MB/s - für alle Komponenten an diesem Bus. Bei der Anschaffung
> >> unsereres Servers haben wir deshalb ein Tyan Board genommen, dass zwei
> >> PCI-X Busse und 1 PCI Bus besitzt, da bremsen sich die Komponenten nicht
> >> gegenseitig aus.
> >
> > Also bevor ich die 126 MB/s ausreize bin ich am Ende der
> > Festplattenmöglichkeiten angelangt :-)
>
> Du musst alle Komponenten zusammenzählen, eine 1GBit Netzwerkkarte
> beansprucht das schon für sich alleine beim theoretischen
> Übertragungsmaximum. Dann die Festplatte, Grafikkarte, Soundkarte... Du
> weißt hoffentlich am besten was bei Dir so alles im Server eingebaut ist.
> Effektiv wirst Du wahrscheinlich schon froh sein, wenn Du mit diesem
> Server 200-500MBit schaffst.
>
abgesehen davon, dass in dem Rechner ausser der Gigabit Nic und 2 Fast
Ethernet karten(von denen im Mom auch nur 1 benutzt wird) nur noch eine
Uralte, gamlige Graphikkarte drin ist, die für die Konsole grade gut ist,
hast du Recht: wenn ich 300 MBit/s schaffen würde, wäre ich happy :-)
> >> Hinzu kommen kann dann auch noch, dass z.B. die Netzwerkkarte zuviele
> >> Interrupts auslösen kann und somit Dein System auch ausbremst. Suche mal
> >> ob es sowas wie interrupt moderation oder so ähnlich für Deine
> >> Karte/Treiber gibt.
> >
> > Wenn ich ein einzelnes File, zB das 1. ISO von Sarge kopiere sollten
> > eigentlich keine Überlastungen der IRQ auftreten ?
>
> Die Interrupts werden von den Datenpaketen der Netzwerkkarte ausgelöst,
> ebenso von den Festplatten. Da reicht halt auch eine Datei aus. Ich vermute
> mal stark, dass der Intel Treiber eine Option für die Interrupt-Reduzierung
> bietet. Dann werden im Cache der Karte Datenpakete gesammelt und erst dann
> an den PCI Bus weitergegeben.
> Bei den PATA Festplatten hast Du vermutlich keine Chance. Ich vermute mal,
> dass SCSI, SATA oder auch PATA Controller mit eigenem Cache auch dazu
> beitragen die IRQ Rate zu reduzieren, onboard PATA oder SATA Controller
> ohne eigenen Cache aber wohl kaum.
>
ich verwenden den onboard Controller, ergo ohne Cache
> >> Verwendest Du tcp oder udp mounts? Bei udp mounts erstmal tcp mounts
> >> testen.
> >
> > äh, da bin ich jetzt erlich gesagt überfragt .... ???
>
> man nfs
>
> mount -t nfs -otcp server:/exportpoint /mountpoint
>
> Allerdings muss Dein server-kernel das unterstützen. War bis vor kurzem bei
> der kernel-Konfiguration noch als experimental markiert, obwohl es schon
> eine ganze Weile von den nfs Kernelentwicklern empfohlen wird.
>
ach so: bis jetzt habe ich nur
mount -t nfs server:/export /mp
verwendet; muss ich mir mal die man etc anschauen;
> >> > Auf der anderen Seite als Client ist ein Notebook mit einem Broadcom
> >> > Gigabit Adapter und einem Durchsatz von ca 27 MB/s ( warum auch immer
> >> > so wenig). Könnte es am Kabel liegen ? Es ist ein CAT5e Patchkabel !
> >>
> >> Dieses Notebook hat sicherlich nur einen normalen PCI Slot,
> >> möglicherweise das Maximum über einen normalen PCI Slot.
> >
> > ja das NB dürfe einen Normalen PCI Slot haben. Allerdings ist IMHO der
> > Speed der Festplatte des NB das langsamste an der ganzen Geschicht, oder
> > der nfsd zickt irgendwie rum , dass er nicht die volle leistung bringt (
> > rpc, portmapper, .....)
> >
> > An der Stelle soll mal gesagt sein, dass das NB der einzigste Client ist
> > ...
>
> Was hilft es wenn es der einzige Client ist, es aber selber nur max. 27MB/s
> über die Netzwerkkarte verarbeiten kann?
>
ist schon klar; wollte damit nur Klarstellen, dass nicht noch 50 andere
Clients auf den Fileserver zugreifen und es somit nicht verwunderlich wäre
wenn entsprechd wenig bei jedem einzelnen ankäme.
> Grüße,
> Bernd
Grüsse, Simon
Reply to: