2te Netzwerkkarte einrichten
2te Netzwerkkarte einrichten
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
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
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 ?
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 ?
- pdreker
- Beiträge: 8298
- Registriert: 29.07.2002 21:53:30
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Nürnberg
Warum?Aber einen Netzwerktreiber als Modul halte ich nicht fuer optimal. Lieber fest in der Kernel kompilieren.
Patrick
Definitely not a bot...
Jabber: pdreker@debianforum.de
Jabber: pdreker@debianforum.de
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
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
- pdreker
- Beiträge: 8298
- Registriert: 29.07.2002 21:53:30
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Nürnberg
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.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.
Patrick
Definitely not a bot...
Jabber: pdreker@debianforum.de
Jabber: pdreker@debianforum.de
- pdreker
- Beiträge: 8298
- Registriert: 29.07.2002 21:53:30
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Nürnberg
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
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
Jabber: pdreker@debianforum.de
Hm, hast Du auch einsas0r hat geschrieben:was mach ich falsch ? evtl. das modul noch angeben ?
Code: Alles auswählen
auto eth1
Moin Patrick,
wann gehst Du so in's Bett?
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.
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).
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
wann gehst Du so in's Bett?
Hab auch gleich mal reingeschaut und waere ohne deine Erleuterung, zumindest fuer Intel CPUs, warscheinlich erstmal auf dem Holzweg gelandet.Details findet man in Documentation/cachetlb.txt im Kernel Source
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.
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.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...
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).
Vergleichbar mit den Motorola-Traps?[*] Ich habe gerade nochmal geschaut: softirq heisst dieses Konzept wenigsten im 2.6 Kernel...
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
Dann schreib mal 'auto eth0 eth1' in die erste Zeile.sas0r hat geschrieben:hi,
ne hab ich net,dieser befehl steht auch nicht bei eth0 .... siehe oben,so sieht die datei aus.
cu
Das sorgt dafuer dass die Karten zur Bootzeit initialisiert werden.
Der 3c59x Driver sollte der Passende fuer die Boomerang sein. Ist er vorhanden?