2te Netzwerkkarte einrichten

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
sas0r
Beiträge: 13
Registriert: 07.11.2003 21:08:33
Kontaktdaten:

2te Netzwerkkarte einrichten

Beitrag von sas0r » 07.11.2003 21:11:58

Hallo,

habe folgendes problem :

2 Nics

00:0d.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24)
00:10.0 Ethernet controller: 3Com Corporation 3c900 Combo [Boomerang]

die 3c900 ist fürs intere netzt,funzt auchg super,nur wie conf ich die externe karte,hat ebenfalls dann ne feste ip .....

Mfg

sas0r

arzie
Beiträge: 134
Registriert: 17.02.2002 15:51:03

Beitrag von arzie » 07.11.2003 21:40:37

hat ebenfalls dann ne feste ip .....
Ist das jetzt dein Ziel das nicht du erreicht hast oder dein Problem?

arzie

sas0r
Beiträge: 13
Registriert: 07.11.2003 21:08:33
Kontaktdaten:

Beitrag von sas0r » 07.11.2003 21:42:17

na ich weiss nicht wie ich die 2te karte confen soll, bzw. mit was ... ifconfig ?

bitte um hilfe wie man unter einer shell dies macht.

danke

arzie
Beiträge: 134
Registriert: 17.02.2002 15:51:03

Beitrag von arzie » 07.11.2003 22:00:01

Wird in /etc/network/interfaces Konfiguriert

Die Konfiguration der ersten Karte steht da schon drin, kannst quasi Abschreiben, halt mit anderer IP Addresse und so.

Dann /etc/init.d/networking Restarten und es sollte funktionieren

arzie

sas0r
Beiträge: 13
Registriert: 07.11.2003 21:08:33
Kontaktdaten:

Beitrag von sas0r » 07.11.2003 22:07:08

hab ich gemacht :

eth0 Link encap:Ethernet HWaddr 00:01:02:1A:F7:89
inet addr:192.168.1.5 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4939 errors:0 dropped:0 overruns:0 frame:0
TX packets:5099 errors:0 dropped:0 overruns:0 carrier:2
collisions:18 txqueuelen:100
RX bytes:483303 (471.9 KiB) TX bytes:613259 (598.8 KiB)
Interrupt:10 Base address:0xf400

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:104 errors:0 dropped:0 overruns:0 frame:0
TX packets:104 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:9777 (9.5 KiB) TX bytes:9777 (9.5 KiB)


----------------

iface eth0 inet static
address 192.168.1.5
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1

iface eth1 inet static
address xxx.xxx.xxx.xxx
netmask 255.255.255.0
network xxx.xxx.xxx.0
broadcast xxx.xxx.xxx.255
# gateway 192.168.1.1

was mach ich falsch ? evtl. das modul noch angeben ?

arzie
Beiträge: 134
Registriert: 17.02.2002 15:51:03

Beitrag von arzie » 07.11.2003 22:17:34

sas0r hat geschrieben: evtl. das modul noch angeben ?
Gute Idee.
Was sagt denn 'modprobe 3c59x' ?

Aber einen Netzwerktreiber als Modul halte ich nicht fuer optimal. Lieber fest in der Kernel kompilieren.

arzie

Benutzeravatar
pdreker
Beiträge: 8298
Registriert: 29.07.2002 21:53:30
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Nürnberg

Beitrag von pdreker » 07.11.2003 23:41:43

Aber einen Netzwerktreiber als Modul halte ich nicht fuer optimal. Lieber fest in der Kernel kompilieren.
Warum?

Patrick
Definitely not a bot...
Jabber: pdreker@debianforum.de

arzie
Beiträge: 134
Registriert: 17.02.2002 15:51:03

Beitrag von arzie » 08.11.2003 00:11:51

Mehr aus philosophischen Gruenden.
Ich sehe keinen Sinn darin einen Driver den man sowieso immer braucht und niemals entlaed als Modul zu halten.

Evlt. hat es bei schwaechern CPUs auch einen Performancevorteil durch die bessere Nutzung des Caches weil der Kernel einen zusammenhaengenden Addressraum belegt und eine hoehere Chance besteht das bei Einspuengen in den Driver der Cache nicht geflushed werden muss.

Gruss
arzie

Benutzeravatar
pdreker
Beiträge: 8298
Registriert: 29.07.2002 21:53:30
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Nürnberg

Beitrag von pdreker » 08.11.2003 01:08:07

arzie hat geschrieben:Evlt. hat es bei schwaechern CPUs auch einen Performancevorteil durch die bessere Nutzung des Caches weil der Kernel einen zusammenhaengenden Addressraum belegt und eine hoehere Chance besteht das bei Einspuengen in den Driver der Cache nicht geflushed werden muss.
Die CPU Caches werden bei jedem Contextswitch und natürlich auch beim Kernel Entry geflushed, weil die CPU die TLBs neu laden muss (Wechsel des Adressraums). Von daher ist der Punkt haltlos.

Patrick
Definitely not a bot...
Jabber: pdreker@debianforum.de

arzie
Beiträge: 134
Registriert: 17.02.2002 15:51:03

Beitrag von arzie » 08.11.2003 01:46:45

Du meinst dass zwischen NIC Driver / Netfilter / IP Stack ein Contextwechsel stattfindet?

Hast du mal einen Pointer wo ich genaueres darueber lesen kann?

arzie

Benutzeravatar
pdreker
Beiträge: 8298
Registriert: 29.07.2002 21:53:30
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Nürnberg

Beitrag von pdreker » 08.11.2003 02:25:38

Was folgt ist eine *ganz* *ganz* *grobe* Beschreibung! Details findet man in Documentation/cachetlb.txt im Kernel Source (Ich habe bei Kernel 2.6 nachgeschaut).

Zwischen NIC Driver, Netfilter und IP Stack käme man zwar theoretisch ohne Kontextswitch aus (Das ist nicht wirklich ein Contextswitch: CS sind eigentlich eine Userspaceangelegenheit), allerdings ist es unwahrscheinlich, dass das so ist. Der eigentlich NIC Driver wird ja durch einen IRQ getriggert. Beim Eintritt in die ISR wird auf jeden Fall der Cache und die TLBs geflushed. Die ISR macht aber nur die minimal nötige Arbeit, sie wird nicht das komplette Paket handeln, das würde viel zu lange dauern. Also wird einfach der IRQ bestätigt, und die nötige Arbeit in eine Queue (früher hiessen die "bottom-halves" [*]) gestellt. Dann erfolgt der RFI und wieder ein Cache und TLB Flush. Dann ist irgendwann die Bottom Half dran (per Timer Interrupt). Diese holt dann die Pakete aus der NIC und gibt sie an den Netzwerkstack, usw. mit IP Tables, und schliesslich der Userspace Anwendung, wo die Daten ankommen. Dabei können viele Stellen wieder durch einen Interrupt unterbrochen werden. Bei Kernel 2.4 tritt allein der Timer IRQ 100mal pro Sekunde auf, bei Kernel 2.6 sogar 1000mal. Bei diesen ganzen IRQs wird jedesmal Cache und TLBs geflushed. Wenn Du einen pre-emptible Kernel hast finden sogar noch häufiger Kernel-Userspace Übergänge statt.

Wie schon gesagt, das ist sehr grob und verallgemeinert. Die Caches werden selektiv geflushed, es werden also nur bestimmte Adressräume rausgeworfen, und je nach Umstand wird auch mehr oder weniger rausgeworfen.

Aber ganz abgeshen davon: die Module liegen ganz normal im Adressraum des Kernel und die Caches sind schlauer, als dass sie nur für grosse Zusammenhängende Bereiche effizient wären. Der Athlon XP Barton hat einen 16-fach assoziativen 2nd Level Cache. Das bedeutet, dass jede Speicheradresse potentiell an 16 unterschiedlichen Positionen im Cache liegen kann. Dier 1st Level Cache ist ein strict Harvard Cache (separate Caches für Daten und Instruktionen) und ist 2-fach assoziativ. Man kann z.B. blind davon ausgehen, dass ISRs, die häufig (mehrmals pro Sekunde) aufgerufen werden, nie aus dem 2nd Level Cache geflushed werden.

Wenn Du mehr wissen willst, kann ich Dir noch ein paar Bücher empfehlen, aber Thema ist *sehr* komplex, je nachdem auf welcher Ebene man einsteigen will... ;-)

[*] Ich habe gerade nochmal geschaut: softirq heisst dieses Konzept wenigsten im 2.6 Kernel...

Patrick
Definitely not a bot...
Jabber: pdreker@debianforum.de

Benutzeravatar
spiffi
Beiträge: 1128
Registriert: 09.08.2003 19:02:27

Beitrag von spiffi » 08.11.2003 03:04:03

sas0r hat geschrieben:was mach ich falsch ? evtl. das modul noch angeben ?
Hm, hast Du auch ein

Code: Alles auswählen

auto eth1 
in der /etc/network/interfaces?

sas0r
Beiträge: 13
Registriert: 07.11.2003 21:08:33
Kontaktdaten:

Beitrag von sas0r » 08.11.2003 10:42:30

hi,

ne hab ich net,dieser befehl steht auch nicht bei eth0 .... siehe oben,so sieht die datei aus.

cu

arzie
Beiträge: 134
Registriert: 17.02.2002 15:51:03

Beitrag von arzie » 08.11.2003 11:54:42

Moin Patrick,
wann gehst Du so in's Bett? ;)
Details findet man in Documentation/cachetlb.txt im Kernel Source
Hab auch gleich mal reingeschaut und waere ohne deine Erleuterung, zumindest fuer Intel CPUs, warscheinlich erstmal auf dem Holzweg gelandet.
Da steht naemlich,

.. the physically indexed physically tagged caches of IA32 processors have no need to implement these interfaces since the caches are fully synchronized and have no dependency on translation information.

Wenn Du mehr wissen willst, kann ich Dir noch ein paar Bücher empfehlen, aber Thema ist *sehr* komplex, je nachdem auf welcher Ebene man einsteigen will...
Ganz unten im TTL-Bereich bin ich fit und programmieren kann ich auch. Wenn es sowas wie eine Grundlagenbibel fuer den Mittelteil gibt, wuerde ich das ganz gerne lesen, ja.

Ansonsten halte ich mich zwar fuer Netzwerkfest, da ich aber erst seit 1 Jahr mit Linux zu tun habe gibt es erstmal andere Prioritaeten (nach der Familie). ;)
[*] Ich habe gerade nochmal geschaut: softirq heisst dieses Konzept wenigsten im 2.6 Kernel...
Vergleichbar mit den Motorola-Traps?

BTW: Und trotzdem kompiliere ich mir alle Driver die ich brauche in den Kernel.
Auf meiner Alpha gibt es ueberhaupt keine Module, das reduziert die Komplexitaet des Gesammtsystems und erleichtert die Fehlersuche, zumindest fuer mich.

Gruss
Arno

arzie
Beiträge: 134
Registriert: 17.02.2002 15:51:03

Beitrag von arzie » 08.11.2003 12:18:44

sas0r hat geschrieben:hi,

ne hab ich net,dieser befehl steht auch nicht bei eth0 .... siehe oben,so sieht die datei aus.

cu
Dann schreib mal 'auto eth0 eth1' in die erste Zeile.
Das sorgt dafuer dass die Karten zur Bootzeit initialisiert werden.

Der 3c59x Driver sollte der Passende fuer die Boomerang sein. Ist er vorhanden?

Antworten