Beiträge von angu

Hallo zusammen.

TL;DR:
Die aktuell in openSUSE enthaltene CUPS Version scheint beim Druck einzelner Aufträge / Seiten etwa 40% langsamer zu drucken als bisher,
wobei die Seiten nicht mehr am Stück, sondern in Häppchen mit Pausen dazwischen aus dem Drucker kommen.
Woran kann das liegen?

Lange Version
============
Ich habe ein Problem mit meiner LEAP 42.3 Installation und CUPS 1.7.5. Ein HP-Drucker (M608) der bisher unter openSUSE 13.2 (CUPS 1.5.4) betrieben wird ist unter LEAP erheblich langsamer.
Daraufhin habe ich Tests gemacht und herausgefunden, dass das neue System für das Drucken von 10 einzelnen PDFs statt 27 jetzt 40 Sekunden benötigt.
Das mag nicht so schlimm klingen, aber das System quasi den ganzen Tag auf diese weise, weshalb der Gesamtvorgang etwa 1,5 Stunden länger dauern würde als bisher.
Das neue System hat gleiche CPU und benutzt zusätzlich eine SSD - die man auch deutlich merkt. Es läuft ansonsten einwandfrei - ich arbeite täglich damit.

Man kann natürlich die Druckende Anwendung modifizieren - aber das geht nicht so ohne weiteres und verursacht erhebliche Kosten falls es überhaupt möglich ist.
Kurz und gut - ich kann das System nicht updaten.

Details:
Ich messe die Zeit so für den Druck eines 10-Seitigen Dokuments:
date && lp -d M608_Test 10_Seitiges_Dokument.pdf && read -p "Enter drücken wenn das letzte Blatt raus ist ..." && date
Ergebnisse:
altes System: 27 Sekunden
neues System: 29 Sekunden
Also alles noch im Rahmen - 1-2 Sekunden sind nicht schlimm und außerdem eh im Bereich der Messungenauigkeit.

Und den Druck 10 einzelner Dokumente mit je einer Seite messe ich so:
date && lp -d M608_Test Seite_01.pdf Seite_02.pdf Seite_03.pdf Seite_04.pdf Seite_05.pdf Seite_06.pdf Seite_07.pdf Seite_08.pdf Seite_09.pdf Seite_10.pdf && read -p "Enter drücken wenn das letzte Blatt raus ist ..." && date
Wobei die 10 Dateien auch tatsächlich unterschiedlichen Inhalt haben, es handelt sich aber um die selben 10 Seiten wie beim ersten Test.
Ergebnisse:
altes System: 27 Sekunden
neues System: 40 Sekunden <-- Hier liegt das Problem

Was ich dabei auch feststelle, ist dass einige Seiten schnell hintereinander gedruckt werden (meist 3), dann eine Pause kommt, dann wieder einige Seiten usw. So als würden die folgenden Aufträge erst übermittelt wenn die vorherigen abgeschlossen sind oder so.

Zunächst dachte ich es läge am neueren Treiber oder an HPLIP (dann ohne ausprobiert) und wollte mich schon an HP wenden. Jedoch habe ich obige Ergebnisse durch das kopieren der Konfiguration aus der
/etc/cups/printers.conf,
/etc/cups/lpoptions
/etc/printcap und dem Kopieren der entsprechenden ppd-Datei:
/etc/cups/ppd/M608_Test.ppd
vom alten ins neue System ermittelt.
Ich habe auch noch andere Treiber (HP9050, HPM806) ausprobiert (Drucker normal mit yast installiert) - welche alle auch mit diesem Drucker funktionieren - die Sind zwar alle etwas unterschiedlich von der Geschwindigkeit,
aber die heftige Differenz zwischen altem und neuem System bleibt.

Kommt dieses merkwürdige Verhalten vielleicht jemandem bekannt vor? Hat sich ggf. etwas am der CUPS-Verhalten geändert - irgend ein "Feature" das die Kommunikation mit dem Drucker bei Einzelaufträgen verzögert?
(... das man ggf. umkonfigurieren kann?)
Oder hat jemand ne Idee, was ich noch ausprobieren kann?

Also das was ich meinte hat nichts mit irgend welchen Grafikdefekten zu tun und verkrümelt sich auch zuverlässig nach gewisser Zeit wieder.
Das System wird zwar eine gewisse Zeit lang langsamer läuft aber ansonsten einwandfrei weiter.

Die von dir zuerst genannten Grafikartefekte bei den Icons habe ich (nach dem Suspend glaube ich) auch. Die haben aber nichts damit zu tun und sind harmlos.
(Ich selektiere dann einfach alle Icons - "tue so" als wollte ich sie verschieben - dann werden sie neu gezeichnet und gut.

Also wenn es dieser Bug in Zusammenhang mit btrfs ist (nicht notwendigerweise ein btrfs Bug - ich habe mich da ungünstig ausgedrückt),
dann passiert es tendenziell, wenn der Rechner längere Zeit abgeschaltet (kompletter Boot) war kurz nachdem Einschalten und dauert
etwa 1/2 Stunde. Dabei kannst du im ksysguard sehen, dass ein btrfs Prozess einen CPU Kern voll auslastet.
(100%/Anzahl Kerne - also 25% bei einem Vierkerner)

Vermutlich ist es immer noch dieser btrfs-bug:
Bug 1017461 – btrfs balance renders system unresponsive and eventually even kills WiFi when quota is enabled

Ist im Prinzip vermutlich nix wildes, sorgt aber dafür dass das System für eine gewisse Zeit unbenutzbar ist.

Hast du die Probleme ständig oder nur so selten wie im Thread beschrieben?

Also soweit ich mich erinnere, habe ich immer den Inhalt des default Profilverzeichnisses - also von <kauderwelsch>.default in die neue Installation kopiert (<anderes kauderwelsch>.default) und dann funktionierte sofort alles.

Das Verzeichnis ist normalerweise <user>/.thunderbird

Es wird nur angezeigt über ls mit Option (z.B. ls -a in der Konsole) oder bei Dolphin mit "Alt+." bzw. im Menü über Einstellungen.

Du hast doch nicht erwartet, dass ich *selbstständig* denke?

Ähh - was ist denn die Netzwerkkonfig? Alle Dateien und Unterverzeichnisse aus /etc/sysconfig/network/?
Das scheinen mir ein bisschen viele zu sein um sie hier zu posten.

Ist 42.2 nicht "unterstützt"?

Also es scheint wohl im Moment noch ein Fehler in Wicked zu sein, der zu o.g. Fehlermeldung und damit zum nicht funktionieren des
Routungeintrags führt.

Der beste "Workaround" scheint mir darim zu bestehen, das route-Kommando in /etc/init.d/after.local einzutragen.
Die Datei ist zwar nicht explizit für Netzwerkrouten vorgesehen, funktioniert aber.

wau:/home/douglas/Dokumente # ls -al /etc/sysconfig/network/
insgesamt 60
drwxr-xr-x 1 root root   164 14. Jun 15:38 .
drwxr-xr-x 1 root root   762 10. Jan 09:50 ..
-rw-r--r-- 1 root root  8693 12. Jun 15:02 config
-rw-r--r-- 1 root root  8212 12. Jun 15:02 dhcp
-rw-r--r-- 1 root root   163 14. Sep 2015  ifcfg-enp2s0
-rw------- 1 root root   173 14. Sep 2015  ifcfg-lo
-rw-r--r-- 1 root root 21738  6. Okt 2014  ifcfg.template
drwxr-xr-x 1 root root   100 14. Sep 2015  if-down.d
drwxr-xr-x 1 root root   150 14. Sep 2015  if-up.d
drwx------ 1 root root     0 25. Sep 2014  providers
-rw-r--r-- 1 root root   113 14. Jun 10:28 routes
drwxr-xr-x 1 root root   234 14. Sep 2015  scripts

In der Zwischenzeit habe ich folgendes herausbekommen:
- Bei Suse gibts NetworkManager und Wickedd :-), ersteres für grafische Benutzeroberflächen/Laptops - ich benutze also wicked.
- Wicked wird benutzt seit 13.2 und konnte das (statische Route bei dhcp ohne defaultroute) laut Bug 907495 noch nie. (Obwohl es vorher Jahrelang funktionierte wurde der Bug nicht als solcher anerkannt :-[)
- Mit NetworkManager geht es einwandfrei (Es gibt sogar eine Option zum Ignorieren der Defaultroute über DHCP)

Jetzt habe ich es mal auf einem 42.2-System probiert:
- da ist die Lage schon besser - DHCP funktioniert trotz eingetragener statischer Route (diesmal in ifroute-eth0 - eingetragen durch yast),
aber leider ist die route trotzdem nicht gesetzt, denn wickedd schmeißt folgende Fehlermeldung:

Jun 19 17:06:19 linux-1io5 wickedd[993]: __ni_rtnl_send_newroute(ipv4 192.168.129.0/24 via 133.98.2.220 dev eth0 type unicast table main scope universe protocol boot): ni_nl_talk failed [Unspecific failure]

Da ich sowieso updaten muss, würde es völlig reichen, wenn es unter 42.x funktioniert.

Natürlich muss es möglich sein dhcp mit statischen Routen zu mischen. Ist ja auch schon bewiesen - denn das Routing funktioniert ja wenn ich die Route per Hand setze.Die Frage lautet also wie bringe ich suse in der Konfiguration dazu, dhcp normal zu benutzen, und trotzdem die statische Route zu akzeptieren.

Da es sich um unterschiedliche Router für unterschiedliche Zwecke handelt macht das auch Sinn:
Die meisten Hosts benötigen nur dhcp, nur ein einziger muss das andere Netz kennen. Die Route nur auf dem Gateway einzutragen reicht alleine natürlich nicht aus,
denn woher soll mein System wissen, dass das Netz hinter dem Router überhaupt existiert - genau dazu dient ja ein Routingeintrag.

Ich kann natürlich die Route einfach als cronjob eintragen, oder als skript nach dem hochfahren "irgendwo" ausführen.
Aber ich hätte halt gern gewusst wie man es richtig macht.