Hello, all. Since moving to the newer clients using libssh, I've noticed what appears to be a performance degradation. It smells like Nagle coalescing packets, e.g., most of the screen will paint, then it will pause a moment, and then the rest will paint. Is there any chance we have neglected to disable Nagle when invoking libssh?
This appears to have affected the SNMP over SSH project: http://books.google.com/books?id=S62is2vVoVgC&pg=PA29&lpg=PA29&dq=libssh +nagle&source=bl&ots=F8Iw-pvQxd&sig=f5dfy0K0ewzSZOhqzTJRSKsDKZ8&hl=en&ei=KppzTrCZD4LJgQeMxLzzDA&sa=X&oi=book_result&ct=result&resnum=1&sqi=2&ved=0CBwQ6AEwAA#v=onepage&q=libssh%20nagle&f=false
This is in section 4.1. The difference was a latency of over 800ms to one of under 60ms. That seems to be about what I am seeing. There is a delay of roughly a second and then the rest of the screen comes through. Thanks - John
Hi John, hi Alex, On Fr 16 Sep 2011 21:56:38 CEST "John A. Sullivan III" wrote:
Hello, all. Since moving to the newer clients using libssh, I've noticed what appears to be a performance degradation. It smells like Nagle coalescing packets, e.g., most of the screen will paint, then it will pause a moment, and then the rest will paint. Is there any chance we have neglected to disable Nagle when invoking libssh?
This appears to have affected the SNMP over SSH project: http://books.google.com/books?id=S62is2vVoVgC&pg=PA29&lpg=PA29&dq=libssh +nagle&source=bl&ots=F8Iw-pvQxd&sig=f5dfy0K0ewzSZOhqzTJRSKsDKZ8&hl=en&ei=KppzTrCZD4LJgQeMxLzzDA&sa=X&oi=book_result&ct=result&resnum=1&sqi=2&ved=0CBwQ6AEwAA#v=onepage&q=libssh%20nagle&f=false
This is in section 4.1. The difference was a latency of over 800ms to one of under 60ms. That seems to be about what I am seeing. There is a delay of roughly a second and then the rest of the screen comes through. Thanks - John
Indeed the TCP_NODELAY (which means: turn Nagle off) is not set for the ssh tunnel in X2goClient. It probably is for the SSH connection itself, as the SNMP patch has been reported to libssh upstream and their patch suggestion has been sensible. However, for the SSH tunnels built up for X2go this TCP_NODELAY option does perhaps not get set. @Alex: would this patch fix that in x2goclient??? diff --git a/sshprocess.cpp b/sshprocess.cpp index 9e72e8f..03ee9b6 100644 --- a/sshprocess.cpp +++ b/sshprocess.cpp @@ -88,6 +88,7 @@ void SshProcess::tunnelLoop() const char y=1; #endif setsockopt(serverSocket, SOL_SOCKET, SO_REUSEADDR,&y, sizeof(int)); + setsockopt(serverSocket, IPPROTO_TCP, TCP_NODELAY,&y, sizeof(int)); address.sin_family=AF_INET; address.sin_addr.s_addr=INADDR_ANY; @John: could you get the latest sources of x2goclient from our Git: git clone git://code.x2go.org/x2goclient.git and run debuild -uc -us (plus fullfill build-deps before) on a Debian squeeze or above system and check if the patch fixes your delays??? Best+Thanks, Mike -- DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419 GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Fri, 2011-09-16 at 23:17 +0200, Mike Gabriel wrote:
Hi John, hi Alex,
On Fr 16 Sep 2011 21:56:38 CEST "John A. Sullivan III" wrote:
Hello, all. Since moving to the newer clients using libssh, I've noticed what appears to be a performance degradation. It smells like Nagle coalescing packets, e.g., most of the screen will paint, then it will pause a moment, and then the rest will paint. Is there any chance we have neglected to disable Nagle when invoking libssh?
This appears to have affected the SNMP over SSH project: http://books.google.com/books?id=S62is2vVoVgC&pg=PA29&lpg=PA29&dq=libssh +nagle&source=bl&ots=F8Iw-pvQxd&sig=f5dfy0K0ewzSZOhqzTJRSKsDKZ8&hl=en&ei=KppzTrCZD4LJgQeMxLzzDA&sa=X&oi=book_result&ct=result&resnum=1&sqi=2&ved=0CBwQ6AEwAA#v=onepage&q=libssh%20nagle&f=false
This is in section 4.1. The difference was a latency of over 800ms to one of under 60ms. That seems to be about what I am seeing. There is a delay of roughly a second and then the rest of the screen comes through. Thanks - John
Indeed the TCP_NODELAY (which means: turn Nagle off) is not set for the ssh tunnel in X2goClient. It probably is for the SSH connection itself, as the SNMP patch has been reported to libssh upstream and their patch suggestion has been sensible. However, for the SSH tunnels built up for X2go this TCP_NODELAY option does perhaps not get set.
@Alex: would this patch fix that in x2goclient???
diff --git a/sshprocess.cpp b/sshprocess.cpp index 9e72e8f..03ee9b6 100644 --- a/sshprocess.cpp +++ b/sshprocess.cpp @@ -88,6 +88,7 @@ void SshProcess::tunnelLoop() const char y=1; #endif setsockopt(serverSocket, SOL_SOCKET, SO_REUSEADDR,&y, sizeof(int));
setsockopt(serverSocket, IPPROTO_TCP, TCP_NODELAY,&y, sizeof(int));
address.sin_family=AF_INET; address.sin_addr.s_addr=INADDR_ANY;
@John: could you get the latest sources of x2goclient from our Git:
git clone git://code.x2go.org/x2goclient.git
and run debuild -uc -us (plus fullfill build-deps before) on a Debian squeeze or above system and check if the patch fixes your delays???
Best+Thanks, Mike <snip> Thanks for digging that out, Mike. I'm going to mark this mail so I don't forget it as I likely won't have a chance to do this before Monday. Perhaps we'll have confirmation from Alex by then - John
Hi John, hi Alex,
On Fr 16 Sep 2011 21:56:38 CEST "John A. Sullivan III" wrote:
Hello, all. Since moving to the newer clients using libssh, I've noticed what appears to be a performance degradation. It smells like Nagle coalescing packets, e.g., most of the screen will paint, then it will pause a moment, and then the rest will paint. Is there any chance we have neglected to disable Nagle when invoking libssh?
This appears to have affected the SNMP over SSH project: http://books.google.com/books?id=S62is2vVoVgC&pg=PA29&lpg=PA29&dq=libssh +nagle&source=bl&ots=F8Iw-pvQxd&sig=f5dfy0K0ewzSZOhqzTJRSKsDKZ8&hl=en&ei=KppzTrCZD4LJgQeMxLzzDA&sa=X&oi=book_result&ct=result&resnum=1&sqi=2&ved=0CBwQ6AEwAA#v=onepage&q=libssh%20nagle&f=false
This is in section 4.1. The difference was a latency of over 800ms to one of under 60ms. That seems to be about what I am seeing. There is a delay of roughly a second and then the rest of the screen comes through. Thanks - John
Indeed the TCP_NODELAY (which means: turn Nagle off) is not set for the ssh tunnel in X2goClient. It probably is for the SSH connection itself, as the SNMP patch has been reported to libssh upstream and their patch suggestion has been sensible. However, for the SSH tunnels built up for X2go this TCP_NODELAY option does perhaps not get set.
@Alex: would this patch fix that in x2goclient???
diff --git a/sshprocess.cpp b/sshprocess.cpp index 9e72e8f..03ee9b6 100644 --- a/sshprocess.cpp +++ b/sshprocess.cpp @@ -88,6 +88,7 @@ void SshProcess::tunnelLoop() const char y=1; #endif setsockopt(serverSocket, SOL_SOCKET, SO_REUSEADDR,&y, sizeof(int));
setsockopt(serverSocket, IPPROTO_TCP, TCP_NODELAY,&y, sizeof(int));
address.sin_family=AF_INET; address.sin_addr.s_addr=INADDR_ANY;
@John: could you get the latest sources of x2goclient from our Git:
git clone git://code.x2go.org/x2goclient.git
and run debuild -uc -us (plus fullfill build-deps before) on a Debian squeeze or above system and check if the patch fixes your delays???
Best+Thanks, Mike <snip> Hmm . . . I wonder if this explains why the Windows client performance is so much worse than Linux. I assumed it was an X to GDI translation issue but the symptoms I described in scrolling through Evolution mail are press several keystrokes and one actions, then a long pause, then
On Fri, 2011-09-16 at 23:17 +0200, Mike Gabriel wrote: the rest of the keystrokes follow as if they've been buffered - John
Am 17.09.2011 03:39, schrieb John A. Sullivan III:
On Fri, 2011-09-16 at 23:17 +0200, Mike Gabriel wrote:
Hi John, hi Alex,
On Fr 16 Sep 2011 21:56:38 CEST "John A. Sullivan III" wrote:
Hello, all. Since moving to the newer clients using libssh, I've noticed what appears to be a performance degradation. It smells like Nagle coalescing packets, e.g., most of the screen will paint, then it will pause a moment, and then the rest will paint. Is there any chance we have neglected to disable Nagle when invoking libssh?
This appears to have affected the SNMP over SSH project: http://books.google.com/books?id=S62is2vVoVgC&pg=PA29&lpg=PA29&dq=libssh +nagle&source=bl&ots=F8Iw-pvQxd&sig=f5dfy0K0ewzSZOhqzTJRSKsDKZ8&hl=en&ei=KppzTrCZD4LJgQeMxLzzDA&sa=X&oi=book_result&ct=result&resnum=1&sqi=2&ved=0CBwQ6AEwAA#v=onepage&q=libssh%20nagle&f=false
This is in section 4.1. The difference was a latency of over 800ms to one of under 60ms. That seems to be about what I am seeing. There is a delay of roughly a second and then the rest of the screen comes through. Thanks - John
Indeed the TCP_NODELAY (which means: turn Nagle off) is not set for the ssh tunnel in X2goClient. It probably is for the SSH connection itself, as the SNMP patch has been reported to libssh upstream and their patch suggestion has been sensible. However, for the SSH tunnels built up for X2go this TCP_NODELAY option does perhaps not get set.
@Alex: would this patch fix that in x2goclient???
diff --git a/sshprocess.cpp b/sshprocess.cpp index 9e72e8f..03ee9b6 100644 --- a/sshprocess.cpp +++ b/sshprocess.cpp @@ -88,6 +88,7 @@ void SshProcess::tunnelLoop() const char y=1; #endif setsockopt(serverSocket, SOL_SOCKET, SO_REUSEADDR,&y, sizeof(int));
setsockopt(serverSocket, IPPROTO_TCP, TCP_NODELAY,&y, sizeof(int));
address.sin_family=AF_INET; address.sin_addr.s_addr=INADDR_ANY;
I don't think that that can be helpful. This part of code is only for reverse tunnel which is used for FS forwarding and Pulse Audio.
@John: could you get the latest sources of x2goclient from our Git:
git clone git://code.x2go.org/x2goclient.git
and run debuild -uc -us (plus fullfill build-deps before) on a Debian squeeze or above system and check if the patch fixes your delays???
Best+Thanks, Mike
<snip> Hmm . . . I wonder if this explains why the Windows client performance is so much worse than Linux. I assumed it was an X to GDI translation issue but the symptoms I described in scrolling through Evolution mail are press several keystrokes and one actions, then a long pause, then the rest of the keystrokes follow as if they've been buffered - John
X2go-Dev mailing list X2go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
I can imagine, that it can be problem in libssh on Windows. Can you try to build a new libssh.dll on your system? However, I still cannot reproduce your issue on my windows client :( regards, Alex -- Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de --> X2go - everywhere@home
On Mon, 2011-09-19 at 09:51 +0200, Oleksandr Shneyder wrote:
Am 17.09.2011 03:39, schrieb John A. Sullivan III: <snip>>>> Hello, all. Since moving to the newer clients using libssh, I've
noticed what appears to be a performance degradation. It smells like Nagle coalescing packets, e.g., most of the screen will paint, then it will pause a moment, and then the rest will paint. Is there any chance we have neglected to disable Nagle when invoking libssh? <snip> I can imagine, that it can be problem in libssh on Windows. Can you try to build a new libssh.dll on your system? However, I still cannot reproduce your issue on my windows client :(
regards, Alex <snip> Thanks, Alex, although I see the problem in Linux, though not as badly. I can give a new libssh.dll a try. Any pointers on how I build myself a new one? Thanks - John
Am 19.09.2011 13:18, schrieb John A. Sullivan III:
On Mon, 2011-09-19 at 09:51 +0200, Oleksandr Shneyder wrote:
Am 17.09.2011 03:39, schrieb John A. Sullivan III: <snip>>>> Hello, all. Since moving to the newer clients using libssh, I've
noticed what appears to be a performance degradation. It smells like Nagle coalescing packets, e.g., most of the screen will paint, then it will pause a moment, and then the rest will paint. Is there any chance we have neglected to disable Nagle when invoking libssh? <snip> I can imagine, that it can be problem in libssh on Windows. Can you try to build a new libssh.dll on your system? However, I still cannot reproduce your issue on my windows client :(
regards, Alex <snip> Thanks, Alex, although I see the problem in Linux, though not as badly. I can give a new libssh.dll a try. Any pointers on how I build myself a new one? Thanks - John
X2go-Dev mailing list X2go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
As I can remember, you need a cmake and mingw. for other dependencies you will be informed by cmake.
regards, Alex
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Hi Alex, On Mo 19 Sep 2011 09:51:16 CEST Oleksandr Shneyder wrote:
Am 17.09.2011 03:39, schrieb John A. Sullivan III:
On Fri, 2011-09-16 at 23:17 +0200, Mike Gabriel wrote:
Hi John, hi Alex,
On Fr 16 Sep 2011 21:56:38 CEST "John A. Sullivan III" wrote:
Hello, all. Since moving to the newer clients using libssh, I've noticed what appears to be a performance degradation. It smells like Nagle coalescing packets, e.g., most of the screen will paint, then it will pause a moment, and then the rest will paint. Is there any chance we have neglected to disable Nagle when invoking libssh?
This appears to have affected the SNMP over SSH project: http://books.google.com/books?id=S62is2vVoVgC&pg=PA29&lpg=PA29&dq=libssh +nagle&source=bl&ots=F8Iw-pvQxd&sig=f5dfy0K0ewzSZOhqzTJRSKsDKZ8&hl=en&ei=KppzTrCZD4LJgQeMxLzzDA&sa=X&oi=book_result&ct=result&resnum=1&sqi=2&ved=0CBwQ6AEwAA#v=onepage&q=libssh%20nagle&f=false
This is in section 4.1. The difference was a latency of over 800ms to one of under 60ms. That seems to be about what I am seeing. There is a delay of roughly a second and then the rest of the screen comes through. Thanks - John
Indeed the TCP_NODELAY (which means: turn Nagle off) is not set for the ssh tunnel in X2goClient. It probably is for the SSH connection itself, as the SNMP patch has been reported to libssh upstream and their patch suggestion has been sensible. However, for the SSH tunnels built up for X2go this TCP_NODELAY option does perhaps not get set.
@Alex: would this patch fix that in x2goclient???
diff --git a/sshprocess.cpp b/sshprocess.cpp index 9e72e8f..03ee9b6 100644 --- a/sshprocess.cpp +++ b/sshprocess.cpp @@ -88,6 +88,7 @@ void SshProcess::tunnelLoop() const char y=1; #endif setsockopt(serverSocket, SOL_SOCKET, SO_REUSEADDR,&y, sizeof(int));
setsockopt(serverSocket, IPPROTO_TCP, TCP_NODELAY,&y, sizeof(int));
address.sin_family=AF_INET; address.sin_addr.s_addr=INADDR_ANY;
I don't think that that can be helpful. This part of code is only for reverse tunnel which is used for FS forwarding and Pulse Audio.
I took another close look at the code of sshProcess.cpp. The patch is applied to the method sshProcess::tunnelLoop. This method only gets execute in sshProcess::startTunnel. The call is: <quote> if (!reverse) tunnelLoop(); else { <blablabla> } </quote> So this makes me think that tunnelLoop() is not for reverse tunneling but for the graphics tunnel. Could you take another look please? Thanks, Mike -- DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419 GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Am 19.09.2011 13:30, schrieb Mike Gabriel:
Hi Alex,
On Mo 19 Sep 2011 09:51:16 CEST Oleksandr Shneyder wrote:
Am 17.09.2011 03:39, schrieb John A. Sullivan III:
On Fri, 2011-09-16 at 23:17 +0200, Mike Gabriel wrote:
Hi John, hi Alex,
On Fr 16 Sep 2011 21:56:38 CEST "John A. Sullivan III" wrote:
Hello, all. Since moving to the newer clients using libssh, I've noticed what appears to be a performance degradation. It smells like Nagle coalescing packets, e.g., most of the screen will paint, then it will pause a moment, and then the rest will paint. Is there any chance we have neglected to disable Nagle when invoking libssh?
This appears to have affected the SNMP over SSH project: http://books.google.com/books?id=S62is2vVoVgC&pg=PA29&lpg=PA29&dq=libssh
+nagle&source=bl&ots=F8Iw-pvQxd&sig=f5dfy0K0ewzSZOhqzTJRSKsDKZ8&hl=en&ei=KppzTrCZD4LJgQeMxLzzDA&sa=X&oi=book_result&ct=result&resnum=1&sqi=2&ved=0CBwQ6AEwAA#v=onepage&q=libssh%20nagle&f=false
This is in section 4.1. The difference was a latency of over 800ms to one of under 60ms. That seems to be about what I am seeing. There is a delay of roughly a second and then the rest of the screen comes through. Thanks - John
Indeed the TCP_NODELAY (which means: turn Nagle off) is not set for the ssh tunnel in X2goClient. It probably is for the SSH connection itself, as the SNMP patch has been reported to libssh upstream and their patch suggestion has been sensible. However, for the SSH tunnels built up for X2go this TCP_NODELAY option does perhaps not get set.
@Alex: would this patch fix that in x2goclient???
diff --git a/sshprocess.cpp b/sshprocess.cpp index 9e72e8f..03ee9b6 100644 --- a/sshprocess.cpp +++ b/sshprocess.cpp @@ -88,6 +88,7 @@ void SshProcess::tunnelLoop() const char y=1; #endif setsockopt(serverSocket, SOL_SOCKET, SO_REUSEADDR,&y, sizeof(int));
setsockopt(serverSocket, IPPROTO_TCP, TCP_NODELAY,&y, sizeof(int));
address.sin_family=AF_INET; address.sin_addr.s_addr=INADDR_ANY;
I don't think that that can be helpful. This part of code is only for reverse tunnel which is used for FS forwarding and Pulse Audio.
I took another close look at the code of sshProcess.cpp. The patch is applied to the method sshProcess::tunnelLoop. This method only gets execute in sshProcess::startTunnel.
The call is:
<quote> if (!reverse) tunnelLoop(); else { <blablabla> } </quote>
So this makes me think that tunnelLoop() is not for reverse tunneling but for the graphics tunnel.
Could you take another look please?
Thanks, Mike
hmmm, ok, seems you are right :) Can you apply this patch to source tree and I'll try to build a windows binary tomorrow. regards, Alex -- Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de --> X2go - everywhere@home
Hi Alex,
On Mo 19 Sep 2011 13:44:15 CEST Oleksandr Shneyder wrote:
hmmm, ok, seems you are right :) Can you apply this patch to source tree and I'll try to build a windows binary tomorrow.
regards, Alex
patch has been committed. I'll build new packages for Debian tonight
(I am at a customer location right now).
Thanks, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Mon, 2011-09-19 at 14:54 +0200, Mike Gabriel wrote:
Hi Alex,
On Mo 19 Sep 2011 13:44:15 CEST Oleksandr Shneyder wrote:
hmmm, ok, seems you are right :) Can you apply this patch to source tree and I'll try to build a windows binary tomorrow.
regards, Alex
patch has been committed. I'll build new packages for Debian tonight
(I am at a customer location right now).Thanks, Mike
<snip> I can confirm the significant improvement in performance. For example, and what really made me think Nagle, my ping results display much better. When doing ping tests previously, the results would stutter even though the response times were nearly even. In fact, sometimes I would seem to miss a packet only to have two display the next second. They are now perfectly smooth.
However, we still have a BIG problem. X2Go client printing still segfaults the entire client every single time we try to print. Phil has confirmed this independently from me. Any ETA on that fix? Thanks - John
Hi John,
On Di 20 Sep 2011 12:37:18 CEST "John A. Sullivan III" wrote:
On Mon, 2011-09-19 at 14:54 +0200, Mike Gabriel wrote:
Hi Alex,
On Mo 19 Sep 2011 13:44:15 CEST Oleksandr Shneyder wrote:
hmmm, ok, seems you are right :) Can you apply this patch to source tree and I'll try to build a windows binary tomorrow.
regards, Alex
patch has been committed. I'll build new packages for Debian tonight (I am at a customer location right now).
Thanks, Mike
<snip> I can confirm the significant improvement in performance. For example, and what really made me think Nagle, my ping results display much better. When doing ping tests previously, the results would stutter even though the response times were nearly even. In fact, sometimes I would seem to miss a packet only to have two display the next second. They are now perfectly smooth.
PERFECT!!!!
I have also checked python-x2go for TCP_NODELAY issues. And: audio had
Nagle still turned on, now Nagle is turned off for all sorts of
tunneling in python-x2go, as well. (Audio is now much smoother than it
was before).
However, we still have a BIG problem. X2Go client printing still segfaults the entire client every single time we try to print. Phil has confirmed this independently from me. Any ETA on that fix? Thanks - John
I have just fixed a build problem on Debian wheezy/sid with
x2goclient. I tested the newly built package locally and printing
works, never encountered any problem before, though. But this might be
because I am mainly using pyhoca-gui for working with X2go.
Packages with the cupsprint.h patch are currently building and should
be available in half an hour's time. Please check, if the problem is
solved with them.
Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Am 20.09.2011 12:37, schrieb John A. Sullivan III:
On Mon, 2011-09-19 at 14:54 +0200, Mike Gabriel wrote:
<snip> I can confirm the significant improvement in performance. For example, and what really made me think Nagle, my ping results display much better. When doing ping tests previously, the results would stutter even though the response times were nearly even. In fact, sometimes I would seem to miss a packet only to have two display the next second. They are now perfectly smooth.
However, we still have a BIG problem. X2Go client printing still segfaults the entire client every single time we try to print. Phil has confirmed this independently from me. Any ETA on that fix? Thanks - John
I cannot reproduce it. I've tried to print with win xp and win7. No issues. Can it be an issue related to your special environment?
regards,
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
On Tue, 2011-09-20 at 16:42 +0200, Oleksandr Shneyder wrote:
Am 20.09.2011 12:37, schrieb John A. Sullivan III:
On Mon, 2011-09-19 at 14:54 +0200, Mike Gabriel wrote:
<snip> I can confirm the significant improvement in performance. For example, and what really made me think Nagle, my ping results display much better. When doing ping tests previously, the results would stutter even though the response times were nearly even. In fact, sometimes I would seem to miss a packet only to have two display the next second. They are now perfectly smooth.
However, we still have a BIG problem. X2Go client printing still segfaults the entire client every single time we try to print. Phil has confirmed this independently from me. Any ETA on that fix? Thanks - John
I cannot reproduce it. I've tried to print with win xp and win7. No issues. Can it be an issue related to your special environment?
regards, <snip> I doubt it as the problem is one the client side and not the server side. All our changes were to the server. This is in the Squeeze client and not Windows - John
Hi John,
On Di 20 Sep 2011 18:27:24 CEST "Jhn A. Sullivan III" wrote:
<snip> I doubt it as the problem is one the client side and not the server side. All our changes were to the server. This is in the Squeeze client and not Windows - John
Does the problem disappear with the latest x2goclient (built today
around 4pm CEST).Can you send me the ,,printing'' config file in ~/.x2goclient?
Can you send me /etc/cups/printers.conf?
Thanks, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Tue, 2011-09-20 at 20:15 +0200, Mike Gabriel wrote:
Hi John,
On Di 20 Sep 2011 18:27:24 CEST "Jhn A. Sullivan III" wrote:
<snip> I doubt it as the problem is one the client side and not the server side. All our changes were to the server. This is in the Squeeze client and not Windows - John
Does the problem disappear with the latest x2goclient (built today
around 4pm CEST).Can you send me the ,,printing'' config file in ~/.x2goclient?
Can you send me /etc/cups/printers.conf?
Thanks, Mike <snip> Just tried. It still crashes. Here is /etc/cups/printers.conf: # Printer configuration file for CUPS v1.4.4 # Written by cupsd # DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING <DefaultPrinter HP_2605dn> Info HP2605dn Location Kennebunk MakeModel HP Color LaserJet 2605dn Foomatic/Postscript DeviceURI socket://192.168.223.99:9100 State Idle StateTime 1311624159 Type 8400924 Filter application/vnd.cups-raw 0 - Filter application/vnd.cups-postscript 100 foomatic-rip Filter application/vnd.cups-pdf 0 foomatic-rip Accepting Yes Shared No JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 OpPolicy default ErrorPolicy stop-printer </Printer>
and here is .x2goclient/printing: [General] showdialog=true pdfview=false
[print] startcmd=false command=lpr stdin=false ps=false
[view] open=true command=kpdf
[CUPS] defaultprinter=HP_2605dn options\HP2605="Duplex=DuplexTumble", "HPColorSmart=Manual", "ColorModel=Gray1200x1200dpi" options\HP2605dn="Duplex=DuplexNoTumble", "CMAndResolution=Gray600x600dpi" options\HP_2605dn="Duplex=DuplexNoTumble"
I took an strace but it does not reveal a lot. Here are pertinent sections from the end of x2gotrace.3420:
time(NULL) = 1316637069 time(NULL) = 1316637069 recv(29, "-hold-until-default\0\7no-hold!\0\24j"..., 2048, 0) = 2048 time(NULL) = 1316637069 recv(29, "utionD\0\0\0\5sidesD\0\30job-hold-until"..., 2048, 0) = 2048 time(NULL) = 1316637069 recv(29, "\4\0\0\0&#\0\0\0\4\0\0@\1#\0\0\0\4\0\0@\2#\0\0\0\4\0\0@\3"..., 448, 0) = 448 time(NULL) = 1316637069 open("/etc/cups/lpoptions", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) access("/home/jsullivan/.cups/lpoptions", F_OK) = -1 ENOENT (No such file or directory) open("/home/jsullivan/.lpoptions", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) stat64("/home/jsullivan/.x2goclient/printing", {st_mode=S_IFREG|0755, st_size=369, ...}) = 0 open("/home/jsullivan/.x2goclient/printing", O_RDONLY|O_LARGEFILE| O_CLOEXEC) = 31 fcntl64(31, F_SETFD, FD_CLOEXEC) = 0 fstat64(31, {st_mode=S_IFREG|0755, st_size=369, ...}) = 0 close(31) = 0 stat64("/home/jsullivan/.x2goclient/printing", {st_mode=S_IFREG|0755, st_size=369, ...}) = 0 stat64("/home/jsullivan/.x2goclient/printing", {st_mode=S_IFREG|0755, st_size=369, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 stat64("/etc/cups/ppd/HP_2605dn.ppd", {st_mode=S_IFREG|0644, st_size=9953, ...}) = 0 gettimeofday({1316637069, 848633}, NULL) = 0 symlink("/etc/cups/ppd/HP_2605dn.ppd", "/tmp/4e7a498dcf2f9") = 0 open("/tmp/4e7a498dcf2f9", O_RDONLY|O_LARGEFILE) = 31 fcntl64(31, F_GETFD) = 0 fcntl64(31, F_SETFD, FD_CLOEXEC) = 0 read(31, "*PPD-Adobe: \"4.3\"\n*%\n*% For info"..., 4096) = 4096 read(31, "\n*PageRegion Letter/US Letter: \""..., 4096) = 4096 read(31, "Standard \"(001.004S)\" Standard R"..., 4096) = 1761 read(31, "", 4096) = 0 read(31, "", 4096) = 0 close(31) = 0 unlink("/tmp/4e7a498dcf2f9") = 0 stat64("/home/jsullivan/.x2goclient/printing", {st_mode=S_IFREG|0755, st_size=369, ...}) = 0 open("/home/jsullivan/.x2goclient/printing", O_RDONLY|O_LARGEFILE| O_CLOEXEC) = 31 fcntl64(31, F_SETFD, FD_CLOEXEC) = 0 fstat64(31, {st_mode=S_IFREG|0755, st_size=369, ...}) = 0 close(31) = 0 stat64("/home/jsullivan/.x2goclient/printing", {st_mode=S_IFREG|0755, st_size=369, ...}) = 0 stat64("/home/jsullivan/.x2goclient/printing", {st_mode=S_IFREG|0755, st_size=369, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 time(NULL) = 1316637070 time(NULL) = 1316637070 . . . . time(NULL) = 1316637071 time(NULL) = 1316637071 clock_gettime(CLOCK_MONOTONIC, {709, 441819023}) = 0 select(13, [12], NULL, NULL, {0, 0}) = 0 (Timeout) clock_gettime(CLOCK_MONOTONIC, {709, 444143062}) = 0 open("/home/jsullivan/.x2go/S-jasiii-53-1316636661_stDKDE_dp24/spool", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 31 statfs("/home/jsullivan/.x2go/S-jasiii-53-1316636661_stDKDE_dp24/spool", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=12812451, f_bfree=11505345, f_bavail=11375175, f_f getdents(31, /* 3 entries */, 32768) = 76 stat64("/home/jsullivan/.x2go/S-jasiii-53-1316636661_stDKDE_dp24/spool/.", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 stat64("/home/jsullivan/.x2go/S-jasiii-53-1316636661_stDKDE_dp24/spool/13008-jasiii-cupsjob13904.pdf", {st_mode=S_IFREG|0644, st_size=23397, ...}) = 0 getdents(31, /* 0 entries */, 32768) = 0 close(31) = 0 stat64("/home/jsullivan/.x2go/S-jasiii-53-1316636661_stDKDE_dp24/spool/..", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 clock_gettime(CLOCK_MONOTONIC, {709, 729349572}) = 0 poll([{fd=7, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=7, revents=POLLOUT}]) writev(7, [{"\224\7\2\0\0\22\200\3\22\0\n\0\377\21\200\3[\1\0\0[\1\0\0 \10\21\200\3\20\0\0\0"..., 96}, {NULL, 0}, {"", 0}], 3) = 96 read(7, "\34\0\335b\377\21\200\3[\1\0\0\234\324\n\0\0\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0"..., 4096) = 704 read(7, 0x9bede30, 4096) = -1 EAGAIN (Resource temporarily unavailable) read(7, 0x9bede30, 4096) = -1 EAGAIN (Resource temporarily unavailable) munmap(0xb5b82000, 65932) = 0 munmap(0xb5ab5000, 633604) = 0 munmap(0xb5aa6000, 58716) = 0 munmap(0xb5894000, 584396) = 0 poll([{fd=7, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=7, revents=POLLOUT}]) writev(7, [{"\224\7\2\0\31\0\200\3\22\0\n\0\30\0\200\3[\1\0\0[\1\0\0\10 \21\200\3\20\0\0\0"..., 3372}, {NULL, 0}, {"", 0}], 3) = 3372 poll([{fd=7, events=POLLIN}], 1, -1) = 1 ([{fd=7, revents=POLLIN}]) read(7, "\34\0\345b\30\0\200\3[\1\0\0N\325\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\0\0"..., 4096) = 1376 read(7, 0x9bede30, 4096) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=7, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=7, revents=POLLIN|POLLOUT}]) read(7, "\26\0\201du\1\200\1u\1\200\1\0\0\0\0\0\0\0\0t\0\36\0\0\0\0\0\0 \0\0\0", 4096) = 32 writev(7, [{"O\7\2\0\1\0\200\3<\0\2\0\0\0\200\3.\1\2\0\5\0\200\3+\21\1 \0", 28}, {NULL, 0}, {"", 0}], 3) = 28 poll([{fd=7, events=POLLIN}], 1, -1) = 1 ([{fd=7, revents=POLLIN}]) read(7, "\1\1\205d\0\0\0\0\6\0`\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0", 4096) = 32 read(7, 0x9bede30, 4096) = -1 EAGAIN (Resource temporarily unavailable) close(7) = 0 write(8, "\1\v\1\0\1\0\0\0\0\0\0\0\0\0\0\0", 16) = 16 close(8) = 0 open("/proc/stat", O_RDONLY|O_CLOEXEC) = 7 read(7, "cpu 53876 11825 26767 40263 127"..., 8192) = 2875 close(7) = 0 write(6, "@", 1) = 1 close(6) = 0 close(5) = 0 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_NOCLDSTOP}, {0xb68cc3b0, [], SA_NOCLDSTOP}, 8) = 0 exit_group(0) = ?
I tried to intercept it with ddd but that didn't work. Interestingly, its messages were that the program closed normally as if x2goprinting is invoking a close event. I'll see what I can do to get this to run from a debugger but it is a showstopping bug for us - John
On Wed, 2011-09-21 at 16:55 -0400, John A. Sullivan III wrote:
On Tue, 2011-09-20 at 20:15 +0200, Mike Gabriel wrote:
Hi John,
On Di 20 Sep 2011 18:27:24 CEST "Jhn A. Sullivan III" wrote:
<snip> I doubt it as the problem is one the client side and not the server side. All our changes were to the server. This is in the Squeeze client and not Windows - John
Does the problem disappear with the latest x2goclient (built today
around 4pm CEST).Can you send me the ,,printing'' config file in ~/.x2goclient?
Can you send me /etc/cups/printers.conf?
Thanks, Mike <snip> Just tried. It still crashes. Here is /etc/cups/printers.conf: # Printer configuration file for CUPS v1.4.4 # Written by cupsd # DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING <DefaultPrinter HP_2605dn> Info HP2605dn Location Kennebunk MakeModel HP Color LaserJet 2605dn Foomatic/Postscript DeviceURI socket://192.168.223.99:9100 State Idle StateTime 1311624159 Type 8400924 Filter application/vnd.cups-raw 0 - Filter application/vnd.cups-postscript 100 foomatic-rip Filter application/vnd.cups-pdf 0 foomatic-rip Accepting Yes Shared No JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 OpPolicy default ErrorPolicy stop-printer </Printer>
and here is .x2goclient/printing: [General] showdialog=true pdfview=false
[print] startcmd=false command=lpr stdin=false ps=false
[view] open=true command=kpdf
[CUPS] defaultprinter=HP_2605dn options\HP2605="Duplex=DuplexTumble", "HPColorSmart=Manual", "ColorModel=Gray1200x1200dpi" options\HP2605dn="Duplex=DuplexNoTumble", "CMAndResolution=Gray600x600dpi" options\HP_2605dn="Duplex=DuplexNoTumble"
I took an strace but it does not reveal a lot. Here are pertinent sections from the end of x2gotrace.3420:
time(NULL) = 1316637069 time(NULL) = 1316637069 recv(29, "-hold-until-default\0\7no-hold!\0\24j"..., 2048, 0) = 2048 time(NULL) = 1316637069 recv(29, "utionD\0\0\0\5sidesD\0\30job-hold-until"..., 2048, 0) = 2048 time(NULL) = 1316637069 recv(29, "\4\0\0\0&#\0\0\0\4\0\0@\1#\0\0\0\4\0\0@\2#\0\0\0\4\0\0@\3"..., 448, 0) = 448 time(NULL) = 1316637069 open("/etc/cups/lpoptions", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) access("/home/jsullivan/.cups/lpoptions", F_OK) = -1 ENOENT (No such file or directory) open("/home/jsullivan/.lpoptions", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) stat64("/home/jsullivan/.x2goclient/printing", {st_mode=S_IFREG|0755, st_size=369, ...}) = 0 open("/home/jsullivan/.x2goclient/printing", O_RDONLY|O_LARGEFILE| O_CLOEXEC) = 31 fcntl64(31, F_SETFD, FD_CLOEXEC) = 0 fstat64(31, {st_mode=S_IFREG|0755, st_size=369, ...}) = 0 close(31) = 0 stat64("/home/jsullivan/.x2goclient/printing", {st_mode=S_IFREG|0755, st_size=369, ...}) = 0 stat64("/home/jsullivan/.x2goclient/printing", {st_mode=S_IFREG|0755, st_size=369, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 stat64("/etc/cups/ppd/HP_2605dn.ppd", {st_mode=S_IFREG|0644, st_size=9953, ...}) = 0 gettimeofday({1316637069, 848633}, NULL) = 0 symlink("/etc/cups/ppd/HP_2605dn.ppd", "/tmp/4e7a498dcf2f9") = 0 open("/tmp/4e7a498dcf2f9", O_RDONLY|O_LARGEFILE) = 31 fcntl64(31, F_GETFD) = 0 fcntl64(31, F_SETFD, FD_CLOEXEC) = 0 read(31, "*PPD-Adobe: \"4.3\"\n*%\n*% For info"..., 4096) = 4096 read(31, "\n*PageRegion Letter/US Letter: \""..., 4096) = 4096 read(31, "Standard \"(001.004S)\" Standard R"..., 4096) = 1761 read(31, "", 4096) = 0 read(31, "", 4096) = 0 close(31) = 0 unlink("/tmp/4e7a498dcf2f9") = 0 stat64("/home/jsullivan/.x2goclient/printing", {st_mode=S_IFREG|0755, st_size=369, ...}) = 0 open("/home/jsullivan/.x2goclient/printing", O_RDONLY|O_LARGEFILE| O_CLOEXEC) = 31 fcntl64(31, F_SETFD, FD_CLOEXEC) = 0 fstat64(31, {st_mode=S_IFREG|0755, st_size=369, ...}) = 0 close(31) = 0 stat64("/home/jsullivan/.x2goclient/printing", {st_mode=S_IFREG|0755, st_size=369, ...}) = 0 stat64("/home/jsullivan/.x2goclient/printing", {st_mode=S_IFREG|0755, st_size=369, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 time(NULL) = 1316637070 time(NULL) = 1316637070 . . . . time(NULL) = 1316637071 time(NULL) = 1316637071 clock_gettime(CLOCK_MONOTONIC, {709, 441819023}) = 0 select(13, [12], NULL, NULL, {0, 0}) = 0 (Timeout) clock_gettime(CLOCK_MONOTONIC, {709, 444143062}) = 0 open("/home/jsullivan/.x2go/S-jasiii-53-1316636661_stDKDE_dp24/spool", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 31 statfs("/home/jsullivan/.x2go/S-jasiii-53-1316636661_stDKDE_dp24/spool", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=12812451, f_bfree=11505345, f_bavail=11375175, f_f getdents(31, /* 3 entries */, 32768) = 76 stat64("/home/jsullivan/.x2go/S-jasiii-53-1316636661_stDKDE_dp24/spool/.", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 stat64("/home/jsullivan/.x2go/S-jasiii-53-1316636661_stDKDE_dp24/spool/13008-jasiii-cupsjob13904.pdf", {st_mode=S_IFREG|0644, st_size=23397, ...}) = 0 getdents(31, /* 0 entries */, 32768) = 0 close(31) = 0 stat64("/home/jsullivan/.x2go/S-jasiii-53-1316636661_stDKDE_dp24/spool/..", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 clock_gettime(CLOCK_MONOTONIC, {709, 729349572}) = 0 poll([{fd=7, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=7, revents=POLLOUT}]) writev(7, [{"\224\7\2\0\0\22\200\3\22\0\n\0\377\21\200\3[\1\0\0[\1\0\0 \10\21\200\3\20\0\0\0"..., 96}, {NULL, 0}, {"", 0}], 3) = 96 read(7, "\34\0\335b\377\21\200\3[\1\0\0\234\324\n\0\0\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0"..., 4096) = 704 read(7, 0x9bede30, 4096) = -1 EAGAIN (Resource temporarily unavailable) read(7, 0x9bede30, 4096) = -1 EAGAIN (Resource temporarily unavailable) munmap(0xb5b82000, 65932) = 0 munmap(0xb5ab5000, 633604) = 0 munmap(0xb5aa6000, 58716) = 0 munmap(0xb5894000, 584396) = 0 poll([{fd=7, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=7, revents=POLLOUT}]) writev(7, [{"\224\7\2\0\31\0\200\3\22\0\n\0\30\0\200\3[\1\0\0[\1\0\0\10 \21\200\3\20\0\0\0"..., 3372}, {NULL, 0}, {"", 0}], 3) = 3372 poll([{fd=7, events=POLLIN}], 1, -1) = 1 ([{fd=7, revents=POLLIN}]) read(7, "\34\0\345b\30\0\200\3[\1\0\0N\325\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\0\0"..., 4096) = 1376 read(7, 0x9bede30, 4096) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=7, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=7, revents=POLLIN|POLLOUT}]) read(7, "\26\0\201du\1\200\1u\1\200\1\0\0\0\0\0\0\0\0t\0\36\0\0\0\0\0\0 \0\0\0", 4096) = 32 writev(7, [{"O\7\2\0\1\0\200\3<\0\2\0\0\0\200\3.\1\2\0\5\0\200\3+\21\1 \0", 28}, {NULL, 0}, {"", 0}], 3) = 28 poll([{fd=7, events=POLLIN}], 1, -1) = 1 ([{fd=7, revents=POLLIN}]) read(7, "\1\1\205d\0\0\0\0\6\0`\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0", 4096) = 32 read(7, 0x9bede30, 4096) = -1 EAGAIN (Resource temporarily unavailable) close(7) = 0 write(8, "\1\v\1\0\1\0\0\0\0\0\0\0\0\0\0\0", 16) = 16 close(8) = 0 open("/proc/stat", O_RDONLY|O_CLOEXEC) = 7 read(7, "cpu 53876 11825 26767 40263 127"..., 8192) = 2875 close(7) = 0 write(6, "@", 1) = 1 close(6) = 0 close(5) = 0 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_NOCLDSTOP}, {0xb68cc3b0, [], SA_NOCLDSTOP}, 8) = 0 exit_group(0) = ?
I tried to intercept it with ddd but that didn't work. Interestingly, its messages were that the program closed normally as if x2goprinting is invoking a close event. I'll see what I can do to get this to run from a debugger but it is a showstopping bug for us - John <snip> Well this is bizarre. I just ran x2goclient in Qt-Creator and used its debugger. Similar to ddd, no indication of a segfault.
I set a breakpont in PrintDialog::accept(). While I was deciding what to do next, I started receiving "no response received" error messages from the client session I had opened.
Eventually , I stepped through to PrintProcess::loadSettings() and the if ( dlg.exec() ==QDialog::Rejected ) line and it stuck there. Stepping over, Stepping out all brought me back to that line. I finally just did a run and my client was gone. No seg fault - just a clean client exit as a result of printing! Any ideas? - John
Am 21.09.2011 22:55, schrieb John A. Sullivan III:
I tried to intercept it with ddd but that didn't work. Interestingly, its messages were that the program closed normally as if x2goprinting is invoking a close event. I'll see what I can do to get this to run from a debugger but it is a showstopping bug for us - John
X2go-Dev mailing list X2go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
Hallo John,
I still thinking, that client crashes because it cannot work with output from your server. Can you give me a X2Go account on one of your servers, where you have troubles with printing?
regards
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Am 21.09.2011 22:55, schrieb John A. Sullivan III:
I tried to intercept it with ddd but that didn't work. Interestingly, its messages were that the program closed normally as if x2goprinting is invoking a close event. I'll see what I can do to get this to run from a debugger but it is a showstopping bug for us - John
<snip> Hallo John,
I still thinking, that client crashes because it cannot work with output from your server. Can you give me a X2Go account on one of your servers, where you have troubles with printing?
regards <snip> Thanks, Alex. I'm working on getting that set up for you. Interestingly, even if I cancel the print job from the x2go print
On Thu, 2011-09-22 at 07:51 +0200, Oleksandr Shneyder wrote: dialog, x2goclient still exits - John
On Thu, 2011-09-22 at 14:51 -0400, John A. Sullivan III wrote:
Am 21.09.2011 22:55, schrieb John A. Sullivan III:
I tried to intercept it with ddd but that didn't work. Interestingly, its messages were that the program closed normally as if x2goprinting is invoking a close event. I'll see what I can do to get this to run from a debugger but it is a showstopping bug for us - John
<snip> Hallo John,
I still thinking, that client crashes because it cannot work with output from your server. Can you give me a X2Go account on one of your servers, where you have troubles with printing?
regards <snip> Thanks, Alex. I'm working on getting that set up for you. Interestingly, even if I cancel the print job from the x2go print
On Thu, 2011-09-22 at 07:51 +0200, Oleksandr Shneyder wrote: dialog, x2goclient still exits - John
<snip> Argh! the printing seems to be misbehaving on the demo system - taking a long time and often failing. I do not see where it is messing up. However, I do wonder if we have a backwards compatibility problem. Here is what is happening on our server end. The cups-x2go backend perl script has been modified so the jobs are sent with the following:
system ("scp -i $printdsa $pfile $tfile x2goprint\@$x2goserver:"); system( "ssh -i $printdsa x2goprint\@$x2goserver \"sudo x2goprint $userName $sess $bname $bname.title\"" );
In other words, we are transferring the print and title file and placing it in the x2goprint user's home directory (which happens to be /var/spool/x2goprint) and then invoking x2goprint in the x2go server via an ssh command.
The x2goprint command is from 3.0.1-5. It just seems to move the file to the appropriate directory:
my ($tm,$tm,$uid,$gid,$tm,$tm,$tm,$homedir)=getpwnam("x2goprint"); my $printdir=$homedir;
my $title; if( -e "$printdir/$titleFile") { open (TITLE,"<$printdir/$titleFile"); $title=<TITLE>; close (TITLE); unlink("$printdir/$titleFile"); }
($tm,$tm,$uid,$gid,$tm,$tm,$tm,$homedir)=getpwnam($user);
my $spooldir="/tmp/spool_$user/$session";
my $mounts=sudo x2gopgwrapper getmounts $session;
if( $mounts=~m/$spooldir/)
{
move ("$printdir/$file", "$spooldir") or die "$!: Can't rename
$file to $homedir/.x2go/C-$session/$file";
# chown $uid, $gid, "$homedir/.x2go/C-$session/$file";
# system ("su $user -c \"mv $homedir/.x2go/C-$session/$file
$spooldir\"");
my $counter = 0;
while ( ! -f "$spooldir/$file.ready" && $counter < 10 )
{
open (RFILE,">$spooldir/$file.ready");
print RFILE "$file\n$title";
close (RFILE);
$counter = $counter + 1;
}
if ( $counter > 1 ) { syslog("info", "Failed to write ready file -Count $counter - C-$session/$file"); }
To get to the demo system, point your client to vdhost01.pacifera.com and use port 442. Thanks - John
On Thu, 2011-09-22 at 07:51 +0200, Oleksandr Shneyder wrote:
Am 21.09.2011 22:55, schrieb John A. Sullivan III:
I tried to intercept it with ddd but that didn't work. Interestingly, its messages were that the program closed normally as if x2goprinting is invoking a close event. I'll see what I can do to get this to run from a debugger but it is a showstopping bug for us - John
X2go-Dev mailing list X2go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
Hallo John,
I still thinking, that client crashes because it cannot work with output from your server. Can you give me a X2Go account on one of your servers, where you have troubles with printing?
regards
X2go-Dev mailing list X2go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
It looks like the newer clients have magically solved the problem. Much appreciated! - John
Am 05.04.2012 10:28, schrieb John A. Sullivan III:
It looks like the newer clients have magically solved the problem. Much appreciated! - John
X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
Hi John,
there is no magic here ;) I think it because of this patch: http://code.x2go.org/gitweb?p=x2goclient.git;a=commit;h=c52f0ad4025111590c81...
regards, Alex
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Am 10.04.2012 11:45, schrieb Oleksandr Shneyder:
Am 05.04.2012 10:28, schrieb John A. Sullivan III:
It looks like the newer clients have magically solved the problem. Much appreciated! - John
Hi John,
there is no magic here ;) I think it because of this patch: http://code.x2go.org/gitweb?p=x2goclient.git;a=commit;h=c52f0ad4025111590c81...
Good riddance! What a nasty little bugger that was.
-Stefan
On Mon, 2011-09-19 at 14:54 +0200, Mike Gabriel wrote:
Hi Alex,
On Mo 19 Sep 2011 13:44:15 CEST Oleksandr Shneyder wrote:
hmmm, ok, seems you are right :) Can you apply this patch to source tree and I'll try to build a windows binary tomorrow.
regards, Alex
patch has been committed. I'll build new packages for Debian tonight
(I am at a customer location right now).Thanks, Mike
<snip> I can confirm the significant improvement in performance. For example, and what really made me think Nagle, my ping results display much better. When doing ping tests previously, the results would stutter even though the response times were nearly even. In fact, sometimes I would seem to miss a packet only to have two display the next second. They are now perfectly smooth.
However, we still have a BIG problem. X2Go client printing still segfaults the entire client every single time we try to print. Phil has confirmed this independently from me. Any ETA on that fix? Thanks - John <snip> Mike, have we had a regression in the heuler code to reintroduce this
On Tue, 2011-09-20 at 06:37 -0400, John A. Sullivan III wrote: problem? I'm noticing similar behavior. I thought is was an Internet connectivity issue on my part as we were having issues but we spent hours today confirming that the circuits had been repaired and Internet performance is better than ever here in the test lab but we are still seeing the delayed screen painting. The client is 3.99.0.2. Thanks - John
On Mon, 2011-09-19 at 14:54 +0200, Mike Gabriel wrote:
Hi Alex,
On Mo 19 Sep 2011 13:44:15 CEST Oleksandr Shneyder wrote:
hmmm, ok, seems you are right :) Can you apply this patch to source tree and I'll try to build a windows binary tomorrow.
regards, Alex
patch has been committed. I'll build new packages for Debian tonight
(I am at a customer location right now).Thanks, Mike
<snip> I can confirm the significant improvement in performance. For example, and what really made me think Nagle, my ping results display much better. When doing ping tests previously, the results would stutter even though the response times were nearly even. In fact, sometimes I would seem to miss a packet only to have two display the next second. They are now perfectly smooth.
However, we still have a BIG problem. X2Go client printing still segfaults the entire client every single time we try to print. Phil has confirmed this independently from me. Any ETA on that fix? Thanks - John <snip> Mike, have we had a regression in the heuler code to reintroduce this
On Tue, 2011-09-20 at 06:37 -0400, John A. Sullivan III wrote: problem? I'm noticing similar behavior. I thought is was an Internet connectivity issue on my part as we were having issues but we spent hours today confirming that the circuits had been repaired and Internet performance is better than ever here in the test lab but we are still seeing the delayed screen painting. The client is 3.99.0.2. Thanks - John I can confirm this again today - that annoying phenomenon that provokes constant typing errors when the last key (e.g., backspace or delete) is
On Tue, 2011-10-18 at 19:05 -0400, John A. Sullivan III wrote: pressed and there is a several second delay before the effect is seen even on a blazing fast connection.
In fact, I wonder if this is causing the Firefox problem. As we reported earlier, only when using then newer versions of X2Go client, we have problems where Firefox hangs for roughly 16 seconds. All other applications are functioning and it is not a Firefox issue; it is a screen updating issue. Hmm . . . I suppose that means it would not be Nagle as other applications are working properly. Oh well but, as an aside, we would consider the Firefox problem to be another critical error blocking production release. Thanks - John
Hmm . . . I suppose that means it would not be Nagle as other applications are working properly. Oh well but, as an aside, we would consider the Firefox problem to be another critical error blocking production release. Just out of curiosity: Does ff have anything on nfs? I had this very strange behaviour using TB when my mails were stored on NFS. Oddly I had
On 2011-10-19 15:47, John A. Sullivan III wrote: the feeling that this was worse using x2go. (No the latter is not reasonable in any way. ;) )
Cheers Morty
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
On Wed, 2011-10-19 at 16:07 +0200, Moritz Struebe wrote:
Hmm . . . I suppose that means it would not be Nagle as other applications are working properly. Oh well but, as an aside, we would consider the Firefox problem to be another critical error blocking production release. Just out of curiosity: Does ff have anything on nfs? I had this very strange behaviour using TB when my mails were stored on NFS. Oddly I had
On 2011-10-19 15:47, John A. Sullivan III wrote: the feeling that this was worse using x2go. (No the latter is not reasonable in any way. ;) ) <snip> Hi, Morty. Thanks for asking. No, it is presented as local storage but it is pulling across an iSCSI connection. The problem is greatly exacerbated in the libssh versions. The older X2Go version gave about a 3 second delay which was annoying. The newer versions give a 16-20 second delay which is just about unusable. As reported earlier, we notice it most with AJAX intensive sites - John
Hi John,
On Mi 19 Okt 2011 01:05:45 CEST "John A. Sullivan III" wrote:
Mike, have we had a regression in the heuler code to reintroduce this problem?
No, there has been no regression in x2goclient code. The heuler REPOS
builds from master branch's HEAD of code. Refer to the last commits in
X2go Git of x2goclient:
http://code.x2go.org/gitweb?p=x2goclient.git;a=summary
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Wed, 2011-10-19 at 19:25 +0200, Mike Gabriel wrote:
Hi John,
On Mi 19 Okt 2011 01:05:45 CEST "John A. Sullivan III" wrote:
Mike, have we had a regression in the heuler code to reintroduce this problem?
No, there has been no regression in x2goclient code. The heuler REPOS
builds from master branch's HEAD of code. Refer to the last commits in
X2go Git of x2goclient: http://code.x2go.org/gitweb?p=x2goclient.git;a=summary
<snip> Thanks for checking, Mike. I wonder why I'm getting this very marked, naglish behavior. Take care - John
On Mon, 2011-09-19 at 13:44 +0200, Oleksandr Shneyder wrote:
Am 19.09.2011 13:30, schrieb Mike Gabriel:
Hi Alex,
On Mo 19 Sep 2011 09:51:16 CEST Oleksandr Shneyder wrote:
Am 17.09.2011 03:39, schrieb John A. Sullivan III:
On Fri, 2011-09-16 at 23:17 +0200, Mike Gabriel wrote:
Hi John, hi Alex,
On Fr 16 Sep 2011 21:56:38 CEST "John A. Sullivan III" wrote:
Hello, all. Since moving to the newer clients using libssh, I've noticed what appears to be a performance degradation. It smells like Nagle coalescing packets, e.g., most of the screen will paint, then it will pause a moment, and then the rest will paint. Is there any chance we have neglected to disable Nagle when invoking libssh?
This appears to have affected the SNMP over SSH project: http://books.google.com/books?id=S62is2vVoVgC&pg=PA29&lpg=PA29&dq=libssh
+nagle&source=bl&ots=F8Iw-pvQxd&sig=f5dfy0K0ewzSZOhqzTJRSKsDKZ8&hl=en&ei=KppzTrCZD4LJgQeMxLzzDA&sa=X&oi=book_result&ct=result&resnum=1&sqi=2&ved=0CBwQ6AEwAA#v=onepage&q=libssh%20nagle&f=false
This is in section 4.1. The difference was a latency of over 800ms to one of under 60ms. That seems to be about what I am seeing. There is a delay of roughly a second and then the rest of the screen comes through. Thanks - John
Indeed the TCP_NODELAY (which means: turn Nagle off) is not set for the ssh tunnel in X2goClient. It probably is for the SSH connection itself, as the SNMP patch has been reported to libssh upstream and their patch suggestion has been sensible. However, for the SSH tunnels built up for X2go this TCP_NODELAY option does perhaps not get set.
@Alex: would this patch fix that in x2goclient???
diff --git a/sshprocess.cpp b/sshprocess.cpp index 9e72e8f..03ee9b6 100644 --- a/sshprocess.cpp +++ b/sshprocess.cpp @@ -88,6 +88,7 @@ void SshProcess::tunnelLoop() const char y=1; #endif setsockopt(serverSocket, SOL_SOCKET, SO_REUSEADDR,&y, sizeof(int));
setsockopt(serverSocket, IPPROTO_TCP, TCP_NODELAY,&y, sizeof(int));
address.sin_family=AF_INET; address.sin_addr.s_addr=INADDR_ANY;
I don't think that that can be helpful. This part of code is only for reverse tunnel which is used for FS forwarding and Pulse Audio.
I took another close look at the code of sshProcess.cpp. The patch is applied to the method sshProcess::tunnelLoop. This method only gets execute in sshProcess::startTunnel.
The call is:
<quote> if (!reverse) tunnelLoop(); else { <blablabla> } </quote>
So this makes me think that tunnelLoop() is not for reverse tunneling but for the graphics tunnel.
Could you take another look please?
Thanks, Mike
hmmm, ok, seems you are right :) Can you apply this patch to source tree and I'll try to build a windows binary tomorrow.
regards, Alex <snip> Hi, Alex. Are the Windows packages available anywhere to test? Thanks - John
Am 20.09.2011 12:39, schrieb John A. Sullivan III:
<snip> Hi, Alex. Are the Windows packages available anywhere to test? Thanks - John
X2go-Dev mailing list X2go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
http://www.x2go.org/deb/windows/x2goclient-3.99.0.1-092011-setup.exe
Mike, put it, please, on right place
regards,
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Hi all,
On Di 20 Sep 2011 15:35:13 CEST Oleksandr Shneyder wrote:
Am 20.09.2011 12:39, schrieb John A. Sullivan III:
<snip> Hi, Alex. Are the Windows packages available anywhere to test? Thanks - John
X2go-Dev mailing list X2go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
http://www.x2go.org/deb/windows/x2goclient-3.99.0.1-092011-setup.exe
Mike, put it, please, on right place
This is the official and sustaining download link... http://code.x2go.org/releases/binary-win32/x2goclient/x2goclient-3.99.0.1rc1...
@Alex: I have attributed the version with rc1 (release candidate 1).
Cheers, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Am 20.09.2011 16:14, schrieb Mike Gabriel:
Hi all,
On Di 20 Sep 2011 15:35:13 CEST Oleksandr Shneyder wrote:
Am 20.09.2011 12:39, schrieb John A. Sullivan III:
<snip> Hi, Alex. Are the Windows packages available anywhere to test? Thanks - John
X2go-Dev mailing list X2go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
http://www.x2go.org/deb/windows/x2goclient-3.99.0.1-092011-setup.exe
Mike, put it, please, on right place
This is the official and sustaining download link... http://code.x2go.org/releases/binary-win32/x2goclient/x2goclient-3.99.0.1rc1...
@Alex: I have attributed the version with rc1 (release candidate 1).
Cheers, Mike
X2go-Dev mailing list X2go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
ok, thank you
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
On Fri, 2011-09-16 at 23:17 +0200, Mike Gabriel wrote:
Hi John, hi Alex,
On Fr 16 Sep 2011 21:56:38 CEST "John A. Sullivan III" wrote:
Hello, all. Since moving to the newer clients using libssh, I've noticed what appears to be a performance degradation. It smells like Nagle coalescing packets, e.g., most of the screen will paint, then it will pause a moment, and then the rest will paint. Is there any chance we have neglected to disable Nagle when invoking libssh?
This appears to have affected the SNMP over SSH project: http://books.google.com/books?id=S62is2vVoVgC&pg=PA29&lpg=PA29&dq=libssh +nagle&source=bl&ots=F8Iw-pvQxd&sig=f5dfy0K0ewzSZOhqzTJRSKsDKZ8&hl=en&ei=KppzTrCZD4LJgQeMxLzzDA&sa=X&oi=book_result&ct=result&resnum=1&sqi=2&ved=0CBwQ6AEwAA#v=onepage&q=libssh%20nagle&f=false
This is in section 4.1. The difference was a latency of over 800ms to one of under 60ms. That seems to be about what I am seeing. There is a delay of roughly a second and then the rest of the screen comes through. Thanks - John
Indeed the TCP_NODELAY (which means: turn Nagle off) is not set for the ssh tunnel in X2goClient. It probably is for the SSH connection itself, as the SNMP patch has been reported to libssh upstream and their patch suggestion has been sensible. However, for the SSH tunnels built up for X2go this TCP_NODELAY option does perhaps not get set.
@Alex: would this patch fix that in x2goclient???
diff --git a/sshprocess.cpp b/sshprocess.cpp index 9e72e8f..03ee9b6 100644 --- a/sshprocess.cpp +++ b/sshprocess.cpp @@ -88,6 +88,7 @@ void SshProcess::tunnelLoop() const char y=1; #endif setsockopt(serverSocket, SOL_SOCKET, SO_REUSEADDR,&y, sizeof(int));
setsockopt(serverSocket, IPPROTO_TCP, TCP_NODELAY,&y, sizeof(int));
address.sin_family=AF_INET; address.sin_addr.s_addr=INADDR_ANY;
@John: could you get the latest sources of x2goclient from our Git:
git clone git://code.x2go.org/x2goclient.git
and run debuild -uc -us (plus fullfill build-deps before) on a Debian squeeze or above system and check if the patch fixes your delays??? <snip> In process. May I ask why apache2 is one of the build dependencies for X2GoClient? Thanks - John
Hi John,
On Mo 19 Sep 2011 11:46:47 CEST "John A. Sullivan III" wrote:
In process. May I ask why apache2 is one of the build dependencies for X2GoClient? Thanks - John
we ship a html man page with x2goclient. This html man page is built
with man2html. In squeeze man2html recommends apache2. In wheezy+
man2html falls into two packages: man2html-base and man2html. Only the
latter then recommends apache2.
In our build environment, we ignore recommended packages as they are
not necessary for building the package.
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi John,
On Fr 16 Sep 2011 21:56:38 CEST "John A. Sullivan III" wrote:
Hello, all. Since moving to the newer clients using libssh, I've noticed what appears to be a performance degradation. It smells like Nagle coalescing packets, e.g., most of the screen will paint, then it will pause a moment, and then the rest will paint. Is there any chance we have neglected to disable Nagle when invoking libssh?
Have you tested the anti-Nagle patch with the Windows version of
x2goclient??? Is the sluggishness issue gone? Just for the records.
Thanks, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Fri, 2011-09-30 at 08:32 +0200, Mike Gabriel wrote:
Hi John,
On Fr 16 Sep 2011 21:56:38 CEST "John A. Sullivan III" wrote:
Hello, all. Since moving to the newer clients using libssh, I've noticed what appears to be a performance degradation. It smells like Nagle coalescing packets, e.g., most of the screen will paint, then it will pause a moment, and then the rest will paint. Is there any chance we have neglected to disable Nagle when invoking libssh?
Have you tested the anti-Nagle patch with the Windows version of
x2goclient??? Is the sluggishness issue gone? Just for the records.
<snip> Sorry, I thought I had mentioned that. Alas, not. In fact, I am in it right now reading my email via Evolution and it is painfully, dangerously slow. My guess is this is more a X to GDI issue, i.e., a vcxsrv issue but I'm not sure - John
-
John A. Sullivan III -
Mike Gabriel -
Moritz Struebe -
Oleksandr Shneyder -
Stefan Baur