Kleines Update:
Das Problem konnte von Qnap reproduziert werden und es wird ein Fix erstellt.
Kommt wahrscheinlich mit der nächsten Firmware Version.
FInde es nur schade, dass mir hier im Forum niemand helfen konnte. Ich hatte wenigstens gehofft, dass weitere User das gleiche Problem haben und bestätigen können.
Das Problem scheint übrigens schon länger zu existieren. Selbst mit der vorletzten 4.3.6 Firmware tritt es auf.
Kann noch jemand anderes das Problem reproduzieren? Ich bin gerade im Ping Pong Modus mit dem Support ohne das wir zu einem Ergebnis kommen.
Ich komm auf ähnliche Wert. Ich habe alle 3 Laufwerk (inkl. der SSD) die Performance getestet und sie sieht überall gleich aus.
Update: Ich habe jetzt bei QNAP ein Ticket eröffnet.
Running warmup...
Running a 400MB file write on Y: 5 times...
Iteration 1: 99,25 MB/sec
Iteration 2: 116,92 MB/sec
Iteration 3: 116,92 MB/sec
Iteration 4: 115,86 MB/sec
Iteration 5: 115,86 MB/sec
-----------------------------
Average (W): 112,96 MB/sec
-----------------------------
Running a 400MB file read on Y: 5 times...
Iteration 1: 97,36 MB/sec
Iteration 2: 97,73 MB/sec
Iteration 3: 97,36 MB/sec
Iteration 4: 97,36 MB/sec
Iteration 5: 97,36 MB/sec
-----------------------------
Average (R): 97,44 MB/sec
-----------------------------Mit der 1146 von Dezember hatte ich das Problem auch schon. Ich habe das NAS aber auch erst seit ca. 2 Wochen.
Steht doch alles in meinem 2. Beitrag:
Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! 
Die Zitat Funktion des Forums richtig nutzen
Disk: 1 WD Red 5400U/min mit 5GB im 1. Slot, HGST Deskstar NAS 7200u/min mit 4GB im 2. Slot, Crucial M4 mit 250GB im 3. Slot, 4. Slot leer
Egal von welcher Platte ich lese, es kommen immer nur ~95MB/s raus. Alle Disks sind als Einzellaufwerke/statisches Volumen eingerichtet.
Es handelt sich um eine Crucial M4, der Leistungstest leifert über 500MB/s Lesegeschwindigkeit. Wie gesagt, es wird nicht an den Laufwerken liegen sondern irgendetwas limitiert das Lesen. Selbst bei einem frisch aufgesetzten System komme ich nur auf 95MB/s lesen, aber auf 112MB/s wenn ich auf das NAS schreibe und das egal welches Laufwerk ich nehme.
was soll meine „Platte“ im PC damit zu tun haben? Das steckt eine 1TB Samsung M2 drin?
Im NAS steckt ne 250GB SSD drin und selbst wenn ich von der Lese kriege ich nur 95MB/s raus.
Ich hatte die Hoffnung, dass es bei dem Problem um eine einfach Einstellungssache handelt :-/
Meine Parameter lauten:
QNAP TS-453be mit 16GB
QTS Version: 4.4.1.1216 (mit der vorherigen Version aus dem Dezember war das Bild aber das gleiche)
SMB Version: Im Moment habe ich alles von 1-3 zugelassen, habe aber auch schon mit Einschränkungen experimentiert (ohne Erfolg)
Disk: 1 WD Red 5400U/min mit 5GB im 1. Slot, HGST Deskstar NAS 7200u/min mit 4GB im 2. Slot, Crucial M4 mit 250GB im 3. Slot, 4. Slot leer
Egal von welcher Platte ich lese, es kommen immer nur ~95MB/s raus. Alle Disks sind als Einzellaufwerke/statisches Volumen eingerichtet.
Die Datenrate habe ich mit einzelnen Files >20GB getestet
Die Anbindung zwischen NAS und PC läuft über 2 kleine Switche (unmanaged) von D-Link 5-Port bzw. Netgear 8-Port.
Die Kabel habe ich auch schon getauscht, aber auch ohne Erfolg.
Aktuell habe ich das NAS mit 2 Netzwerkkabeln angeschlossen, auch wenn das eigentlich nichts bringt. Das Problem tritt aber auch auf, wenn ich nur ein Kabel anschließe (an LAN1 Port).
An den Netzwerkeinstellungen habe ich bis auf eine feste IP nichts eingestellt. Keine Jumbo Frames etc.
Wie gesagt, das hochschieben läuft mit Vollgas, nur wenn die vom NAS auf den Computer kopiere wird hard bei 95MB/s limitiert.
Moin,
ich bin von einem TS-251C auf ein TS-453BE umgestiegen und habe jetzt das Problem, dass die Lesengeschwindigkeit langsamer ist als mit dem TS-251c.
Mit dem TS-251C konnte ich die Gbit Leitung komplett ausnutzen (sprich ~112MB/s), mit dem TS-453BE liegt die Geschwindigkeit nur bei ca. ~95MB/s, der Wert sieht auch sehr festgenagelt aus (also keine Schwankungen nach oben oder unten).
Beim Schreiben habe ich das Problem nicht. Hat jemand eine Idee woran es liegen kann.
Es sind aktuell fast keine Dienst eingerichtet und die Datenrate messe ich per Samba als auch per FTP Zugriff.
Danke schon mal im voraus,
Moon
Ich glaube das liegt an der neue Firmware von Oktober (wenn du auf diese aktualisiert hast). Ich hab ziemlich ähnliche Meldung mit mit DMESG kann ich sehen, dass ständig Aktion ist.
Bin jetzt zurück auf die Firmware von September und habe keine Probleme mehr. (hoffentlich)
Noch eine finale Rückmeldung.
Vom Qnap Helpdesk habe ich eine neue BIOS Version (SAB6AR11) für mein TS-251C erhalten. Diese ist die Version, die mein Problem beheben soll. Gestern Abend habe ich das Bios Upgrade durchgeführt, damit ich heute morgen prüfen kann, ob nach dem automatischen Start noch Fehler in den Kernel Log geschrieben werden. Noch zum Hinweis: Das Problem tritt eigentlich nur auf, wenn man einen Energiezeitplan angelegt hat und das NAS dadurch starten lässt.
Das NAS fuhr dann auch heute morgen planmäßig hoch. Im Kernel Log sind keine Fehler mehr zu finden und die Platten gehen automatisch in Standby/Stromspar Mode. Damit ist mein Problem gelöst.
Danke nochmal für den Support.
dr_mike: Danke für den Support.
Ich habe jetzt ein Ticket bei QNAP aufgemacht und eine kleine Batchdatei geschrieben, die morgens das QNAP noch einmal rebootet nachdem es nach Energiesparplan gestartet wurde. Nach dem Reboot kommt die Fehler nicht mehr und die Platten legen sich schlafen. Mal schauen, was der Support schreibt.
Ich bin ja jetzt im richtigen Thread angekommen 
Ich habe mich mal ein wenig mit meinen wenigen Kenntnissen „durch“ das NAS bewegt. Ich fasse mal zusammen.
Wenn ich DMESG nach dem Start (ca. 10-20min) ausführe, sehe ich folgende Meldung:
[37544.040995] hpet1: lost 9599 rtc interrupts
Die Meldung bekomme ich sehr häufig.
Wenn ich nun blkdevMonitor ausführe legen sich die Platten auch schön schlafen, sonst nicht. Warum kann ich leider nicht feststellen.
So wie ich das verstanden habe ist die o.g. Meldung Schuld daran, dass die Festplatten nicht in den Standby gehen.
Lösung soll sein, dass man das BIOS aktualisiert. Um das BIOS zu bekommen, muss man QNAP in Taiwan kontaktieren. Wenn man kein neues BIOS bekommt, kann man das NAS nur umtauschen.
Ist das alles so korrekt?
Was noch interessant ist, wenn ich das NAS über die Web-GUI neustarte, tritt die Meldung nicht mehr auf und die Platten gehen in den Standby.
Hi,
der Sammelthema war geschlossen, so dass ich mich nicht anhängen konnte, daher der neue Thread.
Ich habe direkt auch schon den Grund gefunden:
[37544.040995] hpet1: lost 9599 rtc interrupts
[37544.315360] hpet1: lost 9600 rtc interrupts
[37544.567872] hpet1: lost 9600 rtc interrupts
[37544.819821] hpet1: lost 9600 rtc interrupts
Ich suche jetzt noch in den Foreneinträgen nach einer Lösung.
Ich habe auch das Problem, dass die Festplatten meines TS-251C nicht in denStandby gehen.
Sämtliche Tipps auf der QNAP Seite habe ich probiert und zum Schlussversucht mit dem bkldevMonitor rauszufinden, welcher Prozess den Standbyverhindert.
Jetzt kommt das kuriose. Sobald ich dasScript bkldevMonitor laufen lasse gehen alle Platten nach und nachin Standby (nicht sofort aber nach 20-30min). Was kann das sein?
Ich habe für das NAS einenEnergiesparplan erstellt, dass sich das Ding gegen 23:00 Uhr ausschaltet unddann um 6 Uhr wieder startet. Nach dem Start am Morgen gehen die Platten wiedernicht in den Standby, sondern erst, wenn ich wieder das Script gestartet habe.
Für einen Tipp wäre ich dankbar.
Moondiver
Ich habe auch mal die Crontab angehängt:
[~] # crontab -l
0 3 * * 0 /etc/init.d/idmap.sh dump
0 4 * * * /sbin/hwclock -s
0 3 * * * /sbin/vs_refresh
0 3 * * * /sbin/clean_reset_pwd
0-59/15 * * * * /etc/init.d/nss2_dusg.sh
30 7 * * * /sbin/clean_upload_file
0 2 * * * /sbin/qfstrim
0-59/10 * * * * /etc/init.d/storage_usage.sh
30 3 * * * /sbin/notice_log_tool -v -R
30 23 * * 0 /etc/init.d/poweroff
0 6 * * 1 /etc/init.d/startup
4 3 * * 3 /etc/init.d/backup_conf.sh
30 7 * * * /usr/local/sbin/version_cleaner -t 0 > /dev/null 2>/dev/null
35 7 * * * /sbin/qbox_util -c > /dev/null 2>/dev/null
03 06 * * * /share/CACHEDEV1_DATA/.qpkg/QcloudSSLCertificate/bin/ssl_agent_cli
0 11 * * * . /share/CACHEDEV1_DATA/.qpkg/CloudDriveSync/bin/env.sh; USERNAME="admin" python /share/CACHEDEV1_DATA/.qpkg/CloudDriveSync/bin/engine.pyc sync 1 &> /share/CACHEDEV1_DATA/.qpkg/CloudDriveSync/data/0/console_output/1
0 17 * * * . /share/CACHEDEV1_DATA/.qpkg/CloudDriveSync/bin/env.sh; USERNAME="admin" python /share/CACHEDEV1_DATA/.qpkg/CloudDriveSync/bin/engine.pyc sync 1 &> /share/CACHEDEV1_DATA/.qpkg/CloudDriveSync/data/0/console_output/1
* * * * * /mnt/ext/opt/netmgr/util/lock_timer.sh
0 9 * * * . /share/CACHEDEV1_DATA/.qpkg/CloudBackupSync/bin/env.sh; USERNAME="admin" python /share/CACHEDEV1_DATA/.qpkg/CloudBackupSync/bin/engine.pyc sync 1 &> /share/CACHEDEV1_DATA/.qpkg/CloudBackupSync/data/0/console_output/1Der Fehler scheint mit Firmware v3.3.3 behoben zu sein.
Ich konnte die unterschiedlichsten Datein bis ca. 300MB ohne Probleme kopieren können.
Hab ich leider schon alles kontrolliert und sogar die unterschiedlichsten Konstellationen ausprobiert, sogar eine komplett Neuinstallation des Notebooks hab ich vorgenommen. Was mich wundert ist, dass ich das Problem mit 2 Netbook reproduzieren kann. Dabei ist auf dem einem Win7 und auf dem anderen WinXP. Das einzige was gleich ist, dass in beiden Atheros 11n Chip verbaut sind, aber auch nicht die gleichen. Ich habe auch hier schon sämtliche Treiberkonstellationen bzw. Versionen ausprobiert. Und das Schlimmste ist, sobald ich auf die Firmware V3.2.8 (von 3.3/3.3.1 oder 3.3.2) wieder downgrade, ist das Problem weg.
Ich versuch einfach mal einen kleinen Überblick über meine gesamte Infrastruktur (LAN und WLAN) zugeben und wie ich das Ganze teste:
Ich hab ein etwas komplexeres (drahtgebundenes) Netzwerk bestehenden aus einem zentralen 8 Port Gigabitswitch von Level-One. Von dort aus verteile ich das LAN in alle Etagen und Zimmer. Im Wohnzimmer und unterem Dach verteile ich das LAN noch über einen 5 Port Gigabitswitch von D-Link und im Wohnzimmer über ein Fastethernet Switch weiter. Die Fritzbox ist übrignes direkt am Level-One Switch angeschlossen und das NAS seit kurzen auch. Das NAS war aber vormals direkt mit dem D-Link Switch verbunden, da die Temperaturen unterm Dach aber zuhoch geworden sind, ist das NAS seit 1-2 Wochen in den Keller gewandert. (Das Problem tritt aber in beiden Konstellationen auf)
Meine drahtlose Infrastruktur ist dabei wesentlich einfach. Als Access Point fungiert wie gesagt die Fritzbox 7390 die nur im 2,4Ghz Modus arbeitet und das in einem gemischten 11g+n Netzwerk (WPA+WPA2 Verschlüsselung). Wlan Endgeräte habe ich nur 3 Stück im Einsatz, wobei meinst nur 1-2 aktiv sind. Es handelt sich dabei um ein Samsung NC10 mit Atheros 11n Karte, ein Samsung N130 mit 11n sowie ein iPhone 3G mit 11g.
Mein Problem tritt bei folgenden einfach Aktion auf. Ich möchte eine beliebige Datei (im Testfall so um die 100MB oder größer) von meinem Netbook (NC10 oder N130) auf mein NAS in ein Unterverzeichnis von Public kopieren oder verschieben, also schreibender Zugriff. Ich habe mir hierzu eine (feste) Laufwerksverknüpfung mit dem NAS erstellt, wobei der Public Ordner den Laufwerksbuchstaben Z: hat. Ich kopiere nun eine beliebige Datei vom Desktop des Netbooks in das Unterverzeichnis. Hierbei bricht der Schreibvorgang in 2 von 3 Fällen an unterschiedlichen stellen ab. Es gelingt ab und zu auch die Datei vollständig zu kopieren. Je größer die Datei ist, desto unwahrscheinlicher ist es aber, dass ich Erfolg habe.
Da die Fritzbox im Flur unterm Dach steht und ich aber häufig aus dem Wohnzimmer surfe (Luftlinie ca. 10m mit Wänden) erreiche ich nur eine Verbindungsgewschwindigkeit von ca. 1,5 bis 4 MB/s, je nachdem wo das Netbook gerade im Wohnzimmer steht. Die Geschwindigkeit lese ich übrigens aus dem Windowskopierdialog ab. Als Betriebssystem kommt auf dem Netbook Windows 7 pro zum Einsatz.
Noch zum Fehlerbild, während des Kopierens bleibt der Fortschrittsbalken irgendwann hängen und nach 1,2,3 Minuten bricht der Kopierenvorgang mit dem Fehler ab, dass die Daten nicht kopiert werden können.
Sobald ich eine Firmware >3.3 installiere kann ich den Fehler reproduzieren mit z.B. V3.2.8 ist der Fehler nicht mehr vorhanden.
Moondiver
Wenn ich wüßte was das mit Wlan zutun hätte, würde ich hier nicht fragen.
Fakt ist, dass ich per LAN keine Probleme habe
Fakt ist, dass ich Dateien nicht immer per Wlan auf das NAS kopieren kann
Fakt ist, dass dieses Problem reproduzierbar auftritt, wenn ich eine Firmware mit Versionnr. größer v3.3 aufspiele
Ich kann mir nur vorstellen, dass es mit der langsamen Übertragung von Wlan zu tun hat. Die Datenrate beim Upload liegt zwischen 1,5-4MB/s. Im Gegensatz zum LAN bremst nicht das NAS sondern die Wlan Verbindung. Ich vermute irgendwie ein Timingproblem im Zusammenhang mit Performanceoptimierungen, da das Problem bei allen Firmwareversionen auftritt, die eine höhere Schreib- und Leseperformance (3-10%) haben.
Ich würde den Beitrag nicht posten, wenn ich mir das Problem selbst erklären könnte und das was mich massiv wundert ist, dass das Problem durch eine anderen NAS Firmware behoben werden kann.
Dann frag ich mich aber, warum ich mit der V3.2.8 (und kleiner) das Problem nicht habe, aber mit der > v3.3?
Durch meine Tests könnte ich ja feststellen, dass das Problem mit einer Änderung der NAS Firmware behoben ist. Ich geh sehr wohl davon aus, dass das NAS der Schuldige ist.
Ich glaiub schon, dass das Problem am Qnap liegt, da es nur je nach Firmware auftritt, alle anderen Komponenten sind unverändert.
Wie gesagt, V3.2.8/3.2.7 etc. kein Problem, v3.3.x Problem.
Ich hab das Problem bei allen Firmware Versionen bei denen die Schreibgeschwindigkeit irgendwie beschleunigt ist. Die V3.3.x ist bei mir per LAN ca. 3-10% schneller als die V3.2.8 und vorherige. Es war nur eine Firmware Version (ich meine v3.2.5 oder v3.2.6) vorher mal dabei, die ähnlich schnelle Schreibzugriff geliefert hat.