Neuigkeiten im RDE Web aus 2001 :
Sept 01 - UDMA Treiber für Netware
Durch Zufall haben wir einen IDE-UDMA Treiber (udma.nlm) für Netware gefunden. Eigentlich haben wir nach DLT Treibern gesucht, aber wie es mal so ist, man findet immer etwas mehr. Vorher haten wir 3 PROMISE IDE Controller gekauft, um mit deren "native!" DMA Treibern zu versuchen, die sagenhaften 20 Mbyte/sec Transfer- Geschwindigkeiten der 40 Giga Maxtor Platten unter Linux auch auf unserem Netware 4.11 Server zu realisieren. Vergeblich.
Juli 01 - Nach den dotCOM Flops kommt der SAN Flop.
Alle brauchen ein SAN (Storage over Network), wurde/wird prognostiziert und für viele ist es der letzte Strohhalm im Vertrieb. Wenn dann sonst nichts mehr geht, dann wird Unsinn verkauft. "Storage over IP" ist nach unseren Erfahrungen bisher genauso ein Flop wie "Voice over IP" im Internet. Das TCP/IP Protokoll war nie dafür geplant, große Datenmengen effizient über die Leitung zu jagen, geschweige denn definierte Antwortzeiten (kurze Latenzzeiten) zu gewährleisten. Haben Sie mal über VOIP mit dem Ausland telefoniert. Uns macht das fast irre, wenn die Gesprächsfetzen mit bis zu 3 Sekunden Verzögerung eintreffen, das ist ja nicht mal "Vorkriegstechnik". Und erst die Performance von SAN mit 100Mbit/s, die ist ja sogar schlechter als bei WIN NT4.0 Servern. Da bleiben wir noch lange bei unseren Netware 4.11 Servern.
"Da weiß man was man hat". ( lesen Sie auch Information Week Ausgabe 16 vom 26.7.01 Seite 14) Oder lesenSie mal etwas über Fibre-Channel hier.
Mai 01 - Die Finanzen:
Um den gestiegenen Anforderungen nach Eigenkapital gerecht zu werden, wurde in 2000 unser Stammkapital auf DM 130.000 aufgestockt. Die Ausweitung unserer Engagements hat es dann doch notwendig gemacht, das lange Festhalten an unserer 50.000er GmbH aufzugeben. So beißen sich der Wunsch nach Reduzierung der Haftung (darum eine GmbH) und dem Wunsch nach guten Beziehungen zu unserer Bank sowie einer problemlosen Belieferung durch die Lieferanten mit ausreichend Material.
April 01 - Der Gag mit dem goldenen Superlüfter
entpuppt sich nach und nach als Flopp. Nach unseren Messungen der Temperaturen an verschiedenen Kühlkörpern mit verschiedenen Prozessoren ist er meist ungünstiger in der Kühlleistung. Wir werden wieder zu den schwarzen Kühlkörpern mit U-Profil und großem Lüfter zurückkehren.
Auch mit den einst hochgelobten PCI Netzwerkkarten mit dem DEC / Intel Chip 21143 in Verbindung mit HP Hochleistungs-Switches gibt es Probleme. Diese Karten haben die Neigung, Daten zu zerstückeln und zeigen willkürliche Aussetzer bzw. Hänger.
Feb. 2001 - 100 MBit/sec Fast-Ethernet und 155 MBit/sec ATM Netzwerkstrecken aufgebaut.
Erfahrung beruht immer auf Wissen und Ausprobieren. So halten wir es auch mit der Netzwerk-technologie oberhalb 100 MBit/sec. Und die beste Erfahrung ist die, die man selbst gemacht hat. Wir haben bei uns im Haus zwei Highspeed Switches über 20m mit einer Duplex-Glasfaser Leitung verbunden. Die Leitung könnte bis 2km lang sein. Man sagt zwar, daß in der Glasfaser die Bits schneller (also mit Lichtgeschwindigkeit) "fließen", wir konnten es aber nicht feststellen. So bleibt 100 MBit eben 100 MBit.
Für weitere Tests haben wir zwei CICSO Lightstream 1010 Switches mit 155 Mbit/sec Fiberoptic- Einschüben unter einander verbunden. Diese Lightstreams gehören zum Feinsten, daß die Branche im ATM Switching zu bieten hat. Pro Switch sind 32 x 155 Mbit Ports oder 6 x 622 MBit Ports mit voller Bandbreite einsetztbar. Jeder Switch hat eine (Backplane-) Kapazität von 5 Gigabit/Sec Transferleistung.
Dez 2000 - AMD Durons und Athlons
Ein paar Informationen zum Stromverbrauch der neuen AMD Sockel A CPU´s finden Sie hier.
Wir haben übrigens keinen einzigen INTEL Pentium Slot 1 oder Slot 2 Server bei uns im Einsatz und auch nur einen einzigen AMD Slot A Server. Nachdem in der c´t schon recht früh das Konzept der Slot-Technik bei den CPU´s verworfen wurde, haben wir (mit etwas Glück) diesen Step übersprungen, zumal sich selbst ein Fachmann bei den Intel Slot Typen nicht mehr auskennt.
Okt 2000 - unsere MS SQL 6.5 Datenbank im Web
Für unseren eigenen Gebrauch und für diffizile Telefonate mit unseren Kunden haben wir uns einen Internet-Zugang zu unserem Producalc Rechnungswesen geschaffen. Die Sicherheitsanforderungen sind bei uns im Haus extrem hoch, sodaß wir durch einen Apache Webserver hindurch (unter Linux) auf einen NT 4.0 Server mit der Microsoft SQL Datenbank Version 6.5 zugreifen. Das ist aber nicht unsere Arbeits-Datenbank, sondern nur eine Hilfs-Datenbank auf einem 2. NT-Server, die per Replikation von der Haupt-Datenbank in eintägigen Intervallen aktualisiert wird.
Die Anbindung ist über eine Pearl Programmierung unter Linux vorgenommen worden. Dadurch ist es (hoffentlich) unmöglich, vom Web aus auf unsere Existens zuzugreifen. Da wir selbst dabei noch nicht 100% sicher sind, greifen wir nur auf den replizierten NT 2.Server zu. Ein Rückwärtsgang vom 2.Server auf den eigentlichen Hauptserver ist dann wirklich nicht mehr möglich, ich habe diese Module alle gelöscht.
Es könnte also ein WIN NT SQL Hauptserver in Ihrem Unternehmen z.B. in Berlin stehen, der seine Daten nächtlich auf einen NT SQL Server in unserer Technik per ISDN Direktanwahl repliziert und erst diese Daten werden eingeschränkt und ganz gezielt im Internet zur Verfügung gestellt.
Diese Technik ist zwar enorm produktiv, aber von der Installation und Logistik her nicht mehr trivial. Wer Ihnen da etwas Anderes erzählt, von dem werden Sie definitiv belogen. Insbesondere die Online Datensicherung während des laufenden Betriebs hat es in sich und die ist genauso wichtig wie die Zugangs-Sicherheit der SQL-Server.
Wir werden jetzt versuchen, unsere Datenbank auf MS SQL 7.0 bzw SQL 2000 hochzufahren. Da hapert es aber noch an einem funktionierenden 32 Bit ODBC Treiber unter Linux.
Aug/2 2000 Benchmark Tests mit 10/100 MBit/sec Ethernet-Karten mit DEC Chip 21143
Für diese Benchmaks benutzen wir unser altes bewährtes DOS Tool "LLSEEK.EXE", das Sie auch von diesem Server herunterladen können. Dabei wird auf jedweden Overhead wie Grafik oder Windows oder anderem Schnickschnack verzichtet, sodaß die volle CPU Leistung für die Messungen zur Verfügung steht.
Unter bestimmten Einstellungen wird die reine Netto-Übertragungrate der Netzwerkkarten in Abhängigkeit von der zu übertragenden Netto-Blockgröße ermittelt.
| Hub/Switch Fabrikat alle 10/100 MBit/sec und full duplex |
Compushack Fastline II DEC 21143 PD 16 KB Blocks |
CNET CNE100E DEC 21143 PD 16 KB Blocks |
Compushack Fastline II DEC 21143 PD 200Byte Blocks |
CNET CNE100E DEC 21143 PD 200Byte Blocks |
Hub/Switch Gerätepreis ca. in DM |
| Karte-zu-Karte direkt (crossover) |
9,68 MByte/sec | 9,68 MByte/sec | 1,030 MByte/sec | 1,025 MByte/sec | 0.- |
| 3COM 8Port Hub TP800 (nur 100 MBit) |
9,6 MByte/sec | 9,6 MByte/sec | 1,020 MByte/sec | 1,020 MByte/sec | ehemals ca 300.- |
| 8 Port Switch Switchline 8EL |
8,95 MByte/sec | 8,5 MByte/sec | 0,88 MByte/sec | 0,87 MByte/sec | ca 300.- |
| 12 Port Switch LevelOne FSW 1204 |
8,93 MByte/sec | 8,9 MByte/sec | 0,870 MByte/sec | 0,87 MByte/sec | ca1000.- |
| 40/80 Port Switch HP 4000M managed |
8,91 MByte/sec | 8,8 MByte/sec | 0,875 MByte/sec | 0,87 MByte/sec | 7800.- |
Bei der IPX/SPX Messung von Karte zu Karte ohne Hub/Switch mit einem Cat5 Crossover Kabel erreichen wir die absolute maximale Transferrate von ca 9,6 Megabyte/Sekunde netto, also ohne den Protokoll-Overhead.
Bei einem Hub mit nur 2 Stationen haben wir fast keinen Verlust, bei jeder weiteren Station geht die Datenrate drastisch (dramatisch) in die Knie.
Bei einem Switch haben wir bei zwei Stationen schon ca 10% Verlust gegenüber einem Hub oder einer (Crossover-) Diektverbindung aber der Verlust geht bei weiteren Stationen moderat zurück, außer, wenn alle Station auf den einen Server zugreifen wollen. Dann ist dieser Server-Strang das Nadelör.
In unserer internen RDE und IPW-POP Technik betreiben wir jetzt an unserem HP 4000M mehr als 17 Server mit unterschiedlichen Protokollen (TCP/IP und IPX/SPX) und bis zu 9 Arbeitsstationen mit 4 HP DAT 6fach-Wechslern. Bei unseren weiteren Messungen hat sich gezeigt, daß die Backbone-Leistung des HP 4000M einschließlich seiner Management-Funktionen die größten Reserven hatte, auch wenn die maximale Portzahl noch nicht ausgenutzt wird.
Da wir den HP Switch 4000 mit einem HP Switch 2000 kaskadiert haben, haben wir einen weiteren "Anfangsverlust" von 10% schon bei einer einzigen Punkt zu Punkt Verbindung. Das nehmen wir aber in Kauf, da diese (insgesamt -18%) Geschwindigkeit von da an extrem stabil bleibt.
Die kleineren Switches gingen bei 4 zu 4 Stationen dannn doch auf ca 60% der maximalen Leistung zurück.
- Hier der Bildschirm in einer WIN98SE DOS-Box. Mehr Informationen gibt es hier.
Die Historie ist noch viel länger.
Bitte wählen Sie ein Jahr oben links im Menü.