Ich übertrage via Ethernet 100Mbit lokal Dateien, ohne dass es auf beiden Rechnern durch User weiteres los ist. Ich habe "gefühlsmäßig" in Erinnerung, dass das schon mal viel schneller ging. Sind diese Zeiten ok? Mir ist schon klar, dass die HD am sendenden Rechner nicht die schnellste ist. Engpass sollte aber trotzdem das Netzwerk sein, oder? 030705et.tgz 100% |*****************************| 3587 KB 01:27 030705et.tgz 100% |*****************************| 3587 KB 01:33 030705ul.tgz 100% |*****************************| 1966 KB 00:49 030705ul.tgz 100% |*****************************| 1966 KB 00:52 030705ho.tgz 100% |*****************************| 6243 KB 02:49 030705ho.tgz 100% |*****************************| 6243 KB 02:43 Sendender Rechner: hdparm /dev/hda /dev/hda: multcount = 16 (on) IO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 8 (on) geometry = 1048/255/63, sectors = 16841664, start = 0 hdparm -t /dev/hda3 /dev/hda3: Timing buffered disk reads: 64 MB in 4.72 seconds = 13.56 MB/sec Empfangender Rechner: hdparm /dev/hdb /dev/hdb: multcount = 16 (on) IO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 8 (on) geometry = 9729/255/63, sectors = 156301488, start = 0 hdparm -t /dev/hdb9 /dev/hdb9: Timing buffered disk reads: 64 MB in 1.60 seconds = 40.00 MB/sec Al
Hi Al, On Sat, Jul 05, 2003 at 05:01:18PM +0200, Al Bogner wrote:
Ich habe "gefühlsmäßig" in Erinnerung, dass das schon mal viel schneller ging. Sind diese Zeiten ok? Mir ist schon klar, dass die
030705et.tgz 100% |*****************************| 3587 KB 01:27
d@l:~> time scp -P 6666 d@g:/mnt/share/rand.img rand.img. 100% |***************************| 703 MB 01:23 real 1m24.002s user 0m0.130s sys 0m8.230s ich gehe mal davon aus, das dir der Full/Half Dublex Mode da in die Suppe spuckt. Achte darauf das beide Karten den gleichen Modus verwenden. Möglichkeit 1: mii-tool Möglichkeit 2: dos setup.exe für die Netzwerkkarte (ezsetup o.Ä.) Oder Dein Rechner (der die Daten verschlüsselt) ist etwas langsam (CPU) Greetings Daniel -- -wer sich nicht bewegt spürt seine fesseln nicht-
On Saturday 05 July 2003 18:34, Daniel Lord wrote:
030705et.tgz 100% |*****************************| 3587 KB 01:27
rand.img. 100% |***************************| 703 MB 01:23
ich gehe mal davon aus, das dir der Full/Half Dublex Mode da in die Suppe spuckt. Achte darauf das beide Karten den gleichen Modus verwenden.
Möglichkeit 1: mii-tool
Das mii-tool ist nicht bei SuSE enthalten, oder habe ich es nicht gefunden? Ich werde mir das mal suchen und runterladen.
Möglichkeit 2: dos setup.exe für die Netzwerkkarte (ezsetup o.Ä.)
Oder Dein Rechner (der die Daten verschlüsselt) ist etwas langsam (CPU)
Na ja, es sind nicht die schnellsten Rechner, der sendende Rechner ist ein Celeron 800, der empfangende Rechner ein Celeron 1300. Am sendenden Rechner sind 2 Netzwerkkarten vorhanden: 00:0b.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 01) 00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Es wird aber nur eth0 mit der Intel-Karte verwendet. Am empfangenden Rechner wird eine Realtek-Karte verwendet: 02:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Al
On Saturday 05 July 2003 19:11, Al Bogner wrote:
Das mii-tool ist nicht bei SuSE enthalten, oder habe ich es nicht gefunden? Ich werde mir das mal suchen und runterladen.
Es ist schon vorhanden und zwar bei den net-tools. mii-tool -v eth0 eth0: no autonegotiation, 100baseTx-FD, link ok product info: National DP83840A rev 0 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control Ich habe dem System ein mii-tool -F 100baseTx-FD eth0 spendiert und nun liegt die Transfer-Geschwindigkeit bei den selben Dateien unter 0 Sekunden. Interessant ist, dass vor mii-tool -F mii-tool eth0 eth0: no autonegotiation, 100baseTx-FD, link ok ebenfalls angezeigt wurde. Ich verstehe auch nicht, warum mit -v "autonegotiation enabled" angezeigt wird, und ohne -v "no autonegotiation". Widerspricht sich das nicht? Eventuell kann es auch am swap gelegen sein. Da habe ich schon mehrmals festgestellt, dass News von leafnode nach einer Uptime von ca. 10h relativ langsam geladen werden, weil geswapt wurde. Ich weiß, dass 10h Uptime nicht lange sind, aber der Rechner wird täglich wegen Energiekosteneinsparung nachts runtergefahren. Der Rechner hat 256MB RAM und ohne X sollte das wohl genug sein. Gibt es eine Möglichkeit dem Rechner swap nur in "Notfällen" zu erlauben und sonst lieber den Puffer zu reduzieren? Al
Daniel Lord wrote:
ich gehe mal davon aus, das dir der Full/Half Dublex Mode da in die Suppe spuckt. Achte darauf das beide Karten den gleichen Modus verwenden. Möglichkeit 1: mii-tool Möglichkeit 2: dos setup.exe für die Netzwerkkarte (ezsetup o.Ä.)
Mein "Router" hat zum LAN hin eine RTL-8139. YAST erkennt die und sagt, das sei die eth0. Da ich dieses mii-tool bisher nicht kannte, hab ich mir grad mal die eth0 zeigen lassen: Die eth0 geht auf einen 10/100 MBit Switch ---------------------------------------------------- bla:~/.ssh # mii-tool -v eth0 eth0: 10 Mbit, half duplex, no link product info: vendor 00:00:00, model 0 rev 0 basic mode: 10 Mbit, half duplex basic status: no link capabilities: advertising: ---------------------------------------------------- und dann ---------------------------------------------------- bla:~/.ssh # mii-tool --force=100baseTx-FD eth0 bla:~/.ssh # mii-tool -v eth0 eth0: 10 Mbit, half duplex, no link product info: vendor 00:00:00, model 0 rev 0 basic mode: 10 Mbit, half duplex basic status: no link capabilities: advertising: ---------------------------------------------------- scp pumpt auch für 10MBit erwartungsgemäß 130 MB in 1:59 auf eine andere Kiste. Was kann ich noch tun ? Rechner Pentium 200 MMX SuSE 8.1
Hallo Andreas, On Sun, Jul 06, 2003 at 06:27:45AM +0200, Andreas wrote:
Möglichkeit 2: dos setup.exe für die Netzwerkkarte (ezsetup o.Ä.) ^^^^^^^^^^^^^^ [1] Das Tool schreibt die Einstellungen fest ins EEPROM der Netzwerkkarte.
Mein "Router" hat zum LAN hin eine RTL-8139. YAST erkennt die und sagt, das sei die eth0.
ifconfig sagt das auch?
Da ich dieses mii-tool bisher nicht kannte, hab ich mir grad mal die eth0 zeigen lassen:
Die eth0 geht auf einen 10/100 MBit Switch
Der Switch hat doch normalerweise eine Anzeige ob 100 oder 10 Mbit für den entsprechenden Link benutzt werden.
product info: vendor 00:00:00, model 0 rev 0 ^^^^^^^^ Da sollte etwas sinnvolles stehen. Das sind normalerweise die ersten 3 Stellen deiner MAC Adresse die den Hersteller bezeichnen.
basic mode: 10 Mbit, half duplex basic status: no link ^^^^^^^ Das bedeutet das kein Netzwerkkabel eingesteckt ist und/oder der Chipsatz nicht 100% erkannt/unterstützt wird. Wäre noch interessant was für eine Version des Realtek Chips du _genau_ hast. Evtl. gibt es im Netz auch eine neuere Version des mii-tools.
bla:~/.ssh # mii-tool --force=100baseTx-FD eth0
ein force sollte eigentlich nicht nötig sein. /sbin/mii-tool -A 100baseTx-FD eth1 Müsste völlig ausreichen.
scp pumpt auch für 10MBit erwartungsgemäß 130 MB in 1:59 auf eine andere Kiste.
Was kann ich noch tun ?
siehe [1] Greetings Daniel -- Darkness is falling, over my mind | http://www.againsttcpa.com/ My burning eyes are, deadly blind | http://www.notcpa.org/ Now there is nothing like it seem | http://chaosradio.ccc.de/cr78.html All illusion, only dreams........ --- Darkwell "Realm Of Darkness"
Daniel Lord wrote:
Möglichkeit 2: dos setup.exe für die Netzwerkkarte (ezsetup o.Ä.) ^^^^^^^^^^^^^^ [1] Das Tool schreibt die Einstellungen fest ins EEPROM der Netzwerkkarte.
Ups ... das is so ne 0815 RTL von Atelco, die hier schon ewig rumeiert, ohne dass ich mir darum Gedanken gemacht hab, ob die auch tatsächlich die 100 mbit schaufelt, die sie müßte. Ich hab noch nicht so lang Progrmme dort liegen, die ich von dort starte und OpenOffice kommt ja schon immer, auch lokal, etwas träge hoch.
Mein "Router" hat zum LAN hin eine RTL-8139. YAST erkennt die und sagt, das sei die eth0. ifconfig sagt das auch?
---------------------------------------------------------------- eth0 Protokoll:Ethernet Hardware Adresse 00:50:BF:E2:35:0E inet Adresse:192.168.0.254 Bcast:192.168.0.255 Maske:255.255.255.0 inet6 Adresse: fe80::250:bfff:fee2:350e/10 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:64591 errors:0 dropped:0 overruns:0 frame:0 TX packets:120277 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:100 RX bytes:6058663 (5.7 Mb) TX bytes:156494641 (149.2 Mb) Interrupt:10 ----------------------------------------------------------------
Da ich dieses mii-tool bisher nicht kannte, hab ich mir grad mal die eth0 zeigen lassen: Die eth0 geht auf einen 10/100 MBit Switch Der Switch hat doch normalerweise eine Anzeige ob 100 oder 10 Mbit für den entsprechenden Link benutzt werden.
Das sagt nicht wirklich viel aus. Ich hatte auch mal eine 16 Bit PCMCIA mit rtl8139, die auch nur 10 MBit Bandbreite lieferte, obwohl alle Lichter und Softwaremeldungen korrekt aussahen. Mit einer 32Bit PC-Card liefs dann rund. An dem Switch leuchten an dem Port alle 3 LEDs. An der Karte aber nur eine LED. Kabel habe ich grad auch getauscht. Sehr seltsam.
product info: vendor 00:00:00, model 0 rev 0 basic status: no link ^^^^^^^ Das bedeutet das kein Netzwerkkabel eingesteckt ist und/oder der
Also da is schon ein Kabel dran ;) Ich hab grad mal via SSH die eth1 mit 'ifconfig eth1 down' gestoppt.
Chipsatz nicht 100% erkannt/unterstützt wird. Wäre noch interessant was für eine Version des Realtek Chips du _genau_ hast.
Wo steht das ... mal vom Chip auf der Karte abgesehn.
bla:~/.ssh # mii-tool --force=100baseTx-FD eth0 ein force sollte eigentlich nicht nötig sein. /sbin/mii-tool -A 100baseTx-FD eth1 Müsste völlig ausreichen.
---------------------------------------------------------------- bla:~ # /sbin/mii-tool -A 100baseTx-FD eth0 restarting autonegotiation... bla:~ # /sbin/mii-tool eth0 eth0: 10 Mbit, half duplex, no link ---------------------------------------------------------------- bla:~ # /sbin/mii-tool -F 100baseTx-FD eth0 bla:~ # /sbin/mii-tool eth0 eth0: 10 Mbit, half duplex, no link ---------------------------------------------------------------- Gruß Andreas
Hallo Andreas, On Sun, Jul 06, 2003 at 01:57:18PM +0200, Andreas wrote:
Daniel Lord wrote:
Möglichkeit 2: dos setup.exe für die Netzwerkkarte (ezsetup o.Ä.) ^^^^^^^^^^^^^^ [1] Das Tool schreibt die Einstellungen fest ins EEPROM der Netzwerkkarte.
eth0 Protokoll:Ethernet Hardware Adresse 00:50:BF:E2:35:0E ^^^^^^^^ Das sollte auch bei product info: vendor stehen.
Das sagt nicht wirklich viel aus. Ich hatte auch mal eine 16 Bit PCMCIA mit rtl8139, die auch nur 10 MBit Bandbreite lieferte, obwohl alle Lichter und Softwaremeldungen korrekt aussahen. Mit einer 32Bit PC-Card liefs dann rund.
*g* wenn der Bus nur 10Mbit Bandweite hat bekommst halt keine 100 rüber.
Sehr seltsam.
nö
Wo steht das ... mal vom Chip auf der Karte abgesehn.
evtl. findest Du was in /proc/pci ... aufschrauben ist besser Versuch es mal mit dem DOS Tool und ausserdem per FTP Greetings Daniel -- #!/bin/sh echo 'Linux Must Die!' | wall dd if=/dev/zero of=/vmlinuz bs=1 \ count=`du -Lb /vmlinuz | awk '{ /^([0-9])+/ ; print $1 }'` shutdown -r now
Andreas wrote:
Mein "Router" hat zum LAN hin eine RTL-8139. YAST erkennt die und sagt, das sei die eth0. Da ich dieses mii-tool bisher nicht kannte, hab ich mir grad mal die eth0 zeigen lassen:
[... mii-tool ändert nichts ...]
scp pumpt auch für 10MBit erwartungsgemäß 130 MB in 1:59 auf eine andere Kiste.
Was kann ich noch tun ?
Rechner Pentium 200 MMX SuSE 8.1
Blöde Frage: Deine Netzwerkkarte ist schon eth_0_ ? Guck Dir mal die Seite http://www.scyld.com/diag_index.html an. Dort gibt es noch viele andere Tools für diverse Kartenchipsätze. cu
Hallo Markus, On Sun, Jul 06, 2003 at 11:34:36AM +0200, Markus Kolb wrote:
Andreas wrote:
Rechner Pentium 200 MMX ^^^^^^^^^^^^^^^ das habe ich vorher doch glatt überlesen. Ich fürchte das ist Dein Problem. Verschick die Daten mal per ftp. Dann bekommst Du warscheinlich eine bessere Performance.
Mein Athlon 800 mit 512MB SDRAM ist beim verschicken mit ssh auf 98% Systemlast. Greetings Daniel -- Niemand hat mich gefragt, ob ich geboren werden will! jetzt seht ihr was ihr davon habt.
Hallo, On Sun, 06 Jul 2003, Daniel Lord schrieb:
On Sun, Jul 06, 2003 at 11:34:36AM +0200, Markus Kolb wrote:
Andreas wrote:
Rechner Pentium 200 MMX ^^^^^^^^^^^^^^^ das habe ich vorher doch glatt überlesen. Ich fürchte das ist Dein Problem. Verschick die Daten mal per ftp. Dann bekommst Du warscheinlich eine bessere Performance.
Mein Athlon 800 mit 512MB SDRAM ist beim verschicken mit ssh auf 98% Systemlast.
Die Realtek 81XX chips waelzen fast alle Arbeit auf die CPU ab, wenn dann noch die Kodierung fuer ssh dazu kommt, lasten 100 MBit durchaus die CPU aus. Die meisten anderen Chips sind in der Beziehung wesentlich performanter. -dnh -- 171: PMPO Leistungsabgabe bei spontaner Verbrennung (Arndt Spelten)
Daniel Lord wrote:
Hallo Markus,
On Sun, Jul 06, 2003 at 11:34:36AM +0200, Markus Kolb wrote:
Andreas wrote:
Rechner Pentium 200 MMX
^^^^^^^^^^^^^^^ das habe ich vorher doch glatt überlesen. Ich fürchte das ist Dein Problem. Verschick die Daten mal per ftp. Dann bekommst Du
Das ist Andreas' Problem... ;)
Andreas wrote:
Rechner Pentium 200 MMX
Daniel Lord wrote:
das habe ich vorher doch glatt überlesen. Ich fürchte das ist Dein Problem. Verschick die Daten mal per ftp. Dann bekommst Du
SAMBA bzw Win2000 ist auch net schneller. Im Win2K habe ich sogar 100 MBit Voll Duplex fest einstellen können. Die Performance vom Netz ist aber dennoch 10 MBit gemäß. Markus Kolb wrote:
Das ist Andreas' Problem... ;)
Nö, also der Pentium isses nicht höchstens das Mainboard kontra NIC. Die NIC kommt offenbar nicht in den 100 MBit Modus. Paradoxer Weise leuchtet am Switch das 100 MBit LED aber nicht an der Karte. Noch mal zur allgemeinen Erbauung : ----------------------------------------------------- bla:/data1/src # ./rtl8139-diag -aa -ee -mm rtl8139-diag.c:v2.11 4/22/2003 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a RealTek RTL8139 adapter at 0x6500. The RealTek chip appears to be active, so some registers will not be read. To see all register values use the '-f' flag. RealTek chip registers at 0x6500 0x000: e2bf5000 00000e35 80000000 41000000 0008a09a 0008a03c 0008a03c 0008a03c 0x020: 01862000 01862600 01862c00 01863200 09a20000 0d0a0000 fb68fb58 0000c07f 0x040: 74000680 0000f78e 9114b814 00000000 000d1400 00000000 0088c100 00100000 0x060: 1100f00f 01e1782d 000145e1 00000000 00000004 000307c8 b0f243b9 8a36df43. Realtek station address 00:50:bf:e2:35:0e, chip type 'rtl8139C'. Receiver configuration: Normal unicast and hashed multicast Rx FIFO threshold 2048 bytes, maximum burst 2048 bytes, 32KB ring Transmitter enabled with NONSTANDARD! settings, maximum burst 1024 bytes. Tx entry #0 status 0008a09a complete, 154 bytes. Tx entry #1 status 0008a03c complete, 60 bytes. Tx entry #2 status 0008a03c complete, 60 bytes. Tx entry #3 status 0008a03c complete, 60 bytes. Flow control: Tx disabled Rx disabled. The chip configuration is 0x14 0x0d, MII half-duplex mode. No interrupt sources are pending. Decoded EEPROM contents: PCI IDs -- Vendor 0x10ec, Device 0x8139. PCI Subsystem IDs -- Vendor 0x1113, Device 0xec01. PCI timer settings -- minimum grant 32, maximum latency 64. General purpose pins -- direction 0xe1 value 0x12. Station Address 00:50:BF:E2:35:0E. Configuration register 0/1 -- 0x0d / 0xc2. EEPROM active region checksum is 08d2. EEPROM contents (64 words): 0x00: 8129 10ec 8139 1113 ec01 4020 e112 5000 0x08: e2bf 0e35 0d14 f7c2 8801 43b9 b0f2 071a 0x10: df43 8a36 df43 8a36 43b9 b0f2 1111 1111 0x18: 0000 0000 0000 0000 0000 0000 0000 0000 ... The RTL8139 does not use a MII transceiver. It does have internal MII-compatible registers: Basic mode control register 0x1100. Basic mode status register 0x782d. Autonegotiation Advertisement 0x01e1. Link Partner Ability register 0x45e1. Autonegotiation expansion 0x0001. Disconnects 0x0000. False carrier sense counter 0x0000. NWay test register 0x0004. Receive frame error count 0x0000. -----------------------------------------------------
Al Bogner wrote:
Ich übertrage via Ethernet 100Mbit lokal Dateien, ohne dass es auf beiden Rechnern durch User weiteres los ist.
Ich habe "gefühlsmäßig" in Erinnerung, dass das schon mal viel schneller ging. Sind diese Zeiten ok? Mir ist schon klar, dass die HD am sendenden Rechner nicht die schnellste ist. Engpass sollte aber trotzdem das Netzwerk sein, oder?
030705et.tgz 100% |*****************************| 3587 KB 01:27
Das ist so in etwa halbe DSL Downloadgeschwindigkeit. Hast Du das Problem z.B. bei ftp oder http auch? Dann solltest Du mal das Netzwerk durchchecken. Ich kenne das Phänomen aber auch. Allerdings werden bei mir immerhin 1MBps übertragen und ich schiebe das Problem auf pscp von Putty (einem scp für MS Windows), da es nur bei der Verwendung mit diesem bei mir auftritt. Bei der Übertragung mit Linux-scp wird max. Übertragungsrate erreicht. Du scheinst ja auf beiden Rechnern Linux zu haben und daher kann ich leider keine weiteren Tipps geben. cu
Am Samstag, 5. Juli 2003 18:44 schrieb Markus Kolb:
Ich kenne das Phänomen aber auch. Allerdings werden bei mir immerhin
Das ist auch ganz normal. Die Daten werden bei scp ja kodiert übertragen. Das bedeutet, dass a) Rechenkapazitäten benötigt werden b) Mehr Daten übertragen werden Dadurch kommt es zu deutlichen Reduzierungen im Durchsatz! Das beste Beispiel ist eine p640 auf Arbeit, auf die wir aus Sicherheitsgründen nur per ssh zugreifen. Die Kiste ist durch die Dienste, die auf der Kiste Laufen, ehh schon fast immer auf 100% Last und dadurch kommt es dazu, dass wir minimale Transferzeiten haben. Trotz schnellem Netz sind hohe Raten nicht zu erreichen. Und das bei einer Kiste, die sehr enorme IO Leistungen zu bieten hat! Konrad
On Saturday 05 July 2003 19:13, Konrad Neitzel wrote:
Am Samstag, 5. Juli 2003 18:44 schrieb Markus Kolb:
Ich kenne das Phänomen aber auch.
Das Mail ist bei mir noch nicht angekommen.
Das ist auch ganz normal. Die Daten werden bei scp ja kodiert übertragen. Das bedeutet, dass a) Rechenkapazitäten benötigt werden b) Mehr Daten übertragen werden
Die ursprünglichen Zeiten sind aber schon extrem daneben. Ich habe dieselben Dateien mittlerweile von einem anderen Celeron 800 zu diesem Celeron 1300 kopiert und jede Datei wurde unter 1 Sekunde kopiert. Ich werde mal die 2. Netzwerkkarte (Realtek statt Intel) probieren und sehen wie schnell es dann ist. Aber ich muß jetzt gleich weg. Al
Hallo! Am Samstag, 5. Juli 2003 19:35 schrieb Al Bogner:
Das ist auch ganz normal. Die Daten werden bei scp ja kodiert übertragen. Das bedeutet, dass a) Rechenkapazitäten benötigt werden b) Mehr Daten übertragen werden
Die ursprünglichen Zeiten sind aber schon extrem daneben.
Evtl. habe ich nicht gut genug gelesen, aber mehr als den Faktor 2 würde ich - wenn nicht massive Lastprobleme hinzu kommen - auch nie dulden.
Ich habe dieselben Dateien mittlerweile von einem anderen Celeron 800 zu diesem Celeron 1300 kopiert und jede Datei wurde unter 1 Sekunde kopiert.
Ich werde mal die 2. Netzwerkkarte (Realtek statt Intel) probieren und sehen wie schnell es dann ist. Aber ich muß jetzt gleich weg.
Ja - das wäre ein sehr guter Lösungsansatz in meinen Augen. Wenn das autoprobing z.B. schief läuft weil Switch und Netzwerkkarte sich nicht sauber einigen können, dann kriegt man ganz miese Raten bis hin zu gar keiner Verbindung. Mit den besten Grüßen, Konrad
Konrad Neitzel wrote:
Das beste Beispiel ist eine p640 auf Arbeit, auf die wir aus Sicherheitsgr?nden nur per ssh zugreifen. Die Kiste ist durch die Dienste, die auf der Kiste Laufen, ehh schon fast immer auf 100% Last und dadurch kommt es dazu, dass wir minimale Transferzeiten haben. Trotz schnellem Netz sind hohe Raten nicht zu erreichen. Und das bei einer Kiste, die sehr enorme IO Leistungen zu bieten hat!
Aber dann würde es sich doch empfehlen, den sshd mit ner höheren Priorität laufen zu lassen. Schließlich kostet die Wartezeit der Administratoren einen Haufen Geld, und bei der Gesammtleistung einer solchen IBM-Kiste sollten die anderen Dienste nur dabei mäßig gebremst werden, oder? cu cp
Am Samstag, 5. Juli 2003 19:40 schrieb Christoph Purrucker:
Konrad Neitzel wrote:
Das beste Beispiel ist eine p640 auf Arbeit, auf die wir aus Sicherheitsgr?nden nur per ssh zugreifen. Die Kiste ist durch die Dienste, die auf der Kiste Laufen, ehh schon fast immer auf 100% Last und dadurch kommt es dazu, dass wir minimale Transferzeiten haben. Trotz schnellem Netz sind hohe Raten nicht zu erreichen. Und das bei einer Kiste, die sehr enorme IO Leistungen zu bieten hat!
Aber dann würde es sich doch empfehlen, den sshd mit ner höheren Priorität laufen zu lassen. Schließlich kostet die Wartezeit der Administratoren einen Haufen Geld, und bei der Gesammtleistung einer solchen IBM-Kiste sollten die anderen Dienste nur dabei mäßig gebremst werden, oder?
Nunja - Wir machen daran kaum Administrative Arbeiten. Hier handelt es sich um den sogenannten "Masterserver" eines Software-Verteil Systemes. Und es würde keine echten Vorteile bringen. Na klar wäre es zum Teil schön, wenn man z.B. ein Office Paket in weniger als 2 - 3 Stunden zum Versand auf den Server bekommen könnte, aber das ist nicht unbedingt unser Hauptproblem im Softwareversand :-)) Aber dieses WE wurde eine neue Version eingespielt, die angeblich deutlich bessere Performance bieten soll ... also lassen wir uns mal überraschen :) (Was zeigt, dass ich hier normalerweise auch nur die Rolle eines Nutzers spiele.) Bei Al bringt dieses extreme Beispiel leider nichts, da er ja schon geschrieben hat, dass die Kisten bei ihm nicht unter Last laufen. Und die Raten sind ja um ein Vielfaches langsamer und nicht nur Faktor 2 oder so, so dass es nicht am erhöten Datenaufkommen liegen kann. Danke auf jeden Fall für diese Idee! Ich selbst bin auf diese Idee nicht gekommen - wobei dies allerdings auch nie ein vordergründiges Problem von unserer Seite war. Mit den besten Grüßen, Konrad
Konrad Neitzel wrote:
Am Samstag, 5. Juli 2003 18:44 schrieb Markus Kolb:
Ich kenne das Phänomen aber auch. Allerdings werden bei mir immerhin
Das ist auch ganz normal. Die Daten werden bei scp ja kodiert übertragen. Das bedeutet, dass a) Rechenkapazitäten benötigt werden b) Mehr Daten übertragen werden
Dadurch kommt es zu deutlichen Reduzierungen im Durchsatz!
Aber nicht um den Faktor 5 oder mehr bei aktuellen Rechnern, die ausser scp nichts machen; Da sollte genügend Rechenkapazität zur Verfügung stehen um die Bandbreite einer 100MBit Karte auszulasten.
Das beste Beispiel ist eine p640 auf Arbeit, auf die wir aus Sicherheitsgründen nur per ssh zugreifen. Die Kiste ist durch die Dienste, die auf der Kiste Laufen, ehh schon fast immer auf 100% Last und dadurch kommt es dazu, dass wir minimale Transferzeiten haben. Trotz schnellem Netz sind hohe Raten nicht zu erreichen. Und das bei einer Kiste, die sehr enorme IO Leistungen zu bieten hat!
Wie wär's mal ein paar Prozessoren mehr reinzupacken? cu
Am Samstag, 5. Juli 2003 19:57 schrieb Markus Kolb:
Das beste Beispiel ist eine p640 auf Arbeit, auf die wir aus Sicherheitsgründen nur per ssh zugreifen. Die Kiste ist durch die Dienste, die auf der Kiste Laufen, ehh schon fast immer auf 100% Last und dadurch kommt es dazu, dass wir minimale Transferzeiten haben. Trotz schnellem Netz sind hohe Raten nicht zu erreichen. Und das bei einer Kiste, die sehr enorme IO Leistungen zu bieten hat!
Wie wär's mal ein paar Prozessoren mehr reinzupacken?
Wäre hier bestimmt DIE Lösung. Leider ist diese Lösung mit gewissen Kosten verbunden, die dann halt auch übernommen werden müssten ... Mit den besten Grüßen, Konrad
Konrad Neitzel wrote:
Am Samstag, 5. Juli 2003 19:57 schrieb Markus Kolb:
Das beste Beispiel ist eine p640 auf Arbeit, auf die wir aus [...]
Wie wär's mal ein paar Prozessoren mehr reinzupacken?
Wäre hier bestimmt DIE Lösung. Leider ist diese Lösung mit gewissen Kosten verbunden, die dann halt auch übernommen werden müssten ...
Wann hast Du Geburtstag ? ;o) cu, schönes Wochenende noch Markus
participants (7)
-
Al Bogner -
Andreas -
Christoph Purrucker -
Daniel Lord -
David Haller -
Konrad Neitzel -
Markus Kolb