An einen PC mit Win 10 pro melde ich mich ohne Paßwort an.
Auf diesen PC möchte ich per RDP zugreifen (RDP ist aktiviert).
Ich bekomme aber immer eine seltsame Fehlermeldung.
Ich vermute den Grund darin, daß der PC kein Paßwort hat.
Wenn dem so ist:
Wie/wo kann ich dem PC ein Paßwort verpassen?
Oder wie/wo kann ich einen neuen User mit Paßwort anlegen?
Oder wie/wo kann ich einen neuen User mit Paßwort anlegen?
In dem du in die Benutzerverwaltung gehst. Startmenü aufklappen, "Weitere Benutzer" buchstabenweise eintippen bis die "Andere Benutzer anlegen..." auftaucht.
Kommandozeile als
Admin öffnen und folgenden Befehl eingeben: net user Benutzername
Passwort /add
Habe ich durchgeführt, es gab auch eine Rückmeldung mit irgendwas erfolgreich.
Jetzt bootet der PC zum Sperrbildschirm, fragt nach einem PW, aber ich komme einfach durch Drücken von Return oder Klicken auf den Sperrbildschirm auf den Desktop...
Bei RDP klappt die Anmeldung natürlich nicht.
Falls es irgendwie damit zu tun haben sollte:
Der User ist der, den das (vorinstallierte) Windows hatte. Diesen habe ich über die Systemsteuerung umbenannt.
Verstehe ich irgendwie nicht.
Für einen anderen PC habe ich bei RDB einfach Computername, User und PW
eingegeben und es lief...
Google verrät an 999 Stellen:
Wenn ein Passwort auf dem Remote-Computer geändert bzw. neu eingerichtet worden ist, muss es dort lokal mindestens einmal genutzt werden, damit es dort in den Cache gelangt. Erst dann kann man es aus der Ferne nutzen.
(Eine durchaus sinnvolle Schutzmaßnahme.)
Wenn ein Passwort auf dem Remote-Computer geändert bzw. neu eingerichtet
worden ist, muss es dort lokal mindestens einmal genutzt werden, damit
es dort in den Cache gelangt.
Und wie wird das PW "genutzt"?
Wie ich schon schrieb, komme ich durch einen Klick oder Returndruck auf den Sperrbildschirm direkt auf die Win-Oberfläche!
Auf der Windows-Oberfläche ins Startmenü gehen, dort "Bentzer wechseln"(*). Den neuen Benutzer auswählen und dich einmal anmelden. Dabei wird eine Warnung aufpoppen (anderer Benutzer aktiv, ...). Akzeptieren und Anmeldung fortsetzen. Dann bist du neben dem Hauptbenutzer auch unter dem "neuen" Benutzer angemeldet. Wenn die Anmeldung dur h ist, kannst du dich gleich wieder anmelden. Dann kommt der Anmeldenbildschirm wieder, aber diesmal mit einer Auswahl von zwei Benutzern: dem Standard Benutzer und dem Neuen. Hier einfach den Standardbenutzer auswählen und Return drücken. Und alles ist wie gewohnt. Jetzt geht auch die Remote-Anmeldung.
PS: Ich sitze gerade nicht vor dem PC. Daher kann ich die exakten Begriffe nicht prüfen. Aber sinngemäß stimmt das schon so, wie oben beschrieben.
Tja, die Nachteile und Quirks von RDP, einer der größten: Der RDP-Benutzer ist immer jemand anders, will sagen: da meldet sich jemand mit seinem eigenen Bildschirm und eigener Tastatur an, den ich als Benutzer an der Maschine selbst weder sehen noch beeinflussen kann.
Mit VNC oder Teamviewer dagegen ist man der der davorsitzt, nur eben woanders. Wesentlich einfacher und übersichtlicher.
War RDP tatsächlich gezielt gewollt, oder ging es nur um "das ist eingebaut, das kostet nix"?
Nix mit vorher lokal anmelden und Cache. Lokales Konto anlegen und Benutzer in die Remotedesktopbenutzer-Gruppe aufnehmen. Dann kann man sich sofort remote anmelden. Einziges Problem: Windows Professional lässt nur einen Benutzer gleichzeitig zu. Ein noch lokal angemeldeter Benutzer wird nach 30 Sekunden abgemeldet.
Windows Professional
lässt nur einen Benutzer gleichzeitig zu. Ein noch lokal angemeldeter
Benutzer wird nach 30 Sekunden abgemeldet.
Ja, via RDP kann nur "einer gleichzeitig" rein. Der lokale bleibt aber m.W. aktiv?
Oder wurde das irgendwann in Win11 geändert? Ich habs früher™ mal irgendwann getestet, da ging es stundenlang parallel. Nur das beide User nichts voneinander wissen.
Wie ich schon schrieb, komme ich durch einen Klick oder Returndruck auf
den Sperrbildschirm direkt auf die Win-Oberfläche!
Nutzen tut man ein PW, indem man sich damit anmeldet.
Wenn du ohne PW oder andere Legitimation auf den Desktop gelangst, hast du dich nicht als ein Nutzer angemeldet, an den du ein Passwort vergeben hast.
Vielleicht hast du auch die Rechner verwechselt. Jeder Rechner hat eine eigene Nutzerdatenbank mit eigenen Passwörtern. Auf dem fernzusteuernden PC muss ein Nutzer mit Passwort angelegt sein, und auf dem fernsteuernden Rechner musst du diese beiden eingeben (nicht anlegen).
Ja, via RDP kann nur "einer gleichzeitig" rein. Der lokale bleibt aber
m.W. aktiv?
Oder wurde das irgendwann in Win11 geändert?
Ich glaube, 1x lokal + 1x RDP geht schon seit Windows XP nicht mehr.
Wenn man sich per RDP einloggt, wird der lokale User ausgeloggt, bzw. wenn es derselbe User ist, wird die vorhandene Session durch den RDP-Client übernommen.
Wenn man sich per RDP einloggt, wird der lokale User ausgeloggt, bzw.
wenn es derselbe User ist, wird die vorhandene Session durch den
RDP-Client übernommen.
Wer schon IT kannte, als die noch EDV hieß, für den ist das, was RDP macht, eine völlig normale Sache.
Die Client-Server-Struktur des Großrechner-Bereichs: ein zentraler Rechner hoher Leistung (der "Server"), an den etliche Terminals (die "Clients") mit wenig oder ganz ohne eigene Intelligenz angeschlossen sind. Die Nutzer an diesen dummen Terminals nutzen jeder für sich Anwendungsprogramme, die komplett auf dem Server laufen. Der Server hat in der Regel gar keinen Bildschirm und keine Tastatur; für Wartungsarbeiten loggt sich der Admin an einem der Terminals ein.
Nach genau demselben Prinzip funktioniert RDP: Man sitzt an einem Terminal und nutzt Anwendungsprogramme, die auf einem entfernten PC laufen. Nur aus praktischen/finanziellen Gründen ist das Terminal ein normaler PC (mit dem man auch anderes tun kann) und kein Terminal ohne Intelligenz, das man ja für nichts anderes gebrauchen könnte.
Man sieht auf dem Monitor ein Bild, das so aussieht, als wäre es das Desktop-Bild des Windows auf dem Server-PC. Das ist es aber gar nicht, weil das gar nicht existiert (der Server hat keinen Monitor oder zeigt dort keinen Desktop an), das wird nur simuliert. Deswegen gibt es da eigentlich gar keinen zweiten Nutzer, der am Server sitzt und mit dem der erste Nutzer kommunizieren könnte.
Was VNC, Teamviewer u. Ä. machen, ist etwas völlig anderes: Da geht es darum, dass zwei Nutzer miteinander kommunizieren, und nicht darum, die Leistung eines entfernten Servers zu nutzen. Eine völlig andere Aufgabenstellung/Zielsetzung.
Was VNC, Teamviewer u. Ä. machen, ist etwas völlig anderes:
Eben genau das war meine Frage: will man tatsächlich einen normalen PC als Server nutzen und einen zweiten Arbeitsplatz da per RDP realisieren, oder will man "ich kann da gerade nicht sitzen, will aber das machen was ich sonst da mache".
Im privaten/nicht-kommerziellen Umfeld ist das zu 90% letzteres.
Tja, die Nachteile und Quirks von RDP, einer der größten: Der
RDP-Benutzer ist immer jemand anders
Nö, nö. Es ist schon derselbe Benutzer. Nur eben eine andere Session.
Mit VNC oder Teamviewer dagegen ist man der der davorsitzt, nur eben
woanders.
Auch das kann RDP. Nennt sich dann nicht "remote desktop" sondern "remote help". Und das können (im Unterschied zu remote desktop) auch die kastrierten Home-Versionen von Windows.
Allerdings hat MS die Prozedur zur Kontaktaufnahme so kompliziert gestaltet, dass die Sache dadurch nahezu unbenutzbar ist. Deswegen wurde und wird dies auch so gut wie nie in der Praxis benutzt.
War RDP tatsächlich gezielt gewollt
Ja, nomen est omen. Es ging darum, einem den eigenen(!) Desktop auch aus der Ferne bereit zu stellen. Und wenn man in der Ferne ist, kann man unmöglich auch gleichzeitig lokal sein. Also wird eine eventuell noch laufende lokale Session suspendiert, wenn die Anmeldung zu einer remote Session erfolgt.
Allerdings hat das im Kern natürlich pekuniäre Gründe. Der eigentliche Grund ist, dass die Client-Versionen von Windows grundsätzlich nur eine aktive Session erlauben. Die Server-Versionen hingegen erlauben immerhin zwei. Mehr geht nur mit dem (extrem teuren) Terminal-Server, den MS aus naheliegenden Gründen natürlich sehr gern verkaufen würde.
Eben genau das war meine Frage: will man tatsächlich einen normalen PC
als Server nutzen und einen zweiten Arbeitsplatz da per RDP realisieren,
oder will man "ich kann da gerade nicht sitzen, will aber das machen was
ich sonst da mache".
Ja und? Das geht hervorragend mit RDP. Meldet man sich mit dem gleichen Benutzerkonto an, wie das, was vorher lokal am Rechner angemeldet war, übernimmt man diese Sitzung.
Und wenn der Rechner, von dem man sich via RDP anmeldet, einen höher auflösenden Monitor hat, dann kann man diese Auflösung auch nutzen -- selbst wenn am fernzusteuernden Monitor nur 'ne olle VGA-Gurke mit 640x480 hängt. Das geht auch mit mehreren Monitoren.
Und wenn man dann wieder direkt vor dem Rechner sitzt, kann man die RDP-Sitzung übernehmen - einfach lokal anmelden, fertig.
In dieser Beziehung ist RDP ganz erheblich besser als VNC, Teamviewer und Co., denn die können nur mit der lokal vorgegebenen Monitorauflösung arbeiten.
Im übrigen kann RDP auch verwendet werden, um einem lokal angemeldeten Benutzer "über die Schulter" zu schauen (was für eine Supportfall relevant ist), das geht mit der Kommandozeilenoption "shadow". Will man auch steuernd eingreifen, brauchts /control.
Ja und? Das geht hervorragend mit RDP. Meldet man sich mit dem gleichen
Benutzerkonto an, wie das, was vorher lokal am Rechner angemeldet war,
übernimmt man diese Sitzung.
Stimmt, das hatte ich in meinem Posting falsch dargestellt. Die eigene Session kann man übernehmen (das ist sogar das Standardverhalten). Was ich schrieb, betrifft also nur die Sessions anderer Benutzer. Die werden suspendiert.
Ich glaube, 1x lokal + 1x RDP geht schon seit Windows XP nicht mehr.
In der ersten Version von XP, also die ohne Servicepack, war es tatsächlich noch möglich. Hat mich damals sehr gewundert, denn diese Funktionalität verkaufte MS teuer mit dem Terminalserver (jetzt Remote Desktop Host). Wie auch immer, der "Fehler" wurde in Redmond schnelle bemerkt und mit dem Servicepack 1 behoben.
@Topic
Der Zugriff über das Netzwerk ohne Kennwort ist per Default gesperrt. Kann man über Gruppenrichtlinien ändern:
gpedit.msc ausführen (lokale Gruppenrichtlinien)
Richtlinien für lokaler Computer
Windows-Einstellungen
Lokale Richtlinien
Sicherheitsoptionen
"Konten: Lokale Kontenverwendung von leeren Kennwörtern auf Konsolenanmeldung beschränken" -> auf Deaktiviert setzen
kommst Du nicht auf die Idee, diese Fehlermeldung zu zitieren?
Meinst du, wenn ich das abends zuhaus probiere, kann ich mich dann morgens auf Arbeit noch an den Wortlaut der Meldung erinnern?
Was ist denn das Spezielle am ersten/einzigen Win-User?
Ich habe den Computernamen irgendwo in den Systemeinstellungen (Taskleiste links Rechtsklick) geändert. Irgendwo dort habe ich auch den Usernamen geändert (finde die Stelle aber gerade nicht mehr...).
Der Username wurde aber nicht vollständig geändert, irgendwo spukte immer noch der ursprünglicher Username rum.
Unter "Computerverwaltung/lokale Benutzer/Benutzer/" stand bei "Vollständiger Name" der neue Name, bei "Name" noch der ursprüngliche.
Als ich bei "Name" den neuen Usernamen eingetragen hatte, war Ruhe.
PW setzen hat auch erst damit funktioniert:
Jens M. schrieb im Beitrag #8010966:
Normalerweise setzt/ändert man sein PW, in dem man Strg/Alt/Entf drückt
und dort "Kennwort ändern" auswählt....
Der "Erste" User ist automatisch ein Admin, mehr nicht.
Bei so einer Umbenennungsaktion wird im Normalfall der Profilordner nicht umbenannt.
D.h. "Berta" wird als Berta angezeigt, das Profil liegt aber (in der Regel) unter "C:\Users\Adam".
Das kann verwirrend sein, auch für diverse Software, denn diese Namensungleichheit gilt auch in der Registry und an anderen Stellen.
Besser isses da, einen neuen Benutzer anzulegen und den alten nach dem Übertragen der Daten zu löschen.
Ich glaube, 1x lokal + 1x RDP geht schon seit Windows XP nicht mehr.
In der ersten Version von XP, also die ohne Servicepack, war es
tatsächlich noch möglich. Hat mich damals sehr gewundert, denn diese
Funktionalität verkaufte MS teuer mit dem Terminalserver (jetzt Remote
Desktop Host). Wie auch immer, der "Fehler" wurde in Redmond schnelle
bemerkt und mit dem Servicepack 1 behoben.
Bei Windows-Server 2003 konnte man den Terminal-Server einfach installieren, den zugehörigen Lizenz-Server für User-Lizenzen (nicht für Devices) konfigurieren und nicht aktivieren, schon hat der Lizenz-Server immer beliebig viele temporäre User-Lizenzen für den Terminal-Server bei jeder User-Anmeldung neu vergeben, ohne dass man überhaupt für eine User-Lizenz bezahlt und installiert hat. Hab keine Ahnung, ob und wann Microsoft den Bug behoben hat.
kommst Du nicht auf die Idee, diese Fehlermeldung zu zitieren?
Meinst du, wenn ich das abends zuhaus probiere, kann ich mich dann
morgens auf Arbeit noch an den Wortlaut der Meldung erinnern?
Was kannst Du überhaupt, quer durchs Forum erscheinst Du mir als Chaot.
"wenn ich das abends zuhaus probiere", könnte ich Screenshots direkt ins Forum posten, Du nicht?
Bei Windows-Server 2003 konnte man den Terminal-Server einfach
installieren, den zugehörigen Lizenz-Server für User-Lizenzen (nicht für
Devices) konfigurieren und nicht aktivieren, schon hat der Lizenz-Server
immer beliebig viele temporäre User-Lizenzen für den Terminal-Server bei
jeder User-Anmeldung neu vergeben,
Die Lizenz tut hier absolut nichts zur Sache. Im Gegensatz zum 'normalen' Windows kann man auf dem Server mehrere Remoteverbindungen parallel aufmachen. Wenn man die nicht beendet, belegen die Speicher und sind auch nach Neustart weiterhin aktiv.
Halte ich für eine idiotische Idee, Scheunentor offen und direkt daneben
stehen ein paar Kerzen und Streichhölzer.
Im Heimnetzwerk vertretbar, sonst natürlich nicht.
Im Gegensatz zum
'normalen' Windows kann man auf dem Server mehrere Remoteverbindungen
parallel aufmachen. Wenn man die nicht beendet, belegen die Speicher
Ja. Aber wo genau ist das Problem? Eine getrennte RDP-Sitzung bleibt auch unter Desktop-Windows weiterhin im Speicher.
Oder wie/wo kann ich einen neuen User mit Paßwort anlegen?
Das konnte man doch bisher immer schon bei der Anmeldung machen. Oder nicht?
Ich gehe jetzt mal die KI fragen, warum das mit dem Custom-Gruppen-Erstellen in Baldurs Gate 2 in Windows - aber nicht in Linux funktioniert.
Darüberhinaus wäre es ja schon schön, wenn Windows endlich mal Großrechner/Terminal-Funktionen einbauen könnte, damit eben mehrere Leute an einem Rechner sitzen können. Das wäre sicher auch noch gut für den Muli-Monitor-Betrieb.
Linux kann ja Multiseat, - Windows dagegen hat Linux intus kann aber nicht.. - hehe, irgendwie fehlt auf beiden Systemen dies und das, was x hat und y nicht oder umgekehrt was y hat und x nicht -> ein Teufelskreis!
wenn Windows endlich mal
Großrechner/Terminal-Funktionen einbauen könnte, damit eben mehrere
Leute an einem Rechner
Haben sie doch. Musst nur dafür zahlen.
Remote Desktop Services (RDS), dazu einen Licensing Server, und genug CALs.
Hat MS zwar m.W. abgekündigt (Die Leute sollen doch endlich in die Cloud), aber kannst du noch kaufen/nutzen.
Ich gehe jetzt mal die KI fragen, warum das mit dem
Custom-Gruppen-Erstellen in Baldurs Gate 2...
Mein Tipp (Nach den Erfahrungen mit deinen Skyrim-Problemen): Du hast wieder irgendwelche Sabotage-DLLs in deinen Overrides. Aber lass die KI mal machen.
wenn Windows endlich mal
Großrechner/Terminal-Funktionen einbauen könnte, damit eben mehrere
Leute an einem Rechner
Wenn M$ und die Softwarefirmen sich an die damals /verbindlichen/
Richtlinien, was Antwortzeiten und UI-Design halten würden... ☺
Am Grossrechner gab es keine /Sanduhr/.
Und das schon seit Windows 2000. Die Funktionalität ist in den
Serverversionen enthalten, bezahlt wird deren Nutzung per Gerät oder
User.
W2000 Workstation /fehlt/ der Terminalserver/RDP-Dienst.
Weswegen ich dann den Advanced Server installiert habe.
Der mag aber auch nur 2 Verbindungen, was mir bei dem aber
auch reicht.
Die perfekte Lösung ist das aber auch nicht. Gibt es doch
Software, die eine Installation auf dem Server glatt ablehnt.
Wenn M$ und die Softwarefirmen sich an die damals /verbindlichen/
Richtlinien, was Antwortzeiten und UI-Design halten würden... ☺
Am Grossrechner gab es keine /Sanduhr/.
Hmm... Was gab es statt dessen, wenn z.B. die Anfrage an eine umfangreiche Datenbank mehrere Sekunden oder gar Minuten gedauert hat?
Gar kein Feedback? Irgendwie nicht sehr benutzerfreundlich...
Aber genau das ist ja wohl, was so Unix-typisch ist, oder?
Hmm... Was gab es statt dessen, wenn z.B. die Anfrage an eine
umfangreiche Datenbank mehrere Sekunden oder gar Minuten gedauert hat?
Wenn eine /Antwortzeit/ von z.B. 3 s, für eine Abfrage nicht
eingehalten wurde, war das schlicht ein /Fehler/, und berechtigte
zur Reklamation. Was dann passierte, stand in den Vertragsdokumemten.
Das es nun aus sachlichen Gründen, auch mal länger dauern konnte,
wird es mindensten eine Reaktion gegeben haben, die eine weitere
Abschätznung des verbleibenden Zeitbedarfs enthalten haben dürfte.
Das war aber die absolute Ausnahme.
Gar kein Feedback? Irgendwie nicht sehr benutzerfreundlich...
Im Gegenteil. Garantierte Antwortzeiten sind ausgesprocehn angenehm.
Aber genau das ist ja wohl, was so Unix-typisch ist, oder?
Wenn man UNIX® zum erstenmal unter den Fingern hatte, kam es einem
schon wie ein Grossrechner vor. Die Philosophie der Behandlung
von Nutzertransaktionen, orientiert sich aber /nicht/ am klassischen
Grossrechner.
Am Textterminal gab es dann maximal einen Texthinweis oder einen
Spinner [|/-].
UMIX und garantierte Antwortzeiten? Auch eher nicht.
Wenn eine /Antwortzeit/ von z.B. 3 s, für eine Abfrage nicht
eingehalten wurde, war das schlicht ein /Fehler/, und berechtigte
zur Reklamation. Was dann passierte, stand in den Vertragsdokumemten.
Wow. Umfangreiche Datenbanken und komplexe Abfragen darauf können sehr leicht mal die 3-Sekunden-Grenze reißen. Beispiel: Die gemeinsame DNA-Datenbank der US-Polizeibehörden. So eine Anfrage konnte schon in den frühen 90ern Tage dauern. Und kann es trotz vielfach schnellerer Hardware auch heute noch. Weil sich halt sowohl die Komplexität der möglichen Abfragen als auch der Datenbestand zwischenzeitlich massiv erhöht haben.
Grund zur Reklamation? Nö. Ist einfach so und läßt sich im Rahmen der formalen Logik auch nicht ändern. Auch nicht mit Unix oder irgendeinem anderen OS.
Und ja: In den Clients (sind Windows-basiert) gibt es keine Sanduhr. Statt dessen halt ein Hinweis, dass die Frage bearbeitet und die Antwort irgendwann mal eingehen wird. Das ist ja auch SO VIEL besser als eine Sanduhr...
Mit gut (oder schlecht) gewählten Beispielen, kann man Alles oder
Nichts beweisen. Entscheidend: "Das war aber die absolute Ausnahme."
Ich hatte selbst Ende der 80er Jahre mit Datenbanken und UNIX zu tun,
und die Datenbanksoftware war, wenn man das auf die Leistungsfähigkeit
damaliger Hardware herunterechnet, ausgesprochen performant.
16 bit CPU, 4 MHz Takt, und ca. 50 kB/s Lesegeschwindigkeit der Platte.
Eine Und-verknüpfte Suchanfrage, förderte die Treffer aus einer
Tabelle mit ca. 100000 Einträgen in unter einer Sekunde zu Tage.
Einschliesslich der Daten aus referenzierten weiteren Tabellen.
Unique Keys, und binäre Bäume waren wohl das Hilfsmittel.
Ein Adobereader braucht heute für eine Volltextsuche ca. 1 s für
eine Seite. Möglicherweise geringfügig schneller. ☺
So ein /Dreck/ wäre vom Benutzer damals nicht akzeptiert worden...
Es kann auch kein grundsätzliches Problem sein. Andere Hersteller
sind da 2-3 dezimale Grössenordnungen schneller als das Adobezeug.
Was soll das für eine Platte gewesen sein? Das ist /Diskettengeschwindigkeit/. MFM-Festplatten haben das zehnfache, RLL-Festplatten das fünfzehnfache geliefert.
(Sofern der Festplattencontroller in der Lage war, eine komplette Spur in einem Rutsch zu lesen, sonst brauchte der einen sogenannten "Interleave", was die Lesegeschwindigkeit halbierte oder drittelte, aber nur 50 kB/sec war auch Ende der 80er unterirdisch langsam.
Es war wohl eine Seagate ST251 verbaut. Deren Datenblatt verrät
eine Datenrate von "0.625 MB/S". Das "Drumherum" der Platte
war aber vermutlich mit Z80 und dessen Peripherie realisiert,
und die Daten über Z80-PIOs zur (16 bit-)CPU geschleust.
Ich könnte im Schaltplan nachsehen, hege aber kein Interesse.
Die 50 kB/s habe ich auch nicht gemessen, sondern stammen aus
u.U. unzuverlässigen Informationsquellen.
Die Grössenordnung wird aber stimmen.
Ein XT-Nachbau, 2 Tische in meinem Arbeitszimmerchen weiter, war
unter MS-DOS mit dem selben Plattetyp unterwegs, und bei der
Verarbeitung eher noch langsamer. Dafür konnte man mit M$-C 5.1
recht komfortabel debuggen.
Beim UNIX-System hatte ich immerhin das Privileg, es "aussuchen"
zu dürfen. Allerdings gab es keine praktikablen Alternativen.
Der Preis für das System lag damals, bei ca. einer viertel Million.
Und die Antwortzeiten waren ja auch nicht schlecht. ☺
Es war wohl eine Seagate ST251 verbaut. Deren Datenblatt verrät
eine Datenrate von "0.625 MB/S".
5 MBit/sec Bruttodatenrate. Wenn auf die übliche Art und Weise mit 512-Byte-Sektoren formatiert, dann gab es davon 17 pro Spur und die Platte drehte sich mit 60 Umdrehungen pro Sekunde. Die Nettodatenrate lag daher bei 17 x 512 x 60 Byte pro Sekunde, also 510 kiB/sec.
Das "Drumherum" der Platte war aber vermutlich mit Z80 und dessen
Peripherie realisiert, und die Daten über Z80-PIOs zur (16 bit-)
CPU geschleust.
Gut, mit unpassenden Controllerschaltungen kann man beliebig viel Performance ausbremsen.
Ich hatte zur gleichen Zeit mal mit 68k-Systemen zu tun, bei denen ein ungeschickt programmierter SCSI-Controller in Kombination mit einem ebenfalls ungünstigen MFM-SCSI-Adapter (irgendwas von Omti) die Datenrate auch auf erbärmliche Werte ausbremste, der MFM-SCSI-Adapter konnte natürlich nicht ohne "Interleave" arbeiten, und der ungeschickte Treiber des 53c80 regelte irgendwo unter 100 kByte/sec auch schon ab.
An einem AT aber, wie er Ende der 80er durchaus üblich war, wären diese Datenraten sehr ungewöhnlich gewesen, daher meine Nachfrage. Der Ur-MFM-Controller des AT (WD1003) konnte auch nur im Interleave betreiben werden, was üblicherweise die Datenrate halbierte oder drittelte. Der auch schon Ende der 80er verfügbare WD1006 war da der Durchbruch, der hatte statt 2 kiB RAM als Puffer großzügige 8 kiB RAM, was genügte, um auf "Interlave" verzichten zu können, so daß tatsächlich 510 kiB/sec Nettodatenrate möglich waren. Richtig schick war dann die RLL-Variante davon (WD1006-SR2), die erlaubte, wenn man sich über die Spezifikation der Festplatten hinwegsetzte, anderthalbfache Kapazität und anderthalbfache Geschwindigkeit (26 Sektoren pro Spur, also resultierende Nettodatenrate von 780 kiB/sec).
Ich hab' irgendwo noch im Schrank eine ST125 liegen, die jahrelang problemlos mit genau so einem Controller als ST138R betrieben wurde ...
Und heute findet man einen Internetzugang langsam, der derartige Datenraten liefert. Wie sich die Zeiten ändern ...
