none
Unterschiedliche Wartezeiten bei Druckjob über RDP und Standard TCP/IP-Port RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    wir haben hier eine Site-to-Site VPN-Verbindung über Internet zwischen Zentrale und Filiale. Im Netzwerk der Zentrale befindet sich der Server (W2k3) mit der ERP-Software. Im Netzwerk der Filiale befinden sich ein paar Win7- Clients und ein USB-Drucker, der über eine WLAN-Printerbox ins dortige Netzwerk eingebunden ist und mittels Standard TCP/IP-Port an einem der Clients installiert ist. Die Clients nutzen den RDP-Client von Win7, um auf den Server bzw. auf die ERP-Software zuzugreifen.

    Um den USB-Drucker der Filiale für das ERP-System am Server nutzbar zu machen, gibt es nun zwei Varianten:
    1) Der Drucker wird automatisch, aber temporär über den Remotedesktopclient des Clients am Server zur Verfügung gestellt oder
    2) der Drucker wird dauerhaft mit Standard TCP/IP-Port (LPR oder RAW) unter seiner im entfernten Netzwerk gültigen IP (IP der Printerbox) am Server installiert

    Unsere Beobachtung:
    Bei Einbindung des Druckers über RDP (Variante 1) wird ein Druckjob, z.B. eine Windows-Druckertestseite innerhalb von 1 Sekunde (!) verarbeitet (Druckjob verschwindet aus der Warteschlange und Drucker reagiert). Bei Einbindung des Druckers nach Variante 2 dauert es bei eingestelltem LPR-Protokoll gute 10 s, bei RAW-Protokoll ca. 20 s bis der Druckjob aus der Warteschlage verschwindet und der Drucker reagiert.

    Unser Systemhaus hat m.E. keine überzeugende Erklärung für die unterschiedliche Reaktionszeit. Man argumentiert, das RDP-Protokoll würde die Druckdaten besser komprimieren, als dies bei LPR oder RAW der Fall ist. Uns beschäftigt seitdem die Frage, ob das Systemhaus recht hat und die erhöhte Wartezeit tatsächlich protokollbedingt ist und wir bei Nutzung von Variante 2 damit leben müssen.

    Hat jemand fachkundige Infos für mich, ob es unter den geschilderten Bedingungen normal ist, dass es 10 -20 s dauert, bis der Druckjob verarbeitet wird, bei RDP hingegen sofort? Im Voraus vielen Dank.

    HimCT



    Dienstag, 9. August 2011 06:05
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden
    > bist Du Dir dabei? Ist es Deines Wissens nach definitiv so, dass über
    > RDP eine Komprimierung der Druckdaten im Client und eine Dekomprimierung
     
    MS drückt sich da etwas schwammig aus:
     
    Ich würde auch nicht unterschreiben, daß die Daten wirklich
    "komprimiert" werden, aber auf jeden Fall ist EasyPrint schneller als PCL5.
     
    > Kennst Du zufällig eine Lösung, bei der auch der direkte Datenstrom vom
    > Server zur Printerbox komprimiert werden kann? Unsere Leute in der
    > Filiale sind nämlich nicht sehr glücklich mit der Verzögerung …
     
    Ja ;-) Bluecoat oder Riverbed. ThinPrint gibts auch noch (sowie eine
    Reihe weiterer SW-Anbieter), aber das hab ich mir noch nicht näher
    angeschaut...
     
    Der Vorschlag mit dem dezentralen Druckserver bringt in Deinem Szenario
    nichts, da der Druck ja vom TS aus erfolgt, der "remote" steht.
     
    mfg Martin
     
    A bissle "Experience", a bissle GMV...
    Dienstag, 9. August 2011 14:32
    |

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden
    > z.B. eine Windows-Druckertestseite innerhalb von 1 Sekunde (!)
    > verarbeitet (Druckjob verschwindet aus der Warteschlange und Drucker
    > reagiert). Bei Einbindung des Druckers nach Variante 2 dauert es bei
    > eingestelltem LPR-Protokoll gute 10 s, bei RAW-Protokoll ca. 20 s bis
    > der Druckjob aus der Warteschlage verschwindet und der Drucker reagiert.
     
    Ja, natürlich. Wenn Ihr per IP direkt vom Server druckt, dann geht der
    unkomprimierte Datenstrom (i.d.R. PCL5/6) über die Leitung. Wenn Ihr per
    RDP druckt (möglicherweise sogar 2008R2 mit EasyPrint), dann geht nur
    ein Bruchteil der Daten über die Leitung...
     
    mfg Martin
     
    A bissle "Experience", a bissle GMV...
    Dienstag, 9. August 2011 08:18
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Martin Binder,

    vielen Dank für Deine Antwort.

    Komisch, jetzt wo Du das so schreibst, finde ich das mit der Komprimierung des Datenstroms dann doch nicht mehr so abwegig. Liegt wohl daran, dass unser Systemhaus erst einmal 1 Stunde Dienstleistung mit Rumprobieren (ich habe dabei zugesehen) verbraucht hat, und dann eher zögerlich die Komprimierungsthese aufgestellt hat.

    Ich hoffe Du verzeihst mir, wenn ich nochmals nachfrage – wie sicher bist Du Dir dabei? Ist es Deines Wissens nach definitiv so, dass über RDP eine Komprimierung der Druckdaten im Client und eine Dekomprimierung auf der Serverseite stattfindet, bei den Protokolle LPR bzw. RAW hingegen praktisch keine oder nur eine sehr schwache Komprimierung existiert?

    Kennst Du zufällig eine Lösung, bei der auch der direkte Datenstrom vom Server zur Printerbox komprimiert werden kann? Unsere Leute in der Filiale sind nämlich nicht sehr glücklich mit der Verzögerung …

    himCT

    Dienstag, 9. August 2011 13:54
    |
  • Question
    Anmelden
    1
    Anmelden
    > bist Du Dir dabei? Ist es Deines Wissens nach definitiv so, dass über
    > RDP eine Komprimierung der Druckdaten im Client und eine Dekomprimierung
     
    MS drückt sich da etwas schwammig aus:
     
    Ich würde auch nicht unterschreiben, daß die Daten wirklich
    "komprimiert" werden, aber auf jeden Fall ist EasyPrint schneller als PCL5.
     
    > Kennst Du zufällig eine Lösung, bei der auch der direkte Datenstrom vom
    > Server zur Printerbox komprimiert werden kann? Unsere Leute in der
    > Filiale sind nämlich nicht sehr glücklich mit der Verzögerung …
     
    Ja ;-) Bluecoat oder Riverbed. ThinPrint gibts auch noch (sowie eine
    Reihe weiterer SW-Anbieter), aber das hab ich mir noch nicht näher
    angeschaut...
     
    Der Vorschlag mit dem dezentralen Druckserver bringt in Deinem Szenario
    nichts, da der Druck ja vom TS aus erfolgt, der "remote" steht.
     
    mfg Martin
     
    A bissle "Experience", a bissle GMV...
    Dienstag, 9. August 2011 14:32
    |