OSVR / OSVR-Core

The core libraries, applications, and plugins of the OSVR software platform.
Apache License 2.0
330 stars 124 forks source link

Intermittent failure to receive a path tree within the timeout #99

Open rpavlik opened 9 years ago

rpavlik commented 9 years ago

cc @russell-taylor since this might be VRPN-related.

The creation of a client context includes a startup "spin" where we wait, up to a fixed timeout (500ms or 1s at the moment, IIRC), to get an established VRPN connection and receive a path tree from the server. On some systems, we'll get a VRPN connection within that time, but won't get a path tree reliably within the timeout. (When we do get one, it comes quickly: on the order of 60ms)

Not sure the server setup for reproduction, besides that it does happen with an experimental server analysis plugin using the OSVR public APIs, and that it also happens with servers as shipping. For games, it's not typically an issue, since they will start calling update in their mainloop and when they get the tree eventually it will set up all interface objects and handlers correctly, but for apps like osvr_print_tree that basically just fire up the client for the express purpose of getting the path tree, it's problematic. osvr_print_tree is the easiest client to reproduce this with.

russell-taylor commented 9 years ago

I wonder if we're seeing a race between the connection start up and the ping request coming from the client. One odd thing to try is to put a vrpn_SleepMsecs(1) inside the spin-wait loop. I've seen that work better on some systems. It must be yielding to the kernel more often or something.

rpavlik commented 9 years ago

Here's the code doing the client startup - I thought I had committed a sleep in there, but apparently I just tested one locally and sent a DLL somewhere to test (which reportedly showed the same issue) https://github.com/OSVR/OSVR-Core/blob/master/src/osvr/Client/PureClientContext.cpp#L91

rpavlik commented 9 years ago

May be fixed by #240 (specifically, the queuing and deduplication of the hardware detection and path tree sending).