From: Nicola B. <nb...@es...> - 2005-07-15 16:02:16
|
hi, i'm using a logitech quickcam pro 4000 with player 1.6.4 and with a resolution of 320x240 i keep on having the same message: warning : 100869 bytes leftover on write() to client the strange thing is that if i reduce the frame size to 160x120, i have no more warnings. increasing it to 640x480 i still have them. following some suggestions found on the mailing-list, i tried to change the SetDataMode or the SetFrequency (in PUSH mode). unfortunately, no matter what's the frequency or the data mode: if the resolution is bigger than 160x120, the warning is always the same. i read somewhere i could safely ignore it, but of course i would prefer no warnings at all... cheers nicola -- ------------------------------------------ Nicola Bellotto University of Essex Department of Computer Science Wivenhoe Park Colchester CO4 3SQ United Kingdom Room: 1N1.2.8 Tel. +44 (0)1206 874094 E-Mail: nb...@es... URL: http://privatewww.essex.ac.uk/~nbello ------------------------------------------ |
From: Brian G. <br...@ge...> - 2005-07-15 16:58:33
|
On Jul 15, 2005, at 9:01 AM, Nicola Bellotto wrote: > > i'm using a logitech quickcam pro 4000 with player 1.6.4 and with a > resolution > of 320x240 i keep on having the same message: > > warning : 100869 bytes leftover on write() to client > > the strange thing is that if i reduce the frame size to 160x120, i > have no > more warnings. increasing it to 640x480 i still have them. > following some suggestions found on the mailing-list, i tried to > change the > SetDataMode or the SetFrequency (in PUSH mode). unfortunately, no > matter > what's the frequency or the data mode: if the resolution is bigger > than > 160x120, the warning is always the same. > i read somewhere i could safely ignore it, but of course i would > prefer no > warnings at all... Generally, you shouldn't ignore that warning. It means that the server is sending data faster than your client is consuming it. What I would guess is happening here is that the server is trying to write() an entire image to the client, but the image is bigger than both the TCP send and receive buffers (approx. 250K > approx. 128K). So the write() leaves some bytes behind every time. You'll get those bytes on the next loop through the server's update loop, and TCP ensures that your data won't be garbled. My advice: - Figure out the rate at which your client is actually receiving camera frames, then use SetFrequency to that rate. This will tend to minimize the data backup at the server (i.e., you should tend to receive newer, rather than older, frames). - Speed up the server's update loop with the -u command line option. E.g., 'player -u 1000' would run that loop at 1MHz. This will tend to minimize the time between the multiple write()s that the server needs to get a single frame out. Note that the server can only *try* to achieve a given update rate; it cannot exceed limits imposed by the OS. I'll keep this issue in mind in the changes I'm making to the server core. brian. -- Brian Gerkey br...@ge... http://gerkey.org |
From: Nicola B. <nb...@es...> - 2005-07-16 11:55:36
|
Brian, thanks for the advice. However at the moment I understand there's nothing I can do to avoid that warning, except than reducing the frame size of course. I took particular care indeed in the update rate at which my client receive the data, and I'm sure the frequency of my Read() calls is much bigger than the frequency at which the server sends data. It seems the only way to remove that warning is to resolve the problem of the TCP buffers. I didn't try yet, but perhaps the "cameracompress" driver could be a temporary solution... Cheers, Nicola On Friday 15 Jul 2005 17:58, Brian Gerkey wrote: > On Jul 15, 2005, at 9:01 AM, Nicola Bellotto wrote: > > i'm using a logitech quickcam pro 4000 with player 1.6.4 and with a > > resolution > > of 320x240 i keep on having the same message: > > > > warning : 100869 bytes leftover on write() to client > > > > the strange thing is that if i reduce the frame size to 160x120, i > > have no > > more warnings. increasing it to 640x480 i still have them. > > following some suggestions found on the mailing-list, i tried to > > change the > > SetDataMode or the SetFrequency (in PUSH mode). unfortunately, no > > matter > > what's the frequency or the data mode: if the resolution is bigger > > than > > 160x120, the warning is always the same. > > i read somewhere i could safely ignore it, but of course i would > > prefer no > > warnings at all... > > Generally, you shouldn't ignore that warning. It means that the > server is sending data faster than your client is consuming it. > > What I would guess is happening here is that the server is trying to > write() an entire image to the client, but the image is bigger than > both the TCP send and receive buffers (approx. 250K > approx. 128K). > So the write() leaves some bytes behind every time. You'll get those > bytes on the next loop through the server's update loop, and TCP > ensures that your data won't be garbled. > > My advice: > - Figure out the rate at which your client is actually receiving > camera frames, then use SetFrequency to that rate. This will tend to > minimize the data backup at the server (i.e., you should tend to > receive newer, rather than older, frames). > - Speed up the server's update loop with the -u command line > option. E.g., 'player -u 1000' would run that loop at 1MHz. This > will tend to minimize the time between the multiple write()s that the > server needs to get a single frame out. Note that the server can > only *try* to achieve a given update rate; it cannot exceed limits > imposed by the OS. > > I'll keep this issue in mind in the changes I'm making to the server > core. > > brian. -- ------------------------------------------ Nicola Bellotto University of Essex Department of Computer Science Wivenhoe Park Colchester CO4 3SQ United Kingdom Room: 1N1.2.8 Tel. +44 (0)1206 874094 E-Mail: nb...@es... URL: http://privatewww.essex.ac.uk/~nbello ------------------------------------------ |
From: Nicola B. <nb...@es...> - 2005-07-16 13:00:09
|
Just an update on the topic: I've tried the "cameracompress" driver, which indeed resolved the "bytes leftover" warning. Unfortunately, despite the increasing in the computation due to the JPEG compression, I have also an infinite list of errors like this: ... CameraProxy::Decompress() not a JPEG image, not good! : Success CameraProxy::Decompress() not a JPEG image, not good! : Success Not a JPEG file: starts with 0x72 0x5d sonething very bad has happened CameraProxy::Decompress() not a JPEG image, not good! : Success CameraProxy::Decompress() not a JPEG image, not good! : Success CameraProxy::Decompress() not a JPEG image, not good! : Success Not a JPEG file: starts with 0x6f 0x5f sonething very bad has happened CameraProxy::Decompress() not a JPEG image, not good! : Success CameraProxy::Decompress() not a JPEG image, not good! : Success ... Well, I guess something is not completely right yet with this driver... Anyway, I still prefer a solution on the TCP buffering rather than using image compression, since my hardware resources are the main constraint. Cheers Nicola On Saturday 16 Jul 2005 12:55, Nicola Bellotto wrote: > Brian, > thanks for the advice. However at the moment I understand there's nothing I > can do to avoid that warning, except than reducing the frame size of > course. I took particular care indeed in the update rate at which my client > receive the data, and I'm sure the frequency of my Read() calls is much > bigger than the frequency at which the server sends data. > It seems the only way to remove that warning is to resolve the problem of > the TCP buffers. > I didn't try yet, but perhaps the "cameracompress" driver could be a > temporary solution... > Cheers, > Nicola > > On Friday 15 Jul 2005 17:58, Brian Gerkey wrote: > > On Jul 15, 2005, at 9:01 AM, Nicola Bellotto wrote: > > > i'm using a logitech quickcam pro 4000 with player 1.6.4 and with a > > > resolution > > > of 320x240 i keep on having the same message: > > > > > > warning : 100869 bytes leftover on write() to client > > > > > > the strange thing is that if i reduce the frame size to 160x120, i > > > have no > > > more warnings. increasing it to 640x480 i still have them. > > > following some suggestions found on the mailing-list, i tried to > > > change the > > > SetDataMode or the SetFrequency (in PUSH mode). unfortunately, no > > > matter > > > what's the frequency or the data mode: if the resolution is bigger > > > than > > > 160x120, the warning is always the same. > > > i read somewhere i could safely ignore it, but of course i would > > > prefer no > > > warnings at all... > > > > Generally, you shouldn't ignore that warning. It means that the > > server is sending data faster than your client is consuming it. > > > > What I would guess is happening here is that the server is trying to > > write() an entire image to the client, but the image is bigger than > > both the TCP send and receive buffers (approx. 250K > approx. 128K). > > So the write() leaves some bytes behind every time. You'll get those > > bytes on the next loop through the server's update loop, and TCP > > ensures that your data won't be garbled. > > > > My advice: > > - Figure out the rate at which your client is actually receiving > > camera frames, then use SetFrequency to that rate. This will tend to > > minimize the data backup at the server (i.e., you should tend to > > receive newer, rather than older, frames). > > - Speed up the server's update loop with the -u command line > > option. E.g., 'player -u 1000' would run that loop at 1MHz. This > > will tend to minimize the time between the multiple write()s that the > > server needs to get a single frame out. Note that the server can > > only *try* to achieve a given update rate; it cannot exceed limits > > imposed by the OS. > > > > I'll keep this issue in mind in the changes I'm making to the server > > core. > > > > brian. -- ------------------------------------------ Nicola Bellotto University of Essex Department of Computer Science Wivenhoe Park Colchester CO4 3SQ United Kingdom Room: 1N1.2.8 Tel. +44 (0)1206 874094 E-Mail: nb...@es... URL: http://privatewww.essex.ac.uk/~nbello ------------------------------------------ |
From: Brian G. <br...@ge...> - 2005-07-19 15:02:15
|
On Jul 16, 2005, at 5:59 AM, Nicola Bellotto wrote: > Just an update on the topic: > I've tried the "cameracompress" driver, which indeed resolved the > "bytes > leftover" warning. > Unfortunately, despite the increasing in the computation due to the > JPEG > compression, I have also an infinite list of errors like this: > ... > CameraProxy::Decompress() not a JPEG image, not good! > : Success > CameraProxy::Decompress() not a JPEG image, not good! > : Success > Not a JPEG file: starts with 0x72 0x5d > sonething very bad has happened Could you submit a bug report, with an example .cfg file, so that somebody can look into this? brian. -- Brian Gerkey br...@ge... http://gerkey.org |
From: Brian G. <br...@ge...> - 2005-07-19 15:06:54
|
On Jul 16, 2005, at 4:55 AM, Nicola Bellotto wrote: > thanks for the advice. However at the moment I understand there's > nothing I > can do to avoid that warning, except than reducing the frame size > of course. > I took particular care indeed in the update rate at which my client > receive > the data, and I'm sure the frequency of my Read() calls is much > bigger than > the frequency at which the server sends data. > It seems the only way to remove that warning is to resolve the > problem of the > TCP buffers. You can change the size of those buffers with setsockopt(). Check the man page for details. You would use the SO_SNDBUF and SO_RCVBUF options to change the size of the send and receive buffers, respectively. I would try increasing the server's send buffer and the client's receive buffer. I don't know whether the OS puts a hard limit on the size of those buffers. You can put the call to setsockopt() pretty much anywhere after the socket has been created at each end. Let me know if and how well that works. brian. -- Brian Gerkey br...@ge... http://gerkey.org |
From: Nicola B. <nic...@gm...> - 2005-07-19 16:59:52
|
Hi, I was trying to control the PTZ of my Canon camera using the "cameravcc4" driver on Player 1.6.4. I'm sure the camera works because it is connected to /dev/ttyS1 and I can control it with the Aria's demo program. However, when I try it with Player, for example using the "example/c++/ptz" program, I get the following from the server: [~]$ player /usr/local/atlas/atlas.cfg ** Player v1.6.4 ** * Part of the Player/Stage Project [http://playerstage.sourceforge.net]. * Copyright 2000-2005 Brian Gerkey, Richard Vaughan, Andrew Howard, * Nate Koenig and contributors. * Released under the GNU General Public License. Startup options: [TCP] Parsing configuration file "/usr/local/atlas/atlas.cfg" Using device table: ------------------------------------------------------------ 0 driver p2os id 6665:position:0 1 id 6665:sonar:0 2 id 6665:aio:0 3 id 6665:dio:0 4 id 6665:bumper:0 5 id 6665:power:0 6 id 6665:blobfinder:0 7 id 6665:sound:0 8 driver canonvcc4 id 6665:ptz:0 9 driver sicklms200 id 6665:laser:0 10 driver camerav4l id 6665:camera:0 11 driver vfh id 6665:position:1 ------------------------------------------------------------ listening on port 6665 ** Player [port 6665] client accepted from 127.0.0.1 on socket 7 ** PTZ connection initializing (/dev/ttyS1)... Powering off/on the camera!!!!!!!!!!!!!! Could not set power on: 0 warning : No permissions to command 8:0 warning : No permissions to command 8:0 warning : No permissions to command 8:0 (and so on...) I also tried to remove the power on/off from the "cameravcc4" driver, but still doesn't work. Below, I've included also my configuration file. Any help is appreciated. Cheers, Nicola -- ------------------------------------------ Nicola Bellotto University of Essex Department of Computer Science Wivenhoe Park Colchester CO4 3SQ United Kingdom Room: 1N1.2.8 Tel. +44 (0)1206 874094 E-Mail: nb...@es... URL: http://privatewww.essex.ac.uk/~nbello ------------------------------------------ [~]$ cat /usr/local/atlas/atlas.cfg # Desc: Basic Pioneer2DX # CVS: $Id: pioneer.cfg,v 1.4 2005/04/05 04:18:30 gerkey Exp $ driver ( name "p2os" provides ["odometry::position:0" "sonar:0" "aio:0" "dio:0" "power:0" "sound:0" "blobfinder:0" "bumper:0"] port "/dev/ttyS0" ) driver ( name "canonvcc4" provides ["ptz:0"] port "/dev/ttyS1" ) driver ( name "sicklms200" provides ["laser:0"] port "/dev/ttyS2" delay 40 ) driver ( name "camerav4l" provides ["camera:0"] port "/dev/video0" source 0 size [320 240] norm "ntsc" mode "RGB24" ) driver ( name "vfh" requires ["position:0" "laser:0"] provides ["position:1"] # safety_dist 0.10 free_space_cutoff_0ms 4000000.0 # higher the value, closer to the obstacles (default 2000000) distance_epsilon 0.3 # maximal distance from the target # angle_epsilon 5 ) |
From: Nicola B. <nb...@es...> - 2005-07-20 16:51:16
|
On Tuesday 19 Jul 2005 16:06, Brian Gerkey wrote: > > You can change the size of those buffers with setsockopt(). Check > the man page for details. You would use the SO_SNDBUF and SO_RCVBUF > options to change the size of the send and receive buffers, > respectively. I would try increasing the server's send buffer and > the client's receive buffer. I don't know whether the OS puts a hard > limit on the size of those buffers. You can put the call to > setsockopt() pretty much anywhere after the socket has been created > at each end. Let me know if and how well that works. Well spotted Brian, I've followed your suggestions and the warning disappeared :) Here's the code I've inserted in "server/clientmanager.cc", line 446 (please forgive the ugly code, I just took some examples of setsockopt/getsockopt I found online...): ----- int bufSize = 1024 * 256; if (setsockopt(clientData->socket, SOL_SOCKET, SO_SNDBUF, (char *)&bufSize, (int)sizeof(bufSize)) != 0) { fprintf(stderr, "Error calling setsockopt\n"); exit(-1); } int sndSize = 0; int size = sizeof(int); if (getsockopt(clientData->socket, SOL_SOCKET, SO_SNDBUF, (char *)&sndSize, (socklen_t*)&size) != 0) { fprintf(stderr, "Error calling getsockopt\n"); exit(-1); } else fprintf(stderr, "Send buffer size: %d\n", sndSize); ----- I did the same on the client side, increasing the input buffer of "PlayerClient::conn.socket" with the option SO_RCVBUF. Everything seems to work fine now. Thanks Nicola -- ------------------------------------------ Nicola Bellotto University of Essex Department of Computer Science Wivenhoe Park Colchester CO4 3SQ United Kingdom Room: 1N1.2.8 Tel. +44 (0)1206 874094 E-Mail: nb...@es... URL: http://privatewww.essex.ac.uk/~nbello ------------------------------------------ |
From: Thanomsak A. <tee...@ya...> - 2005-07-22 10:15:06
|
Hi I have same problem that bytes leftover warning when transfer camera data. I add code in server side follow your suggestion. But I don't know how to add code on client side because I can't find "PlayerClient::conn.socket". How can I fix it. Thank you. --- Nicola Bellotto <nb...@es...> wrote: > On Tuesday 19 Jul 2005 16:06, Brian Gerkey wrote: > > > > You can change the size of those buffers with > setsockopt(). Check > > the man page for details. You would use the > SO_SNDBUF and SO_RCVBUF > > options to change the size of the send and receive > buffers, > > respectively. I would try increasing the server's > send buffer and > > the client's receive buffer. I don't know whether > the OS puts a hard > > limit on the size of those buffers. You can put > the call to > > setsockopt() pretty much anywhere after the socket > has been created > > at each end. Let me know if and how well that > works. > > Well spotted Brian, > I've followed your suggestions and the warning > disappeared :) > Here's the code I've inserted in > "server/clientmanager.cc", line 446 (please > forgive the ugly code, I just took some examples of > setsockopt/getsockopt I > found online...): > > ----- > int bufSize = 1024 * 256; > if (setsockopt(clientData->socket, SOL_SOCKET, > SO_SNDBUF, (char *)&bufSize, > (int)sizeof(bufSize)) != 0) > { > fprintf(stderr, "Error calling > setsockopt\n"); > exit(-1); > } > int sndSize = 0; > int size = sizeof(int); > if (getsockopt(clientData->socket, SOL_SOCKET, > SO_SNDBUF, (char *)&sndSize, > (socklen_t*)&size) != 0) > { > fprintf(stderr, "Error calling > getsockopt\n"); > exit(-1); > } > else > fprintf(stderr, "Send buffer size: %d\n", > sndSize); > ----- > > I did the same on the client side, increasing the > input buffer of > "PlayerClient::conn.socket" with the option > SO_RCVBUF. > Everything seems to work fine now. > Thanks > Nicola > > -- > ------------------------------------------ > Nicola Bellotto > University of Essex > Department of Computer Science > Wivenhoe Park > Colchester CO4 3SQ > United Kingdom > > Room: 1N1.2.8 > Tel. +44 (0)1206 874094 > E-Mail: nb...@es... > URL: http://privatewww.essex.ac.uk/~nbello > ------------------------------------------ > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux > Migration Strategies > from IBM. Find simple to follow Roadmaps, > straightforward articles, > informative Webcasts and more! Get everything you > need to get up to > speed, fast. > http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs |
From: Nicola B. <nb...@es...> - 2005-07-22 11:03:25
|
On Friday 22 Jul 2005 11:14, Thanomsak Agganapanya wrote: > Hi > I have same problem that bytes leftover warning > when transfer camera data. I add code in server side > follow your suggestion. But I don't know how to add > code on client side because I can't find > "PlayerClient::conn.socket". > How can I fix it. Thank you. hi, here's my code, hope it helps. cheers nicola ------- PlayerClient robot("localhost"); // increase the buffer size of the socket int bufSize = 1024 * 256; int size = sizeof(int); if ((setsockopt(robot.conn.sock, SOL_SOCKET, SO_RCVBUF, (char *)&bufSize, (int)sizeof(bufSize)) != 0) || (getsockopt(robot.conn.sock, SOL_SOCKET, SO_RCVBUF, (char *)&bufSize, (socklen_t*)&size) != 0)) { std::cerr << "Cannot modify the input buffer size of the socket\n"; exit(-1); } else std::cerr << "Socket input buffer size: " << bufSize << std::endl; -- ------------------------------------------ Nicola Bellotto University of Essex Department of Computer Science Wivenhoe Park Colchester CO4 3SQ United Kingdom Room: 1N1.2.8 Tel. +44 (0)1206 874094 E-Mail: nb...@es... URL: http://privatewww.essex.ac.uk/~nbello ------------------------------------------ |