From: Jordi <mu...@gm...> - 2006-07-03 23:07:27
|
I've uploaded a new version of player and stage .deb files (updated to 2.0.2). I'm using them in Ubuntu Dapper and Debian Sid. They can be downloaded from here: http://jordi.tecnosfera.org/robotOS/debian/pool/main The source for apt is (the line that goes to the /etc/apt/sources.list file: deb http://jordi.tecnosfera.org/robotOS/debian unstable main I've found out that my libraries link with libnvidia-tls . I don't know why and these packages won't work in systems without that library. I can't try it my own as all my systems seems to have that library. Also I don't know how to avoid the player libraries linking with libnvidia-tls. If someone is kind enough to try these packages, be prepared to recompile player and stage in case anything goes wrong. -- Jordi Polo |
From: Brad K. <bkr...@et...> - 2006-07-04 16:03:21
|
Hey all, I just updated playerv to include a PULL mode from the server. We were experiencing problems on some of our slower machines w/ slower connections when using playerv with lasers, maps, amcl, stage, etc. If the computer or connection wasn't fast enough we had data backing up in the pipe and playerv wasn't always fresh. So, I decided to give playerv a go with a PULL mode. By running a couple of simple tests, it looks as if using PULL with the above mentioned devices is actually faster on my shiny new Optiplex than the PUSH modes are. So, I have 2 questions... Can somebody else check this out and determine if I'm just seeing things? If it is faster for others, then I would like to consider moving playerv to PULL mode by default. The code should be checked into CVS and you can use it with > playerv -pull 1 Why is PUSH currently the default mode, and would anyone be interested in changing it? The reason I ask is that our students that use player here have all run into the problem of wondering why their data is never fresh, and I see others on the web with the problem also. My mind is not currently made up which way is better, but I think we may end up with less confused people if we would move to a default PULL mode. On the other hand, maybe we just need to emphasize the point more in the documentation. What do you all think? Best regards, Brad |
From: Fred L. <ff...@ab...> - 2006-07-04 16:33:16
|
On Tue, July 4, 2006 5:03 pm, Brad Kratochvil wrote: > Why is PUSH currently the default mode, and would anyone be interested > in changing it? The reason I ask is that our students that use player > here have all run into the problem of wondering why their data is never > fresh, and I see others on the web with the problem also. Just my 2p worth: I can only use player in PULL mode because generally my loops are too slow and PUSHing is therefore not a good choice. Cheers, Fred |
From: Geoffrey B. <g....@au...> - 2006-07-04 19:22:17
|
In the mailing list history, back around the 9th and 10th of March, there was a discussion about this. My vote is for PULL with suitable replace rules being the default mode, as I think most clients will want to be in this mode. Clients that don't (eg SLAM systems) can change it easily enough. But that's just my opinion. We really need a good idea of what kind of client is the most common to decide what the best default is. As for the speed: are you finding that it's the client or server or both that are faster? Geoff Brad Kratochvil wrote: > Hey all, > > I just updated playerv to include a PULL mode from the server. We were > experiencing problems on some of our slower machines w/ slower > connections when using playerv with lasers, maps, amcl, stage, etc. If > the computer or connection wasn't fast enough we had data backing up in > the pipe and playerv wasn't always fresh. > > So, I decided to give playerv a go with a PULL mode. By running a > couple of simple tests, it looks as if using PULL with the above > mentioned devices is actually faster on my shiny new Optiplex than the > PUSH modes are. So, I have 2 questions... > > Can somebody else check this out and determine if I'm just seeing > things? If it is faster for others, then I would like to consider > moving playerv to PULL mode by default. The code should be checked into > CVS and you can use it with > playerv -pull 1 > > Why is PUSH currently the default mode, and would anyone be interested > in changing it? The reason I ask is that our students that use player > here have all run into the problem of wondering why their data is never > fresh, and I see others on the web with the problem also. > > My mind is not currently made up which way is better, but I think we may > end up with less confused people if we would move to a default PULL > mode. On the other hand, maybe we just need to emphasize the point more > in the documentation. > > What do you all think? > > Best regards, > > Brad -- Robotics research group, University of Auckland http://www.ece.auckland.ac.nz/~gbig005/ |
From: Toby C. <tco...@pl...> - 2006-07-04 20:31:49
|
My personal preference is pull as default. Push is there as default at the moment because that was the default before pull was put in. Possibly more emphasis in the documentation would be good as well. Toby Brad Kratochvil wrote: > Hey all, > > I just updated playerv to include a PULL mode from the server. We were > experiencing problems on some of our slower machines w/ slower > connections when using playerv with lasers, maps, amcl, stage, etc. If > the computer or connection wasn't fast enough we had data backing up in > the pipe and playerv wasn't always fresh. > > So, I decided to give playerv a go with a PULL mode. By running a > couple of simple tests, it looks as if using PULL with the above > mentioned devices is actually faster on my shiny new Optiplex than the > PUSH modes are. So, I have 2 questions... > > Can somebody else check this out and determine if I'm just seeing > things? If it is faster for others, then I would like to consider > moving playerv to PULL mode by default. The code should be checked into > CVS and you can use it with > playerv -pull 1 > > Why is PUSH currently the default mode, and would anyone be interested > in changing it? The reason I ask is that our students that use player > here have all run into the problem of wondering why their data is never > fresh, and I see others on the web with the problem also. > > My mind is not currently made up which way is better, but I think we may > end up with less confused people if we would move to a default PULL > mode. On the other hand, maybe we just need to emphasize the point more > in the documentation. > > What do you all think? > > Best regards, > > Brad > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: Josh B. <jb...@bb...> - 2006-07-05 16:26:18
|
It's been a while since I used player so forgive my potentially na=EFve response. By PULL mode do you mean "polled"? Does the server need explicit confirmation/notification from the client before sending the next chunk = of data? If it is polled, then I would see a couple of reasons for not using it: 1. Could lock the execution of the server in sync with the client. 2. Data latency, if the client has to send a message to the server = before it receives the latest data this incurs an extra delay. A few alternatives: 1. Use an unreliable transport that doesn't fill up buffers but drops instead, unlike TCP. (May need to build an intermediate program to do = this intelligently) 2. Use a client controlled reporting rate: the client specifies the frequency of the reports (which it can adapt over time). This should throttle the server to a level that it can handle. Josh Bers Mobile Networking Systems BBN Technologies jb...@bb... ph. 617.873.4262 fax. 617.873.4523 www.bbn.com > -----Original Message----- > From: pla...@li... > [mailto:pla...@li...] On = Behalf Of > Brad Kratochvil > Sent: Tuesday, July 04, 2006 12:03 PM > To: pla...@li... > Subject: [Playerstage-developers] to push, or not to push >=20 > Hey all, >=20 > I just updated playerv to include a PULL mode from the server. We = were > experiencing problems on some of our slower machines w/ slower > connections when using playerv with lasers, maps, amcl, stage, etc. = If > the computer or connection wasn't fast enough we had data backing up = in > the pipe and playerv wasn't always fresh. >=20 > So, I decided to give playerv a go with a PULL mode. By running a > couple of simple tests, it looks as if using PULL with the above > mentioned devices is actually faster on my shiny new Optiplex than the > PUSH modes are. So, I have 2 questions... >=20 > Can somebody else check this out and determine if I'm just seeing > things? If it is faster for others, then I would like to consider > moving playerv to PULL mode by default. The code should be checked = into > CVS and you can use it with > playerv -pull 1 >=20 > Why is PUSH currently the default mode, and would anyone be interested > in changing it? The reason I ask is that our students that use player > here have all run into the problem of wondering why their data is = never > fresh, and I see others on the web with the problem also. >=20 > My mind is not currently made up which way is better, but I think we = may > end up with less confused people if we would move to a default PULL > mode. On the other hand, maybe we just need to emphasize the point = more > in the documentation. >=20 > What do you all think? >=20 > Best regards, >=20 > Brad >=20 > Using Tomcat but need to do more? Need to support web services, = security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo > = http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
From: Brian G. <br...@ge...> - 2006-07-05 18:31:19
|
On Jul 4, 2006, at 9:03 AM, Brad Kratochvil wrote: > I just updated playerv to include a PULL mode from the server. We > were > experiencing problems on some of our slower machines w/ slower > connections when using playerv with lasers, maps, amcl, stage, > etc. If > the computer or connection wasn't fast enough we had data backing > up in > the pipe and playerv wasn't always fresh. I think that PULL should definitely be the default for playerv. Since it's just visualizing data, there's no reason to require that it get every single packet. > So, I decided to give playerv a go with a PULL mode. By running a > couple of simple tests, it looks as if using PULL with the above > mentioned devices is actually faster on my shiny new Optiplex than the > PUSH modes are. So, I have 2 questions... What do you mean by "faster"? > Why is PUSH currently the default mode, and would anyone be interested > in changing it? The reason I ask is that our students that use player > here have all run into the problem of wondering why their data is > never > fresh, and I see others on the web with the problem also. As Toby mentioned, PUSH is the default pretty much for historical reasons. It ought to provide a lower-latency way to get data, assuming you service the data stream fast enough so that messages don't get backed up. On the other hand, since we moved away from the 10Hz delivery to asynchronous delivery, a lot of people have been seeing queue overflows and stale data. So I can see the argument for moving the default to PULL. brian. |
From: Brad K. <bkr...@et...> - 2006-07-06 06:44:35
|
Brian Gerkey wrote: > What do you mean by "faster"? It's not a terribly sophisticated test, but... I setup a simple stage simulation that uses a robot, map, amcl, and laser. Then, I connected w/ playerv in PUSH mode to all the devices and watched the overall processor usage of the system. I then repeated the same w/ the PULL mode. When looking at top, the two main processor hogs while running playerv were Xorg and playerv. Xorg playerv player PUSH 76% 46% 16-24% PULL 37% 21% 15-20% The reason it's over 100% in PUSH mode (I think) is that I'm running a SMP kernel, so it reports usage over both virtual processors. So, it looks like the server performance is similar in both, but playerv in PUSH mode uses up a bit of processor. Overall, it looks like playerv chews up quite a bit of processor when connecting to multiple devices. It may not hurt to look into that down the road. Best regards, Brad |