Am Wochenende hatte ich mal wieder von USB 10.9.1 gebootet und ein wenig experimentiert, heute auf der Arbeit habe ich die Fritzbox 7340-Firmware geupdatet. Keine Ahnung, ob das mit zuvor beschriebenem zusammenhängen kann, jedoch bricht bei meinem Rechner jetzt häufig die Ethernetgeschwindigkeit auf 10-20KB/s ein. Wenn ich die Ethernetstrippe dann rausziehe, läuft alles weiter gewohnt schnell, weil ich dann mittels Airport verbunden bin. Ich habe keine Ahnung, ob das ein soft- oder hardwareseitiger Fehler ist. Ich kann auch bislang nicht ausschliessen, dass nicht ich der schuldige bin, sondern vielleicht die Gegenseite. Ich habe jedoch bereits einen Switch getauscht und habe mich an zwei andere Switche gehängt, überall das gleiche Problem, alldieweil alle anderen diese Probleme nicht haben.

Wo könnte ich suchen; wie kann ich das Problem einkreisen?

Wie und in welcher Situation bzw. "gegen was" mißt Du das?

Also wenn man's richtig machen will, fängt man "von unten an" zu testen, bspw. per iperf. Aktuelle Fritzbox-Firmwares ab Version 6.x haben bspw. ein verstecktes Feature, um iperf anzuknipsen oder damit zu messen: http://fritz.box/services.lua

Das Pendant dazu am Mac ist aber wieder mal nur Terminal-Zauber: http://code.google.com/p/rudix/downloads/detail?name=iperf-2.0.5-1.pkg

Aber damit läßt sich "Netzwerk an sich" ohne Fremdeinflüsse testen. Ein Klassiker ist ein TCP/IP-Setting, das auch in 10.9 unpassend bzw. konservativ gesetzt ist und sich gegenüber moderneren TCP/IP-Stacks anderer Betriebsystem auswirkt: net.inet.tcp.delayed_ack (steht immer noch per default auf 3 gehört aber auf 2). Ob das 'ne Rolle spielt, merkt man aber ganz schnell, denn wenn das die Ursache ist, dann ist lesen von "Server" schnarchlahm während Schreiben normal schnell geht.

Gibt übrigens noch 'ne ganz triviale Ursache: Defekte bzw. defekt gehende Ethernet-Buchse im Mac (hat mein Macbook, seitdem "schlepp" ich auch immer einen TB-zu-ENet-Adapter mit mir rum). Sowas sollte sich evtl. mittels "ping" und hohen "packet loss"-Werten bemerkbar machen. GUI für ping findet sich in Form von Dienstprogramme Netzwerkdienstprogramm (dort auch der Punkt "netstat" Statistik spannend per Copy&Paste zu pastebin.com)

Ab 10.8 gibt's übrigens noch "/System/Library/CoreServices/Wireless Diagnostics.app", das zumindest für das Zusammensuchen aller netzwerkrelevanten Parameter und Logs gut ist, selbst wenn einen nur Ethernet-Fehlverhalten interessieren sollte.

Oder man verwendet JPerf

Es könnte ein Adressenkonflikt in der FB sein. Denn es ist ein Rechner unter zwei Adressen erreichbar.
Wenn deine Umgebung auf "Automatisch" steht bevorzug Apple das Wlan. Wenn Du du dein Ethernetkabel reinsteckst, switsch der der DHCP-Server der FB noch lange nicht um.
Die FB ist in der Hinsicht bei Verwaltung gültig aktiver Clients recht träge.
Ein wenig Abhilfe könnte sein, wenn deine Netzwerkumgebung klar definiert ist.

Leider eine Finte.
Denn der DHCP vergibt IP-Adressen an die Netzwerkadapter die sich melden und nicht an die Geräte an sich.
Was heißt: Das Book bekommt definitiv für jeden Netzwerkadapter(ganz gleich welcher Art) eine eigene IP-Adresse.

Ein anderer Gedanke:
Du sagst, sobald Du das Kabel rausnimmst ist alles wieder schnell, da er dann über Airport geht.
Deaktiviere Airport mal, wenn Du das Kabel benutzt.
Auch wenn die vorgegebene Reihenfolge befolgt wird, kann es manchmal zu Problemen kommen, wenn man mit Beiden Adaptern gleichzeitig mit dem selben Netzwerk verbunden ist.

Bislang erst einmal danke! Kleiner Zwischenbericht, bevor ich zu meinem Sherlock Holmes ins Bett gehe: Gerade mein "Problem-"Macbook mit Ethernet-Flachbandkabel mit einem alten Macbook verbunden. 2 GB von einem auf dem anderen Rechner laufen so:
Macbook Pro (10.8.5) auf Macbook (10.6.8) mit ca. 65 MB/sek
Macbook (10.6.8) auf Macbook Pro(10.8.5) mit ca. 30-50 MB/sek

Gemessen habe ich das mit MenuMeters und mit der Stoppuhr.

Da scheint dann doch wohl der Fehler woanders zu liegen. Morgen im Büro mal weitersuchen.

Nö, die Reihenfolge, in welcher die einzelnen Interfaces je Netzwerkumgebung definiert sind, bestimmt, was "bevorzugt wird". Auch bei "Automatisch" kann man die Reihenfolge ändern. Sinnvoll ist, das schnellste Interface ganz nach oben zu schieben, da über das dann die sog. "default route" (also alles, was nicht lokal im LAN ist) läuft als auch die entsprechende Netzroute über dieses Interface läuft, falls zwei Interfaces Adressen aus dem selben Netzwerkbereich haben sollten (wie es geschehen kann, wenn identischer DHCP-Server per LAN und WLAN parallel erreichbar ist)

Bei Unklarheiten einfach Dienstprogramme Netzwerkdienstprogramm netstat -- "Routing Tabelle" anzeigen lassen, Kabel abziehen oder WLAN ausknipsen bzw. vice versa, 1 Sek. warten, Vorgang wiederholen (prima Aufwärmübung für Heiner morgen im Büro )

Nein, Scherzle gemacht. Im Büro strukturiert vorgehen aber auf genau solche Details achten.

Ich bin etwas schlauer geworden:
Nach dem Tauschen von Switches und einer Stunde (halb-)gezieltem weiterem Herumprobieren, denke ich, einen Hardwarefehler zunächst einmal ausschliessen zu können.
Folgendes kann ich berichten:
Die Problematik zeigt sich nur bei der "Bildschirmfreigabe", wo sich folgendes zeigt:
Zugriff lokal Ethernet und Airport okay und vernünftig schnell.
Zugriff über vnc:84.34.145.56:5904 geht nur über Airport ausreichend schnell und über Ethernet mit eben der schleppend langsamen Geschwindigkeit. Das war bis vor dem Wochenende nicht so.
Ich konnte deswegen über unsere feste IP den Bildschirm überwachen, da unser Router (Fritzbox) wohl geblickt hat, dass der Rechner, der erreicht werden sollte, im internen Netz ist. Das scheint jetzt nur noch bei Airport so zu gehen; bei Ethernet ruckelt es wie die Pest.
Wo muss ich weiter suchen? (Jetzt ersma essen )

??? Wenn du im Büro bist solltest du doch immer auf die interne IP des zu überwachenden Rechners zugreifen. Wenn du daheim bist dann solltest du allein schon der Sicherheit wegen erstmal ein VPN in die Firma aufbauen (und kannst dann wiederum die interne IP verwenden. Andernfalls sollte es von daheim erstmal egal sein ob du per WLAN oder Kabel zu deinem heimischen Router kommst und von dort über das langsame Internet irgendwann auf der FB des Büros auf schlägst. Dort müßte dann eine Weiterleitung des Ports auf die IP des internen Rechners eingetragen sein... Das ohne weitere Sicherheitsmaßnahmen wie Verschlüsselung der Übertragung ist eigentliche schon grob fahrlässig.

Sofern du intern mit der externen IP versuchst auf den internen Rechner zu kommen ist das eine Frage wie die FB das intern handhabt. Kann klappen oder auch nicht, mal besser, mal schlechter. Letztendlich davon abhängig wie die FB erken das du ja gar nicht von außen kommst sondern intern die externe IP verwendest (also letztendlich im wahrsten Sinne des Spruchs: durch die Brust ins Auge)

Ich habe immer mit "vnc:84.34.145.56:5904" (Das ist das, was Bildschirmfreigabe hinterlegt hat, wenn man eine Verbindung speichert), also eigentlich mit nur einem Klick auf das entsprechende Datei-icon auf den Bildschirm zugegriffen; scheissegal, wo auf der Welt ich gewesen bin. Jetzt funktioniert das halt nicht mehr, bspw. mit Airport schon und mit Ethernet eben nicht und eigentlich möchte ich u.a. gerne wissen, warum.
Ich habe mittlerweile die Fritzbox dahingehend in Verdacht, dass das herausgehauene Firmwareupate (wohl wegen Telefon-angriffen) wohl nicht 100%-ig astrein ist.

Kurze Info: Ich halte es jetzt für wahrscheinlich, dass nach dem firmware-update die Fritz!Box 7340 nicht mehr wie vorher mit einem Netgear FS108 zusammenarbeitet: Wenn ich mit einem Netzwerkkabel meinen Rechner mit der Fritz!Box verbinde, funktioniert alles wie gewünscht, hänge ich den Switch dazwischen, treten ebenfalls die beschriebenen Probleme auf.
Ich habe jetzt gerade beide LAN-Ports der FritzBox in den "PowerMode" versetzt und werde morgen mal weitere Switche testen.
Scheisse!

So! Das Problem erscheint gelöst und ich möchte wie folgt resümieren: Nach (zeitlich gesehen, man beachte, dass ich hier keine Kausalität unterstelle; das darf jeder selbst machen ) dem Sicherheitsupdate der Fritz!Box 7340 auf die Version 99.06.03, arbeitete die Fritz!Box nicht mehr 100%-ig mit dem daran geschalteten Netgear FS108 (100 Mbit/s) zusammen. Letztendlich habe ich diesen durch einen Netgear GS108 (1.000 Mbit/s) ersetzt und jetzt läuft anscheinend alles wieder so wie vorher. (Habe bislang allerdings erst an meinem Arbeitsplatz getestet, bin aber ganz zuversichtlich)

Ich würd sogar so weit gehen und das komplett negieren. Dein FS108 ist doch schon hundert Jahre alt gewesen? Wir haben bei Kunden ganze Chargen an (semi-)defekten FS108 und FS105 gehabt (ich selbst auch Letzteren, der relativ schnell erst seltsam agierte und dann gar nicht mehr)

Hast Du den FS108 mal solo durchgetestet? Zwei Kisten direkt an die Ports, an denen früher FB und Dein Mac hingen, und gemessen?

Ich glaub viel eher an den nur zu präsenten psychologischen Effekt: Bewußte Änderung (Router-Update) erzeugt Sensibilisierung (Switch wird seit Wochen immer lahmer, hoppla jetzt auf einmal gemerkt).

Ich versuche ja, vorsichtig zu sein, mit meinen Behauptungen
Ich habe alles mögliche durchgetestet und jetzt gerade noch einmal, aufgrund Deines Postings, einen nagelneuen FS108, der hier als spare rumliegt, drangepappt. Der Fehler taucht direkt wieder auf. Dann habe ich einfach nur den FS108 durch einen GS108 ersetzt und der Fehler ist weg. Ich kann nicht ausschliessen, dass alle 3 FS108, die ich getestet habe, kaputt sind, sehe das aber als nicht so wahrscheinlich. Irgendwie denke ich, dass die Gigabit-Ports der Fritz!Box mit der neuesten Software vielleicht nicht 100%-ig kompatibel mit den 100-Mbit/s-Ports des FS108 kompatibel sind.

Kann theoretisch zwar sein aber so richtig glaub ich nicht dran, seitdem ich mich seit paar Monaten wieder recht intensiv mit so Winzig-Technik beschäftige (MIPS- oder ARM-basiertes Zeugs wie bspw. auch Fritzboxen). Der Switch in der Fritzbox hängt technisch hinter/vor deren eigenem GBit-NIC (der in dem Ikanos-SoC -- System on a Chip -- innen drinnen steckt ) und ist im Falle der 7390 ein Atheros AR8316. Und ich kann mir nur schwer vorstellen, dass es da irgendeine Möglichkeit gibt, eine Inkompatibilität herbeizuzaubern, weil "plain old Ethernet" ist jetzt seit Jahrzehnten Standard und da darf eigentlich nichts dergleichen mehr passieren. Aber ausgeschlossen ist natürlich nichts.

Aber lassen wir's einfach Du hast eine Lösung gefunden und ich lern nix Neues dabei, weil Du partout nicht das machst, was ich will (und das wäre strukturiertes testen/messen gewesen)

Wie sind denn die Ports eingestellt? Autosensing? Ich meine schon öfters gelesen zu haben, dass das Probleme verursachen kann. Dann einfach die entsprechenden Port, wenn man kann, auf eine fixe Geschwindigkeit einrichten.

Nein, ganz im Gegenteil. Alles Ethernet-Equipment seit sagen wir mal dem Jahr 2000, das kein Auto-Sensing kann, darf getrost als defekt angesehen werden und sollte Reparatur/Entsorgung zugeführt werden.

N-Way kam mit Fast-Ethernet, d.h. vor 20 Jahren. Fast-Ethernet durfte man zwar noch "fest einstellen" aber ab GBit-Ethernet ist sowas schlicht verboten bzw. ein Verstoß gegen die Spezifikationen.

"Auto-Negotiation abschalten" genauso wie "DHCP abschalten" sind immer wieder gern geratene Pseudo-Allheilmittel, die in grauer Vorzeit teilweise sinnvoll waren aber heute nichts weiter als völlig falsch sind. Der Tipp spielt in der selben Liga wie "Rechte Reparieren" oder "defragmentieren" -- bei SSDs oder ab OS X 10.3: Vor langer Zeit mal bedingt sinnvolle Varianten, Symptome zu kaschieren oder Probleme zu lösen, ungeprüft/unreflektiert auf das hier und jetzt anwenden. Schafft mehr Ärger als Nutzen und sollte endlich ins "Museum für obsolete Maßnahmen"!

Wo denn? An dem 100-Mbit-Switch (FS108), wo's eh nicht geht oder an der Fritzbox (green mode: 100 Mbit/sek per N-Way, kein green mode: Gbit/sek per N-Way), wo's eh nicht geht?

Hier soll ja jeder auf seine Kosten kommen. Mein Wissen und Equipment reicht bislang nicht aus, um das von Dir vorgeschlagene (richtig) zu tun. Ich hatte mit …services.lua rumprobiert, habe aber nicht feststellen können, was mir da wie nützen könnte.
(Kurze Info: meine Fritz!Box ist eine 7340, keine 7390)

Ich investiere gerne eine Stunde, um das zu prüfen, was sinnvoll ist; da lerne ich im optimalen Falle ja auch noch was bei. Dummerweise muss man mich da aber ziemlich an die Hand nehmen

@Hidalgo
Ich habe sowohl green- als auch red-Mode getestet und habe keine für mich relevanten Unterschiede festgestellt.

Vielen Dank. Schon wieder etwas gelernt.
Stimmt natürlich. Bei einem dummen Switch kann man da nichts einstellen.
Mir hatte nur mal geholfen, einen Port auf 10 MBit/s einzustellen, damit ein altes VoIP-Telefon noch funktioniert hat. Der Wechsel zu einem anderen Switch war dann die endgültige und bessere Lösung.

Herzlichen Dank für das Angebot. Aber ich glaub, dass wir im Endeffekt beide zu viel Zeit in dem Modus verlieren. V.a. hab ich nach mehreren Supportdramen die letzten Wochen (wo zwischendrin immer viel Zeit fürs Verpeilen hier&dort blieb, weil eh kein "freier Kopf" möglich) jetzt die nächsten Wochen wieder konzentrierte Projektarbeit anstehen/aufzuholen. Und GS108 statt FS108 ist ja nicht nur ein Workaround sondern sogar 'ne Lösung

BTW: Nachdem vor vielen vielen Jahren die Netgear-Switches bei Kunden und im Büro wie die Fliegen starben, waren die in unserem Umfeld lange Zeit tabu. In Umgebungen, wo wegen zentralem Management aber nicht sinnigerweise alle Switches vom selben Hersteller kommen sollten", setzen wir die inzwischen wieder gerne ein. GS110TP am unteren Ende für PoE-Konsumenten (leider grad bzgl. Stromversorgung bisserl arg schwachbrüstig dafür ein Feature-Monster) und bspw. XS712T am oberen Ende (als "gerade so" bezahlbare und flexible 10 GbE-Variante)

O Mann, ich bin so doof. Vorher komplett und jetzt fast wieder überlesen! Danke, entscheidender Hinweis. Die unterscheiden sich netzwerkmäßig "fast gar nicht" außer... die 7340 hat gar keinen integrierten Switch sondern reicht beide GBit-NICs des SoC raus (die 7390 hat dagegen einen NIC intern an den Switch angebunden, an dem die externen LAN-Devices hängen). Damit ist Deine Theorie, dass das Update was verschisselt hat, mehr als plausibel und ich kann nur um Entschuldigung bitten, Dir Lebenszeit gestohlen und Dich auf die falsche Fährte gelockt zu haben

Hintergrund: Bei Dir dürfte die Fritzbox zwischen den beiden Gbit-NICs auf Linux' Bridging-Code aufsetzen (und den hatte AVM zumindest vor Jahren noch an der ein oder anderen Stellen massiv modifiziert), im Falle der 7390 ist einfach ein autarker Switch integriert. Unterschied wie Tag und Nacht. Du könntest mal eine kurze Notiz Richtung AVM-Support schicken und auf Deine Beobachtung mit Bitte um Prüfung hinweisen.

Habe das mal bei AVM gemeldet. Die haben zurückgeschrieben, dass sie ein Ticket eröffnet hätten, sich die Beantwortung meiner Supportanfrage aus aktuellem Anlass jedoch verzögern könnte. Sobald ich was weiß, informiere ich in diesem Thread.

Apropos Lebenszeit: Meine wird nicht gestohlen, sondern gekauft

Ich hab das mal auf Basis von jperf 2.0.2 inkl. iperf 2.0.5 in ein OS X Application Bundle gekippt: http://kaiser-edv.de/downloads/jperf.zip (MD5-Sum: 4e11a156fea654a30552d61ec0e2e13b)

Braucht Java und iperf ist in Ermangelung einer PPC-Kiste leider nur Intel-only...